I've repeated myself a few times, so make a helper to make determining which
GMPs are available easier.
MozReview-Commit-ID: 2fFLeaA5o8u
--HG--
extra : rebase_source : 74ea0b429d339273535610df3bbd7fec7beae469
We don't need this, and we don't seem to be using this anyway.
MozReview-Commit-ID: 7NCRO94PN3m
--HG--
extra : rebase_source : de91b099e5e536eb321584990f18025e08c7cc78
These are done in the GMPProvider, so it's unnecessary to do them again inside
Gecko. Plus, they cause main thread synchronous IPC in multi-process Firefox.
MozReview-Commit-ID: EcG38i3b2Oh
--HG--
extra : rebase_source : 37dffa797be13913131efb0019fd2e32c21b1fb6
This removes the ability for ClearKey to instantiate persistent-license
sessions using the EME APIs.
MozReview-Commit-ID: FXj5YORxpas
--HG--
extra : source : b69b2435f1059a5c7b1dd26947ea500b381ec7f0
We don't need to call MediaKeys::ConnectPendingPromiseIdWithToken() on the
MediaKeySession::Load() path, we already know the session Id, and we've already
removed the session from the list of pending sessions in Load().
MozReview-Commit-ID: KBiEsY95Csi
--HG--
extra : rebase_source : aadc3204409df35e4bbcb9532c530f860681afd1
We are required to do this by the draft EME spec.
MozReview-Commit-ID: FnIEFgVId1z
--HG--
extra : rebase_source : 23042d3acda6cfcb379db457224d648dc955f688
Now that we can link gmp-clearkey's PSSH parser into Gecko, we can
simply use that inside MediaKeySession to validate that the CENC
init data matches the spec.
This change enforces that CENC init data uses the common system Id.
As far as I can tell, Widevine only uses that now.
MozReview-Commit-ID: HrlKQHcv5DI
--HG--
extra : source : f61138f1030e87026eb432e83d36e46c81e55b33
Use a WebIDL dict to define the "keyids" EME init data format, and
then use that to parse and validate incomint "keyids" EME init data
and ensure it's in the expected JSON format, i.e.:
https://w3c.github.io/encrypted-media/format-registry/initdata/keyids.html
This means we now pass the "generateRequest() with too short key ID."
case of encrypted-media-generate-request-disallowed-input.html
(upstream that is, our local copy of that WPT is out of sync).
MozReview-Commit-ID: 6W7j2a9Bg7E
--HG--
extra : source : fed2a26df89a5c2a600a6e6d1ab63ab86706fc45
Implement more of MediaKeySession.generateRequest() to validate initData before
passing to CDM.
Also throw TypeErrors when initData is not valid, as per the spec.
Only trivial validation happens here, I'll add more comprehensive validation in
subsequent patches.
MozReview-Commit-ID: 3jTOsJNvRDo
--HG--
extra : source : d023aec75d1ef1486116510efcc31e2b587e6e50
This allows us to track how often EME CDMs are used, rather than just created.
The telemetry I added in bug 1304207 is reports whenever a CDM is created, but
some sites, such as the Shaka Player demo site, create CDMs without using them,
so that telemetry isn't a great measure in helping us detect when CDMs aren't
being used. Whereas the telemetry added here will report when the CDMs are used
to negotiate a license, i.e. when the CDMs are actually being used.
MozReview-Commit-ID: ExMIcIIBvS1
Add opt-out telemetry probe to track which EME CDMs are being instantiated.
This will enable us to determine when it's safe to remove the Adobe CDM.
MozReview-Commit-ID: iEPSTk7UtP
--HG--
extra : rebase_source : fb51d77f4c15fe2d9ef0adf3c87f6125bb758b9c
This is a follow up from bug 1289623, as I missed a few cases in that bug.
MozReview-Commit-ID: DM7FtVSZUo3
--HG--
extra : rebase_source : 4fd7ae93b1418ded54f0c21a50a654fc962d4892
The spec requires the MediaKeyStatusMap.get(keyId) function to return an 'any'
type, which is undefined for known keys, or a MediaKeyStatus enum value for
known keys.
https://w3c.github.io/encrypted-media/#idl-def-mediakeystatusmap
MozReview-Commit-ID: 3TOFYLacZSc
--HG--
extra : rebase_source : cd067f545cdbd9352ba64fea914128201b458d9c
Update handling of VP8, VP9 to enable decryption and decoding via widevine.
Update handling with further validation to make sure that invalid video types
are rejected when trying to create widevine decryptor session or init widevine
decoders.
MozReview-Commit-ID: 8FOvUJfxr6L
--HG--
extra : rebase_source : 0f6aed8256d7f106a598b09e6f11efe80f0e4bb2
This ensures we'll only retry requests if we know the install operation has
completed for a given GMP. This means if (say) OpenH264 happens to install
while we have a Widevine request pending, we won't retry the Widevine request,
as that would fail. The Widevine request will retry once the Widevine CDM
has downloaded and in turn fires its gmp-changed notification.
MozReview-Commit-ID: E3CV9uID4pS
--HG--
extra : rebase_source : 4e27210a9e6c28118e93f45846b63aaa64f5882d
We're already routing the "gmp-changed" observer service notification over from
the chrome process to the content process, and it fires at pretty much the same
time as the "gmp-path-added" notification (and a few more) so we can just switch
to have the MediaKeySystemAccessManager listen on that notification instead, and
we'll be e10s compatible.
MozReview-Commit-ID: EowFDfdWgAJ
--HG--
extra : rebase_source : ad01990278cf9005f6676ef0b7fa0acbf69249eb
We're supposed to reject MediaKeySystemCapabilities which have a contentType
that has codecs which don't match their major type, i.e. audio codecs in a
video container type.
I missed that, and it's causing us to fail the
test_eme_requestMediaKeySystemAccess case "MP4 video container with both audio
and video codec type in videoType".
MozReview-Commit-ID: KQVGk9hX3eC
--HG--
extra : rebase_source : f8ed145d050bb27f2f6867ec4b308bbcd30d17a5
We're supposed to reject MediaKeySystemCapabilities which have a contentType
that has codecs which don't match their major type, i.e. audio codecs in a
video container type.
I missed that, and it's causing us to fail the
test_eme_requestMediaKeySystemAccess case "MP4 video container with both audio
and video codec type in videoType".
MozReview-Commit-ID: KQVGk9hX3eC
--HG--
extra : rebase_source : b64919e71128b0cd3a1129af56f915ffa5d2025b
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
So if a GMP crashes while doing EME, we'll get a crash report using the new
mechanism.
MozReview-Commit-ID: G8BlFI9jmiF
--HG--
extra : rebase_source : 1cda5c93ea9e547636b34ec2149ef9cd2506ca73
This enables callers to specify a way to determine the correct window to
dispatch the PluginCrashed event to should the GMP actor crash.
We need a way to determine the correct window at crash time, as the GMP's
window can change at runtime. For example, if the GMP is being used for
unencrypted decoding, the <video> element can be moved to a new browser window
at runtime.
Note: I don't handle disconnecting the GMPCrashHandlers in this patch; we do
delete the GMPCrashHandlers in this patch when their associated GMP crashes, and
in the next patch we handle disconnecting GMPCrashHandlers in the case where
we don't crash.
MozReview-Commit-ID: DrwcZAB6Ys0
--HG--
extra : rebase_source : 8da188b68456914773e6adae8cbccd6bf6a6e7a7
I had meant to remove all of these in bug 1276132, but I missed a couple. We
should now check whether Widevine is enabled before hitting these code paths
by checking the preference.
MozReview-Commit-ID: FmAdlgbF0Py
--HG--
extra : source : 586eff45c5479c7efc86435add5f6e9edd5e43b0
extra : amend_source : 65a9902374155d9e3180f0510b1d1434b986dc83
Handle encrypted WebM streams for the clearkey case. Add checking for the
widevine case, though these should currently fail, as not all of the plumping
is in place for widevine.
MozReview-Commit-ID: 5d9fvc5IkZF
--HG--
extra : rebase_source : 9baad2afd7778c350c404c72dcd81426092aa908
Instead of controlling visibility of EME keysystems by build config, do it by
preference. This means keysystems can be turned on easier.
MozReview-Commit-ID: Ky1zrHPubOJ
--HG--
extra : rebase_source : 35d9c26436a86683b902225e7b0d6645b02d8ff9
Instead of controlling visibility of EME keysystems by build config, do it by
preference. This means keysystems can be turned on easier.
MozReview-Commit-ID: Ky1zrHPubOJ
--HG--
extra : rebase_source : 7d68ad8389afdac8fcfffd2c505f8467107c05a5
The Widevine CDM is crashing trying to determine the screen layout, and since
10.6 is being deprecated in August, we're not going to bother making it work.
MozReview-Commit-ID: K1k1WZqjoyy
--HG--
extra : rebase_source : 7862852195a796e6bb18ef763f1b20837801531a
Now that GMPParent detects whether gmp-clearkey can decode using AAC/H.264
using WMF before reporting gmp-clearkey's GMPParent can decode AAC/H.264, we
don't need the GMPDecryptorCallback::SetCapabilities() callback from the GMP to
signal to the PDMFactory that the GMP can decode. We can now trust what the
GMPService tells us.
So we can remove the "waiting for CDM caps" step in the state machine's startup
sequence. And all the plumbing. :)
If we need more caps, like for an decode-and-render path, we can declare those
as API strings in the info file.
MozReview-Commit-ID: E0QhU4cYhjo
--HG--
extra : rebase_source : 7d15ab6a45bac88c15c053f416d941b5fe0807b0
Media Key System access requests are now recorded with their success/failure,
as well as accompanying issues of importance.
In this bug we focus on the Widevine-with-no-WMF case.
MozReview-Commit-ID: ElBN6cXKwAW
The Widevine CDM, and I believe the Adobe CDM too probably, do not mark a
session's keys as unusable when a key session is closed. This means that
the CDMCaps' copy of the keys that are usable is wrong, and so if the media
with the same keys is reloaded with the same MediaKeys, Firefox will assume
that the keys are usable before the license for the keys has been
re-negotiated, and so decryption will fail.
MozReview-Commit-ID: 1kTDzwSD8PE
--HG--
extra : rebase_source : 89c480f36bfaec11ceb5ca1e8d798b0ae795eaea
Pass declared-but-yet-undefined DecoderDoctorDiagnostics pointer to various
routines that contribute to deciding if a media format can be played, and
those that create decoders.
Points where a DecoderDoctorDiagnostics can be injected are currently marked
with "/* DecoderDoctorDiagnostics* */ nullptr", and some will be used in
following patches.
MozReview-Commit-ID: 7u37bvY4CpW
We end up showing the "Adobe EME is preffed off" UI on MacOSX because we're
check for Adobe EME support based on platform, not based on whether it's
configured on in the mozconfig. We should really only check for Adobe EME
if 'ac_add_options --enable-eme=adobe' is present in the build config,
as otherwise preffing it on isn't going to work.
MozReview-Commit-ID: CpSAh6gUU1S
--HG--
extra : rebase_source : 815b5ddf8f2889787acd22ab7a434db9b0f23213
The Widevine CDM does not have an AAC decoder. It can however decrypt audio
streams. It's our policy to not decode AAC streams decrypted by the Widevine
CDM with the Adobe GMP's unencrypted decoding functionality. So reject
MediaKeySystemAccess requests for Widevine if we don't have a system AAC
decoder that we can use.
MozReview-Commit-ID: Ltq52wT1qno
The logic in MediaKeySystemAccess is convoluted because it needs to keep
checking whether we're servicing a clearkey request and whether WMF is
available for gmp-clearkey to decode with. If we instead push those checks down
into GMPParent at the time where we parse the GMP info file, we can just not add
the decode capability to the GMPParent, and can remove the special cases in
MediaKeySystemAccess. This simplifies adding the (similar) special cases for
Widevine in the next patch.
MozReview-Commit-ID: IKD5LU86zIv
This means we won't try to build it when ac_add_options --enable-eme=widevine is
not present, and critically, we won't try to build it on Android, since the Chromium
Widevine plugin isn't available there.
MozReview-Commit-ID: 1jQvAbJP8HG
We need to not build Widevine by default, and when enabled we will need to be able to
ifdef on MOZ_WIDEVINE_EME (see next patch) so that we can not build the code on platforms
where it can't possibly work (Android specifcally, as Widevine isn't available as a
Chromium plugin there).
MozReview-Commit-ID: Avgz5NRcl9v
All the methods in CDMProxy except CDMProxy::OnExpirationChange() that use
mKeys null check mKeys before using it because it can go away during shutdown
before the IPC message to call the methods have had a chance to run.
We should do the null check in CDMProxy::OnExpirationChange() too.
Remove GMPVideoDecoderTrialCreator, and the tests and IPC/IDL supporting it.
--HG--
extra : commitid : HlbJPl2gPAl
extra : rebase_source : fe1773014e5d09da264f85d464e408aca46a60c4
Resurrect WMFDecoderModule::HasAAC() and HasH264(), and use those in
MediaKeySystemAccess.cpp to figure out whether we gmp-clearkey can decode,
rather than assuming Vista and later is always able to decode, as that's not
a valid assumption; Vista may not have the required Platfor Update installed,
or we may be on Windows N or KN without the Media Feature Pack.
--HG--
extra : commitid : 2QrVAGQ5OJa
extra : rebase_source : 8ad6e5c5f87cf2b2489f049543c021723927901a
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This commit was generated using the following script, executed at the
top level of a typical source code checkout.
# Don't modify select files in mfbt/ because it's not worth trying to
# tease out the dependencies currently.
#
# Don't modify anything in media/gmp-clearkey/0.1/ because those files
# use their own RefPtr, defined in their own RefCounted.h.
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
grep -v 'mfbt/RefPtr.h' | \
grep -v 'mfbt/nsRefPtr.h' | \
grep -v 'mfbt/RefCounted.h' | \
grep -v 'media/gmp-clearkey/0.1/' | \
xargs perl -p -i -e '
s/mozilla::RefPtr/nsRefPtr/g; # handle declarations in headers
s/\bRefPtr</nsRefPtr</g; # handle local variables in functions
s#mozilla/RefPtr.h#mozilla/nsRefPtr.h#; # handle #includes
s#mfbt/RefPtr.h#mfbt/nsRefPtr.h#; # handle strange #includes
'
# |using mozilla::RefPtr;| is OK; |using nsRefPtr;| is invalid syntax.
find . -name '*.cpp' -o -name '*.mm' | xargs sed -i -e '/using nsRefPtr/d'
# RefPtr.h used |byRef| for dealing with COM-style outparams.
# nsRefPtr.h uses |getter_AddRefs|.
# Fixup that mismatch.
find . -name '*.cpp' -o -name '*.h'| \
xargs perl -p -i -e 's/byRef/getter_AddRefs/g'
Chris Pearce
Phil Ringnalda
Carsten "Tomcat" Book
Kilik Kuo
Jon Coppeard
James Cheng
Stone Shih
Boris Zbarsky
Jean-Yves Avenard
JW Wang
Kaku Kuo
Bryce Van Dyk
Tim Huang
Iris Hsiao
Tom Tromey
Chris Peterson
stefanh@inbox.com
Jonathan Watt
Kyle Huey
Gerald Squelart
Mike Hommey
Edwin Flores
sajitk
Wes Kocher
Nathan Froyd
Nigel Babu
Sotaro Ikeda
Jocelyn Liu
Edwin Flores