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
