-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Enforce specific live delay to non low latency stream? #3418
Comments
I was asking for this same feature with #3300 . It was declared as fixed as a result of #3316 . I also need the player to implement its catch-up mechanism outside of the low-latency environment (i.e synchronize all live clients 60s behind live). Even with the changes in 3.1.3 this does not seem to be the case? |
It seems that the catch-up mechanism basically works also with non low latency streams. However the initial delay is (in my case) a single-digit number; therefore the catch-up mechanism can take some time, depending on the configured target delay. For my use case, this is still OK (e.g. 20 seconds target delay), but for the 60 seconds target delay you mention, it takes several seconds until that delay is reached. |
#3316 Introduced a threshold for which the catchup mechanism applies. I don't see a reason that speaks against using catchup for non low latency streams. We can add this in the next release. Also keep in mind that dash.js adjusts the target latency to match segment start times. I modified this behavior as part of #3413 which is still work in progress. |
That sounds great!
So this means, if a certain |
@spoeschel @wilaw You can try it out in the nightly build:
Please let me know if you encounter any issues |
I am closing this issue, please find information above. If you see any issues please reopen |
We have the use case that someone watches a DASH stream and meanwhile generates subtitle content that shall be synchronised to the stream then. So this stream (e.g. this one, which is geoblocked to Germany) is required to be reproducibly played with a specific, fixed live delay, let's say with 500ms plus/minus of the desired delay at most.
Currently we work with a two step approach that plays the stream the first time and retrieves the current live latency. After a certain, calculated amount of time (considering the segment size and the fact that playback starts only on segment borders), the stream playback is started a second time, in order to achieve the desired live latency then. This roughly works as expected, but is rather a workaround than a suitable, precise solution.
Reading the documentation and playing around a bit with the configuration, it turned out that dash.js already has a catch-up mechanism (which requires low latency mode to be used) that is used to achieve a specified live delay. This seems to be a good solution (though getting dash.js to seek instead of changing the playback rate by using
liveCatchUpMaxDrift
didn't work here).The stream mentioned above is not a low latency stream. Nevertheless the catch-up feature worked (e.g. using a live delay of 12 seconds). So there is the question, whether the mentioned workaround could be replaced by this feature.
Are there any plans to enable this catch-up mechanism also for non low latency mode? At the moment, the resulting live latency in such a case varies in a range as large as the segment size (therefore the workaround solution decribed above).
Are there any problems to expect, by using the low latency mode with a non low latency stream?
The text was updated successfully, but these errors were encountered: