-
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
Seeking to a previous frame, which is the last frame of the previous segment, hangs or seeks incorrectly #6511
Comments
The test your page performs seeks to the last segment, which appends the end of stream and marks the stream as ended. Seeking back less than Setting |
@robwalch thanks so much! This does help a lot, but it doesn't fully fix the issue unfortunately (I'm trying to fix it 100% because our use case relies on frame accuracy). I tried 2 things:
Just in case it helps - I realized I never properly explained what I meant by "hanging" seeks. It is a seek that never completes if left to run - after modifying Again, thanks a lot, this is already very helpful because the hanging issue was a huge headache for us. If you have any ideas on how to get the seek to reliably work on the first attempt, that would be amazing. |
When you seek to a time near the start of a buffered range ( |
@robwalch that helped me a lot (again :). It seems like the following is a workaround for Chrome:
Unfortunately this workaround doesn't help in Firefox (which has the same issue), because Firefox reports video.buffered as already containing the expected range (that contains the seek target time) when |
Hi @tpazman, I posted #6524 which removes the need for setting You can try it here https://bugfix-backward-seek-near-en.hls-js-4zn.pages.dev/demo/ It does not address the rendering issue that requires additional seeks that you describe above. I call this out in the description (#6524). I consider that a flaw in MSE that must be worked around, which could be addressed by HLS.js. For this we should make a new issue specifically calling out browser behavior that we would like changed for specific use-cases (like stepping back fame-by-frame while paused). |
@robwalch thanks, I checked with the hls.js code from your link and like you said, setting |
What version of Hls.js are you using?
1.5.11
What browser (including version) are you using?
Chrome 126.0.6478.62 (Official Build) (64-bit)
What OS (including version) are you using?
Windows 11 (23H2)
Test stream
https://files.tpazman.com/hls/hlsjsseekissue/playlist.m3u8
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
Expected behaviour
The second seek executes and shows an image of a bunch of sheep in the street recorded from a distance (image at 80.310).
What actually happened?
The second seek never completes - we still see a closeup of the sheep, which is the image from the previous seek (80.356).
However, if we seek to 80.310 without seeking to 80.356 first, then this works and shows the expected image for 80.310. And even going back and forth between 80.310 and 80.356 works correctly, as long as we seek to 80.310 first, and not to 80.356 first.
If we use 80.7 instead of 80.356, seeking to 80.7 first, then to 80.310 will result in the second seek completing, but it will seek to the wrong frame - the first frame of the segment, instead of the last frame of the previous segment. And again, the reverse order, first 80.310, then 80.7 will work correctly.
Console output
Chrome media internals output
The text was updated successfully, but these errors were encountered: