The integer index we're replacing here is based on the order in which
transceivers were added. If we clone the JSEP engine for an sRD that happens to
result in the creation of a transceiver, and at the same time JS calls
addTransceiver, we have a situation where the sRD transceiver is added first
to the cloned JSEP engine, but the addTransceiver transceiver is added first
to the old JSEP engine, resulting in them having the same index. So, let's just
use a proper key for this stuff.
Differential Revision: https://phabricator.services.mozilla.com/D150169
Run `./mach vendor media/libdav1d/moz.yaml` to get the latest dav1d
version and update the revision number in moz.yaml.
According to the changes in *third_party/dav1d/src/meson.build*, the
*media/libdav1d/asm/moz.build* is updated as follows:
- Remove *{arm,x86}/refmvs_init.c*
- Remove *{arm,x86}/cdef_init_tmpl.c*
- Remove *{arm,x86}/filmgrain_init_tmpl.c*
- Remove *{arm,x86}/ipred_init_tmpl.c*
- Remove *{arm,x86}/itx_init_tmpl.c*
- Remove *{arm,x86}/loopfilter_init_tmpl.c*
- Remove *{arm,x86}/looprestoration_init_tmpl.c*
- Remove *{arm,x86}/mc_init_tmpl.c*
- Remove *x86/msac_init.c*
- Add *x86/cdef16_avx512.asm*
- Add *x86/loopfilter16_avx512.asm*
Differential Revision: https://phabricator.services.mozilla.com/D152335
Run `./mach vendor media/libvpx/moz.yaml --patch-mode=none` as what
media/libvpx/README_MOZILLA said.
The update libvpx revision is 168b312774166958897f727196a59ee8ad423e78.
Differential Revision: https://phabricator.services.mozilla.com/D151868
The patches for *.mk files should be applied before running
`generate_sources_mozbuild` since the files in the generated .mozbuild
is based on the files listed in the *.mk
Depends on D150207
Differential Revision: https://phabricator.services.mozilla.com/D150208
The latest version (v1.12.0-rc1) of the libvpx [1] adds some
optimizations with LSX instructions for loongson architecture [2], which
has same name files *quantize_lsx.c* in both vp8/encoder/loongarch and
vpx_dsp/loongarch directories, and so the `find_duplicates` check fails
in *generate_sources_mozbuild.sh*
To avoid the above failure, *quantize_lsx.c* under *loongarch* is
renamed to *quantize_intrin_lsx.c*.
[1] https://chromium.googlesource.com/webm/libvpx/
[2] https://bugs.chromium.org/p/webm/issues/detail?id=1755
Differential Revision: https://phabricator.services.mozilla.com/D150207
In future parts, TaskQueue will require extra initialization to be performed
which cannot happen in a constructor, as it takes references to the TaskQueue
object itself, which will require the introduction of a helper method. This
patch switches all callers of the TaskQueue constructor to use the new method.
Differential Revision: https://phabricator.services.mozilla.com/D142604
0 is a valid limit in setParameters according to the spec. For now, we treat
max-fr=0 in SDP as no limit, since that is what we have been doing.
Differential Revision: https://phabricator.services.mozilla.com/D144009
media/gmp-clearkey/0.1/WMFH264Decoder.cpp(145,24): error: possible misuse of comma operator here [-Werror,-Wcomma]
while (type = nullptr,
^
media/gmp-clearkey/0.1/WMFH264Decoder.cpp(145,10): note: cast expression to void to silence warning
while (type = nullptr,
^~~~~~~~~~~~~~
static_cast<void>( )
Differential Revision: https://phabricator.services.mozilla.com/D144641
This makes some ./mach vendor improvements needed:
- Adds a replace-in-file-regex action
- Allows you to skip copying the temporary extract directory
so that a script can do it
- Removes 'commit' from the look-in-moz.yaml-for-release match
Differential Revision: https://phabricator.services.mozilla.com/D142720
This change does a few things
- Moves get_full_path from a function-local function to
a class member
- Makes yaml_file a class member so I don't need to pass
it everywhere
- Creates a new moz.yaml file directive 'generated'
- Adds that directive to libdav1d
- Detects if any files (other than generated ones) were
modified by an update; and if not - do not update the
moz.yaml. Exit with -2 so Updatebot can detect it.
Differential Revision: https://phabricator.services.mozilla.com/D141994
This ability to set the main thread has never been used, and in many cases is
not possible due to things being cycle collected (and therefore
main-thread-only).
Differential Revision: https://phabricator.services.mozilla.com/D142382
Pick commits:
d97fea4 - Switch device only when the users don't specifiy a particular device (#697)
bdf2837 - Don't reset device if DISABLE_DEVICE_SWITCHING is set
2f50db3 - Fire error callback when reinit fails
4bca265 - Make sure input latency is larger than zero
2d64fff - Return matched device from wasapi_find_bt_handsfree_output_device
f9927c4 - Rename function
8a3d20b - highlight type cast
342ff3c - Avoid duplicate GetDevicePeriod call
d292915 - Call wasapi_create_device only when necessary
016e72e - Don't reset input_bluetooth_handsfree when setting output
86210a1 - Group related lines
1e13faa - Get default_period only when we need it
Differential Revision: https://phabricator.services.mozilla.com/D142365
This addresses the original intent of the bug report which asks for allowing
sndio to be built on more than just OpenBSD. In addition of modifying the
existing --enable-sndio to support this request, the option
--enable-audio-backends was added which takes a list of possible backends to
support per discussion in the bug report.
For example specifying --enable-audio-backends=alsa,jack,pulseaudio,sndio
allows for runtime selection of those four cubeb backends. If all four backends
are available the user can specify `media.cubeb.backend` in `about:config` to
force a specific backend.
Removed superfluous set_define()s as libcubeb's moz.build does the necessary
`DEFINES['...']` assignments for each backend.
In addition logic for finer control of audio backend selection on Android was
added. One can now specify aaudio, opensl or both (which is the default).
Differential Revision: https://phabricator.services.mozilla.com/D141450
This addresses the original intent of the bug report which asks for allowing
sndio to be built on more than just OpenBSD. In addition of modifying the
existing --enable-sndio to support this request, the option
--enable-audio-backends was added which takes a list of possible backends to
support per discussion in the bug report.
For example specifying --enable-audio-backends=alsa,jack,pulseaudio,sndio
allows for runtime selection of those four cubeb backends. If all four backends
are available the user can specify `media.cubeb.backend` in `about:config` to
force a specific backend.
***
Bug 1351378 - Address linter error. r?mhentges,glandium
***
Bug 1351378 - Remove superfluous set_define(). r?mhentges,glandium
libcubeb's moz.build does the necessary `DEFINES['...']` assignments for each
backend. Remove superfluous set_define().
Differential Revision: https://phabricator.services.mozilla.com/D141450
TaskQueueWrapper is used in two ways:
- Through the ref-counted CallWorkerThread, which is, well, ref-counted, and
passed around gecko as an AbstractThread. The lifetime of this task queue is
managed by the ref-count and it may be deleted on any thread (bug 1748333...).
- Through the TaskQueueFactory for libwebrtc's internal use. libwebrtc manages
the lifetime of these task queues explicitly, and does not delete them on the
task queue itself.
This patch adds a DeletionPolicy template parameter to TaskQueueWrapper to put
flag up front whether a TaskQueueWrapper will block shutdown or not.
For the former case above we use DeletionPolicy::NonBlocking and for the latter
DeletionPolicy::Blocking.
Differential Revision: https://phabricator.services.mozilla.com/D137292
Used to be built into CreateIceCtx, but needed to be stand-alone so it
could be called subsequently. Necessitated adding some members so pref-based
config state could be saved for later use.
Differential Revision: https://phabricator.services.mozilla.com/D135365
Used to be built into CreateIceCtx, but needed to be stand-alone so it
could be called subsequently. Necessitated adding some members so pref-based
config state could be saved for later use.
Differential Revision: https://phabricator.services.mozilla.com/D135365
TaskQueueWrapper is used in two ways:
- Through the ref-counted CallWorkerThread, which is, well, ref-counted, and
passed around gecko as an AbstractThread. The lifetime of this task queue is
managed by the ref-count and it may be deleted on any thread (bug 1748333...).
- Through the TaskQueueFactory for libwebrtc's internal use. libwebrtc manages
the lifetime of these task queues explicitly, and does not delete them on the
task queue itself.
This patch adds a DeletionPolicy template parameter to TaskQueueWrapper to put
flag up front whether a TaskQueueWrapper will block shutdown or not.
For the former case above we use DeletionPolicy::NonBlocking and for the latter
DeletionPolicy::Blocking.
Differential Revision: https://phabricator.services.mozilla.com/D137292
The Runnable markers in the profilers are handy, but miss many types of
runnables. This includes most of those that wrap another runnable and run that
at a (possibly) later time.
AbstractThread, TaskDispatcher and TaskQueue does this for e.g. tail dispatched
tasks.
TaskQueueWrapper does this when wrapping webrtc tasks (and Mozilla Runnables) to
be run in a Mozilla TaskQueue with some overhead on the stack.
DelayedRunnable wraps a runnable to be run after a timeout.
It would perhaps be better in many cases to ignore the intermediate runnables,
but I haven't seen a straight forward way to achieve this.
More detailed data could be added on a case by case basis, for instance the
delay for a DelayedRunnable (incl. actual vs. target delay) or the scope of a
task in which a tail-dispatched runnable was dispatched. But this is also true
for the status quo (for instance the time from dispatch to run) so I leave these
ideas as future work.
Differential Revision: https://phabricator.services.mozilla.com/D135027
The Runnable markers in the profilers are handy, but miss many types of
runnables. This includes most of those that wrap another runnable and run that
at a (possibly) later time.
AbstractThread, TaskDispatcher and TaskQueue does this for e.g. tail dispatched
tasks.
TaskQueueWrapper does this when wrapping webrtc tasks (and Mozilla Runnables) to
be run in a Mozilla TaskQueue with some overhead on the stack.
DelayedRunnable wraps a runnable to be run after a timeout.
It would perhaps be better in many cases to ignore the intermediate runnables,
but I haven't seen a straight forward way to achieve this.
More detailed data could be added on a case by case basis, for instance the
delay for a DelayedRunnable (incl. actual vs. target delay) or the scope of a
task in which a tail-dispatched runnable was dispatched. But this is also true
for the status quo (for instance the time from dispatch to run) so I leave these
ideas as future work.
Differential Revision: https://phabricator.services.mozilla.com/D135027
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
This is required to build the midir crate on Linux. The Dockerfile change is
needed to run the just built xpcshell executable on the build host.
Differential Revision: https://phabricator.services.mozilla.com/D124641
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
This is prohibited for regular TaskQueueWrappers, as Delete must join (i.e.
block) the thread after initiating shutdown. But MainAsCurrent is special as
main thread doesn't go away just because MainAsCurrent goes away. It is also
gtest-only, and thus tightly coupled with MediaPipelineTest behavior.
Differential Revision: https://phabricator.services.mozilla.com/D132221
...rather than by unsetting the old remote ssrc on all other conduits that
already have it set.
With this patch we don't risk re-entrancy into UnsetRemoteSSRC (CallWrapper,
VideoConduit) or SetRemoteSSRCConfig (VideoConduit).
Differential Revision: https://phabricator.services.mozilla.com/D130270
...rather than by unsetting the old remote ssrc on all other conduits that
already have it set.
With this patch we don't risk re-entrancy into UnsetRemoteSSRC (CallWrapper,
VideoConduit) or SetRemoteSSRCConfig (VideoConduit).
Differential Revision: https://phabricator.services.mozilla.com/D130270
Other than compiler a bit more code this should have no functional effect, we're setting the values to their default values we had before.
Differential Revision: https://phabricator.services.mozilla.com/D130021
We don't enable PNG_WRITE_FILTER_SUPPORTED that means that do_filter field on the png_struct will always be zero (it's initialized to 0, and any calls to png_set_filter will error out unless the result is setting it to 0 https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/media/libpng/pngwrite.c#1032 ).
Then this code in png_write_IHDR https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/media/libpng/pngwutil.c#829 will execute and set do_filter to PNG_ALL_FILTERS for non-paletted images with >=8 bit depth.
This this code https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/media/libpng/pngwutil.c#339 will execute and set our zlib strategy to PNG_Z_DEFAULT_STRATEGY (as opposed to PNG_Z_DEFAULT_NOFILTER_STRATEGY). PNG_Z_DEFAULT_STRATEGY is also known as Z_FILTERED inside of zlib.
From here https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/modules/zlib/src/zlib.h#589 that means: "Z_FILTERED for data produced by a filter (or predictor) ... Filtered data consists mostly of small values with a somewhat random distribution."
So that is not what we want to our non-filtered image data.
Switching this so that we use PNG_Z_DEFAULT_NOFILTER_STRATEGY improves both the compression and speed. The following is the avg time taken for toDataURL with a canvas containing 3 different images, and dataURL.length.
Z_FILTERED
very simple line art
49.7ms
17618
"very png compressable image from bug 1724331"
60.8ms
192214
a photo
241.3ms
4193966
Z_DEFAULT_STRATEGY
very simple line art
52.2ms
17590
"very png compressable image from bug 1724331"
61.2ms
186182
a photo
213ms
3555170
All images are smaller with Z_DEFAULT_STRATEGY, the photo being 15% smaller. The two compressable images are perhaps very slightly slower, but the large photo is 12% faster.
For bug 1724331 I want to turn on PNG_WRITE_FILTER_SUPPORTED, and this means we avoid this bug because do_filter gets set to PNG_FILTER_NONE which is not equal to PNG_NO_FILTERS (which is a bit confusing). Avoiding his bug means our png encoder produces different output and we have a couple of tests that check against the exact output of the pngencoder that need to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D130019