Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimum latency when using streams with audio tracks #2723

Closed
epiclabsDASH opened this issue Aug 1, 2018 · 3 comments
Closed

Minimum latency when using streams with audio tracks #2723

epiclabsDASH opened this issue Aug 1, 2018 · 3 comments

Comments

@epiclabsDASH
Copy link
Contributor

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.

@wilaw
Copy link
Member

wilaw commented Aug 22, 2018

@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?

@epiclabsDASH
Copy link
Contributor Author

@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.

@epiclabsDASH
Copy link
Contributor Author

epiclabsDASH commented Oct 17, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants