We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
The new video decoder in CDM version 1.4.8.970 seems to calculate its frame size
as about 1.5X of the optimal size. So increase our estimate of CDM video frame
buffer sizes by more than that so that our pre-allocated buffers should be big
enough to accomodate the allocations that the CDM requests.
This means we should be more likely to avoid the slow fallback path where we
have to transfer frames from the CDM to the content process using the non-shmem
path.
MozReview-Commit-ID: 6PT8XVCAL3E
--HG--
extra : rebase_source : a27793b033c4f50f6e15d874558dc50e1410c8be
The strategy we were using to expand the pool of shmems we use to shuffle video
frames between the CDM and content processses is to increase the size of the
pool if the content process receives a video frame in a non-shmem. However the
CDM process will send a frame in a non-shmem if none of the shmems in the pool
are big enough to fit the frame the CDM produces. This happens if we
underestimate the size required for video frames. This causes the
ChromiumCDMParent to increase the number of shmems in the pool every time we
rate switch, until we eventually hit the limit of 50, whereupon playback fails.
So we need to disambiguate between these two cases; the first being we have a
pool of shmems, but they're the wrong size, the second being our shmems are the
right size, but we've run out and we need to expand the shmem pool. The only
place where we know this is in the CDM process. So this commit adds a new
message to PChromiumCDM through which the ChromiumCDMChild can report to the
parent that it needs more shmems in the pool.
The new Widevine CDM has a new video decoder which allocates video frames less
optimally than the previous, which causes us to hit this more often in Nightly.
Our telemetry also indicates we hit this rarely in Beta with the old CDM.
MozReview-Commit-ID: LoSvVhxHQxn
--HG--
extra : rebase_source : 6c7201a74dbf202d0ef8c2269292a80a7ad95dff
extra : source : 57cf5455fd14ef0b68b61f914146ff942b5ca4a0
HasSPS, ExtractExtraData and CompareExtraData have nothing to do with the handling of annex B format. They are raw H264 related methods.
It will also prevent in the following change to have cycling references between two headers.
MozReview-Commit-ID: FCs5aU4GcTU
--HG--
extra : rebase_source : a96fe0c70416d38690b0c2f1dee567b0b025e947
HasSPS, ExtractExtraData and CompareExtraData have nothing to do with the handling of annex B format. They are raw H264 related methods.
It will also prevent in the following change to have cycling references between two headers.
MozReview-Commit-ID: FCs5aU4GcTU
--HG--
extra : rebase_source : b204723cdbb599d4f0a227871ed28f5da39e9cff
The next version of the Widevine CDM (970) has a new H.264 decoder and it does
not appear to be outputing frames it decodes in presentation order, so we need
to reorder the frames output by the CDM.
MozReview-Commit-ID: HMsQVN3NCIU
--HG--
extra : rebase_source : 68ef406556087434fa12b72ae5ed5c2e1bce2b64
This will enable us to pre-allocate the correct number of shared memory buffers
that we pre-allocate for sending video frames between the CDM and Gecko. That
means we won't need to take the slow path to recover from underestimating how
many shmems we need.
MozReview-Commit-ID: Q4mX2rYMz3
--HG--
extra : rebase_source : f9573cfbf4e65013803b46c0909be2c68566e512
The ChromiumCDMParent is informed of the shutdown of its plugin, so we can
use that to inform the CDMProxy that its connection to the CDM has been
severed. This means we shutdown cleanly if the browser closes while playing.
MozReview-Commit-ID: HphQ2exu1gj
--HG--
extra : rebase_source : ff9ee3699915e8b7527570e839eb3bb0a0ab46bc
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
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
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 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
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
The implementations of this protocol will be stubbed out in later patches.
MozReview-Commit-ID: 622CB1BOoR9
--HG--
extra : rebase_source : b796bfb4c0d0d2872787043e3b9fc83a0e6b09ea
Kartikaya Gupta
Chris Pearce
Bill McCloskey
Jean-Yves Avenard
Sebastian Hengst
Kris Maglione
Carsten "Tomcat" Book
Iris Hsiao
JW Wang
Gerald Squelart