Closed Bug 1274933 Opened 9 years ago Closed 9 years ago

Intermittent dom/media/mediasource/test/test_ResumeAfterClearing_mp4.html | Test timed out.

Categories

(Core :: Audio/Video: Playback, defect, P2)

defect

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox49 --- fixed

People

(Reporter: jya, Assigned: jya)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Likely very similar to bug 1270323, symptoms are similar but somehow the fix of bug 1270323 doesn't fix it. Logs show that: audio state: ni=0 no=0 ie=1 demuxr:0 demuxq:0 decoder:1 tt:-1.000000 tths:-1 in:1 out:1 qs=0 pending:0 waiting:1 rnewdata:1 sid:27 So we are in waiting mode, it is marked as having new data received, yet the waiting promise wasn't resolved: [3340] WARNING: Decoder=110d2e80 GetMediaTime=1623945 GetClock=1623945 mState=DECODING mPlayState=3 mDecodingFirstFrame=0 IsPlaying=1 mAudioStatus=waiting mVideoStatus=idle mDecodedAudioEndTime=1625395 mDecodedVideoEndTime=1963333 mIsAudioPrerolling=0 mIsVideoPrerolling=0: Unfortunately, I've only seen it happening twice, going to be hard to reproduce
Blocks: MSE
Actually looking at the log, this is potentially very troublesome. It shows that if decoding is fast and we get to the end of the trackbuffer while we're in the middle of processing an appendBuffer and between two media segments: we will stall and playback will not recover. example: 04:50:01 INFO - audio state: ni=0 no=0 ie=1 demuxr:0 demuxq:0 decoder:1 tt:-1.000000 tths:-1 in:1 out:1 qs=0 pending:0 waiting:1 rnewdata:1 sid:28 04:50:01 INFO - video decoder: wmf software video decoder 04:50:01 INFO - hardware video decoding: disabled 04:50:01 INFO - video frames decoded: 71 (skipped:0) 04:50:01 INFO - video state: ni=0 no=0 ie=1 demuxr:0 demuxq:0 decoder:1 tt:-1.000000 tths:-1 in:72 out:72 qs=1 pending:1 waiting:0 rnewdata:0 sid:29 04:50:01 INFO - mDemuxEOS=1 mOutputRequested=1 mNeedDraining=0 mDraining=1 mDrainComplete=1Dumping data for demuxer eba2220: 04:50:01 INFO - Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 6.826666 04:50:01 INFO - NumSamples:84 Size:17668 NextGetSampleIndex:4294967295 NextInsertionIndex:84 04:50:01 INFO - Buffered: ranges=[(3.900952, 7.801904)] 04:50:01 INFO - Dumping Video Track Buffer(video/avc) - mLastVideoTime: 7.208333 04:50:01 INFO - NumSamples:96 Size:107347 NextGetSampleIndex:96 NextInsertionIndex:96 04:50:01 INFO - Buffered: ranges=[(4.005000, 7.208333)] so here we have audio stuck at 6.826666s. 6.826666 is the end time of the 3rd media segment being processed It's a very narrow gap during which the error can occur as a new task is immediately dispatched to process the next media segment (the appendBuffer adds 2 media segments at once). So I'm marking this as P2 because that needs to be tackled asap.
Priority: P5 → P2
just seen with mochitest dom/media/mediasource/test/test_SeekNoData_mp4.html | Test timed out. same observed behaviour, stall occurs with data in the middle of an append buffer.
Comment on attachment 8755791 [details] MozReview Request: Bug 1274933: Reject data promise when EOS is encountered following waiting for data. r?gerald https://reviewboard.mozilla.org/r/54814/#review51476
Attachment #8755791 - Flags: review?(gsquelart) → review+
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: