A bit of a shot in the dark, but it is possible that data got received but that information got lost as reset was called.
MozReview-Commit-ID: 1KjQeCFsGPJ
--HG--
extra : rebase_source : 3a522045bde0658fdfeccbf4d0cac11b43bc35d7
As the decoder was flushed and reset prior the skip to next keyframe started, and future error would be unrecoverable. So only reset the decoder once the skip completes and succeeded. Otherwise we default back to normal decoding.
MozReview-Commit-ID: GEj1i0EsaYO
--HG--
extra : rebase_source : c1d2beafa6e35f571b941e8f173ec10b726ec1a0
currentTime may be past the start of the internal seek time, but before its end, which would have triggered a false positive: we do not want to jump to the next key frame here.
MozReview-Commit-ID: H5O9XXnk84T
--HG--
extra : rebase_source : 0bc96472acfe03ff0c87a6fc3712bd99b96064b6
With the new video-only seek type, we need to ignore the current audio decoding state whenever video-only seeking is in progress.
MozReview-Commit-ID: 5eynmG2UyyA
--HG--
extra : rebase_source : 7e9bdd7c44cb4a80129bfc468da87288e520c984
MediaFormatReader::mOriginalSeekTarget now has different use and the name was no longer reflective of the actual usage.
MozReview-Commit-ID: Fu0fmgUlbgr
--HG--
extra : rebase_source : 7c106fc4832def7c6a4b91e1950ed5b3e1109129
When resuming from suspended video, don't reset the audio queues or
audio demuxing state in MFR.
Extracted the code from ResetDemuxers() and inlined it at calling sites
as recommended by jya.
MozReview-Commit-ID: 3wpH075RrKW
Implemented by short-circuiting calls to RequestVideoData in MDSM so no
frames are decoded. Resuming playback when video moves to foreground by
using the SeekTask/SeekJob/Seek in MDSM with result of GetMediaTime().
Special consideration is made to only seek the video part of Seek() to
remove an audible glitch in the audio playback when the video becomes
visible again.
MozReview-Commit-ID: 7YFDTanslXu
Access to some members is not thread-safe; but the typical use of those informations is when a mochitest has timed out, and by that time the MFR will have been idled for over 5 minutes.
MozReview-Commit-ID: 21BxrSZXVVJ
Some decoders (WMF) keep some internal counters on how many frames have been output and use this to calculate the time of the decoded audio frame. As such, when internally seeking, the next frame decoded would have always been past the seek target.
MozReview-Commit-ID: puzs6ecqbD
While a seek is pending, the demuxer has been reset meaning that ShouldSkip() would almost always incorrectly return true and would corrupt the seeking state.
MozReview-Commit-ID: 6R912Fu6Nul
--HG--
extra : rebase_source : a20a5d0ed1c0d21c04014790bdf5a0c07edb82a4
MediaDecoderStateMachine's EnqueueFIrstFrameLoadedEvent would previously call
into MediaDecoderReader to update MDR's buffered ranges and enqueue the frame
loaded event. This commit aims to instead have the buffered update take place,
and only afterwards enqueue the event. This should remove the possibility that
the event will be fired and handled before the update of the buffered ranges has
taken place.
MozReview-Commit-ID: GP8w2nF4xmj
--HG--
extra : transplant_source : %A0m%13%95%E3Gs%ACMd%1F%F4%25%B9qE%28J%21R
Decoders are created and initialized automatically when needed.
Also fix issues where we could have a pending initialization promise pending when going into dormant mode.