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
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
MozReview-Commit-ID: KD6GkT6yq5u
After landing bug 1264199, the audible-checking has possibility to fail when the input needs to be resamling.
Resampling only happens when the input sampling rate is not equals to device out sampling rate and we don't want the sampling problem affecting our audio-playback tests, so we change the sampling rate of these ogg file to avoid resampling.
It is a WORKAROUND and should be reverted after landing bug 1269672.
--HG--
extra : rebase_source : 52288b7a2f587f0ea5af7b1498e957d2716bcd63
This function is roughly copied from browser/base/content/test/general/head.js.
It has been widely used in browser chrome mochitests, and should be fine to
have it available to all mochitests via SimpleTest.
MozReview-Commit-ID: DhIfgJiUhXK
--HG--
extra : rebase_source : 95ab1cd6c1ab5f6c0d8f0171865722ca76b41c6e
