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)
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
Comment 1•8 years ago
|
||
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
Comment 2•8 years ago
|
||
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.
Updated•8 years ago
|
Version: unspecified → 47 Branch
Updated•8 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•