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