Assert that the CDM wrapper is given a non-null CDM pointer.
(so GetCDM() doesn't need to be null-checked.)
Renamed WidevineVideoDecoder mCDM to mCDMWrapper, to avoid (my) confusion.
Assert that WidevineVideoDecoder is given a non-null CDM-wrapper pointer.
Assert that WidevineVideoDecoder only accesses the CDM before DecodingComplete.
Small optimization: Move aCDM into mCDM (to save an AddRef/Release pair).
MozReview-Commit-ID: yKupY067ly
--HG--
extra : rebase_source : 94140b423a04f28368de0831761406c145fad93e
Check the return result from Widevine's CDM creation function, and handle
failure.
MozReview-Commit-ID: HYvKgdK53aQ
--HG--
extra : rebase_source : b3e28ba5e0020e3a6dd77c8a83b58be233fdc770
Ensure that there is a CDM before creating a video decoder that relies on that
CDM. This is mainly to prevent using the Widevine video decoder alone, without
decryption.
MozReview-Commit-ID: 7p49CnmV2r7
--HG--
extra : rebase_source : 49b07100b2be56584bc14f41d39d4872f0539c3a
If you request a GMPParent with a nodeId, you should get any already running
instances with the same nodeId in preference to cloning an existing GMP and
assigning it the nodeId.
This is ensures that EME GMP actors that are same-origin run in the same GMP
instance.
The GMP gtests are failing because of the cross-origin checks in
GeckoMediaPluginServiceParent::SelectPluginForAPI(). The loop there selects the
first GMPParent that can be used from the nodeId passed in. We previously
assumed a GMPParent can be used from a nodeId if the GMPParent has the same
nodeId, or if it has not loaded its process and it has no nodeId. The problem
with assuming that, is if an in-use GMPParent with the target nodeId lies in
the GeckoMediaPluginServiceParent::mPlugins list after a GMPParent with no
nodeId, we'll end up using the first GMPParent (the one with no nodeId) rather
than the one with the target nodeId.
The solution is to change GeckoMediaPluginServiceParent::SelectPluginForAPI()
so that effectively if we have a target nodeId, we'll select the first
GMPParent that has the same nodeId, or we'll clone the first which supported
all the requested capabilities/tags.
This means when you request a GMPParent with a given nodeId, you'll get the one
with the same nodeId (origin) by preference.
MozReview-Commit-ID: 4yVnrO8B1Pg
--HG--
extra : rebase_source : 5db7c6ef5f360df7d2244ca828b68b340c4e9a41
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
This will enable log parsers to find step boundaries easier.
MozReview-Commit-ID: G4OaViDd9Fv
--HG--
extra : rebase_source : a7e94e4ec088c4fed7eb2b7a1662e308296e8bb2
Add a js/src/.clang-format that better fits the style used in SpiderMonkey.
Also add a js/src/jit/arm64/vixl/.clang-format to handle the imported VIXL
sources. These sources are from an external source, and they are not
reformatted to make merging future changes easier.
MozReview-Commit-ID: CgzA24csYvp
--HG--
extra : rebase_source : a420b74620bd61452a182b56e42970f4d991148b
We use _pretty_path when specifying the targets of generated files, so
we need to use _pretty_path for the inputs as well. Otherwise make won't
know that they refer to the same file, and result in "No rule to make
target" errors.
MozReview-Commit-ID: JTdLFbkX1J0
Some generated files will depend on other generated files, but still
need to be in the export tier because they are C++ headers.
MozReview-Commit-ID: AFvp92lF0xy
Rename the VIDEO_MSE_UNLOAD_STATE telemetry probe to just
VIDEO_UNLOAD STATE and reactivate it. We were using this
to track MSE deployment success and would now like to
generalize it to all media playback.
We can remove this probe from histogram-whitelists.json because
we now define alert emails and bug numbers.
MozReview-Commit-ID: Jwmdkgl8CC3
Rename the VIDEO_MSE_PLAY_TIME_MS telemetry probe to just
VIDEO_PLAY_TIME_MS and make it active for all video playback.
We were using this to track MSE deployment success. Now we'd
like to do something similar for video playback in general,
regardless of the origin. This allows us to simplify the
collection code somewhat.
MozReview-Commit-ID: 7s8pOQWipf4
This changes to match the spec, which also aligns the behavior of get
and set (get already maps out-of-range values to the default value).
There is currently no interoperable behavior here, but this aligns us
with IE -- tested in 11, hopefully true for Edge too.
On the way, I also fixed the fact that video's height and width were
being treated as signed.
Crash reporting for GMPs being used from the EME call site are not generating
crash reports because they depend on the MediaKeys object calling
GMPService::AddPluginCrashHandler() to associate a window to which the
PluginCrashedEvent is fired. This doesn't work with e10s enabled because the
GMPParent which causes the plugin crash handlers to run is in the chrome
process, but the MediaKeys which adds the handler is in the child process. So
the crash handler is on the GMPServiceChild, but we only run the crash handlers
that were added to the GMPServiceParent in the chrome/parent process.
The solution is to broadcast a message from the chrome process to all the
content processes when a GMP has crashed that causes the GMPServiceChild to
also run its crash handlers.
MozReview-Commit-ID: 8Lek16G9ZGb
--HG--
extra : rebase_source : 180691046812df474ea33324d2b98ac71d11c9cd
Changes in this patch:
* GCLI gave up with testing via phantomjs a while ago, but the docs didn't keep
up, so this fixes the docs.
* gcli/languages/command isn't used in Firefox, but on the web if a converter
wrongly produces a null DOM node, then the UI just looks blank, so this change
makes the error more obvious. However we don't use this in Firefox. I'd like to
remove the module, but not in this patch.
* The delegate type (used when we want to defer the type of a parameter, e.g.
with "pref set PREFNAME VALUE" where the type of value depends on PREFNAME)
forced children to be prediction-less. This allows them to decide for themselves
* The file type assumed that the local filesystem was the same as the remote one
which is clearly wrong. The change to gcli/types/file fixes that.
* Typo fix to gcli/util/util
* On very slow connections gcli/cli.js could get in a pickle where 2 changes
happened out of order. We've planned for this, but got in wrong, so this just
adds a bit of defensive programming.
MozReview-Commit-ID: H88W5UDCikM
--HG--
extra : rebase_source : b4e3da062881a841221c4f8cc9e64046756ed763