LL-DASH unusable in production #268
Comments
|
We are constantly improving LLDASH to operates well in various environments and conditions. (From our findings, the current LLDASH seems to work well only in a small range of environments and conditions.) Of course, it is being delayed by higher priority tasks, but I believe all problems will be resolved. We recently resumed work on stabilizing LLDASH. |
|
@basisbit Details For example, I suppose DASH has a server-client time synchronization algorithm to address this issue. If your server time cannot be set to the same as that of Akamai, it is recommended that you use the following code to make your own time server and then set // Please set this PHP script on the server where OME is running. <?php
$timestamp_in_ms = (int)(microtime(true) * 1000);
$milliseconds = ($timestamp_in_ms % 1000);
$padded = str_pad($milliseconds, 3, '0', STR_PAD_LEFT);
$timestamp = (int)($timestamp_in_ms / 1000);
$datetime = gmdate('Y-m-d\TH:i:s', $timestamp);
echo("${datetime}.${padded}Z");
?>// Please initialize your OvenPlayer as follows: let player = OvenPlayer.create(...);
player.on('dashPrepared', function (dash) {
dash.clearDefaultUTCTimingSources();
dash.addUTCTimingSource('urn:mpeg:dash:utc:http-xsdate:2014', '<your time server URL>');
});If the LL-DASH still does not play even though the time is right, please reply again. |
|
@dimiden afaik, when using https, the akamai-time-sync mechanism should never work because of There is no php-fpm on that server, however I'll try the time server workaround. |
|
the server-local time service and akamai both do approximately return the same UTC time, so time zone is not the reason. However, adding the local time source is required for anyone from EU or from California or from Brazil to be data protection laws compliant. So, thank you for pointing out how to set a custom time source! However, Firefox does still not play the LL-DASH stream. |
|
@basisbit To give you a little bit of a hard-coded explanation, even though the URL set in The issue that LL-DASH is not playing in Firefox is that the sample URL provided by dash.js is not playing either.
|
|
@dimiden Thank you for the additional information! The sample video plays fine with the reference client in version 3.1.0 or 2.9.3 in Firefox 85. OvenPlayer also plays LL-DASH streams fine in the same browser as long as they don't come from OME. You can find a sample at https://jenkins.basisbit.de:943/sample.html |
|
@basisbit The URL of the sample page you provided is a stream created by Live Simulator - [DASH-IF] Low Latency (Single-Rate) (livesim-chunked) -, which plays well, so I'm trying to find a reason why it's not playing by comparing these two differences. The biggest problem is, I don't have time to analyze the problem right now. :) |
|
Hi, after getting LL-Dash perfectly working with chrome I did not manage to get it working on Firefox. Firefox:
Chrome:
Same results with OvenPlayer and demo.ovenplayer.com OvenPlayer is being hosted on a HTTPS-site, OME also have been configured with HTTPS . Also note that on firefox it's generating many 404 like
Chrome (working):
OS: Debian 10 (Linux x86_64 - 4.19.0-16-amd64, SMP Debian 4.19.181-1 (2021-03-19)) Server is not within some kind of VPN or behind a special firewall. OME log: |
|
I can confirm that this issue still exists within the new released v0.11.3 containing the change of UTCTiming. |
|
any update on this? |
|
Only update I can contribute is that it still does not work with v0.12.0 / current master state. |
|
I hope LL-DASH stabilizes as soon as possible, but I'm currently working on another project, so I can't spend much time on this work. |
|
We're sorry, but with the release of LLHLS, we have decided to no longer update LLDASH. Because LLHLS has better performance and compatibility, we decided it was a better decision for everyone to focus more of our energy on it. Instead, we will continue to focus more on LLHLS and WebRTC. Thanks for your contribution. |
|
LLHLS support? yay! That is definitely a huge improvement! THANK YOU SO MUCH!!! |
Describe the bug
LL-DASH streaming is currently
brokenin master. It works when using Chromium based webbrowsers and only as long as there is no frame dropped and no network packet dropped.In typical production setups, LL-DASH often stops playing and the web-player just spins for some time until it eventually tries to restart the stream. Sometimes it tries to load segments that return 404, but the next segment with a higher number returns successfully when manually HTTP GET requested. LL-DASH playback in Firefox fails most of the tries.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Stream should play quite stable for LL-DASH
Logs
Nothing to see from Firefox's failed attempts, but when it fails for Chrome, usually you see something like this in the log:
Server (please complete the following information):
Player (please complete the following information):
Additional context
Related to #182, #248, #162.
Increasing
lowLatencyMpdLiveDelaydid not fix the issue (only found out that playback fails with higher values because OME eventually already has deleted (or never created?) some older chunk files (returns 404 stream not found for those HTTP GET requests for some of the chunk files).Fails in Firefox with OvenPlayer as well as official dash.js reference player 2.9.3 and 3.0.1 and 3.0.3 (others not tested).
Rarely, Firefox manages to play the stream after waiting for it for minutes, but then usually only plays for a few seconds before it loading-spins to oblivion again.
If no developer wants to put the time and effort into fixing LL-DASH for most typical use-cases, please change the documentation so users know that they should probably not spend any time on trying to get LL-DASH to work with OvenMediaEngine as server.
The text was updated successfully, but these errors were encountered: