Update content_decryption_module.h and other Widevine headers. This removes the
CDM8 interface and adds in the CDM10 and CDM11 interfaces. As such this patch
removes references to CDM8 from the code and adds some of the foundations for
supporting CDM10. Most of the CDM10 code will be implemented in another bug, but
there are a number of cases where it was straight forward to shuffle CDM8+9 code
-> CDM9+10, rather than deleting it and replacing it later.
Differential Revision: https://phabricator.services.mozilla.com/D5628
--HG--
extra : moz-landing-system : lando
We now only use the Chromium CDM interface, so there is no need to check isWidevine.
We don't use WidevineAdapter anymore so remove the related check and unused classes.
MozReview-Commit-ID: 3y1lH3OMhwL
--HG--
extra : rebase_source : 955395f3bbbd523236e9ac2480ef21093a281084
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
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
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
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
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 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
This menas we can have GMPVideoDecoder's AVCC -> AnnexB conversion done by the H264Converter, and
simplify the code in WidevineVideoDecoder.
MozReview-Commit-ID: 3HT5VXth6LL
--HG--
extra : rebase_source : b840489edafa5dc981ba44f722d92083a40e34cd
This makes it easier to reuse in the ChromiumCDM code.
Also add an ExtractBuffer() method, which allows us to Move() the contained nsTArray
out without needing to copy the data.
MozReview-Commit-ID: 9suJSfXTVYy
--HG--
extra : rebase_source : 6eec99eb5329f3b8c3bb14d22459fee3bd95caf5
This makes it easier to reuse in the ChromiumCDM code.
Also add an ExtractBuffer() method, which allows us to Move() the contained nsTArray
out without needing to copy the data.
MozReview-Commit-ID: 9suJSfXTVYy
--HG--
extra : rebase_source : 89540b254249833cf8bb09792bb33cc402977d5a
This prevents the Log macro from colliding with the Log function on
IPC ParamTraits definitions.
MozReview-Commit-ID: Hd2v6ilbmGc
--HG--
extra : rebase_source : d26d495878706fe5a2009dd33d226cc71193be13
Fixed coding style of files encountered in P1 and P2.
MozReview-Commit-ID: LApVu9K2oto
--HG--
extra : rebase_source : e3bb296baaec9df2011ff312fec2eda19dd125e6
This works, at least on Windows, if the NSPR_LOG_FILE is set at a file
in the OS temp dir. This means we can turn on CDM logging in release
builds, in the sandboxed child process, without needing to recompile
to #define on logging.
This will make debugging issues with the CDM easier.
MozReview-Commit-ID: 6cAxMy4lv3T
--HG--
extra : rebase_source : eb75bba8e0dc38d1a0137cef28b7589ded43351a
Note: Only the Adobe GMP used enum storage, so not that it's unused we may
as well remove this.
MozReview-Commit-ID: JtmQ69eJzaI
--HG--
extra : rebase_source : 29929e680dc1692b957b34ce274c4944743768e8
DeinitializeDecoder will now only be called if InitializeDecoder has been called first
MozReview-Commit-ID: 93WexomWp92
--HG--
extra : rebase_source : 96dfa5666041340d56fbfce7a46fb7f8f67181dc