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
