First, it should be called "Lookup" rather than "Get" because it returns
DataType (rather than UserDataType), but that would still be confusing,
since as opposed to other Lookup* methods, it does not return a DataType&
(and obviously, it can't). So "Extract" seems to be a better name, cf.
mozilla::Maybe::extract.
Differential Revision: https://phabricator.services.mozilla.com/D105471
It should be called "Get" rather than "Lookup" because it returns
UserDataType. "Add" is called "Insert" in the other methods.
Differential Revision: https://phabricator.services.mozilla.com/D105470
so that EnumerateDevicesImpl() callers don't need to care about this.
This also provides a SourceListener::Stop() call to fix a leak from the logic
in GetSinkDevice().
Differential Revision: https://phabricator.services.mozilla.com/D105252
This was already happening to some extent due to the recursive relationship of
SourceListener::Stop() and GetUserMediaWindowListener::Remove(), but being
direct about it saves a parameter.
Depends on D105248
Differential Revision: https://phabricator.services.mozilla.com/D105249
No code changes.
Build issues were found by renaming `MOZ_GECKO_PROFILER` to something else in toolkit/moz.configure, in both unified and non-unified builds, on all supported platforms.
Also updated some profiler-related comments.
Differential Revision: https://phabricator.services.mozilla.com/D105375
In a case where the packetizer is used and NotifyInputData receives less than a
full packet on the first notification, the first Pull of input data will not
happen during the same iteration.
During the iteration where the first Pull of input data happens, commonly the
following iteration, the appropriate amount of buffering will be calculated.
This calculation will fail to accomodate the silence added in the Pulls since
input data was added to the packetizer but where no input data was pulled.
Thus when input data is pulled we get more than expected out of the packetizer,
and this sets off an assert.
In practice on a non-debug build this patch means that latency is consistently
low (10ms + 128 frames with the packetizer, 128 frames without). Without this
patch it could be up to a packet (10ms) higher when using the packetizer.
Differential Revision: https://phabricator.services.mozilla.com/D105302
This adds 2 checks to deal with overflow related issues when parsing webms.
- Detect uint64 overflows when calculating buffered ranges. This is unlikely,
but appears like something that could conceptually happen given the data types
involved. This isn't strictly needed to fix the bug, but figured I'd guard
against it while I'm in the code.
- Detect issues from uint64 -> int64 conversion when calculating TimeUnits in
the WebM parser. This is needed to fix the bug, as while we do some checks
that start <= end, we were not guarding against this following TimeUnit
conversion. My understanding is we should never encounter negative TimeUnits
for the code in question, so the added check bails if any negative values are
encountered.
Differential Revision: https://phabricator.services.mozilla.com/D105506
This file tickles some asserts due to it containing fuzzed data that leads to
our WebM parser getting extremely large timestamps.
Differential Revision: https://phabricator.services.mozilla.com/D105505
In a case where the packetizer is used and NotifyInputData receives less than a
full packet on the first notification, the first Pull of input data will not
happen during the same iteration.
During the iteration where the first Pull of input data happens, commonly the
following iteration, the appropriate amount of buffering will be calculated.
This calculation will fail to accomodate the silence added in the Pulls since
input data was added to the packetizer but where no input data was pulled.
Thus when input data is pulled we get more than expected out of the packetizer,
and this sets off an assert.
In practice on a non-debug build this patch means that latency is consistently
low (10ms + 128 frames with the packetizer, 128 frames without). Without this
patch it could be up to a packet (10ms) higher when using the packetizer.
Differential Revision: https://phabricator.services.mozilla.com/D105302
For YUV 422 video, when we are sampling UV planes at half the resolution of the
Y plane, we can interpolate from 2 samples for the UV planes as an approximation
of the 4 samples, allowing us to better pack the math into SIMD vectors and
substantially reduce the number of multiplications.
Differential Revision: https://phabricator.services.mozilla.com/D105137
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
`nsSyncSection` is not related with media event, so that's not proper ot put it in `MediaElementEventRunners.h`.
In addition, that can simply be implemented by `NS_NewRunnableFunction` so we don't need `nsSyncSection` anymore.
Differential Revision: https://phabricator.services.mozilla.com/D104115
