You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Play a low latency stream which a segment part is corrupted. In reality we got some race condition that cause the latest part to not fully flushed and available to the HTTP service while the manifest is a little bit faster.
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
Play a low latency stream with at least a corrupted part (not segment)
Expected behaviour
The player can retry the whole state or report error and stop rather than automatically fallback to normal-latency mode while the config lowLatencyMode is true.
My question is not sure it's a right way that the player should do because in my perspective, when I upgraded my stream to use the low-latency mode which mean the normal-latency stream does not qualify our needs. Automatically falling back to use normal-latency mode will cause my end-users to angry with our business even that the issue may be come from another side like corrupted parts. But my users are willing to see a stream reload rather than a high-latency one.
If the current behavior is right, so I think there should be a flag to prevent the player to do the fallback, ex: lowLatencyEnforced = true
What actually happened?
HLS.js fallback to play the low-latency stream as normal-latency stream and never turn it back. The falling to normal-latency happened here
robwalch
removed
the
Needs Triage
If there is a suspected stream issue, apply this label to triage if it is something we should fix.
label
Jan 26, 2025
Latency should fallback to standard playback when the playlist server control does not meet the requirements of the HLS spec Appendix B.1 Low-Latency Server Configuration Profile. I left a comment in PR #6975:
If you like we can add logging to make this behavior clearer while verifying that playback is indeed starting at standard latency because of missing or disabled server-control blocking-reload attribute.
Thank @robwalch, but this issue is just a question and is not related to my pull request. I will check if this behaviour is still happened after the blocking reload is activated. But let's assume that the manifest is correctly implemented blocking reload, is it true that the buffer corruption should not fallback to regular-latency but instead trying to recover the stream?
But let's assume that the manifest is correctly implemented blocking reload, is it true that the buffer corruption should not fallback to regular-latency but instead trying to recover the stream?
Buffer corruption is usually fatal and recovery is non-trivial. The client shouldn't be expected to play assets with corrupted parts at all. If it manages to recover, you should expect playback to be delayed by the amount of time it took to recover.
What version of Hls.js are you using?
#8e77d46
What browser (including version) are you using?
Chrome 132.0.6834.83 (Official build) x64
What OS (including version) are you using?
Window 10
Test stream
No response
Configuration
Additional player setup steps
Play a low latency stream which a segment part is corrupted. In reality we got some race condition that cause the latest part to not fully flushed and available to the HTTP service while the manifest is a little bit faster.
Checklist
Steps to reproduce
Expected behaviour
The player can retry the whole state or report error and stop rather than automatically fallback to normal-latency mode while the config
lowLatencyMode
is true.My question is not sure it's a right way that the player should do because in my perspective, when I upgraded my stream to use the low-latency mode which mean the normal-latency stream does not qualify our needs. Automatically falling back to use normal-latency mode will cause my end-users to angry with our business even that the issue may be come from another side like corrupted parts. But my users are willing to see a stream reload rather than a high-latency one.
If the current behavior is right, so I think there should be a flag to prevent the player to do the fallback, ex:
lowLatencyEnforced
= trueWhat actually happened?
HLS.js fallback to play the low-latency stream as normal-latency stream and never turn it back. The falling to normal-latency happened here
hls.js/src/controller/base-stream-controller.ts
Line 908 in 8e77d46
Console output
Chrome media internals output
The text was updated successfully, but these errors were encountered: