Unnecessary snapping to live edge during startup on slower devices #6998
Comments
grabofus
added
Bug
Needs Triage
|
HLS.js is designed to start playback at specific distance from the end of the HLS playlist to maintain expected latency. The end of the playlist is updating and playback cannot start until media is buffered. When the media takes longer to buffer than playback can start, then the starting point will be moved forward to achieve target latency. |
robwalch
added
Works as expected
and removed
Bug
Needs Triage
|
If you'd like playback to start faster on slower connections, then start on a lower bitrate. |
|
The reason this felt like a bug because the target start time is still within the DVR window, it just happened to slide. after first manifest refresh, once the initial segment is downloaded and readyState turns to 1, playback could begin at the intended position. In this scenario I think hls.js could still just begin with a slightly larger latency. but currently hls.js discards the already downloaded segment on slower devices and readjusts the start position as: I think this could be improved if we'd check the target start position, instead of the currentTime if the initial seek hasn't happened yet, due to the first segment not yet being buffered? This logic only seem to kick in once the first segment is downloaded as until then readyState is 0, so |
|
@robwalch I'm just coming back to this. I don't think quality or DVR duration matters on the device to be honest. The issue seem to be that So regardless of any latency from the live edge, this seek will always trigger if there the start of the DVR window is no longer 0. (The shorter the target duration, the more likely for this to happen). Below is a video demonstrating this issue ( We're patching this in our fork by only using |
|
To summarize from the logs perspective: you are getting "Playback: 0.000 is located too far from the end of live sliding playlist" ( We'll take a PR for this issue. Thank you for identifying and sharing a fix. If this is the case however, there will almost surely be a stall. A down switch should be made, as this result suggests that the segment requested could not be loaded faster than the playlist refresh rate of target duration (generally slower than 1x playback speed). Simply starting at the buffered segment would start playback at a higher than desired latency. |
|
Thank you! PR raised #7063 |
What version of Hls.js are you using?
1.5.12, 1.6.0-beta.2.0.canary.10930
What browser (including version) are you using?
Chrome 68.0.344.106
What OS (including version) are you using?
webOS 5
Test stream
No response
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
Expected behaviour
Device should load first segment and begin playback
What actually happened?
Device finishes downloading the first segment, but after the segment is parsed, but before it would be buffered,
stream-controller'ssynchronizeToLiveEdgefunction can be called leading to an unnecessary seek. Since the segment has not yet been buffered, the media'scurrentTimeis not yet adjusted, which makessynchronizeToLiveEdgethink that the player has fallen out of the DVR window performing an additional seek to a new target start time. On slow network this process occasionally repeats leading to multiple segments being downloaded by the time playback can begin.Console output
Chrome media internals output
The text was updated successfully, but these errors were encountered: