Mark video element as tainted (stored on the decoder owned by video element) when the video is used as source to drawImage() on canvas.
MozReview-Commit-ID: HdciVwhqPu3
Mark video element as tainted (stored on the decoder owned by video element) when the video is used as source to drawImage() on canvas.
MozReview-Commit-ID: HdciVwhqPu3
If the media starts after muting the tab, IsOwnerAudible() would always return
"eNotAudible". It causes that the "play tab" icon can't be displayed because we
only show the "play tab" icon for the "eMaybeAudible" or "eAudible".
We should check whether owner owns the audio track to decide the return value.
MozReview-Commit-ID: DGwkArx0a4R
In bug1319771, we found that the tab would become visible unexpectly in short
period in some situations. We don't want to resume the tab in this kind of
situation, so we check whether there is any alive media component in the tab
using IsServiceStarted(). However, since we have lots different ways to create
the service, this function is not accurate at all.
Therefore, we can add media element directly to the document when it binds to
tree so that we can really know whether there is any alive media component.
MozReview-Commit-ID: FvZFg91IqgE
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 5RnyBRE73lQ
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 703JHj9dICT
We don't have an MP4 demuxer that can handle VP9 in non-fragmented MP4. Jay's
change to DecoderTraits in Bug 1339204 will make MediaSource.isTypeSupported()
report that it can play VP9 in MP4. But we don't want to report that we can
play VP9 in MP4 in HTMLMediaElement.canPlayType(), as usually canPlayType() is
used with the intention to check for whether fragmented MP4 can be played. So
we need to special case canPlayType() so that it reports that it can't play
VP9 in MP4.
The upcoming Rust demuxer will be able to support VP9 in MP4, so once we've
enabled that, we can confidently report in canPlayType that we support VP9 in
MP4.
MozReview-Commit-ID: G0q5ho5N2wr
If the blocked media is paused before resuming it, we should not resume it again
after the tab is visible. The way to achieve that is to unregister the agent so
AudioChannelService can't resume that media because we have disconnected their
relationship.
MozReview-Commit-ID: 6Dq4K9hVsU0
If the blocked media is paused before resuming it, we should not resume it again
after the tab is visible. The way to achieve that is to unregister the agent so
AudioChannelService can't resume that media because we have disconnected their
relationship.
MozReview-Commit-ID: 6Dq4K9hVsU0
MediaContentType can only be created through MakeMediaContentType(), which
returns a Maybe<MediaContentType>.
If the return value is Nothing, parsing failed.
Otherwise the contained MediaContentType object is guaranteed to be valid;
E.g., GetMIMEType() will always return a non-empty string.
Note that this interface will change a lot in the following bugs&patches, so
please don't worry about the 'Get' in the never-failing GetMIMEType(), it will
be gone soon!
MozReview-Commit-ID: IjGKkQ6RVd4
Because we add tracks to the output streams async, it's possible to switch the
mSrcStream of a media element and *then* get a notification of an added track,
when this track originated from the old mSrcStream.
If the new mSrcStream is an output stream of the media element, this would
again add a new track async, which on the next event loop spin would show up
on mSrcStream, and the loop continues.
MozReview-Commit-ID: HmKgXLYmubh
With the attached test case I was failing an assert in a debug build because
NotifyMediaTrackEnabled exited early due to `mReadyState == HAVE_NOTHING` but
NotifyMediaTrackDisabled didn't. The latter would fail an assert.
MozReview-Commit-ID: 7Frpj62s0Bc
