Previously, we'd block loading of non-MSE content when there was a MediaKeys
attached, that is, we'd assume that all content was EME content if a MediaKeys
was attached. But some sites attach a MediaKeys and then load non-MSE non-EME
content, and that (despite being a bit silly) shouldn't fail.
MozReview-Commit-ID: 9LupWaehXim
--HG--
extra : rebase_source : 6db281feb27a61b49dc565d4d4562a3d2366fc89
There's no such step defined in the spec. Despite, this code can no longer be called when readyState is HAVE_NOTHING
MozReview-Commit-ID: 2fDoNHt1COp
--HG--
extra : rebase_source : d8b79acee85b00331f55153626038e26cd4a72c7
There's no such step defined in the spec. Despite, this code can no longer be called when readyState is HAVE_NOTHING
MozReview-Commit-ID: 2fDoNHt1COp
--HG--
extra : rebase_source : baa542cdf3144db8b941c20f22548c67bfc06346
Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
Instead of "not visible", "approximately visible", and "visible" (in display port) we now have "approximately not visible", and "approximately visible" which includes "visible".
Enable nsAttrValue::EnumTable to be initialized with enum. So, we could get rid
of the castings in EnumTable. Fix EnumTable initialization comment.
For those untyped enumerations, declare them with uint8_t, as to other typed
enumerations with type size larger than int16_t, force casting to int16_t.
Use {nullptr,0} instead of {0} to represent the last entry.
MozReview-Commit-ID: 7Dma3Apkmxj
--HG--
extra : rebase_source : b2289866c4c33d80c8e170727bf109d018d92f67
In ancient degisn, we would only register audio channel after the media element has audio track and enoguh data to playback,
that is because the "audio-playback" event would be dispatched with the registration, and then shows the tab audio indicator.
However, now the event dispatching doesn't follow with the registration, it would be triggered when the media element has
really audible data which would be notified from media decoder.
Therefore, the media element without audio track or without enough data can also register audio channel agent, it won't affect
the display of tab audio indicator. The reason we need to do that is for blocking autoplay media in the non-visited tab.
The autoplay can be adding "autoplay" keyword or playing by the script, and we don't want to dispatch dom event for blocked
media. Therefore, we should register audio channel agent to know whether it needs to be blocked immediately even the media
element doesn't have any enough data which can let us to distinguish it have any audio track or not (this information can
be known from metadata).
First, we must check whether the media is blocked which is notified by audio channel agent, and then we can decide whether
need to dispatch the event. If we don't register audio channel agent, that we can't get blocking information.
MozReview-Commit-ID: HLLkOuecql1
--HG--
extra : rebase_source : 99c34f0185276ecd5b70ae09959b47c584d1564e
If the media was blocked, we would postpone the dom event and dispatch them after media is resumed.
MozReview-Commit-ID: LcdJtH16qQn
--HG--
extra : rebase_source : 209d18925a88a9e0dac82f2c0695ec1b60f54f63
This adds support for HTMLMediaElement.mozCaptureStream() and
mozCaptureStreamUntilEnded() for a HTMLMediaElement playing a MediaStream.
This is up to spec, while capturing a HTMLMediaElement playing a file is not.
This incompatibility means we cannot mix sources for the returned MediaStream.
As such, a MediaStream returned while the HTMLMediaElement was playing a file
will only have content while the element is playing files. If the src changes
to a MediaStream, the stream will be empty.
It works the same way if a MediaStream was captured while the HTMLMediaElement
was playing another MediaStream.
This is due to TrackID management - MediaDecoder doesn't care, and creates new
tracks when you seek, so users are unable to keep track, while for MediaStream
we control everything from main thread and keep track of the TrackIDs used
previously.
This also adds a separate path from MediaElementAudioSourceNode so that we don't
forward video tracks when the returned MediaStream is only used internally for
WebAudio. We should in that case not require a DOMMediaStream but just forwarding
tracks to a TrackUnionStream should be enough, and will save us some cpu cycles.
This is however fine for now as it's simpler.
MozReview-Commit-ID: Bg8hESDISDU
--HG--
extra : rebase_source : 83885a73ec8cfc5fbe3c30a9330a52cd6b6dff12
extra : source : f1aec79078869c0a6435a1c06957c649d7a40dd9
Sometimes a track is added to a stream synchronously (before the stream is
exposed to script), and sometimes asynchronously (see the mediacapture-main spec
on the "addtrack" event).
In the latter case we might still need to create the MediaStreamTrack object
synchronously for tracking purposes. CaptureStream of Media element playing a
MediaStream wants this.
MozReview-Commit-ID: 7me8xzN7rwj
--HG--
extra : rebase_source : 4f129b127b855e47aad2ae9ab3981ffde057412d
This prepares HTMLMediaElement for having a separate MediaStreamTrackSource for
MediaStreams, StreamCaptureTrackSource.
MozReview-Commit-ID: FVrYxFgvXgA
--HG--
extra : rebase_source : 5c162a0e861fa693fea0ba6b94b8e45446c0c13c
extra : source : a9151ac77a81573b8dbd9fee9c8aa09ba8dc7812
On Linux x64 PGO try, HTMLMediaElement was reliably invoking
decoder->NotifyOwnerActivityChanged() after SetVisible(false) was
called. This caused the pending suspend to be cancelled and the test
waits for an event that never arrives.
Fixed by adding 'forced hidden' to MediaDecoder that overrides the
element visibility that comes from HTMLMediaElement.
MozReview-Commit-ID: 5aRhxxZ5cZd
--HG--
extra : rebase_source : 5a4e1c44ddd2265eab545f8fe19c4ae47cebf7bf
