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
This is a regression from bug 1162358.
We must be hitting the #ifndef SHMEM_ALLOC_IN_CHILD block in
GMPVideoDecoderChild::Alloc() with multiple allocs doing intr calls at once.
If this happens when a DecodingComplete() comes in, we'll end up sending one
task to re-call RecvDecodingComplete for every Alloc() blocked on an intr
response. This would result in us ending up trying to Send__delete__() in
RecvDecodingComplete() twice. Which causes the runtime abort we're seeing
here.
I think that could happen in the WidevineVideoDecoder if a Decode message comes
in, and goes into a ReturnOutput(), tries to alloc a frame and has to spin on
an intr message response, and another Decode message comes in and does the
same, so GMPVideoDecoderChild::mNeedShmemIntrCount will be 2, and then a
DecodingComplete comes in, and when two tasks on the stack in
GMPVideoDecoderChild::Alloc() finish they both end up dispatching a task to
re-call GMPVideoDecoderChild::RecvDecodingComplete(). So we end up trying to
Send__delete__() in RecvDecodingComplete() twice.
I expect the same problem exists in the GMPVideoEncoder too.
intr, or spinning event loops in general for that matter, is evil.
MozReview-Commit-ID: AKsvP62G3Cx
--HG--
extra : rebase_source : 53ca12dbbbf3ab071788e2322b7c926ec7c0325f
Disconnecting the GMPCrashHelpers at the right time is hard, because in the
crashing case we're all shutdown before the GMPCrashHelpers can be invoked to
help handle the crash report. So add a class to help the helpers;
GMPCrashHelperHolder. This composes into the GMP content protocol actors, to
help them disconnect the crash helpers at the right time. See the comment in
GMPCrashHelperHolder for the details.
MozReview-Commit-ID: E5rE6e5Jues
--HG--
extra : rebase_source : f688bf727f23f773eb995611cec6412ebf021029
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
This will allow us to attach a crash handler to a GMP process after deciding
which GMP to load but before actually loading it.
MozReview-Commit-ID: HwBZU2Q4TX6
--HG--
extra : rebase_source : a68b9cbc31c0b886ba491f8f15f02e4d0e32cae7
Fixes compile errors on Linux when Widevine is compiled.
MozReview-Commit-ID: 19qQw02CqdQ
--HG--
extra : rebase_source : 335124655869da1f899986f7dcd0d7ec1e441f6a
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
Fixes compile errors on Linux when Widevine is compiled.
MozReview-Commit-ID: 19qQw02CqdQ
--HG--
extra : rebase_source : ebb98b25738e0438d873834f07c72be1f4eb71db
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
I want the EME device binding/nodeId code to be callable from gtests, as well
as in plugin-container. I need this because I want to add a gtest that ensures
that we don't regress the EME/GMP device binding code. I want to call the GMP
device binding code in the gtest and in the GMP process, and compare the
result.
So we need to make it possible to link the device binding code into the gtests
as well as plugin-container. So move all code that device binding calls into
librlz, to make it easier to link against all the code required.
Note: the device binding code needs to be statically linked into
plugin-container so that it's covered by the Adobe CDM's voucher tool.
MozReview-Commit-ID: AvBAe1dh49Z
--HG--
rename : ipc/app/sha256.c => dom/media/gmp/rlz/sha256.c
rename : ipc/app/sha256.h => dom/media/gmp/rlz/sha256.h
extra : rebase_source : f60f1e68649fa90cbe1f2fe09f5f69948444b1df
I want the EME device binding/nodeId code to be callable from gtests, as well
as from in plugin-container.
First step is to move the device binding code into a discrete file, so I can
also link that into gtests, and call it from there to compare the result with
what's in the GMP process.
MozReview-Commit-ID: 9xT2rp3hWW
--HG--
extra : rebase_source : 824c7a9841bce83c438decad48ce210f6c2a5571
The original changeset that is being backed out had comment:
Bug 1023941 - Part 2: Static-link the CRT into plugin-container.exe.
MozReview-Commit-ID: 1iPJghgd0t2
--HG--
extra : rebase_source : cbed4e43f51af8ea0c3adbfc150ed029fe0d0f57
The OnSessionClosed() callback is happening on a timer, after
WidevineDecryptor::DecryptingComplete() has been called. So mCallback could
actually be non-null because DecryptingComplete() has been called, but the
object pointed to by mCallback has been deallocated, and mCallback is a
dangling pointer.
MozReview-Commit-ID: 4xdHYRn7EAS
--HG--
extra : source : 55d79997aa3e3e2133d9155c37f4435317b44061
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
We've observed some crashes derefing the callback pointer, which may be
occuring due to shutdown happening before init has setup the callback pointer.
MozReview-Commit-ID: JsOqfjejMVI
--HG--
extra : rebase_source : e175dd8556ad50316bc16232782e593eea3e2ec8
GeckoMediaPluginService::mAbstractThread was not reset as expected from
ShutdownGMPThread, meaning it would retain a reference to the GMP thread, and
it would allow dispatch attempts to the GMP thread after shutdown.
Also mAbstractThread was not protected by a mutex (as mGMPThread was), which is
definitely needed now that it can be reset at shutdown time.
As its prefix implies, GetAbstractThread could return a nullptr, so it should
be checked before every use.
Note that this GetAbstractThread call (and its check) has been moved closer to
the start of functions using it, to avoid unnecessary and potentially invariant-
breaking partial work to take place when we can know in advance that it won't
fully succeed because the GMP thread is not available.
MozReview-Commit-ID: B1drOeM65hr
--HG--
extra : rebase_source : 1d389c663e26a25035bf2aa22b2cca478ef954fe
In bug 1264497 we discovered that Netflix was broken because we'd made a change
to not send the Adobe GMP the device bound nodeId, which it stored in GMP
storage. When the GMP was comparing the nodeId it had stored against what it was
passed (nothing) the comparison was failing. Users could have worked around this
problem by clearing their GMP storage, whereupon the Adobe GMP will have stored
"nothing" as its nodeId.
When bug 1264497 was fixed, users who'd cleared their storage will see Netflix
fail again, as their stored nodeId of "nothing" will again not match what we
pass in. So to fix Netflix for these users, we need to clear GMP storage.
This is another instance of a more general problem that we have occasionally
encountered, namely that sometimes GMP storage becomes incompatible, and we
need to clear it. Having a general mechanism that we can use to clear storage
remotely will be helpful, so this patch adds one, and triggers it to fire.
This mechanism is pref controlled, so that we can issue a hotfix if necessary
to clear GMP storage.
MozReview-Commit-ID: GzSyBj0P2JG
--HG--
extra : rebase_source : b854860ee533b0742a664c862278ce54c9052596
Assert that the CDM wrapper is given a non-null CDM pointer.
(so GetCDM() doesn't need to be null-checked.)
Renamed WidevineVideoDecoder mCDM to mCDMWrapper, to avoid (my) confusion.
Assert that WidevineVideoDecoder is given a non-null CDM-wrapper pointer.
Assert that WidevineVideoDecoder only accesses the CDM before DecodingComplete.
Small optimization: Move aCDM into mCDM (to save an AddRef/Release pair).
MozReview-Commit-ID: yKupY067ly
--HG--
extra : rebase_source : 94140b423a04f28368de0831761406c145fad93e
Check the return result from Widevine's CDM creation function, and handle
failure.
MozReview-Commit-ID: HYvKgdK53aQ
--HG--
extra : rebase_source : b3e28ba5e0020e3a6dd77c8a83b58be233fdc770
Ensure that there is a CDM before creating a video decoder that relies on that
CDM. This is mainly to prevent using the Widevine video decoder alone, without
decryption.
MozReview-Commit-ID: 7p49CnmV2r7
--HG--
extra : rebase_source : 49b07100b2be56584bc14f41d39d4872f0539c3a
