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
If you request a GMPParent with a nodeId, you should get any already running
instances with the same nodeId in preference to cloning an existing GMP and
assigning it the nodeId.
This is ensures that EME GMP actors that are same-origin run in the same GMP
instance.
The GMP gtests are failing because of the cross-origin checks in
GeckoMediaPluginServiceParent::SelectPluginForAPI(). The loop there selects the
first GMPParent that can be used from the nodeId passed in. We previously
assumed a GMPParent can be used from a nodeId if the GMPParent has the same
nodeId, or if it has not loaded its process and it has no nodeId. The problem
with assuming that, is if an in-use GMPParent with the target nodeId lies in
the GeckoMediaPluginServiceParent::mPlugins list after a GMPParent with no
nodeId, we'll end up using the first GMPParent (the one with no nodeId) rather
than the one with the target nodeId.
The solution is to change GeckoMediaPluginServiceParent::SelectPluginForAPI()
so that effectively if we have a target nodeId, we'll select the first
GMPParent that has the same nodeId, or we'll clone the first which supported
all the requested capabilities/tags.
This means when you request a GMPParent with a given nodeId, you'll get the one
with the same nodeId (origin) by preference.
MozReview-Commit-ID: 4yVnrO8B1Pg
--HG--
extra : rebase_source : 5db7c6ef5f360df7d2244ca828b68b340c4e9a41
Prior to this change, we'd store the GMPStorage records for private browsing
sessions in the GMPStorageParent. The problem with this is that they only have
a lifespan matching their corresponding GMPParent. This means that if a GMP
stores something in a PB session, and the GMP is shutdown and then re-created,
we are likely to loose the stored data. This could mean that the PB session
gets results it doesn't expect, and thus expose a way for PB mode to be
detected.
MozReview-Commit-ID: 1OMD0LvidYs
--HG--
extra : rebase_source : 75661a7b1717e39a29c3e12ad203d9273e8485ab
The GMP which GeckoMediaPluginServiceParent::FindPluginForAPIFrom() returns
depends on the order in which GMPs lie in GMPServiceParent::mPlugins. However
when we shutdown a GMPParent we remove and then re-append the GMPParent to
mPlugins. This means the order in which GMPs lie in the list changes.
So when WebRTC requests an H.264 decoder, the first time it will get OpenH264,
since that's first in the list. But once we dispose of that decoder, its
GMPParent will be cloned and the clone will be appended to the end of the
list. This means the next time WebRTC requests a decoder, it'll get whatever
was next in the list.
This could be the Adobe GMP, which seems to be able to handle whatever WebRTC
is putting into it. However, if you do this enough times, you'll get the
Widevine CDM, which can't handle whatever WebRTC is putting into it.
So a quick hack to fix this is in ReAddOnGMPThread is to re-insert the clone
of the GMP into the slot in mPlugins that the original occupied. Then WebRTC
will always get OpenH264 whenever it requests for an H.264 decoder, as the
order of the GMPParents in mPlugins won't change.
MozReview-Commit-ID: Ii4AMqDqAo9
--HG--
extra : rebase_source : 62c10bc5b77ef259917aa6c88309be2423c93914
Crash reporting for GMPs being used from the EME call site are not generating
crash reports because they depend on the MediaKeys object calling
GMPService::AddPluginCrashHandler() to associate a window to which the
PluginCrashedEvent is fired. This doesn't work with e10s enabled because the
GMPParent which causes the plugin crash handlers to run is in the chrome
process, but the MediaKeys which adds the handler is in the child process. So
the crash handler is on the GMPServiceChild, but we only run the crash handlers
that were added to the GMPServiceParent in the chrome/parent process.
The solution is to broadcast a message from the chrome process to all the
content processes when a GMP has crashed that causes the GMPServiceChild to
also run its crash handlers.
MozReview-Commit-ID: 8Lek16G9ZGb
--HG--
extra : rebase_source : 180691046812df474ea33324d2b98ac71d11c9cd
The WMF HasAAC/HasH264 checks were done off the main thread, as soon as the
plugin was loaded, which was way too soon in the overall startup process, when
the WMF subsystem may not have been properly initialized yet, or may be in the
middle of it.
The solution here is to delay these checks until they are actually needed to
respond to a format-support request, as they come later in the process.
Note: This may not be the ideal solution yet, as we are still relying on some
magic sequencing of events. Other avenues have been explored unsuccessfully
yet, but we may want to revisit this issue after this urgent patch has landed.
MozReview-Commit-ID: JVgINc5FLFx
--HG--
extra : rebase_source : 3d02570ed26043d050d4848d968e3c673b35f5c3
Now that adding GMPs to the GMP service is async under the hood, for safety
the GeckoMediaPluginServiceParent needs to expose when adding a GMP
has finished so that things that depend on GMPs being present can be reliable.
For example, the call to GMPDecoderModule::UpdateUsableCodecs() that happens
at the end of AddPluginDirectory depends on the GMPs being up to date, so it
needs to happen after the add has finished.
MozReview-Commit-ID: Fn8b0GNILNg
This means we wait for the GMP service to have finished detecting all available
GMPs from the environment before we start creating GMP actors. Without this, we
get gtest failures due to gtests trying to create GMP actors before the async
GMPServiceParent::LoadFromEnvironment() has completed, i.e. we fail to create
actors because we've not had a chance to setup the GMPParent capabilities yet.
MozReview-Commit-ID: Hl4o1c4QthJ
This makes it easier to chain promises returned by GMPParent::Init() with calls
to GMPServiceParent::LoadFromEnvironment() in the next patch.
MozReview-Commit-ID: KdGVvzAedJW
XPCOMThreadWrapper::GetCurrent() is failing because it's not keeping
AbstractThread::sCurrentThreadTLS up to date. This causes assertion failures
during startup of the GMP stack when dispatching via InvokeAsync to the GMP
thread, which is an XPCOM thread wrapped by the XPCOMThreadWrapper.
We can trivially initialize AbstractThread::sCurrentThreadTLS to be the
XPCOMThreadWrapper on the target thread, since it's thread-local-storage, and
the target thread won't change.
MozReview-Commit-ID: EIEFZppR2PS
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
This ensures that we don't try to use one GMP instance to service multiple same-origin MediaKeys'
CDM access, as the Widevine CDM's Chromium interface is synchronous, so it doesn't handle running
multiple decoders well. Multiple same-origin GMPs can't safely use the same storage concurrently,
but thankfully Widevine doesn't require persistent storage, so we can just disallow that entirely
and avoid the problem.
MozReview-Commit-ID: 78I4IIGgHRA
This means that when initializing the Widevine CDM, we will be able to asynchronously
parse its manifest.json on the main thread, as the WebIDL JSON parser only runs there.
MozReview-Commit-ID: GI1sc4x4m16
I need to make GMPParent::Init() async, because the WebIDL JSON parsing
must happen on the main thread, and GMPParent::Init() is called on the
GMP thread, so I need GMPParent::Init() to be async so that in the
Chrome manifest case it can dispatch a task to the main thread to parse
the Chrome manifest before completing. So I'll make GMPParent::Init()
return a promise, and to do that, I need the GMP thread to have an
AbstractThread wrapper.
MozReview-Commit-ID: 44b4Z4jpar8
Add a GMPAdapter implementation that adapts the Widevine Chrome CDM to
the GeckoMediaPlugin API. We're still allocating memory for video frames
in non shmem buffers, and copying them over to a shmem before returning
them to Gecko, we can fix that at a later date. I hook this adapter up
in a later patch in the series.
MozReview-Commit-ID: 7iSFODVWPu3
Some encrypted MP4 files lack subsample info for some samples, so we need this check
to prevent us crashing on such files.
MozReview-Commit-ID: AXqOCAlb7IY
We have nsDependentCString to avoid needless memory traffic here. We
need an explicit cast, however, because we don't have a ParamTraits
specialization for nsDependentCString, only for nsCString, and template
specialization doesn't take derived classes into account.
But make sure that there's no way a GMP can track and report what a user watches using unencrypted decoding.
MozReview-Commit-ID: DljjYjcziRS
--HG--
extra : rebase_source : 1c4204ff69df0ed03015c069736831e5f8b35a29
The only reason we need to parse the info file in the GMP child process
is because we need to read the "Libs:" line so that the child process
can preload DLLs on Windows. We already parse the GMP info file in the
parent process, so we can remove the need to parse it again if we parse
the "Libs" field in the parent, and pass that through to the child.
Iris Hsiao
Chris Pearce
Tom Tromey
Bob Owen
James Cheng
Gerald Squelart
David Anderson
Bill McCloskey
Mats Palmgren
Jonathan Watt
Phil Ringnalda
Chris Peterson
Kyle Huey
Jean-Yves Avenard
JW Wang
Haik Aftandilian
Jim Mathies
Carsten "Tomcat" Book
Peter Chang
George Wright
Nathan Froyd
Aidin Gharibnavaz