It is now more inline with the api spec in content_decryption_module
MozReview-Commit-ID: KmZzyfvHv5p
--HG--
extra : rebase_source : 783430c2d92018d686ddd8779bea1939936c618a
extra : histedit_source : 653ab1e717ce57c0f3eebfb3e6eddc6fa20d5884
The specification doesn't require there to be a 'type' member of
the keyids init data format.
MozReview-Commit-ID: 7mOm7KwyyuC
--HG--
extra : source : c9fb674f3cb8dff4fe8734e0426e67825878015d
The spec expects this, and now we pass more web platform tests.
MozReview-Commit-ID: 9HJFp2ebczk
--HG--
extra : source : 6d50c9068b52d8846e4d528d150f3f3dbd9a233d
The specification doesn't require there to be a 'type' member of
the keyids init data format.
MozReview-Commit-ID: 7mOm7KwyyuC
--HG--
extra : rebase_source : 88b729ae0b0f851763bbd06ec48bae2d6ac1c47e
The expected value comes first in the EXPECT_EQ gtest macro. So reorder our
calls to this macro in the Pssh Parser gtests to match that.
This makes it easier to read what's the expected value when the test fails.
MozReview-Commit-ID: LJ4ND2gRPi4
--HG--
extra : source : 34254ffcdb6fe9e053449210556fb2333f7a205a
We're now obliged to be stricter, taking from the example of the Web Platform
Tests.
MozReview-Commit-ID: AJNDoRZ9BF8
--HG--
extra : source : 5180fdf042b03362b882ceb3a8ac0e664049bd64
This better reflects that it's used for all CENC keys, not just ClearKey keys.
MozReview-Commit-ID: 9uCzDKVDLjc
--HG--
extra : source : 3307b3e0d411ceb9888f10afdbebc07ab9efce61
We're loading functions from that library dynamically in gmp-clearkey anyway,
we don't need to statically link this.
MozReview-Commit-ID: AKwP5aWLsK3
--HG--
extra : source : 857f21f44316ef8125fedf8db22b5d3191d9c7e9
To validate the PSSH init data passed to EME, I'd like to reuse the same
PSSH parser that the ClearKey CDM shared library uses. So move the code
out of gmp-clearkey and into its own library, so we can link it statically
into code that needs to use it.
MozReview-Commit-ID: 7xSUSmCueJz
--HG--
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.cpp => media/psshparser/PsshParser.cpp
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.h => media/psshparser/PsshParser.h
extra : source : 78dcbc5d3c26547c63269eb14034a67863cf28de
The expected value comes first in the EXPECT_EQ gtest macro. So reorder our
calls to this macro in the Pssh Parser gtests to match that.
This makes it easier to read what's the expected value when the test fails.
MozReview-Commit-ID: LJ4ND2gRPi4
--HG--
extra : rebase_source : 85ca2dcff57354253b801fbd598c89698c74c2d6
We're now obliged to be stricter, taking from the example of the Web Platform
Tests.
MozReview-Commit-ID: AJNDoRZ9BF8
--HG--
extra : rebase_source : 79b13d1d7d1b6b6b4a382b6a17af81606af608fa
This better reflects that it's used for all CENC keys, not just ClearKey keys.
MozReview-Commit-ID: 9uCzDKVDLjc
--HG--
extra : rebase_source : dfd7fe864be6825a86dfed4f60b448a5edac286f
We're loading functions from that library dynamically in gmp-clearkey anyway,
we don't need to statically link this.
MozReview-Commit-ID: AKwP5aWLsK3
--HG--
extra : rebase_source : 23ab95e7bb2f756ef1df7f97b96ec7da0953533f
To validate the PSSH init data passed to EME, I'd like to reuse the same
PSSH parser that the ClearKey CDM shared library uses. So move the code
out of gmp-clearkey and into its own library, so we can link it statically
into code that needs to use it.
MozReview-Commit-ID: 7xSUSmCueJz
--HG--
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.cpp => media/psshparser/PsshParser.cpp
rename : media/gmp-clearkey/0.1/ClearKeyCencParser.h => media/psshparser/PsshParser.h
extra : rebase_source : 3f621aa1d99c6a73f6b5f3ca9d1f84022266a833
Google's Web Platform EME test expects this, and it makes sense.
MozReview-Commit-ID: CCuEHYintob
--HG--
extra : rebase_source : 7b2a9f38b5c22ecb0af8b9a2e270eaa7d0bf2da0
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
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 : f944a40e2287c7a7dd01a2fb145a9e5882dd2368
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
Google's Web Platform EME tests contain a CENC PSSH box with a 0 size field.
Our existing PSSH parser in our ClearKey plugin doesn't handle this well, it
gets stuck in an infinite loop. We should really handle everything that Chrome
handles, so we should handle this input.
We also shouldn't really be using raw pointers in the PSSH parser.
So rewrite the PSSH parser to use a ByteReader, and handle an invalid 0 sized
common SystemID box.
Also add gtests for the parser, and skip over PSSH boxes with unknown SystemIDs
(if they have valid sizes that is).
MozReview-Commit-ID: CdVPpphAJV
--HG--
extra : rebase_source : e9a1b439f8b371653c2c97322a2db64cafef6dd8
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
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
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.
We're failing in the "Very rough kill-switch" case in
GMPVideoDecoderParent::Decode() we find that too many shmems are in use when we
come to send a "Decode" message to the GMP, and that causes an error which
percolates up to cause the test failure.
This patch changes gmp-clearkey to copy the input encrypted and compressed
sample and immediately return the shmem to the parent process. We are
copying the data anyway when we decrypt, so we can rejigg things so that we
don't actually end up doing a second copy.
We're going to change how e.g. CFLAGS are printed out in backend.mk, and
to fit that model, the data in the corresponding moz.build variables
need to be straightened up.
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
CLOSED TREE
Backed out changeset 12ce98475c6e (bug 1119980)
Backed out changeset bdb8d05f8870 (bug 1119980)
Backed out changeset a68a18840492 (bug 1119980)
It's unused (the sole caller is already commented out),
and uses deprecated ftime() & sys/timeb.h which are not
available on OpenBSD and Android NDK r10c.
Dont build openaes/rand.c, OAES_HAVE_ISAAC is not defined.
Remove now unused rand.c & rand.h.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.