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
This prepares HTMLMediaElement for having a separate MediaStreamTrackSource for
MediaStreams, StreamCaptureTrackSource.
MozReview-Commit-ID: FVrYxFgvXgA
--HG--
extra : rebase_source : 5c162a0e861fa693fea0ba6b94b8e45446c0c13c
extra : source : a9151ac77a81573b8dbd9fee9c8aa09ba8dc7812
Bubble information from SamplesWaitingForKey to an HTMLMediaElement so that we
can emit a waitingForKey event. If we are unable to decode more samples due to
needing a key the event will be signalled. See
http://w3c.github.io/encrypted-media/#dom-evt-waitingforkey for more information
on this event.
The code in place before this patch handles updating readyState when we are
waiting for a key, this patch adds the event which should be emitted in such a
case. The spec defines certain preconditions should be the case before running
the algo to emit this event. For example, the element should potentially be
playing, and it should have at least HAVE_FUTURE_DATA ready state. This is not
strictly true for when the new code is run, due how existing code handles ready
state. We are honoring the spirit of the spec, though the letter of the spec is
lightly gone against in the handling of the preconditions.
MozReview-Commit-ID: LKlDd4wkRSE
--HG--
extra : rebase_source : 2c61fc41636e430afa23240ad5d26c886124d87f
After a video has been playing while hidden for a certain time, count the time
until it is not hidden anymore (or it has finished playing), to test-drive how
much decoding time would have been saved by the video-decode-suspend feature.
Note that this is done inside HTMLMediaElement by simulating what should happen
in the MDSM, because instrumenting the MDSM itself and friends would have been
harder and more intrusive.
MozReview-Commit-ID: LdxhPtmoXeA
--HG--
extra : rebase_source : 151e1f1383ab5c445eb8c957be8363340cdc4ab1
After a video has been playing while hidden for a certain time, count the time
until it is not hidden anymore (or it has finished playing), to test-drive how
much decoding time would have been saved by the video-decode-suspend feature.
Note that this is done inside HTMLMediaElement by simulating what should happen
in the MDSM, because instrumenting the MDSM itself and friends would have been
harder and more intrusive.
MozReview-Commit-ID: LdxhPtmoXeA
--HG--
extra : rebase_source : c4063d7c39b56e62e4f397bc21ef889ed14307c8
If the timer is currently running, add started time segment until now to
Total(), and add 1 to Count().
This ensures correct values are returned without having to Pause().
MozReview-Commit-ID: JSBvL93GtkE
--HG--
extra : rebase_source : 86923c39e54c778151812a55e2ad9e4e010047fd
Note that this is a simple duration counter based on the existing (non-hidden)
play-time, but it only counts when video is playing while hidden.
There is no bucketing yet, future probes may add finer-grained information.
MozReview-Commit-ID: DUfryXjGBAN
--HG--
extra : rebase_source : 4d0bd7f60329dba6c6a6ab039cc733315c50b686
1. If mHasUserInteraction MediaElement is false, don't run the TimeMarchesOn because the element is not played. 2. Update the activeCueList only in TimeMarchesOn(). 3. Run TimeMarchesOn() at the beginning of play. r=rillian
MozReview-Commit-ID: BhwsIfRm3B2
--HG--
extra : rebase_source : 9713d4f467f1d708f65a25e54435d0c6e8ff1816
