-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
video (but not audio) playback freezes after seeking back #6777
Comments
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! |
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. |
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: