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
In low latency mode, when playing streams that have audio tracks, there is no way of getting live latencies below 2-2.5 seconds. That's due to the behaviour of fetch API and ReadableStreamDefaultReader, that raises download data events just when one of those things happen:
There is enough data in the buffer. The meaning of "enough" bytes depends on the browser implementation.
There is no enough data but a max wait time (recv timeout) is reached.
In the case of audio tracks that use low bitrates (64Kbps in my tests) above reasons introduce an extra latency in the fetch process that could be slightly higher than 2 seconds. In these cases, if liveDelay is set up to be lower than 2 seconds and catchup mechanism is activated, there are constant playback stall events.
Some ideas that makes sense to implement in dash.js to overcome this issue:
I think makes sense deactivating playback catchup for low latency mechanism in case there are N playback "consecutive" stall events. Doesn't make sense offering a poor user experience (continuous playback stall events) because limitations on the way the buffer is managed by the browser.
Tune current calculation for list of available segments. I have the feeling the current implementation is quite conservative and we are assuming some segments as not available although they are. I could test this modifying mpds of low latency streams and "artificially" increasing availabilityTimeOffset.
Note: seems using ReadableStreamBYOBReader instead of ReadableStreamDefaultReader will help to fix this issue. However, ReadableStreamBYOBReader is still not implemented by any browser.
The text was updated successfully, but these errors were encountered:
@epiclabsDASH - with this stream https://vm2.dashif.org/livesim-chunked/chunkdur_1/ato_7/testpic4_8s/Manifest300.mpd the audio segments are only 40kB yet we do not see the stalling. Why is that? Is it because the segment duration is 8s even though the bitrate is only 37kbps? Is the issue more sensitive to segment duration that bitrate? Any progress on either of the two workarounds?
@wilaw, we are preparing a new version for this week, before the code freeze, so next week release will have the problem fixed. I will keep you updated.
Fixed. There is a new catchup mechanism in place and calculation of available segments has been fixed to improve the behavior of low latency mode. PR #2813
In low latency mode, when playing streams that have audio tracks, there is no way of getting live latencies below 2-2.5 seconds. That's due to the behaviour of fetch API and ReadableStreamDefaultReader, that raises download data events just when one of those things happen:
In the case of audio tracks that use low bitrates (64Kbps in my tests) above reasons introduce an extra latency in the fetch process that could be slightly higher than 2 seconds. In these cases, if liveDelay is set up to be lower than 2 seconds and catchup mechanism is activated, there are constant playback stall events.
Some ideas that makes sense to implement in dash.js to overcome this issue:
availabilityTimeOffset
.Note: seems using ReadableStreamBYOBReader instead of ReadableStreamDefaultReader will help to fix this issue. However, ReadableStreamBYOBReader is still not implemented by any browser.
The text was updated successfully, but these errors were encountered: