In some cases, we need to resend missed VideoSegment to new added MediaStreamVideoSink. Append the latest video frames from updateTracks.
MozReview-Commit-ID: 76RFs5fgKpY
--HG--
extra : rebase_source : 31e5c41caedd337e85fe9277752f6775849627f0
1. The return value is not used.
2. It should be called only when mSentFirstFrameLoadedEvent is false.
3. Transition to SEEK if there is any pending seek or DECODER_STATE_DECODING otherwise.
MozReview-Commit-ID: LIO0MPGzhsX
--HG--
extra : rebase_source : 591339cf0c239be618ecf25e384baab9c0bb35be
We move the handling of pending seek from the entry action of DECODING to that of DECODING_FIRSTFRAME.
MozReview-Commit-ID: qMnJ0ON2cK
--HG--
extra : rebase_source : d35985d8d66b201a842aea0eeb0650e8ade5cc5b
It is impossible to finish decoding first frames while waiting for data.
MozReview-Commit-ID: 8eR8Rf9TuD8
--HG--
extra : rebase_source : f8d14b294f0518f48f72828b3e9ed5f2b18a3479
MDSM used to transition to DECODING in the following places:
1. BUFFERING
2. OnMetadataRead()
3. WAIT_FOR_CDM
4. SeekCompleted()
We will transition to DECODING_FIRSTFRAME in case 2 and 3.
For case 1, BUFFERING makes sense only after decoding first frames. So BUFFERING
should never transition to DECODING_FIRSTFRAME.
For case 4, we always finish decoding first frames before completing seek. So
It should not transition to DECODING_FIRSTFRAME either.
MozReview-Commit-ID: 7VnK82wjgZv
--HG--
extra : rebase_source : c92150a2cd989286d680760c6b7dc615fe58b65e
When separating decoding frist frames from the DECODING state, we need
to change the test `mState == DECODER_STATE_DECODING` to
`mState == DECODER_STATE_DECODING || mState == DECODER_STATE_DECODING_FIRSTFRAME`.
However, we don't make changes for those where mSentFirstFrameLoadedEvent is
proven to be true. Because there is no way for mState to be DECODING_FIRSTFRAME
when mSentFirstFrameLoadedEvent is true.
MozReview-Commit-ID: 7jv3SDlmBBG
--HG--
extra : rebase_source : d7212fa84d81cb1874e6a76fb92627255039e859
Cubeb can be in three states: Uninitialized, initialized (or in
error), or shutdown.
This will ensure that we only initialized cubeb once, and that
we don't attempt to re-initialize it after shutdown.
MozReview-Commit-ID: 8LhRe7bvS4K
--HG--
extra : rebase_source : 3b58d94ad1e578c9316455893deb2d826aefe0dc
DiscardRemaning was needed to prevent debug-time assertion that the buffer was
read completely or explicitly discarded.
However this required extra work in cases where buffer didn't need to be read
to the end.
And also it could cause crashes (in debug versions) if a buffer was not fully
read, be it because the parser was incorrect or because the media file itself
was wrong (though possibly still readable despite that).
Finding parser issues is still possible by manually instrumenting ByteReader
during development.
And reading media file with small recoverable errors is a bonus.
MozReview-Commit-ID: 2RUYzaYAeRW
--HG--
extra : rebase_source : 26c41758b1b2c87542bf4e41d08e361198ca5b13
FinishDecodeFirstFrame() is called from:
1. MaybeFinishDecodeFirstFrame() when mSentFirstFrameLoadedEvent is false.
2. SeekCompleted() when mSentFirstFrameLoadedEvent is false.
MozReview-Commit-ID: HOV3ZeS2qB0
--HG--
extra : rebase_source : c1e19b966c55a6d4ef9b1e4956e719d4d861bb32
The VideoPuppeteer now uses played ranges where possible to calculate the
remaining time. It will also use the played ranges to determine the expected
duration where possible. This is more accurate than using the time when the
tests first poll the video. The first poll time was previously self._start_time,
but I've renamed this to self._first_seen_time, to reduce ambiguity -- the video
may have started playing before this time.
The playback_done function has had it's remaining time check relaxed. Previously
it was possible to skip over the window where a video would be considered
complete, that window is now expanded so that if the start threshold is passed
the video is considered played.
A concrete example: the tests could play a 90 second video, but the duration of
the test is set to 60 so only part of the video need be played back before the
test completes. If a 1 second interval was used in the tests there would be a
window between 59 to 61 seconds during which if the video were polled it would
be considered complete. However, due to latency polling may not take place in
this window, leading to racy fails. Now the tests will consider any point beyond
59 seconds to be complete.
MozReview-Commit-ID: J6DpqCbZxUg
--HG--
extra : rebase_source : 7990e4eee0bce30718b875f652c7148110cd4c3f
This is a quality of life change. Since VideoPuppeteer uses, and since I plan on
using the played ranges of a video element more, it is useful to output them as
part of the str representation.
MozReview-Commit-ID: LwVPfVtFF1v
--HG--
extra : rebase_source : 1ebe4b7a7176a15f7e9300dee84103a8f6b86708
The only time we need to use InputExhausted is for the initial video decoding or when a frame is dropped.
MozReview-Commit-ID: IrHqZXJwQe1
--HG--
extra : rebase_source : eb7ff378adafe05458b79a6c3b6c7593c84d40a2
The MediaFormatReader will no longer attempt to decode several frames in advance and ahead of the MDSM actually requesting it. The speed advantages were dubious at best, and as most MediaDataDecoders abused the use of InputExhausted callbacks we had to place artificial throttle that would often cause side effects.
As such, it is now expected that the MediaDataDecoder will now always call InputExhausted once Input has been called. InputExhausted indicates that the current decoding session has completed and the MediaDataDecoder is waiting for another input.
MozReview-Commit-ID: 9KUpNP9jozV
--HG--
extra : rebase_source : d261a5eb98de54d5bd29acb738c4205c56abca6b
mSentFirstFrameLoadedEvent is sufficient to tell us whether we can handle the pending seek now or later.
MozReview-Commit-ID: KzDd2brvKPA
--HG--
extra : rebase_source : 3c01e4193789c2b535a68ba65d76373269acfc2f
The only time we need to use InputExhausted is for the initial video decoding or when a frame is dropped.
MozReview-Commit-ID: IrHqZXJwQe1
--HG--
extra : rebase_source : d9fec0f88d2c0a878723d75d79aa3ff63b5938cc
The MediaFormatReader will no longer attempt to decode several frames in advance and ahead of the MDSM actually requesting it. The speed advantages were dubious at best, and as most MediaDataDecoders abused the use of InputExhausted callbacks we had to place artificial throttle that would often cause side effects.
As such, it is now expected that the MediaDataDecoder will now always either return a decoded sample or call InputExhausted. Never both.
MediaDataDecoder will continue to work as-is, even if they call InpuxExhausted too many times as the MediaFormatReader will only feed a single sample at a time.
MozReview-Commit-ID: 9KUpNP9jozV
--HG--
extra : rebase_source : ebb919fd3f1ce1adf5d08ed3f4292839b84c8321
Many of the youtube URLs were not being used in tests. Many were are/also dead.
Furthermore, non-embedded links are causing issues due to the next video auto
play feature defaulting to on in youtube.
This is a quick once over to remove unused links, prune some of the dead, and
rewrite those that can be embedded to embedded URLs. In future I would like to
see the embedded links and non embedded separated into their own files. However,
theses changes are a halfway house that will not break compatibility downstream.
MozReview-Commit-ID: 4aPMNjD3LC4
--HG--
rename : dom/media/test/external/external_media_tests/urls/youtube/long3-crashes-720.ini => dom/media/test/external/external_media_tests/urls/youtube/long2-crashes-720.ini
rename : dom/media/test/external/external_media_tests/urls/youtube/long4-crashes-900.ini => dom/media/test/external/external_media_tests/urls/youtube/long3-crashes-900.ini
rename : dom/media/test/external/external_media_tests/urls/youtube/short0-10.ini => dom/media/test/external/external_media_tests/urls/youtube/short1-10.ini
rename : dom/media/test/external/external_media_tests/urls/youtube/short3-crashes-15.ini => dom/media/test/external/external_media_tests/urls/youtube/short2-crashes-15.ini
extra : rebase_source : a5abcc8d7b1f1f1e3e2b6303f91b6183f4e4d9ee
Rework the Youtube puppeteer to look up player and video element based on class
names, instead of ID. This means that the tests can work with embedded players.
This has the benefit that we can use youtube embedded links
(youtube.com/embedded/<videoId>), which do not suffer from auto play related
issues (auto play jumping to another video).
MozReview-Commit-ID: 9UFyL7di6gH
--HG--
extra : rebase_source : 69301bfa2b7ea9fd729742ae670ecb6e8209c4f9
Note nextState is either DECODER_STATE_COMPLETED or DECODER_STATE_DECODING in SeekCompleted().
Their entry actions call ScheduleStateMachine() directly or indirectly.
MozReview-Commit-ID: DpDW7qtlogV
--HG--
extra : rebase_source : a6faef46929de27a863d22d152d8721d68524edf
|SetState(nextState)| is the equivalent of the if/else.
MozReview-Commit-ID: 51ab4BBdd4T
--HG--
extra : rebase_source : ec0eb034dad98a20f961c94e72319fb80ba121c5
UpdatePlaybackPositionInternal(), |mQuickBuffering = false| and |mMediaSink->Redraw| should belong to
the exit action of SEEKING. By change the order of the statements, we have a better definition/scope
for the jobs of each state.
MozReview-Commit-ID: 6WESdwaD8Ba
--HG--
extra : rebase_source : eab747abcf2cf375ed99d5800eba9c5558e1436c
StartDecoding() is called from several places where mState is proven to be not DECODER_STATE_DECODING:
1. Called by PlayStateChanged() when mState is BUFFERING.
2. Called by OnMetadataRead() where mState is DECODING_METADATA.
3. Called by SeekCompleted() where mState is SEEKING.
4. Called by RunStateMachine() when the case is BUFFERING.
5. Called by OnCDMProxyReady() when mState is WAIT_FOR_CDM.
MozReview-Commit-ID: 53LWipLzdRo
--HG--
extra : rebase_source : ec157a8b4075d71ee757f72451a0af4878eda7c9
This member is only assigned but never used now.
MozReview-Commit-ID: IbuAbRaXzc4
--HG--
extra : rebase_source : 166bd3bc7478f725b64b5b2a0e8e258980674d06
The assumption was that the waiting event would be fired once the last frame prior the gap had been played. This is however incorrect, as per spec, the waiting event is to be fired once readyState is <= HAVE_CURRENT_DATA. So the waiting event is actually fired anytime between the start of the last frame and its end.
MozReview-Commit-ID: AA4Qhn7okhB
--HG--
extra : rebase_source : fc1f336b2e07cc2549071563804de8fae9c9ab67
Otherwise we get intermittent in mochitests checking the value of currenTime when events are fired
MozReview-Commit-ID: AVktWrXochp
--HG--
extra : rebase_source : 76c952e62e9b449834d5924454c25ddad305ada6
1- We shouldn't reach ended if we have a gap in the buffered range prior the end of the file (see bug 1297036)
2- Waiting should be fired when readyState goes below HAVE_FUTURE_DATA
MozReview-Commit-ID: 18bEnkNpYvO
--HG--
extra : rebase_source : c42c7fd19fec9ede5bb64ea697a0086116882403
The test accidentally worked because any demuxing failures in ended mode would be treated as EOS. There's no audio between [0-3), so playback couldn't start
MozReview-Commit-ID: 4B90CrVUTy4
--HG--
extra : rebase_source : 9079aa8a6983877745baac71c7868ca360b85095
The aim is to only allow skipping gaps of fuzz=500ms.
MozReview-Commit-ID: 8uHxni2nPHI
--HG--
extra : rebase_source : ccef593170fb3a0c3ff61dc97ad1a0508be06934
This reverts commit 5a949eb358e27
Another more complete solution will follow.
MozReview-Commit-ID: K3lTdrBxW7W
--HG--
extra : rebase_source : d0f9443193b0816ae85972a4a368599b872fd437
Seeking in the buffered range should always succeed, even if we have no data in a given track
MozReview-Commit-ID: FGjsDCNIdWC
--HG--
extra : rebase_source : c91348e44055f82deee0e97da4abef0cf799b225
This is done by moving FlacFrameParsers' AutoByteReader to a more public spot
in libstagefright's bindings.
Using AutoByteReader means there is no more need for explicit calls to
DiscardRemaining(); which means our parsers relying on BoxReader will be more
lenient about boxes that are larger than needed.
MozReview-Commit-ID: 3EERU749WYB
--HG--
extra : rebase_source : 6deba02ac553303b0a2b694c24bfcb54c2e732b1
Also ByteReader and AutoByteReader are marked RAII, to help prevent misuses.
MozReview-Commit-ID: 7oklXs4QMnq
--HG--
extra : rebase_source : 54fca3168a70d951e6012baea4bf0544827cae11
ReleaseResources() is called when MDSM enters dormant or during shutdown.
When it is called in response to dormant request, we don't want to clear
current frames so we are able to enter dormant state more aggressively
even when the media element is visible to the user.
When it is called from MediaDecoderReader::Shutdown(), it doesn't really
call ClearCurrentFrame() because MediaFormatReader::Shutdown clears the
|mVideoFrameContainer| pointer. So it doesn't make a difference to remove
the call.
MozReview-Commit-ID: IakGHbSMWTv
--HG--
extra : rebase_source : 7a25de39e04f5c7728bf65fcd447cc67b7a85411
extra : source : 44ff0ffaf63ad51a7a382cf0ee1c16e64ade63b9
The fuzz value is a +/- one. To check if a target is within an interval
we need to check with half the fuzz only.
MozReview-Commit-ID: J5H5sbNokse
--HG--
extra : rebase_source : aeedcb111c84a353307c8e641385ef0800792fa7
Interval.LeftOf would always return true if the length of the interval
is less than the fuzzing value.
MozReview-Commit-ID: L9uyZjQXnGA
--HG--
extra : rebase_source : af14038da603b928c7a4942f1b37f031908e61bb
Turns out runnables added through
MediaStreamGraph::DispatchToMainThreadAfterStreamStateUpdate on the same
iteration are all run in the same task. Creating them in the owning dom stream
in one task solves the timing issues and lets us add them
(and raise "addtrack") in individual tasks.
MozReview-Commit-ID: 9Q3NoFrmnQs
--HG--
extra : rebase_source : aa391668ec424d2f9b1485f6218d7d1f9948abc9
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
ctai
Phil Ringnalda
JW Wang
Andreas Pehrson
Gerald Squelart
Ryan VanderMeulen
Sotaro Ikeda
Paul Adenot
Tim Huang
Wes Kocher
Bryce Van Dyk
Andi-Bogdan Postelnicu
Jean-Yves Avenard
Jan-Ivar Bruaroey
Makoto Kato
Andrew McCreight
Munro Mengjue Chiang
Kaku Kuo
Byron Campen [:bwc]
Alex Chronopoulos
Michael Layzell
Randell Jesup
James Cheng