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
Server sends 404s when the player tries to download expired segments on this stream: http://wowza.streamroot.io/live/stream1/index.m3u8
To repro, play this stream and throttle the bandwidth to 750kbps from chrome debugger.
But this stream has variable segment length, which can cause several smaller segments to expire at once if a bigger segment is made available at live edge, and on top of that the total duration of the index is also variable.
This part of the code is executing only the first time we download the manifest: https://github.com/dailymotion/hls.js/blob/master/src/controller/buffer-controller.js#L816-L818
so with the variable playlist duration this.seekAfterStalling = this.startPosition + sliding; might be before the start of the playlist when we need to seek.
Reevaluating this.startPosition everytime we reload the manifest seems to help.
A possible improvement could be as well to limit the max latency we can have from the live edge.
(maybe make the startPosition configurable as well, as a time distance from the live edge)
Another possible improvement would be to loosen the criticity of getting a download error on a fragment for live streaming and try seeking forward if we can't download a segment (with a limited amounts of retries).
The text was updated successfully, but these errors were encountered:
Server sends 404s when the player tries to download expired segments on this stream: http://wowza.streamroot.io/live/stream1/index.m3u8
To repro, play this stream and throttle the bandwidth to 750kbps from chrome debugger.
This part of the code should prevent this to happen: https://github.com/dailymotion/hls.js/blob/master/src/controller/buffer-controller.js#L203-L210
But this stream has variable segment length, which can cause several smaller segments to expire at once if a bigger segment is made available at live edge, and on top of that the total duration of the index is also variable.
This part of the code is executing only the first time we download the manifest:
https://github.com/dailymotion/hls.js/blob/master/src/controller/buffer-controller.js#L816-L818
so with the variable playlist duration
this.seekAfterStalling = this.startPosition + sliding;
might be before the start of the playlist when we need to seek.Reevaluating
this.startPosition
everytime we reload the manifest seems to help.A possible improvement could be as well to limit the max latency we can have from the live edge.
(maybe make the startPosition configurable as well, as a time distance from the live edge)
Another possible improvement would be to loosen the criticity of getting a download error on a fragment for live streaming and try seeking forward if we can't download a segment (with a limited amounts of retries).
The text was updated successfully, but these errors were encountered: