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
As well as the obvious #ifdefs, this allows DOMHwMediaStream to be
removed, and also the "phone-state-changed" observer.
--HG--
extra : rebase_source : 373280183e228bd4b9bd9d866959409f2444c77e
Updates to Chromium revision 6e4c388c0117fe408b66fbede91081fb1018c5fe.
Adds Verified Media Pipeline function definitions.
MozReview-Commit-ID: 2H8mMNacQqR
--HG--
extra : rebase_source : d544d6a0c6854ccc29da6ddcc11b4efc8f621036
Update to chromium revision 6e4c388c0117fe408b66fbede91081fb1018c5fe.
Includes cdm::ContentDecryptionModule_9 and cdm::Host_9 definitions,
HDCP definitions, and 10 and 12 bit image format definitions.
MozReview-Commit-ID: bYH3OBSzuT
--HG--
extra : rebase_source : cfc291b3452c2154ecd1ca16a2ece0a5a42f0b5e
Updates to Chromium revision 6e4c388c0117fe408b66fbede91081fb1018c5fe.
Adds Verified Media Pipeline function definitions.
MozReview-Commit-ID: 2H8mMNacQqR
--HG--
extra : rebase_source : dc91151c5ffe94f59346b9f4cbab587e6c0701a3
Update to chromium revision 6e4c388c0117fe408b66fbede91081fb1018c5fe.
Includes cdm::ContentDecryptionModule_9 and cdm::Host_9 definitions,
HDCP definitions, and 10 and 12 bit image format definitions.
MozReview-Commit-ID: bYH3OBSzuT
--HG--
extra : rebase_source : d062d233c9a2b59aa5ae5c6e0584ed13b7c83e6e
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
This involved a change to BackgroundHangMonitor, as it initialized sDisabled
incorrectly to false, instead of true, We need sDisabled initialized to true, as
we cannot assume that it is enabled until BackgroundHangMonitor::Startup() is
called.
MozReview-Commit-ID: 94slLTkNk3C
This involved a change to BackgroundHangMonitor, as it initialized sDisabled
incorrectly to false, instead of true, We need sDisabled initialized to true, as
we cannot assume that it is enabled until BackgroundHangMonitor::Startup() is
called.
MozReview-Commit-ID: 94slLTkNk3C
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
On Linux some implementations of time(0) appear to be suffering from integer
overflow and giving us the wrong dates. This causes the time we expose to the
CDM to be wrong, and so licenses passed to the CDM are failing to authenticate,
and Netflix is thus broken on some Linux systems.
This is only happening in Firefox 54 and earlier, as in those versions we use
the WidevineDecryptor to talk to the CDM. In 55 (in beta) and later we use the
PChromiumCDM protocol to talk to the CDM. This doesn't use time(0) to get a
time for the CDM, so it's immune to the problem here.
So this patch makes the GetCurrentWallTime() implementation in
WidevineDecryptor match the code currently being used on Nightly and Beta in
the ChromiumCDMChild::GetCurrentWallTime() function.
Since we use the PChromiumCDM protocol to talk to the CDM on Nightly and Beta
by default, the WidevineDecryptor isn't actually being used on Nightly and
Beta. So this patch will only cause a behaviour change in Release, which still
uses the old backend. However it will make Release run the same code that we're
running in Nightly and Beta, so it should be safe to uplift to Release.
MozReview-Commit-ID: J58iDyinyQG
--HG--
extra : rebase_source : dcdf4a846f7b007526aa626db24598942f13f01d
Includes re-importing gyp files removed from upstream in v56, and then
updating them to match the BUILD.gn file changes.
--HG--
rename : media/webrtc/trunk/webrtc/call/audio_send_stream.cc => media/webrtc/trunk/webrtc/call/audio_send_stream_call.cc
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
The sandbox blocks loading of GMPs when the GMP resides in a directory stored
in a path which contains a symlink or junction point. So resolve GMP paths
fully before instantiating the GMP process.
MozReview-Commit-ID: EvPCpNIDNwg
--HG--
extra : rebase_source : 7df8236c9988a674ae128faf63b949fd711ab4e0
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
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
This allows more use of the implicit version of InvokeAsync() without specifying the storage types explicitly.
MozReview-Commit-ID: 40WisaVX8Jy
--HG--
extra : rebase_source : ba34515788f0bc8264fac9a6897e234966d8b762
extra : source : b651963fe562755c0b2998ae6a95ffad400060ad
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
Jan Beich
Chris Pearce
Carsten "Tomcat" Book
Bevis Tseng
Kartikaya Gupta
Wes Kocher
Bob Owen
Nicholas Nethercote
Michael Layzell
Mats Palmgren
Bill McCloskey
Jean-Yves Avenard
Sebastian Hengst
Randell Jesup
Nathan Froyd
Kris Maglione
JW Wang
Gerald Squelart
Iris Hsiao