robwalch
commented
4 years ago if a user waits around on my page for a few seconds before hitting the play button, the video permanently lags behind the live edge by latency + wait time seconds.
That could happen when preloading, but it's more likely that there is always going to be additional latency up to TARGETDURATION based on how old the live playlist is when it is first loaded.
A few suggestions:
- Disable preloading
- Use
video.playbackRateto adjust playback speed to catch up to the desired latency, or slow down when the buffer gets very low and playback is at risk of stalling
The playbackRate adjustment might get added to hls.js in the future, following version 1.0 and low-latency playback. But I recommend you try it yourself. You can find an example of code that achieves this here https://github.com/jwplayer/hls.js/blob/demo/nab-lhls/src/controller/playback-rate-controller.ts
Playlist synchronization will be also improved in v1.o leading to more stable latency estimates. Whether latency will be accurate on join depends on your playlist and whether it and the CDN it's behind exposes the "age" header.
Set liveSyncDurationCount to 1, and liveMaxLatencyDurationCount... ... It seems like hls.js automatically recovers from this situation, but I'm not sure what the rules around this are.
The rules for resyncing are based on liveSyncDurationCount and liveMaxLatencyDurationCount which are subject to your playlist's TARGETDURATION (or liveSyncDuration and liveMaxLatencyDuration if you want to specify values in seconds). See _ensureFragmentAtLivePoint:
https://github.com/video-dev/hls.js/blob/f29283260253a569d37ce37b8f9fe15dc220d453/src/controller/stream-controller.js#L259
teenoh
stale[bot]
chloekim02
What do you want to do with Hls.js?
I'm building an app where I overlay a bunch of data on top of a live video stream. The data is synced to the video using timing metadata embedded into the stream.
My app is extremely time-sensitive, so I want my stream to be as low-latency as possible. I'm currently able to achieve a latency of around 8-10 seconds by tweaking my stream parameters as well as the hls.js configuration. I'm pretty happy with this. However there are 2 issues that I've been seeing in production:
Users on networks that have variable speed fall behind the live edge over time because the video occasionally stalls while hls.js loads new fragments. As these stalls add up over time, I end up with latencies close to 15-20 seconds. It seems like hls.js automatically recovers from this situation, but I'm not sure what the rules around this are.
On browsers that block auto-playing videos, if a user waits around on my page for a few seconds before hitting the play button, the video permanently lags behind the live edge by
latency + wait timeseconds. There's no recovery in this case.What are the rules around recovering from high-latency situations?
Is there a way to ensure that my users are always as close as possible to the live edge of a stream?
Could I tell hls.js to automatically fast-forward in a live stream if the user falls too far behind the live edge?
What have you tried so far?
liveSyncDurationCountto 1, andliveMaxLatencyDurationCountto 3. I was hoping that just setting these values will give me the behavior that I need, but they don't seem to have an effect.As a quick and dirty hack, I seek forward in the live video if I fall behind the live edge by more than 15 seconds. The following code runs every second until latency falls back below 15 seconds: