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
1. Delete MediaPrefs::EMEChromiumAPIEnabled() and related logic.
2. We now only use the Chromium CDM interface so delete the opposite side check of MediaPrefs::EMEChromiumAPIEnabled().
MozReview-Commit-ID: GDFrrf4WlWf
--HG--
extra : rebase_source : 987667dd47757afd58e7da10b60c0e1e1ec89d39
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
When we shutdown the browser while the GMPService is active we can end up
leaking a GMPParent, GeckoMediaPluginServiceParent, and a Runnable. I tracked
this down to the runnable dispatched to the GMP thread in
GMPParent::ChildTerminated(). The dispatch of this runnable is failing as we
are dispatching the runnable to a reference of the GMP thread which we have
previously acquired, but that thread is now shutdown. So the dispatch fails,
and if you look in nsThread::DispatchInternal() you'll see that we deliberately
leak the runnable if dispatch fails! The runnable leaking means that the
references it holds to the GMPParent and the GMP service parent leak.
The solution in this patch is to not cache a reference to the GMP thread on the
GMPParent; instead we re-request the GMP thread from the GMPService when we
want it. This means that in the case where the browser is shutting down,
GMPParent::GMPThread() will return null, and we'll not leak the runnable. We'll
then follow the (hacky) shutdown path added in bug 1163239.
We also need to change GMPParent::GMPThread() and GMPContentParent::GMPThread()
to return a reference to the GMP thread with a refcount held on it, in order
to ensure we don't race with the GMP service shutting down the GMP thread
while we're trying to dispatch to in on shutdown.
MozReview-Commit-ID: CXv9VZqTRzY
--HG--
extra : rebase_source : e507e48ee633cad8911287fb7296bbb1679a7bcb
This ensures that when we're using the ChromiumAdapter that we actually ask it
whether it'll work, rather than asking the adapter we're not using.
MozReview-Commit-ID: 85nZPl9MdWa
--HG--
extra : rebase_source : 90de89bec9b004859c3c2c09ed8efbd255acc141
Infrastructure necessary to create an instance of the CDM process.
MozReview-Commit-ID: 7oQ86x6BNWj
--HG--
extra : rebase_source : c725a958c507b7f93ce9cfccc475f259ae9ccbc2
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
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
This basically rolls back aec9905b06fe from bug 1278198.
MozReview-Commit-ID: Drho21X6npW
--HG--
extra : rebase_source : 372bc7f4771ec0268535e3df2a745bc9fae8bd3b
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
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
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
Instead of controlling visibility of EME keysystems by build config, do it by
preference. This means keysystems can be turned on easier.
MozReview-Commit-ID: Ky1zrHPubOJ
--HG--
extra : rebase_source : 35d9c26436a86683b902225e7b0d6645b02d8ff9
Instead of controlling visibility of EME keysystems by build config, do it by
preference. This means keysystems can be turned on easier.
MozReview-Commit-ID: Ky1zrHPubOJ
--HG--
extra : rebase_source : 7d68ad8389afdac8fcfffd2c505f8467107c05a5
