Rust's std::sync::Mutex has some nice properties. Its philosphy is to lock
data, rather than code.
It wraps data you're trying to make thread safe with a mutex, and in order to
get a reference to the wrapped data you need to lock the mutex and access it
through an intermediate layer. This is good, as the mutex that's protecting
access to the data is explicitly associated with the data, and it's impossible
to forget to take the lock before accessing the data.
This patch adds a similar mutex wrapper to Media Playback code. If it works
well, we can look at moving it into xpcom.
MozReview-Commit-ID: 4APAic6Fh8m
--HG--
extra : rebase_source : 3dc2b4916d3fd31f622af2b0c26ac3c0707d3300
Mostly-mechanical additions:
- Log constructions&destructions, usually by just inheriting from
DecoderDoctorLifeLogger, otherwise with explicit log commands (for internal
classes for which DecoderDoctorTraits can't be specialized),
- Log links between most objects, e.g.: Media element -> decoder -> state
machine -> reader -> demuxer -> resource, etc.
And logging some important properties and events (JS events, duration change,
frames being decoded, etc.)
More will be added later on, from just converting MOZ_LOGs, and as needed.
MozReview-Commit-ID: KgNhHSz35t0
--HG--
extra : rebase_source : dd7206e350e32671adc6f3b9e54ebf777251de2c
We remove the instantiation of EMEVideoDecoder and GMPCDMProxy in Part1. Just delete it and its h/cpp from moz.build
MozReview-Commit-ID: 8kGQK967pR0
--HG--
extra : rebase_source : 77750e6a92e6b649c41e7a8f769fa14c810e8e18
1. Delete MediaPrefs::EMEChromiumAPIEnabled() and related logic.
2. We now only use the Chromium CDM interface so delete the opposite side check of MediaPrefs::EMEChromiumAPIEnabled().
MozReview-Commit-ID: GDFrrf4WlWf
--HG--
extra : rebase_source : 987667dd47757afd58e7da10b60c0e1e1ec89d39
Replace it with NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION, because it
has been the same for a while.
MozReview-Commit-ID: 5agRGFyUry1
--HG--
extra : rebase_source : 5388c56b2f6905c6ef969150f0c5b77bf247624d
As per Bug 1355252, the EME spec requires our
navigator.requestMediaKeySystemAccess() function to reject request for
configurations which don't contain at least one MediaKeySystemCapabilities
(audioCapabilities or videoCapabilities).
That's step 15 of this algorithm:
https://w3c.github.io/encrypted-media/#get-supported-configuration-and-consent
We also shouldn't be assuming that WebM and MP4 normatively imply a specific
set of codecs and codec constraints, as that violates step 10 of the "Get
Supported Capabilities for Audio/Video Type" algorithm.
https://w3c.github.io/encrypted-media/#get-supported-capabilities-for-audio-video-type
Making this change has the effect of causing us to reject configurations with
MediaKeySystemCapabilities where those capabilities don't specify a codec
string.
This patch adds a deprecation warning to encourage authors to make their sites
spec compliant.
MozReview-Commit-ID: 6kM9LATDfy6
--HG--
extra : rebase_source : 96763bd49cbebb81ac565a8862cb0ad97838181f
extra : source : 9df49a410082d68041377dabbbebfb458a580041
This makes it easier to tell what's going on; whether we've created a
MediaKeySystemConfiguration which can persist state.
MozReview-Commit-ID: L4dbmMVYhsM
--HG--
extra : rebase_source : e47e60f5091b6b5477b2c8bd63ba408922706082
This will enable us to re-use the logging code in MediaKeySystemAccess to log
the configuration we end up instantiating the MediaKeySystemAccess with.
MozReview-Commit-ID: AMnauhMLJ1R
--HG--
extra : rebase_source : a2dfeb7b263108ac1c60bfe2f47755e0a73d6324
We want requests for MediaKeySystemAccess with persistentState to be rejected
if the window is in Private Browsing mode. This is primarily so that users in
Private Browsing mode don't unknowningly use up their "device limits"; some DRM
streamers have limits on the numbers of unique devices that can be
provisioned/used in a given time period, and the device ID is persisted in the
persistent state. So if we're flushing that state, the user will use up one of
their device quota on every new session, and quickly hit their limit, and be
unable to continue watching DRM video.
MozReview-Commit-ID: JWNO1kcU2ST
--HG--
extra : rebase_source : ad4e22629acfdd82aff8ead764949939726adbf4
Step 10 of EME's "Get Supported Capabilities for Audio/Video Type" algorithm
says we can assume default codecs only if a container normatively implies a
specific set of codec and codec constraints. Our code assumes that WebM implies
Vorbis/VP8 and MP4 implies AAC/H.264, but those aren't actually normatively
required by either of these containers' specifications. So we shouldn't assume
these containers imply those codecs.
MozReview-Commit-ID: G9TDOmrjhpp
--HG--
extra : rebase_source : 2f040d76c8cb240359401fe1dc1e3eefa029d77b
Sebastian Hengst
Tristan Bourvon
Nathan Froyd
Boris Zbarsky
Daniel Holbert
Videet
Chris Pearce
Gerald Squelart
Jon Coppeard
James Cheng
Kris Maglione
Chris Peterson
Phil Ringnalda
Andrew McCreight
Carsten "Tomcat" Book
Bill McCloskey
Masatoshi Kimura