Functionality is now provided through AudioConverter class.
MozReview-Commit-ID: 5MchZT1XRoO
--HG--
extra : rebase_source : 270581b49043f102a89e5eea97195379a937da22
This is using the same downmixer algorithm as found in the ogg reader.
MozReview-Commit-ID: 5KwVLPOg7Tt
--HG--
extra : rebase_source : 523979251421c49ddd05b90498d2ec8eb3309b94
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
Current downmixer was using vorbis channel order (which isn't surprising as it was extracted from the Ogg reader).
Make it use SMPTE order as that's now what all MediaDataDecoder output.
MozReview-Commit-ID: 5Kf7UnC52wL
--HG--
extra : rebase_source : 1848ffac58b854c7886871a0ff3dadbc92e111a2
To be used in combination with AudioDataBuffer class that will be able to perform format conversion.
Can currently only perform channel re-ordering.
Future use will add downmixing, upmixing and resampling capabilities.
MozReview-Commit-ID: 2FBu9aRVtgj
--HG--
extra : rebase_source : 366178114b2bd3da40b247ae0fbe1e04cf83e452
Long term goal would be to merge AudioConfig with the existing AudioInfo class which doesn't provide sufficient data to properly determine how to play multichannel audio.
MozReview-Commit-ID: 3UDpZWPBUvS
--HG--
extra : rebase_source : 0643fdba0a6decf4f76c42f40bbb1b237e3e0300
Along with AlignedByteBuffer and AlignedFloatBuffer
MozReview-Commit-ID: LmGc2JDBETi
--HG--
extra : rebase_source : b1091188870f0cfbfebcacad940504b02bc7c1dc
Same after a reset or the first frame ever returned by the demuxer.
MozReview-Commit-ID: 6b7XlIk5GE4
--HG--
extra : rebase_source : 7e7b92c2ed7ea6973ad3869477b3110925a64525
The idea is that we can call Ensure{Audio/Video}DecodeTaskQueued() directly
since the conditions in the DispatchDecodeTasksIfNeeded() have already been
checked.
MozReview-Commit-ID: 9xataQiuSIx
--HG--
extra : transplant_source : %E4t%20%1FV%12%FE%08%9Cx%D7%0A%C3C%B0M%14%80%E4%85
Peter Chang
Eugen Sawin
Milan Sreckovic
Thomas Zimmermann
JW Wang
Jean-Yves Avenard
Kirk Steuber
Chris Pearce
Randell Jesup
Jan Henning
Paul Adenot
Ryan VanderMeulen
Kaku Kuo
Kilik Kuo