Dash-Industry-Forum / dash.js

A reference client implementation for the playback of MPEG DASH via Javascript and compliant browsers.
http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html
Other
5.06k stars 1.67k forks source link

low latency in the realm of 0 < X < 1s #2664

Closed amitmiz closed 6 years ago

amitmiz commented 6 years ago

Wanted to ask if such low live latncy is supported - becuase on my setup, the minimum latency I could get is 1secs even though the stream infrastructure supports lower latnecy than 1 sec,

I think the issue caused by the fact that dash js doesnt support such use case and wanted to make sure.

for example During my invastigations I saw the function decideSegmentListRangeForTemplate which takes the represention availablity range and return the available segments indexes However it reutns that

//SegmentUtils.js

 start = Math.floor(Math.max(originAvailabilityTime - availabilityLowerLimit, periodRelativeRange.start) / duration);
 end = Math.floor(Math.min(start + availabilityUpperLimit / duration, periodRelativeRange.end / duration));

 range = {start: start, end: end};

namely , it will always floor the fractions of the end range for example let say my periodRelativeRange is {start : 0, end : 9} for a 1sec long segment then it will be just fine and return the correct index, however if using AvialabiltyTimeOffset of 0.5 for example then my periodRelativeRange might be {start : 0, end :9.5} which means that I can already get the next fragment without getting 404, however because of the Math.floor I will able to download the segment only when range.end would be 10

So wanted to know if this is really the issue, and if it does I guess the calculation of available segments should be changed to support the <1 s latenecy, My idea is to use Math.ceil if the fraction is higher than availablityTimeOffset

Thank you!

epiclabsDASH commented 6 years ago

@amitmiz, I don't think that's possible. I have detected some "stability issues" in browsers when playing buffer goes below 0.5 seconds (they are detected and reported by the player as a buffer stall), a situation that is going to become normal when using latencies below 1 second.

Something could be done in the browser side (Chrome, Firefox, etc) to improve this behaviour but, honestly, you should re-consider if using an HTTP based streaming protocol for getting latencies below 1 second is the right choice.