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.
