The first checking condition in the IsAllowedPlay() is used to prevent the play() operation
is called by untrusted JS when media.autoplay.enabled=false. Therefore, we don't need to check
that in CanActivateAutoplay().
MozReview-Commit-ID: 6yqoG8ISyra
--HG--
extra : rebase_source : a3e52a1a5591691f503d7d4ca78dda63c05aef27
Because the agent's initialization might fail if we don't get the valid inner window, we need to
check whether the agent exists before calling the agent's method.
MozReview-Commit-ID: IUuvyGh7CMd
--HG--
extra : rebase_source : 54d0811aad736abdbac5ae7c3cd8cfebed88923a
We don't want to stop the loading process even we canceled the play operation.
MozReview-Commit-ID: FyPqBlDKYo0
--HG--
extra : rebase_source : fdbc4390a7763bdbe26e8b809d977234bb5360ea
The old way is to start playing first, and then block the media element. This
way is too complicated because it involves lots of interal state and isn't intuitive.
The new way is to ignore the play if the media element should be blocked. It's
easy to know and we doesn't need to keep any internal states because we don't play
the media element.
MozReview-Commit-ID: B20e0pvXES4
--HG--
extra : rebase_source : 6bff5447783c2997050e5c69884afe2c85ddf382
We create audio channel agent in the beginning in oreder to use some agent's methods.
But the agent is still started after media element starting playing.
MozReview-Commit-ID: KPGb7snB2t7
--HG--
extra : rebase_source : dba4b687f572d520481721f48a0b4e9796f73e1f
We uses "media-playback" event to notify fennec media control about media start
and end. However, if we resume media which was paused by media control, it won't
send any notification to JAVA side so that the MediaControlService can't change
the correct playing icon.
Therefore, we create new event to inform this situation.
MozReview-Commit-ID: zScaHxvHXM
--HG--
extra : rebase_source : e1434840de36d8621a58fc7406b0f42673a2f3db
This means 'waitingforkey' will be fired at a predictable time.
MozReview-Commit-ID: HMt1RbgrbuR
--HG--
extra : rebase_source : cb8c36eacd3e78ae5105cd30da7a51d8241dbd5b
Since I want to use more agent's functions in MediaElement and I don't think these functions need to be exposed on IDL level. (for other languages binding)
Therefore, I want to use AudioChannelAgent directly in MediaElement.
MozReview-Commit-ID: 43FvDeLpZPt
--HG--
extra : rebase_source : 78741d791eb66cfb6223866ce823f217e3438fdb
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
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
Alastor Wu
Andreas Pehrson
Chris Pearce
JW Wang
James Cheng
Jean-Yves Avenard
Phil Ringnalda
Carsten "Tomcat" Book
kaku@mozilla.com
Jeremy Chen
Gerald Squelart
Bryce Van Dyk
bechen
Iris Hsiao
Kaku Kuo
Sebastian Kaspari
Gregory Szorc
ctai