The CDM10 interface makes 2 notable changes here:
1) Instead of the binary choice between unencrypted and encrypted (which assumed
cenc encryption), the interface now allows for specification of encryption used.
Practically this means we will eventually need to support choosing between not
encrypted, cenc, or cbcs.
2) The interface adds a bool for hardware secure codecs for use when
initializing the CDM.
This changeset adjusts the IPDL for the CDM to accommodate these changes. The
changes are also supported in surrounding code, but are not fully plumbed to
either the web, or the CDM.
Fully supporting new encryption schemes and hardware secure codecs will require
further work which is beyond the scope of this bug.
Some formatting drive bys so new formatting and old formatting both match
expected formatting by clang-format.
Depends on D5629
Differential Revision: https://phabricator.services.mozilla.com/D5630
--HG--
extra : moz-landing-system : lando
Note: Only the Adobe GMP used enum storage, so not that it's unused we may
as well remove this.
MozReview-Commit-ID: JtmQ69eJzaI
--HG--
extra : rebase_source : 29929e680dc1692b957b34ce274c4944743768e8
Now that we're not supporting Adobe EME anymore, we don't need to
provide a mechanism for GMPs to block browser shutdown.
MozReview-Commit-ID: KUC94IBQiod
--HG--
extra : rebase_source : ed521f28e272de11b2d0c4546b98baf6bd7c6e72
This basically rolls back aec9905b06fe from bug 1278198.
MozReview-Commit-ID: Drho21X6npW
--HG--
extra : rebase_source : 372bc7f4771ec0268535e3df2a745bc9fae8bd3b
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
The Adobe GMP only supports up to GMPDecryptor version 7. We're now up to
version 9. So we need to provide an adaptor to convert the old version to run
with the new interface.
MozReview-Commit-ID: 5dKreev7JMv
--HG--
extra : rebase_source : b9aa1b66ad23e9f7ddbe60b71c94c161ad974818
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
To allow GMPs time to update to new GMPDecryptor versions, we support the
latest GMPDecryptor version, and the previous.
In order to support a consistent interface to Gecko, we adapt the previous
GMPDecryptor version to the latest in the GMP child process. So Gecko always
thinks it's talking to the latest version.
We also make gmp-fake deliberately support the previous GMPDecryptor version,
to ensure this code path remains tested.
