We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
We are pre-allocating shmems in the content process for use by the CDM in the
GMP process. We guess the size of shmem required. However if we guess wrong,
currently we always end up taking the non-shmem path for video frames to
return to the content process, which results in us sending another shmem
(of the wrong size) to the CDM, and this continues until we hit the limit
on the number of shmems that we tolerate the CDM asking for.
So in this patch, I change our behaviour to detect when we're allocating
shmems that are too small, whereupon we purge the existing shmems and switch
to allocating them at the size being requested by the CDM.
This means we recover from incorrectly guessing the size of shmems required
by the CDM. The overhead of an incorrect guess should be one video frame
transferred via the nsTArray path.
MozReview-Commit-ID: 8o1s7FI2UBd
--HG--
extra : rebase_source : 0612d199686278612e8c58dc97e96a9304ea3ee9
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
Infrastructure necessary to create an instance of the CDM process.
MozReview-Commit-ID: 7oQ86x6BNWj
--HG--
extra : rebase_source : c725a958c507b7f93ce9cfccc475f259ae9ccbc2
This means we can reuse LogToConsole inside the new CDM decoder backend.
This change also makes GMPUtils.cpp build in non-unified build mode.
MozReview-Commit-ID: AFkdHIos4X2
--HG--
extra : rebase_source : d31e794ce94fa724a90b1cfa842a86d119a4e2d1
extra : source : 6cad0b06a556795f6d6de123bb5a153ff06062f5
I've repeated myself a few times, so make a helper to make determining which
GMPs are available easier.
MozReview-Commit-ID: 2fFLeaA5o8u
--HG--
extra : rebase_source : 74ea0b429d339273535610df3bbd7fec7beae469
James Cheng
Eric Rahm
Chris Pearce
Wes Kocher
Ehsan Akhgari
Matthew Gregan