Closed Bug 1284700 Opened 8 years ago Closed 8 years ago

MSE playback stalls when seeking to time 0 in a stream with audio track but only one video frame

Categories

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

47 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox47 --- affected
firefox48 --- affected
firefox49 --- affected
firefox-esr45 --- unaffected
firefox50 --- affected

People

(Reporter: cpeterson, Unassigned)

References

Details

(Keywords: regression)

This issue was originally reported in the HLS.js GitHub issue tracker: https://github.com/dailymotion/hls.js/issues/536 STR: 1. Play one of these streams: * stream with audio track but only one video frame: http://dailymotion.github.io/hls.js/demo/?src=http%3A%2F%2Fd12zt1n3pd4xhr.cloudfront.net%2Ffp%2Ftest%2Fstarttime.m3u8&enableStreaming=true&autoRecoverError=true&enableWorker=true&levelCapping=-1&defaultAudioCodec=undefined * or stream where audio track starts one second later than the video track: http://dailymotion.github.io/hls.js/demo/?src=http%3A%2F%2Fcdn.flowplayer.org%2F202777%2F161139.m3u8&enableStreaming=true&autoRecoverError=true&enableWorker=true&levelCapping=-1&defaultAudioCodec=undefined 2. After playing for a few seconds, click the video pause button. 3. Seek to video time 0. RESULT: Firefox 47 stalls, showing a progress spinner. Firefox 46, Chrome, Edge, IE11, and Safari all play the stream from the beginning, as expected. I bisected this seeking problem to Jean-Yves' fix for bug 1243608 in Firefox 47. That was a fix for a stall when seeking ahead in videos that have an audio track but only a single video frame, which was a regression from the fix for bug 1112438 where seeking to 0 didn't work for some videos with non-zero audio start time. Jean-Yves asserts on GitHub that this is not a Firefox bug, however Chrome, Edge, IE11, and Safari can all play these streams successfully: https://github.com/dailymotion/hls.js/issues/536#issuecomment-229711509
I don't see anything there to fix. There's no data to seek to. Hls.js should monitor the buffered range and make whatever adjustments necessary. Only reason it currently works with chrome is due to their buggy buffered range calculation that shows the video has having 0 buffered. Once they fix that we can revisit.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
The core fix of bug 1243608 and 1112438 is that previous if say you had data from 1000s onward, you could have seeked to 0 and playback would have actually started at 1000s! It would also have shown for the first frame the first frame buffered regardless of timing. There is no regression, just incidental change of an incorrect behaviour.
Version: unspecified → 47 Branch
You need to log in before you can comment on or make changes to this bug.