The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 92870f1adc7ae68e58b15443e4223012bdf0e39a
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 4beba0212411a0f5867feb506bbf732f5a934fa9
We want to replace the use of int64_t for microseconds by TimeUnit
whenever possible since int64_t is ambiguous which could be microseconds
or milliseconds.
MozReview-Commit-ID: LRz9d4yKBYJ
--HG--
extra : rebase_source : 1f73f1f338142b3183491d04726821a881ccabbe
extra : intermediate-source : 88e167b7b06303d10d92cd5317502f405d1c553e
extra : source : 98deb30ec93d395f9951f5fc488170ae35e29675
mServiceChild is a UniquePtr, so nulling it will destroy the GMPServiceChild,
which will destroy the associated message channel. So we need to close the
channel first before it gets destroyed. (Just as it was correctly done in
Observe() above.)
MozReview-Commit-ID: INuHN2Is7bC
--HG--
extra : rebase_source : 2a927bb06dd8fb4f1114dc0b64025cbdddc7c133
Makes transfer of samples between the content and CDM processes use shmems.
The Chromium CDM API requires us to implement a synchronous interface to supply
buffers to the CDM for it to write decrypted samples into. We want our buffers
to be backed by shmems, in order to reduce the overhead of transferring decoded
frames. However due to sandboxing restrictions, the CDM process cannot allocate
shmems itself. We don't want to be doing synchronous IPC to request shmems
from the content process, nor do we want to have to do intr IPC or make async
IPC conform to the sync allocation interface. So instead we have the content
process pre-allocate a set of shmems and give them to the CDM process in
advance of them being needed.
When the CDM needs to allocate a buffer for storing a decrypted sample, the CDM
host gives it one of these shmems' buffers. When this is sent back to the
content process, we copy the result out (uploading to a GPU surface for video
frames), and send the shmem back to the CDM process so it can reuse it.
We predict the size of buffer the CDM will allocate, and prepopulate the CDM's
list of shmems with shmems of at least that size, plus a bit of padding for
safety. We pad frames out to be the next multiple of 16, as we've seen some
decoders do that.
Normally the CDM won't allocate more than one buffer at once, but we've seen
cases where it allocates two buffers, returns one and holds onto the other. So
the minimum number of shmems we give to the CDM must be at least two, and the
default is three for safety.
MozReview-Commit-ID: 5FaWAst3aeh
--HG--
extra : rebase_source : a0cb126e72bfb2905bcdf02e864dc654e8340410
This means we can pass anything that converts implicitly to a Span to
PostResult, including an nsTArray<uint8_t>. We can also pass a Span
that contains the contents of a Shmem's buffer.
MozReview-Commit-ID: 8AAcRmVCEVy
--HG--
extra : rebase_source : 44dfbc465db14bb689a653e6c0b3cbc626c0a0d1
This ensures that the IPC connection from the content process to the main
process is shut down as soon as possible. Once all the IPC connections are
closed, the main process removes its async shutdown blocker, and Firefox
can shutdown.
MozReview-Commit-ID: 8rqa384ayd9
--HG--
extra : rebase_source : b9cbbb9f4c22016284a8d49cddaea0d96666acf9
This ensures that when we've started shutdown we don't try to start up new
GMPs. Doing so would create more connections from the content process to the
main process, and the main process can't shutdown until all such connections
are shut down.
MozReview-Commit-ID: KE8nCoLXjdd
--HG--
extra : rebase_source : 674f3c4ddcb5bb93dd775a861b425d25510871e9
This will allow us to broadcast a notification to the GMPServices running in
the content processes when they need to shutdown.
MozReview-Commit-ID: FviFDgNMnUV
--HG--
extra : rebase_source : f4ad3c6df0e14c88db1199fbe6281d67f98590ae
When we shutdown the browser while the GMPService is active we can end up
leaking a GMPParent, GeckoMediaPluginServiceParent, and a Runnable. I tracked
this down to the runnable dispatched to the GMP thread in
GMPParent::ChildTerminated(). The dispatch of this runnable is failing as we
are dispatching the runnable to a reference of the GMP thread which we have
previously acquired, but that thread is now shutdown. So the dispatch fails,
and if you look in nsThread::DispatchInternal() you'll see that we deliberately
leak the runnable if dispatch fails! The runnable leaking means that the
references it holds to the GMPParent and the GMP service parent leak.
The solution in this patch is to not cache a reference to the GMP thread on the
GMPParent; instead we re-request the GMP thread from the GMPService when we
want it. This means that in the case where the browser is shutting down,
GMPParent::GMPThread() will return null, and we'll not leak the runnable. We'll
then follow the (hacky) shutdown path added in bug 1163239.
We also need to change GMPParent::GMPThread() and GMPContentParent::GMPThread()
to return a reference to the GMP thread with a refcount held on it, in order
to ensure we don't race with the GMP service shutting down the GMP thread
while we're trying to dispatch to in on shutdown.
MozReview-Commit-ID: CXv9VZqTRzY
--HG--
extra : rebase_source : e507e48ee633cad8911287fb7296bbb1679a7bcb
This is required for the browser clearing persistence tests to pass.
MozReview-Commit-ID: Ai9qc6Ds1IG
--HG--
extra : rebase_source : 80c2133e26742410fda983e3c18c35736fc013d0
This severs the ChromiumCDMVideoDecoder's connection with the CDM. The CDM process
will shutdown when the MediaKeys also severs its connection.
MozReview-Commit-ID: Aqc4y5Nxjvc
--HG--
extra : rebase_source : 5a2f77ffe84f9b99b4668520c838b29a428578d3
At this stage, I store video frames in memory in nsTArrays rather than in
shmems just so we can get this working. Once this is working, I'll follow up
with patches to switch to storing all large buffer traffic between the CDM and
other processes in shmems.
I'm not planning on preffing this new CDM path on until that's in place.
MozReview-Commit-ID: LSTb42msWQS
--HG--
extra : rebase_source : b7f162515a1a32b2c344c11d0fa5c7004cec2e15
The MediaKeys accesses the ChromiumCDMProxy on the main thread. But the
ChromiumCDMVideoDecoder will need to access the ChromiumCDMProxy on the decode
task queue in order to get a reference to the ChromiumCDMParent so that it can
talk to the CDM (on the GMP thread).
Additionally we'll need to shutdown the ChromiumCDMProxy, and if we do that
on the main threrad while the ChromiumCDMVideoDecoder is trying to get the
ChromiumCDMParent reference, we could hit thread safety issues.
So we need to hold a lock while reading or writing from the ChromiumCDMProxy's
reference to the ChromiumCDMParent. So add a GetCDMParent() function to the
ChromiumCDMProxy which takes the lock while reading or writing the reference.
This means that the caller will always get a valid reference. There is no guarantee
that the ChromiumCDMParent isn't shutdown after the reference is taken; if that
happens, the ChromiumCDMParent returned will fail on all operations.
In a later patch in this series, the ChromiumCDMProxy will anull its reference
to the ChromiumCDMParent on shutdown, and cause GetCDMParent to return null.
So callers need to null check the return value of GetCDMParent.
MozReview-Commit-ID: 4xL41YbwkxL
--HG--
extra : rebase_source : aa854e9d88965d7da60231d6f6a3912bf6ad2eeb
This means the EME PDM implementation can safely tell when a CDMProxy is a
ChromiumCDMProxy, so we can create an appropriate MediaDataDecoder for it (in
the next patch).
MozReview-Commit-ID: CpL6QRa7SwJ
--HG--
extra : rebase_source : 3821c378c73067066f3cc67499680bdf546fb4f0
This ensures that when we're using the ChromiumAdapter that we actually ask it
whether it'll work, rather than asking the adapter we're not using.
MozReview-Commit-ID: 85nZPl9MdWa
--HG--
extra : rebase_source : 90de89bec9b004859c3c2c09ed8efbd255acc141
We still use the same EMEDecryptor MediaDataDecoder as is used by the existing
EME decrypting path.
MozReview-Commit-ID: 3pXPjChctLb
--HG--
extra : rebase_source : 67575a02290ddb871510dd88f59fdab77658b3ce
This means the MediaKeys is able to create a CDM.
MozReview-Commit-ID: 94Xc7sCLhH3
--HG--
extra : rebase_source : 914db1f04e0770776ae25c7b8bdc59e729fe78d0
This will eventually replace GMPCDMProxy. Methods will be implemented in later
patches.
MozReview-Commit-ID: 86pwo81tFZv
--HG--
extra : rebase_source : df41a20a0fefaf26a63ed18f1ccdf7fa5a3a1e89
We currently use an adapter object to adapt plugins that don't conform to the
GMP interface to the GMP interface.
We use the WidevineAdapter to talk to the CDM from the two GMP IPDL protocols.
We will be using a single protocol to talk to the Chromium CDM, so we need a
new adapter which handles that.
MozReview-Commit-ID: F7hnZ9oo9mJ
--HG--
rename : dom/media/gmp/widevine-adapter/WidevineAdapter.cpp => dom/media/gmp/ChromiumCDMAdapter.cpp
rename : dom/media/gmp/widevine-adapter/WidevineAdapter.h => dom/media/gmp/ChromiumCDMAdapter.h
extra : rebase_source : 7c08edea3c11d41eb3ecfa9c7a8ef65cf3b8ddb0
Infrastructure necessary to create an instance of the CDM process.
MozReview-Commit-ID: 7oQ86x6BNWj
--HG--
extra : rebase_source : c725a958c507b7f93ce9cfccc475f259ae9ccbc2
We currently do two sync IPCs to launch a GMP; one from content to main process
to get the nodeId and a second to get a GMPContentParent for that nodeId.
We use the nodeIds to ensure that the GMPVideoDecoder and GMPDecryptor actors
correspond to the same CDM instance/process. However once we switch to having
one protocol that encompasses both decryption and decoding, we don't need to
worry about making sure our decoder and decryptor actors match up, as we only
have one underlying connection to the CDM instance.
So we can merge the get nodeId and get GMPContentParent operations into a
single operation that does both. To do this, we just need to pass the
parameters used to calculate the nodeId in the LaunchGMP message.
Once we've switched EME over to using the CDM via a single actor, we can remove
the nodeId nsCString from our media code and from GMPVideoDecoder and
GMPVideoEncoder.
MozReview-Commit-ID: 7GXlJ37fOTZ
--HG--
extra : rebase_source : cf20a165048f777f34dab01fce984018ad641b85
The implementations of this protocol will be stubbed out in later patches.
MozReview-Commit-ID: 622CB1BOoR9
--HG--
extra : rebase_source : b796bfb4c0d0d2872787043e3b9fc83a0e6b09ea
Carsten "Tomcat" Book
Chris Pearce
Iris Hsiao
JW Wang
Gerald Squelart