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
The clock that GMP currently exposes to CDMs has second precision. Whereas the
clock that Chromium exposes to CDMs has microsecond precision. We should use
the same clock as Chromium does (since we have its code in our tree already) so
that our CDM harness is as compatible to Chromium as possible.
MozReview-Commit-ID: FssZZFg4vhn
--HG--
extra : rebase_source : 8fab078ba0ecf351a9a8147d3f7434d40a2e0a25
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
The work I did in bug 1306314 seems to have either regressed or never worked
properly for multiple CDM same origin processes. I'd guess the decryptor IPDL
protocol actor ID must not be as unique as I thought. So if we just use a
counter managed by the GMPDecrytorChild, we'll get a per CDM unique ID, which
is sufficient.
MozReview-Commit-ID: KSh72ptX5fn
--HG--
extra : rebase_source : 9dd558aa9b2e9154e70fc328009b79e1daa884b2
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 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
This prevents the Log macro from colliding with the Log function on
IPC ParamTraits definitions.
MozReview-Commit-ID: Hd2v6ilbmGc
--HG--
extra : rebase_source : d26d495878706fe5a2009dd33d226cc71193be13
Sometimes the build breaks because this file uses nsPrintfCString but
doesn't include its header.
MozReview-Commit-ID: CcawXkMucdA
--HG--
extra : rebase_source : 3b36138053c1ffa557fd59af37cf1cfa4166493a
The job id is just a counter, so rather than have other users of DecryptJob
reimplement their own counter, we can push the id/counter code into DecryptJob
itself.
MozReview-Commit-ID: 3RB8ctplWkK
--HG--
extra : rebase_source : f6cd7fddb2bf208419cf314cd7b01c508d68b49e
extra : source : 9b18193d0c1ccdedec25f7395fe124a86660b9d5
This means it can be used in other CDMProxies, specifically the
upcoming Chromium CDM code in bug 1315850.
MozReview-Commit-ID: G26xclqhtSw
--HG--
extra : rebase_source : 041c2cb41ba444e0dea8de3ddcc6a119d480f4f7
extra : source : c7f66edac83a6662d99f59a48f70c539f8ccecc8
The job id is just a counter, so rather than have other users of DecryptJob
reimplement their own counter, we can push the id/counter code into DecryptJob
itself.
MozReview-Commit-ID: 3RB8ctplWkK
--HG--
extra : rebase_source : 7ee0e48ab7638d1f713ee6dd852ab4b5f91119e8
extra : source : 9b18193d0c1ccdedec25f7395fe124a86660b9d5
This means it can be used in other CDMProxies, specifically the
upcoming Chromium CDM code in bug 1315850.
MozReview-Commit-ID: G26xclqhtSw
--HG--
extra : rebase_source : c4c99063f7423b8cbbd49865d2d45eca32c254ce
extra : source : c7f66edac83a6662d99f59a48f70c539f8ccecc8
This means we don't need to include GMPService.h in GMPCrashHelperHolder.h,
in order to use the GMPService inside GMPCrashHelperHolder.
This which prevents an inclusion cycle between GMPService.h and GMPCrashHelperHolder.h
in another patch I'm working on.
MozReview-Commit-ID: AbcXvv4UMyl
--HG--
extra : rebase_source : bdae6e1fbbbe8ce4100f51d2339f69c23f12859f
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
GMP gtests fail on ASAN builds now since the GMPLoader requires a sandbox
starter, and ASAN doesn't run with a GMP sandbox. So only enforce that we
need a sandbox starter if we've built with sandboxing enabled.
MozReview-Commit-ID: GptxIZ7TFIy
--HG--
extra : rebase_source : 6265f91a9c80555b63f71ac5da116450d4728df1
The GMPLoader code was in plugin-container so that it was covered by
Adobe's voucher of plugin-container, but that's no longer necessary.
MozReview-Commit-ID: 3VRBAohRI9I
--HG--
extra : rebase_source : 58a30855ade14af4c4b1420edabd3abb398f232e
DeinitializeDecoder will now only be called if InitializeDecoder has been called first
MozReview-Commit-ID: 93WexomWp92
--HG--
extra : rebase_source : 96dfa5666041340d56fbfce7a46fb7f8f67181dc
Assigns the preference security.sandbox.logging.enabled and the environment variable MOZ_SANDBOX_LOGGING to control whether or not sandbox violations are logged. The pref defaults to true. On Linux, only the environment variable is considered.
--HG--
extra : rebase_source : f67870a74795228548b290aec32d08552c068874
This removes the open of PGMPContent from PGMP, the bridge of
PGMPService and PGMP from PGMPContent, and the spawn of PGMP from
PGMPService. I did these changes all at once because the way the
bridges works it was hard to split it up.
--HG--
extra : rebase_source : d9311e3047b9855ad422838f5a8b6bfdc382d225
We already do this in GMPParent::ReadGMPInfoFile(), and I neglected to check
this in the Chromium/Widevine manifest parsing code. This means we won't add
the GMPParent to our list of GMPParents, and so
navigator.requestMediaKeySystemAccess won't advertise that we support Widevine.
MozReview-Commit-ID: 7x7pbO5vC5e
--HG--
extra : rebase_source : 6d220066d01921d67f0ccf917cb94da887ea01a8
Turns on sandbox denial logging if security.sandbox.logging.enabled is true.
Removes most sandbox violation messages but some related messages generated
by other processes will still get through.
--HG--
extra : rebase_source : 4f06e70d53b0f500cc85a869c5bd7f8ea20d8341
This basically rolls back aec9905b06fe from bug 1278198.
MozReview-Commit-ID: Drho21X6npW
--HG--
extra : rebase_source : 372bc7f4771ec0268535e3df2a745bc9fae8bd3b
This was only to support legacy storage for the Adobe GMP, and we don't support that any more.
MozReview-Commit-ID: BQLTDq535Qa
--HG--
extra : rebase_source : df73267af09847487e78513e774baa209c700a76
Now that we're not supporting Adobe EME anymore, we don't need to
provide a mechanism for GMPs to block browser shutdown.
MozReview-Commit-ID: KUC94IBQiod
--HG--
extra : rebase_source : ed521f28e272de11b2d0c4546b98baf6bd7c6e72
We were seeing almost permaorange failures in the WebRTC H.264/GMP tests
due to the GMP being shutdown in the parent process in between the
content process performing an OOP select operation and then performing
an OOP launch operation.
That is, in GeckoMediaPluginServiceChild::GetContentParent() in between
the SendSelectGMP completing and the SendLaunchGMP completing, the GMP
would shutdown and so when the launch operation ran in the main process
it would fail.
The select and launch are seperate operations so that the crash handler
can be reported to the content process and an association can be made
in the content process between the plugin ID and the crash helper before
we try to launch the GMP. This is so that if the GMP crashes on startup,
we're ready to handle the crash.
However it turns out that if the GMP crashes on startup, the crash report
message comes in after another round of the event/IPC message loop. So we
actually do have time in the content process to connect the crash helper
after the launch fails.
So in order to fix the problem of the GMP shutting down in between select
and launch, we can partially revert the changes I made in Bug 1267918 to
merge selecting and launching GMPs back into a single operation.
MozReview-Commit-ID: 5n4T1Gqlvr3
--HG--
extra : rebase_source : 6e6892a5e32a485b5bfc2f93bddb2d2fe5a422bd
In a similar vein to the previous patch, while we're waiting on a
GetContentParent promise to resolve, we don't want the GMPParent
to shutdown. So make IsUsed() check whether we're waiting on a
GetContentParent promise to resolve, so we don't pull the rug out
from under any code waiting to get a content parent to bridge a
GMP.
MozReview-Commit-ID: 8cTCuXLXMsK
--HG--
extra : rebase_source : 8cc04d57ea1ef4e48c7ff088dbb12eabe4b3b223
extra : source : f79a51d9bd193024f7359ba6ff75076b15d15faf
When GMPService::GetContentParent returns a MozPromise, we end up failing in
test_peerConnection_scaleResolution.html with e10s enabled because we Close()
the GMPContentParent twice. The test causes two GMPVideoEncoderParents to
be created. When the number of IPDL actors on the GMPContentParent reach 0,
we close the IPC connection. With GetContentParent() returning a MozPromise,
it's more async, and so we can end up requesting the content parent in order
to create the second GMPVideoEncoderParent, but while we're waiting for
the promise to resolve the previous GMPVideoEncoderParent is destroyed and
the GMPContentParent closes its IPC connection. Then the GetContentParent
promise resolves, and that fails to operate correctly since it's closed its
IPC connection.
My solution here is to add a "blocker" that prevents the GMPContentParent from
being shutdown while we're waiting for the GetContentParent promise to resolve.
MozReview-Commit-ID: HxBkFkmv0tV
--HG--
extra : rebase_source : 59aa7bcfe8b8f44274d136d6147a946542a64fff
extra : source : 59ab10349b58b0fbe13dca9312ec82332f7c3dbe
The mochitest harness on Windows sets MOZ_GMP_PATH to paths with a mixture of
Windows and UNIX dir separators, and the NS_NewLocalFile() call in
GMPServiceParent::AddOnGMPThread() fails on this input.
We've had this problem before, and if we fixed the test harness to give us
input with platform specific line endings somebody would likely just break this
again someday and have this issue again, so just make the GMP service normalize
the paths it's given to have consistent dir separators.
This makes test_peerConnection_basicH264Video.html pass when run
locally on my Windows machine.
MozReview-Commit-ID: 88hSvTdZuWg
--HG--
extra : rebase_source : 2cf63ccd1155e59f9745163cf4a28d3bdb7012ba
We will use the new type for the generated IPDL message handler
prototype to make sure correct error handling method is called.
MozReview-Commit-ID: AzVbApxFGZ0
This change ensures that we don't create a new random node Id for every
MediaKeys object using Widevine - which has the effect of ensuring
Widevine CDMs that are same origin get created in the same process, and
that persistent storage can be used and retrieved.
MozReview-Commit-ID: K55rkcu9jWo
--HG--
extra : rebase_source : ebca24d2eeb4acd5fb14e0063cf2065c419853b1
Store a mapping of decryptor ID to the CDM instance that the corresponding
WidevineDecryptor is using. This allows us to link GMPDecryptor instances
with the corresponding GMPVideoDecoder.
The CDM is stored inside the CDMWrapper, so that we destroy the CDM instance
when the last reference to the CDM is dropped.
MozReview-Commit-ID: FQYzh77yjoC
--HG--
extra : rebase_source : 772d4bead18a9b88e7f9ee30b0f169a192322e24
Retrieve the ID of the GMPDecryptor from the GMPCDMProxy, and pass that
through to the GMPVideoDecoder's constructor.
MozReview-Commit-ID: IuNsSroZ9Zu
--HG--
extra : rebase_source : d678628dec67a059aec06918f07ea93ecc54a5f9
This enables us to identify GMPDecryptor instances in the child process, so that
in a later patch when we create a GMPVideoDecoder instance, we can associate it
with a GMPDecryptor. Then the cdm::ContentDecryptionModule8 instance that these
two actors are adapted to can know whom it's supposed to respond to.
We use the IPDL PGMPDecryptorChild actor ID as the GMPDecryptor's ID. This is unique
per GMP process, which is sufficient.
MozReview-Commit-ID: 7NKND9VjPUW
--HG--
extra : rebase_source : da14d9a8a7313a609e30649af1a23e79b3e401fe
This change ensures that we don't create a new random node Id for every
MediaKeys object using Widevine - which has the effect of ensuring
Widevine CDMs that are same origin get created in the same process, and
that persistent storage can be used and retrieved.
MozReview-Commit-ID: K55rkcu9jWo
--HG--
extra : rebase_source : 9bd789d05d1f5ed0a00eeb9870668e6335e899e6
Store a mapping of decryptor ID to the CDM instance that the corresponding
WidevineDecryptor is using. This allows us to link GMPDecryptor instances
with the corresponding GMPVideoDecoder.
The CDM is stored inside the CDMWrapper, so that we destroy the CDM instance
when the last reference to the CDM is dropped.
MozReview-Commit-ID: FQYzh77yjoC
--HG--
extra : rebase_source : 7e8c264200e904a4f5a1311f11cd317d98df9791
Retrieve the ID of the GMPDecryptor from the GMPCDMProxy, and pass that
through to the GMPVideoDecoder's constructor.
MozReview-Commit-ID: IuNsSroZ9Zu
--HG--
extra : rebase_source : 6f1db4a019deaedac07fa15c1958270268dcb941
This enables us to identify GMPDecryptor instances in the child process, so that
in a later patch when we create a GMPVideoDecoder instance, we can associate it
with a GMPDecryptor. Then the cdm::ContentDecryptionModule8 instance that these
two actors are adapted to can know whom it's supposed to respond to.
We use the IPDL PGMPDecryptorChild actor ID as the GMPDecryptor's ID. This is unique
per GMP process, which is sufficient.
MozReview-Commit-ID: 7NKND9VjPUW
--HG--
extra : rebase_source : 6ea7dfa358f8d13f7d36db5a581fc075268038b7
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
This ensures that when requests for keysystem access in the content process
retry, they do so on an up-to-date set of capabilities.
MozReview-Commit-ID: JxmlZnFhKYs
--HG--
extra : rebase_source : 6e02777be6a0692c7e157d3ab0a1952c3017c208
We only have one version of a GMP installed at once anyway. This version code
is to support Adobe Primetime, and that's disabled.
Making the behaviour of this code simpler will make it easier to have the
same behaviour of the GetGMPVersion code in e10s and non-e10s mode.
I will be removing this code soon, but I will do that in a later patch, so as
to not complicate the uplift.
MozReview-Commit-ID: 3cn7GhihWzm
--HG--
extra : rebase_source : f4e3470794a2a3dd1d97b8e78fe21df887854dc0
In order to avoid doing a synchronous call from content process to chrome
process in order to determine what GMPs are usable, maintain a cache of GMP
capabilities in the content processes.
We must seed the cache when content processes are created, as the GMP service
is started up and GMPs are added to it before the first (or any subsequent)
content process is created.
MozReview-Commit-ID: Eb4Pu81XHmn
--HG--
extra : rebase_source : ef5de4dd17ee337ca378569691e55d4cfb7939ef
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
Update handling of VP8, VP9 to enable decryption and decoding via widevine.
Update handling with further validation to make sure that invalid video types
are rejected when trying to create widevine decryptor session or init widevine
decoders.
MozReview-Commit-ID: 8FOvUJfxr6L
--HG--
extra : rebase_source : 0f6aed8256d7f106a598b09e6f11efe80f0e4bb2
It was possible for WidevineVideoDeocder when allocating shmems for frames to
become reentrant. If a further frame was allocated during this reentrancy it
would be returned before the first frame being allocated. As frames are fed into
the decoder in order, altering this order for returned frames would result in an
out of order display.
This is addressed by keeping a deque of frames and allocating them in order.
There are changes to guard again reentracy issues with draining also. Previously
it was possible to drain a decoder, but still have a frame allocation be
pending, resulting in a drain being completed, and a frame being returned follow
that. This has been addressed by not draining during reentrancy.
MozReview-Commit-ID: LcIsmyabqAv
--HG--
extra : transplant_source : %DB%F7%E3%DC%2AkZ%9D%11Xc%06a%A0%21%EB%05%0E%BDp
We're already routing the "gmp-changed" observer service notification over from
the chrome process to the content process, and it fires at pretty much the same
time as the "gmp-path-added" notification (and a few more) so we can just switch
to have the MediaKeySystemAccessManager listen on that notification instead, and
we'll be e10s compatible.
MozReview-Commit-ID: EowFDfdWgAJ
--HG--
extra : rebase_source : ad01990278cf9005f6676ef0b7fa0acbf69249eb
The Adobe GMP only supports up to GMPDecryptor version 7. We're now up to
version 9. So we need to provide an adaptor to convert the old version to run
with the new interface.
MozReview-Commit-ID: 5dKreev7JMv
--HG--
extra : rebase_source : b9aa1b66ad23e9f7ddbe60b71c94c161ad974818
The Adobe GMP only supports up to GMPDecryptor version 7. We're now up to
version 9. So we need to provide an adaptor to convert the old version to run
with the new interface.
MozReview-Commit-ID: 5dKreev7JMv
--HG--
extra : rebase_source : f944a40e2287c7a7dd01a2fb145a9e5882dd2368
Chris Pearce
JW Wang
Carsten "Tomcat" Book
Sebastian Hengst
Jeff Walden
Jean-Yves Avenard
Iris Hsiao
Wes Kocher
Tom Tromey
David Anderson
David Anderson
Sylvestre Ledru
Brad Lassey
Jay Harris
David Parks
Andrew McCreight
Bevis Tseng
David Parks
Ryan VanderMeulen
Mike Hommey
Andrea Marchesini
Chris Peterson
Haik Aftandilian
James Cheng
Gerald Squelart
Jed Davis
Kan-Ru Chen
Andi-Bogdan Postelnicu
Kilik Kuo
Cervantes Yu
Phil Ringnalda
Michael Layzell
Tim Huang
Nicholas Nethercote
Bryce Van Dyk