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
An alternative approach would be to merge max_fs with maxWidth*maxHeight and let
the VideoAdapter decide on the resolution entirely. Then the logic could have
stayed in place.
But the VideoAdapter has another algorithm for finding the ideal resolution,
which for the unittest for this feature selects 960x640 rather than 1080x720.
This moves the checking so we can keep using the same logic as before.
This also enables a disabled test so we have test coverage of these parameters.
Differential Revision: https://phabricator.services.mozilla.com/D105778
The main point of this patch is to harden how conduits handle configuration
changes. With conduit controller classes acting in a layer on top of conduits
(and their old sync style APIs), for instance
`mTransmitting = true; mTransmitting = false;` on the control thread gets
elided and cannot be used as a mean of applying configuration changes in the way
`StartTransmitting(); ChangeConfig(); StopTransmitting();` could.
This patch removes the conduit controller classes, instead moving their mirrors
directly into the conduits. This allows for one larger "ConfigChanged" method
which can apply all the config changes while being aware of the state of the
conduit.
This patch effectively moves from setters to mirrors.
Unittests are updated to work with the new async structure. They're only on main
thread, but updates still happen async. Some helpers ensure that state changes
and direct (tail dispatched) tasks run in a for the tests sync fashion.
Differential Revision: https://phabricator.services.mozilla.com/D123222
SharedWebrtcState when managed by PeerConnectionCtx is destroyed on main thread.
With interactions with call instances being async, there is no guarantee that
the objects owned by SharedWebrtcState (and referenced through raw pointers by
Call instances) are alive until all Call instances have been destroyed.
Making the WebrtcCallWrapper keep a strong-ref to the SharedWebrtcState will
ensure it can manage the lifetime of the SharedWebrtcState for as long as
necessary.
Differential Revision: https://phabricator.services.mozilla.com/D112857
This patch mainly sets the stage for using codec configs with StateMirroring.
It also makes the code a bit simpler, and removes the need to handle the nullptr
case.
Differential Revision: https://phabricator.services.mozilla.com/D112855
On its own this patch should mainly be seen as a refactor of the way we handle
races in MediaPipelineTransmit::SetTrack. Namely that Stop() immediately
followed by SetTrack was exposed to racing prior to this patch.
This patch makes MediaPipelines use a WatchManager to manage their tracks.
For receive pipelines, mActive triggers whether we enable the receive listener.
For transmit pipelines, mActive and mDomTrack triggers whether mDomTrack's
underlying track is hooked up to feed data to the conduit. A hole is also
punched through this allowing for unittests to set an overriden send track
to avoid mocking a MediaStreamTrack (DOM object) and MediaTrackGraph (several
non-virtual methods we'd need to override).
This patch also moves the responsibility of starting and stopping conduits to
the transceiver/receiver objects, where most of the interaction with the
conduits is already happening.
Differential Revision: https://phabricator.services.mozilla.com/D112854
This patch makes mediapipeline_unittest pass an event target to the Call wrapper
but keeps using main thread for that event target, so that it can keep the test
cases simpler by allowing sybnc calls into the conduits.
TaskQueueWrapper::MainAsCurrent is no longer needed as mediapipeline_unittest
was the last user of it. A simpler version remains dedicated in
mediapipeline_unittest instead.
Differential Revision: https://phabricator.services.mozilla.com/D112853
Ideally TaskQueueWrapper would implement both webrtc::TaskQueueBase and
AbstractThread, but webrtc::TaskQueueBase is not refcounted so implementing both
in the same class is not possible.
This patch implements AbstractThread in a refcounted class CallWorkerThread on
top of TaskQueueWrapper. Because of SharedModuleThread not having a thread-safe
refcount, the same CallWorkerThread must be used for all Call instances.
PeerConnectionCtx's SharedWebrtcState becomes the canonical owner of the
CallWorkerThread, but WebrtcCallWrappers will all hold a strong reference to it.
The new AbstractThread allows us to use webrtc TaskQueues with Mozilla
specific higher order threading functions, like MozPromise, MediaEventSource,
and whatever else could come in handy, without having to use an explicit
CurrentTaskQueueSetter (which is not public) everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D112844
The cache can be a lot simpler than the old one, since libwebrtc handles
pruning old entries for us, and since we're now telling libwebrtc when we
render frames (so we don't have to make our own stats with guesses of when
frames will be rendered). We also now have a single implementation of the
cache in the base class.
This patch also removes the old CSRC stat insertion stuff we hacked into
libwebrtc for testing, and handles that stuff in our cache directly.
Differential Revision: https://phabricator.services.mozilla.com/D108669
This patch changes the meaning of the target architecture to mean what it nominally should according to the gn documentation. I question as to if this could be upstreamed, but it may be worth a shot. If we do choose to pursue that. There are several other smaller patches that tackle individual instances, that this could be combined with.
Differential Revision: https://phabricator.services.mozilla.com/D119707
Peer connections are cleaned up on shutdown through an xpcom-shutdown observer.
It doesn't block shutdown throughout async operations.
webrtc::Call instances are currently used on the main thread and so destroying
them could be a sync operation. However with upcoming threading model changes
they are moving to a worker thread, making destruction of them inevitably async.
Currently they are even destroyed async, even though still on the main thread,
to better simulate the behavior we'd see with the threading model updated.
Destroying Call instances async can lead to a race between destroying all
TaskQueues tied to the Call instance, and reaching xpcom-shutdown-threads.
xpcom-shutdown-threads will shut down the thread pools backing the TaskQueues,
making future dispatches fail. We have asserts checking that dispatches always
succeed.
This patch adds a ShutdownBlocker to the Call wrapper, so progressing to
xpcom-shutdown-threads is blocked until Call instances are cleaned up and no
more dispatches are expected.
Differential Revision: https://phabricator.services.mozilla.com/D105770
Prior to this patch, WebRtcCallWrapper would never clear the call instance,
meaning that it went away as the classes having references to WebRtcCallWrapper
also went away. These are mainly TransceiverImpl and PeerConnectionMedia. There
are other classes too, but these are the ones that have a strong-ref to
WebRtcCallWrapper *and* are cycle collected.
With the worker threads in libwebrtc now using our own TaskQueues on top of
our SharedThreadPool instances, the ownership model of the Call instances
becomes problematic.
On shutdown, xpcom-shutdown-threads happens before the cycle collector is shut
down.
xpcom-shutdown-threads will however, block shutdown until all SharedThreadPools
have been shut down.
If a TransceiverImpl sits around until shutdown it **will** only be destroyed
during cycle collector shutdown. And, alas, we reach a deadlock as we're stuck
in xpcom-shutdown-threads until that TransceiverImpl gets destroyed.
This patch decouples the Call instance lifetime from the cycle collector, and
avoids the shutdown hang.
Differential Revision: https://phabricator.services.mozilla.com/D103496
This sets up our code for creating Call instances so that it works. A number of
things are left to do. Most notable fixing the threading model.
Until that is fixed we use main thread as a "worker" but this is not ideal.
It both leads to excessive work loads on main, and us having to set main as
"current" (using upstream's API for this) whenever we call into main from what
is meant to be the worker thread.
Differential Revision: https://phabricator.services.mozilla.com/D102285
Upstream's implementation for rid and mid assumes they are always present but
the current code in MediaPipelineFilter had them optional. We need to double
check which way it should be.
Differential Revision: https://phabricator.services.mozilla.com/D130073
This is a fairly significant update, so required a few changes to Gecko code, but I've commented on the interesting details, so they should be easy to find
Differential Revision: https://phabricator.services.mozilla.com/D129465
This patch:
- moves the AutoNestedEventLoopAnnotation into SpinEventLoopUntil.h
- introduces the motivated SpinEventLoopUntil
- maps remaining SpinEventLoopUntil instances to SpinEventLoopUntil with "Missing motivation."
- changes relevant uses in nsThread and nsThreadManager to the motivated SpinEventLoopUntil
- changes all uses with IgnoreAndContinue behavior to the motivated SpinEventLoopUntil
Differential Revision: https://phabricator.services.mozilla.com/D126714
This patch:
- moves the AutoNestedEventLoopAnnotation into SpinEventLoopUntil.h
- introduces the motivated SpinEventLoopUntil
- maps remaining SpinEventLoopUntil instances to SpinEventLoopUntil with "Missing motivation."
- changes relevant uses in nsThread and nsThreadManager to the motivated SpinEventLoopUntil
- changes all uses with IgnoreAndContinue behavior to the motivated SpinEventLoopUntil
Differential Revision: https://phabricator.services.mozilla.com/D126714
I was checking if the caller was 'log' but that wasn't correct
because we pass the result of the function to log, we don't call
it from log
Differential Revision: https://phabricator.services.mozilla.com/D124939
I was checking if the caller was 'log' but that wasn't correct
because we pass the result of the function to log, we don't call
it from log
Differential Revision: https://phabricator.services.mozilla.com/D124939
media/libjpeg/1050342.diff is no longer necessary and a correction
appears to have been made in the library. Chromium no longer uses this
patch either.
media/libjpeg/assembly-tables.diff and media/libjpeg/externalize-table.diff
require significant changes in order to apply. This may be done in a
future followup patch, but is deemed less important than updating
libjpeg-turbo.
With these patches, an update to libjpeg-turbo 2.1.1 should apply
cleanly and build.
Differential Revision: https://phabricator.services.mozilla.com/D125458
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
Reorder includes to match Google C++ style. The follow decisions were made to
resolve ambiguities.
- The pssh parser and clearkey are considered part of mozilla-central/Gecko and
so have their includes grouped into the 'your project' includes at the end of
includes. I.e. they're grouped with other mozilla-central headers.
- NSS and the CDM headers are considered as coming from other libs, so are
placed in a block preceding the mozilla-central's.
I think everything else is decided by using the style guide and by Mozilla using
case sensitive sorting.
This also changes a few instances of using "systemheader.h" to <systemheader.h>,
which is more in line with the style guide.
Differential Revision: https://phabricator.services.mozilla.com/D123230
This implements logic in the clear key CDM to emulate protection queries. The
CDM will only do so if configured using the new test key system added prior to
this patch.
Differential Revision: https://phabricator.services.mozilla.com/D122633
This lets the clear key CDM behave differently if it's created with the
protection query key system. The different behaviour will be implemented in
following patches and gated behind the member set here.
Differential Revision: https://phabricator.services.mozilla.com/D122632
Updatebot
Byron Campen
Chun-Min Chang
Butkovits Atila
Paul Adenot
Tom Ritter
Andi-Bogdan Postelnicu
Matthew Gregan
Sebastian Hengst
Bogdan Szekely
David Shin
Nico Grunbaum
Iulian Moraru
serge-sans-paille
Mike Hommey
Ryan VanderMeulen
Kagami Sascha Rosylight
Nika Layzell
Johann
Cosmin Sabou
Nordin Abouzahra
Timur Valeev
june wilde
Randell Jesup
Noemi Erli
Jon Bauman
Norisz Fay
Andrew Osmond
Nils Ohlmeier
Andreas Pehrson
Cristian Tuns
Andreea Pavel
Marian-Vasile Laza
stransky
Gabriele Svelto
Alexandru Michis
Chris Peterson
Sylvestre Ledru
Ulrich-Matthias Schäfer
Narcis Beleuzu
Timothy Nikkel
Dan Minor
criss
Jens Stutte
Bryce Seager van Dyk