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.
Without this, existing installs of the Adobe x64 Windows GMP from the zip file
where the GMP files are read-only will not be able to be installed.
--HG--
extra : rebase_source : 21ac7b0e4c55cc26e17f05563f61bdce65117507
UnloadPlugins runs in the GMP thread. While it locks mMutex, any locking
attempt on the main thread would effectively block the main thread while we are
calling CloseActive on each plugin.
The problem is that CloseActive calls GeckoMediaServiceParent::GetSingleton(),
which dispatches a task to the main thread, which may be blocked because of
mMutex.
To solve this inter-locking issue, the list of plugins is first copied to a
local array, after which mMutex may be released, and we may now call
CloseActive without risking locking.
Initialize GMPStorage::mShutdown to true, so that if Init() has not completed
yet or if it failed, other methods will not try and access a null mStorage.
Remove GMPVideoDecoderTrialCreator, and the tests and IPC/IDL supporting it.
--HG--
extra : commitid : HlbJPl2gPAl
extra : rebase_source : fe1773014e5d09da264f85d464e408aca46a60c4
Thanks to bug 1121676, GMPParent does not need to be created and destroyed
on the main thread. Main-thread constraints have been removed.
Also, this means that GeckoMediaPluginServiceParent::ClonePlugin() and
AddOnGMPThread (running on the GMP thread) do not need to sync-dispatch the
creation on the main thread.
This should remove the deadlock that prevents
GeckoMediaPluginServiceParent::UnloadPlugins() from running on the GMP thread.
Peter Chang
Chris Pearce
George Wright
Nathan Froyd
Kyle Huey
Jean-Yves Avenard
Aidin Gharibnavaz
Bob Owen
Carsten "Tomcat" Book
Birunthan Mohanathas
Phil Ringnalda
Bill McCloskey
Gerald Squelart
Nicholas Nethercote
Randell Jesup