This will allow us to broadcast a notification to the GMPServices running in
the content processes when they need to shutdown.
MozReview-Commit-ID: FviFDgNMnUV
--HG--
extra : rebase_source : f4ad3c6df0e14c88db1199fbe6281d67f98590ae
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
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
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
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
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
This enables callers to specify a way to determine the correct window to
dispatch the PluginCrashed event to should the GMP actor crash.
We need a way to determine the correct window at crash time, as the GMP's
window can change at runtime. For example, if the GMP is being used for
unencrypted decoding, the <video> element can be moved to a new browser window
at runtime.
Note: I don't handle disconnecting the GMPCrashHandlers in this patch; we do
delete the GMPCrashHandlers in this patch when their associated GMP crashes, and
in the next patch we handle disconnecting GMPCrashHandlers in the case where
we don't crash.
MozReview-Commit-ID: DrwcZAB6Ys0
--HG--
extra : rebase_source : 8da188b68456914773e6adae8cbccd6bf6a6e7a7
This will allow us to attach a crash handler to a GMP process after deciding
which GMP to load but before actually loading it.
MozReview-Commit-ID: HwBZU2Q4TX6
--HG--
extra : rebase_source : a68b9cbc31c0b886ba491f8f15f02e4d0e32cae7
GeckoMediaPluginService::mAbstractThread was not reset as expected from
ShutdownGMPThread, meaning it would retain a reference to the GMP thread, and
it would allow dispatch attempts to the GMP thread after shutdown.
Also mAbstractThread was not protected by a mutex (as mGMPThread was), which is
definitely needed now that it can be reset at shutdown time.
As its prefix implies, GetAbstractThread could return a nullptr, so it should
be checked before every use.
Note that this GetAbstractThread call (and its check) has been moved closer to
the start of functions using it, to avoid unnecessary and potentially invariant-
breaking partial work to take place when we can know in advance that it won't
fully succeed because the GMP thread is not available.
MozReview-Commit-ID: B1drOeM65hr
--HG--
extra : rebase_source : 1d389c663e26a25035bf2aa22b2cca478ef954fe
Prior to this change, we'd store the GMPStorage records for private browsing
sessions in the GMPStorageParent. The problem with this is that they only have
a lifespan matching their corresponding GMPParent. This means that if a GMP
stores something in a PB session, and the GMP is shutdown and then re-created,
we are likely to loose the stored data. This could mean that the PB session
gets results it doesn't expect, and thus expose a way for PB mode to be
detected.
MozReview-Commit-ID: 1OMD0LvidYs
--HG--
extra : rebase_source : 75661a7b1717e39a29c3e12ad203d9273e8485ab
The GMP which GeckoMediaPluginServiceParent::FindPluginForAPIFrom() returns
depends on the order in which GMPs lie in GMPServiceParent::mPlugins. However
when we shutdown a GMPParent we remove and then re-append the GMPParent to
mPlugins. This means the order in which GMPs lie in the list changes.
So when WebRTC requests an H.264 decoder, the first time it will get OpenH264,
since that's first in the list. But once we dispose of that decoder, its
GMPParent will be cloned and the clone will be appended to the end of the
list. This means the next time WebRTC requests a decoder, it'll get whatever
was next in the list.
This could be the Adobe GMP, which seems to be able to handle whatever WebRTC
is putting into it. However, if you do this enough times, you'll get the
Widevine CDM, which can't handle whatever WebRTC is putting into it.
So a quick hack to fix this is in ReAddOnGMPThread is to re-insert the clone
of the GMP into the slot in mPlugins that the original occupied. Then WebRTC
will always get OpenH264 whenever it requests for an H.264 decoder, as the
order of the GMPParents in mPlugins won't change.
MozReview-Commit-ID: Ii4AMqDqAo9
--HG--
extra : rebase_source : 62c10bc5b77ef259917aa6c88309be2423c93914
Now that adding GMPs to the GMP service is async under the hood, for safety
the GeckoMediaPluginServiceParent needs to expose when adding a GMP
has finished so that things that depend on GMPs being present can be reliable.
For example, the call to GMPDecoderModule::UpdateUsableCodecs() that happens
at the end of AddPluginDirectory depends on the GMPs being up to date, so it
needs to happen after the add has finished.
MozReview-Commit-ID: Fn8b0GNILNg
This means we wait for the GMP service to have finished detecting all available
GMPs from the environment before we start creating GMP actors. Without this, we
get gtest failures due to gtests trying to create GMP actors before the async
GMPServiceParent::LoadFromEnvironment() has completed, i.e. we fail to create
actors because we've not had a chance to setup the GMPParent capabilities yet.
MozReview-Commit-ID: Hl4o1c4QthJ
Remove GMPVideoDecoderTrialCreator, and the tests and IPC/IDL supporting it.
--HG--
extra : commitid : HlbJPl2gPAl
extra : rebase_source : fe1773014e5d09da264f85d464e408aca46a60c4
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h