video (but not audio) playback freezes after seeking back #6777
Comments
luwes
added
Bug
Needs Triage
|
This is a major issue for us since users tend to skip around in a video to see different highlights, etc. Thanks for looking into this issue. |
Is this specific to Chrome MSE playback? If you perform a micro-seek (currentTime += 0.0001) at the right time (after playback resumes but all video frames are dropped until the next key frame) does that correct the issue? (Seeks flush the pipeline and is also necessary when crossing small video gaps to prevent stalls one second after entering a new video buffered range.) Sounds related to the LL-HLS issue we have with video "freezing" when appends are performed over the play-head. |
|
Yes, it looked like a Chrome only thing in the tests I did. Thanks, we can give that a try! |
robwalch
added
gap-controller
browser: Chrome
Browser issue
|
After reproducing this in Chrome 130 on mac, simply issuing another seek won't do the trick. Only one You should report this issue to Chrome and as a workaround, flush the forward buffer when seeking back into an unbuffered range. To make things easier we can look into making |
|
@robwalch lol was digging through some old notes when I saw this and thought it sounded an awful lot like... #3596 (which I had saved). I'm fairly confident this is related as well. Other relevant links:
In theory, hls.js could try to keep track of segment boundaries in the SourceBuffer's |
|
So this asset contains overlapping samples? |
|
It shouldn't (though I haven't confirmed). What I suspect is happening is the back buffer flushing is lopping off an IDR frame but not the whole GOP and we end up in edge cases from that with the seeking + fetching/buffering. |
|
HLS.js’s back buffer flushing doesn't operate on media less than a target durations behind the playhead. It is completely diabled by default and only set to 90 seconds on the demo page. |
|
If frames are being removed that should be reflected in the buffered ranges. I don't see how this is not a bug in Chrome.
We’re not using append window |
|
I should add that I reproduced the issue with default settings: No HLS.js back buffer removal whatsoever. If HLS.js was performing back buffer removal, I would expect it to re-buffer any fragments that overlap with the flushed range. |
github-project-automation
bot
moved this to Top priorities
in HLS.js Release Planning and Backlog
|
@luwes and @cjpillsbury, Were you able to workaround or resolve this issue? It's not a bug in hls.js as far as I can tell. |
robwalch
moved this from Top priorities
to Nice to have
in HLS.js Release Planning and Backlog
|
Is this the same issue? #6374 We're seeing this too - haven't yet tried implementing the flush workaround, but based on the comments in that other issue it seems to work. Having a built-in option for this would be great. |
|
Don't want to speak for @luwes who was digging into this, but I think we're just accepting this as status quo for the time being? |
|
Yes, @cjpillsbury is right. We didn't implement a workaround yet. Flushing the buffer seems like a good plan but I imagine we'd have to take care of caching the segment responses then so no new requests are made? |
Unless segment caching is handled by the browser, they will be reloaded. HLS.js doesn't cache segment data that has been appended to a source buffer. We want to avoid OOM errors on low end devices and user-agents with strict memory limits. |
|
This issue duplicates #6374 (however steps to reproduce in this issue work every time, while steps and "also this" comments in that issue are not easily reproducible). The issue here (as opposed to similar issues like #5631) is that when seeking back and appending earlier segments that abut with previously appended segment, the buffered time range is contiguous, but video playback stalls at the abutting time, likely due to some overlap in sample or other issue in decoding that hls.js is not responsible for. |
robwalch
added
Revisit-at-later-release-cycle
|
The window to land this in v1.6.0 has passed. This will be revisited with this group of issues: https://github.com/video-dev/hls.js/issues?q=state%3Aopen%20label%3A%22browser%3A%20Chrome%22 Some work has been done to detect missed frames (not dropped because they were appended late): This issue and duplicate #6374 are caused by abutting appends in reverse order (append 10-20 then append 0-10: video stops rendering at 10 until next GoP). |
|
If you are interested in code that examines mp4 content prior to append (it may be relevant to detecting this behavior) here you go: I don't think the segments are missing an IDR at the start in this case, but other sample information that could be extracted as demonstrated in the change above may be useful in detecting overlap or some other condition that leads to Chrome not rendering video after the abutting append (splice) point. |
What version of Hls.js are you using?
v1.5.16
What browser (including version) are you using?
Chrome 129.0.6668.100
What OS (including version) are you using?
MacOS 14.6.1
Test stream
https://hlsjs.video-dev.org/demo/?src=https%3A%2F%2Fstream.mux.com%2F00pwc00zuut01c4KeE939WuLERfgSWYxFXOIMSnTW1X5y8.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOnRydWUsInN0b3BPblN0YWxsIjpmYWxzZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
Expected behaviour
Video plays back normally without freezing.
What actually happened?
The video playback freezes while audio playback is fine and is audible.
I tested it on Safari and Firefox and from brief testing it didn't seem to be an issue on those browsers.
related issue muxinc/elements#940
Console output
Chrome media internals output
No response
The text was updated successfully, but these errors were encountered: