Additionally, mark non fatal decoding error as such.
Due to the complexity of WMF decoder error handling, this will be done in a follow up bug.
MozReview-Commit-ID: KHWORM8899c
--HG--
extra : rebase_source : 77ada9bb95ba4d44d1bca209e4a7d28369f24f6e
Will allow to pass detailed failure causes in a followup patch.
MozReview-Commit-ID: 5yGjzZNcYWg
--HG--
extra : rebase_source : fdd76c98900320352ee3c349de1c40df29122ca9
We provide even further details for the GMP decoder. Other decoders to follow.
MozReview-Commit-ID: 7NxJPec8xWv
--HG--
extra : rebase_source : f44120983070e5c107ecd5cafc762da90aab44bf
If initializing DXVA fails, we end up destroying the DXVA2Manager on the
decode task queue. The DXVA2Manager asserts that it's destroyed on the
main thread, so we should dispatch a task to destroy it on the appropriate
thread instead of destorying it on the wrong one.
MozReview-Commit-ID: 2pbeMOm74et
--HG--
extra : rebase_source : c4a6871877747d4e04494c638d83b225decaf249
Following bug 1301307, exception is properly thrown when buffer is full, giving the opportunity to the JS player to adjust accordingly. Confirmed to work with YouTube with an audio threshold of only 1MB.
MozReview-Commit-ID: 77K8UPhb9zj
--HG--
extra : rebase_source : 64b75f7f563ba9d6fc0c6feeaf7c945894fd6a06
The WMF decoder doesn't handle well the case where a single frame was given to decode.
When draining, the output is a correctly decoded frame but with a time of 0 and a duration set at 1/30th.
This is a workaround
MozReview-Commit-ID: JbjgNmPXKIM
--HG--
extra : rebase_source : f25a1fd503678383265ec5053b41f3116ff52da0
So we have only one place to transition to the SHUTDOWN state which is Shutdown().
MozReview-Commit-ID: 6MNISCea94Q
--HG--
extra : rebase_source : 3e5a2084a158fc9569b3b7d3b95033d7fe4233b2
There is no point in scheduling an addition cycle to do that.
Also remove the annoying debugging message which is not helpful.
MozReview-Commit-ID: BMjeTNg6HCY
--HG--
extra : rebase_source : df1be5984072fd64070bd5da98e7e27a46c59756
extra : source : 93c2408e698b0e597b6ab8cb47255c53cf65e67d
We don't want to run MDSM cycles anymore once shutdown begins.
MozReview-Commit-ID: 7Py20oqWNBG
--HG--
extra : rebase_source : 42793b4463593cf4efa7eae6d59c79dc528a82b2
We don't want to receive notifications from MediaEventSource or WatchManager once shutdown begins.
MozReview-Commit-ID: LiKUjOGuxyX
--HG--
extra : rebase_source : 05af4df691f174e8c4c6082bafc14c04534ce8fa
There are too many cases where the MP4 is improperly muxed and frames are incorrectly reported as keyframe.
Instead we now look inside the H264 stream and check for IDR frames.
We also ensure that the first frame returned after a seek is always a true keyframe.
For plain MP4, seeking in those broken files will lead to broken A/V sync. The only way to fix this would be to check for the frame type when reading the samples table. However, this would require to read the entire stream which isn't viable.
MozReview-Commit-ID: Cpv5y7HVD0N
--HG--
extra : rebase_source : 2f92032fe39ed6ad6c2b82438f405040b5e7d30c
- Use format() instead of old style formatting (%s, etc).
- Remove unneeded positional args on format strings.
- Break some long lines for pep8 conformance.
- Use brackets instead of \ to continue long lines.
- Log interval on video puppeteer.
- Remove an unneeded media source check. We have explicit media source checks
in tests, and the media source prefix has changed, rendering the check broken.
MozReview-Commit-ID: 4FPVoOD0P5B
--HG--
extra : rebase_source : 3bfdc4a5aee5c419e4ccacc923ec539cbaa1d14f
We've had large numbers of shutdown hangs with the Windows H.264 decoder stuck
calling IMFTransform::ProcessOutput(), blocking shutdown. I can reproduce this
with videos with dimensions less than 32 pixels.
Chrome also encountered this with the WMF decoder:
https://bugs.chromium.org/p/chromium/issues/detail?id=373288
The WMF H.264 Decoder is documented to have a minimum resolution of 48x48 pixels.
So this patch causes us to reject H.264 files with either width or height less
than 48 pixels.
I have been able to play files down to 34x34 pixels on Windows 10, but it seems
safest to just follow the what's documented in MSDN, and reject files that are
smaller than the documented minimum.
MozReview-Commit-ID: 5peP6UGnAaB
--HG--
extra : rebase_source : 6e29812642bc3f8ca0f5b39b36064a6d50e09ea7
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
