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 unbuffered position immediately after play loads same segment repeatedly #3811
Comments
Hi @cheweytoo, I am unable to connect to your site to view the test page and reproduce the issue:
Please provide a sample stream that can be accessed to reproduce the issue on the demo page with steps that include where and when to seek. |
This warning indicates that the segment's video track does not start with a keyframe, so only roughly the second half of the segment can be buffered. Usually, this results in the previous segment also being loaded, and then this segment being reloaded (so only one reload which unless you disable the worker so that the response can be cached in the main thread is unavoidable in all recent versions of hls.js). This feature is called backtracking, and I need a sample stream to see why it's not working in this case. |
Works for me, from several different endpoints. I did restart the webserver a short while ago though, you might have gotten unlucky.
That's fully automated on the test page :-) |
What version of Hls.js are you using?
1.0.2 light
1.0.2 non-light
Issue
When seeking immediately after play or a seek to a position that is not yet buffered, the segment for the new position is loaded several times (e.g. segment27_0_av.ts in test case below). Playback stalls until hls.js gets on its feet again and loads the segment following the loop-loaded one.
How many times the affected segment is loaded does not seem to be completely deterministic, and I've seen Firefox 87 load segment27_0_av.ts up to 85(!) times.
The same thing seems to happen with a level switch immediately after a seek, but not every time.
What browser and OS (including versions) are you using?
Firefox 87.0 on Ubuntu 20.04.2
Firefox 88.0 on Windows 10
Edge 85.... on Windows 10
Edge 90.0.818.4 on Windows 10
Chrome 90.0.4430.85 on Windows 10
The issue shows in all of them, with Firefox 88 the "least affected", with only 3-5 loads of segment27_0_av.ts.
Test page:
https://dev.vergnumpft.de/avstuff/hls.js_tests/hls102_segment_loop.html
Configuration:
Happens with
debug = false
andautoStartLoad = true
as well though.Auto level switch is disabled, via
Without those lines, i.e. with auto level switch active, it is even worse, and e.g. in Firefox 87 the looped loading of segment 27 never stops.
Checklist
The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
None that seem obviously related
The issue occurs in the stable client on https://hls-js.netlify.com/demo and not just on my page
The issue occurs in the latest client on https://hls-js-dev.netlify.com/demo and not just on my page
No to both. I probably simply haven't been able to click fast enough though. The button on my test page reliably reproduces it.
The stream has correct Access-Control-Allow-Origin headers (CORS)
There are no network errors such as 404s in the browser console when trying to play the stream
Steps to reproduce
Bug is 100% reproducible here.
Expected behavior
Load each media segment only once; continue/keep playing
Actual behavior
…/segment27_0_av.ts is loaded many, many times; playback stalls
Console output
Uh… lots and lots.
First couple of spurious segment loads, in Firefox 87:
Also see your own console output from the test page.
The text was updated successfully, but these errors were encountered: