-
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
Interrupting buffering with stopLoad()
and then restarting with startLoad()
causes a transition to the lowest level
#5230
Comments
After calling hls.stopLoad() and then hls.startLoad(), the player restarted loading the same fragment at the same level as the one that was interrupted (note two lines that read Only after buffering that fragment, the player then logs a down switch. I see there was a drastic change is estimate. Looking into root-cause. |
I missed it on the first try, but after a careful review of step 2, used With trace logs enabled I see that before the restarting and rebuffering the fragment that was interrupted, estimates look OK:
But then we get a rude awakening right after buffering the fragment that was interrupted:
Best guess is that LoaderState ( |
The is issue is that when startLoad is called, the current level's Playlist is reloaded, replacing stream-controller's LevelDetails with a new fragment list containing new Fragment references and stats. When this happens while the fragment is being loaded, the reference Fix prevents the playlist from being reloaded when it does not need to be, and uses the correct fragment object reference for continuity in the event it would not be (this had been fixed for live where fragment lists are merged, but we never expect to replace loaded playlist data for VOD) e49ff5c |
Warn on currentFrag context reference change and use currentFrag to maintain correct stats ref Fixes #5230
Warn on currentFrag context reference change and use currentFrag to maintain correct stats ref Fixes #5230
Warn on currentFrag context reference change and use currentFrag to maintain correct stats ref Fixes #5230
Warn on currentFrag context reference change and use currentFrag to maintain correct stats ref Fixes #5230
Thank you so much for digging into this so quickly! ❤️ |
Warn on currentFrag context reference change and use currentFrag to maintain correct stats ref Fixes #5230
This fix worked for me! |
What version of Hls.js are you using?
1.3.3
What browser (including version) are you using?
Chrome Version 110.0.5481.77 (Official Build) (64-bit)
What OS (including version) are you using?
Debian 9
Test stream
https://hls-js.netlify.app/demo/
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
hls.stopLoad()
in the console. Notice the level of the fragments being buffered (for me it starts at level 3, then goes up to level 4).hls.startLoad()
to resume buffering. Notice that the level switches down (for me, it switches down to level 2), then slowly switches back up again.Expected behaviour
I would not expect any level switching to take place after I call
hls.startLoad()
, since nothing about my bandwidth or streaming capabilities have changed. It seems like manually stopping + starting the load is messing with the automatic level switcher.What actually happened?
When I call
hls.stopLoad()
and thenhls.startLoad()
, the video level switches dramatically downward (from 4 -> 2 in my case).Console output
Chrome media internals output
No response
The text was updated successfully, but these errors were encountered: