video-dev / hls.js

HLS.js is a JavaScript library that plays HLS in browsers with support for MSE.
https://hlsjs.video-dev.org/demo
Other
14.97k stars 2.59k forks source link

Best configuration for low latency stream? #6662

Open whatever1211 opened 2 months ago

whatever1211 commented 2 months ago

What do you want to do with Hls.js?

I want the best player configure with Hls.js to run low latency stream without stall, and correct bandwidth estimate.

What have you tried so far?

Here is our stream: https://llhls-demo.ovenmediaengine.com/app/stream/llhls.m3u8 Below is our current configure. We are using Hls.js version 1.4.12.

config = {
    maxBufferLength: 20,
    backBufferLength: 2,
    maxBufferSize: 0,
    enableWorker: false,
    abrBandWidthUpFactor: 0.5,
    lowLatencyMode: true,
    manifestLoadPolicy: {
        default: {
            maxTimeToFirstByteMs: Infinity,
            maxLoadTimeMs: 10000, // Updated value
            timeoutRetry: {
                maxNumRetry: 2,
                retryDelayMs: 0,
                maxRetryDelayMs: 0
            },
            errorRetry: {
                maxNumRetry: 1,
                retryDelayMs: 1000,
                maxRetryDelayMs: 8000
            }
        }
    },
    playlistLoadPolicy: {
        default: {
            maxTimeToFirstByteMs: 10000,
            maxLoadTimeMs: 10000, // Updated value
            timeoutRetry: {
                maxNumRetry: 2,
                retryDelayMs: 0,
                maxRetryDelayMs: 0
            },
            errorRetry: {
                maxNumRetry: 2,
                retryDelayMs: 1000,
                maxRetryDelayMs: 8000
            }
        }
    },
    fragLoadPolicy: {
        default: {
            maxTimeToFirstByteMs: 10000,
            maxLoadTimeMs: 20000, // Updated value
            timeoutRetry: {
                maxNumRetry: 4,
                retryDelayMs: 0,
                maxRetryDelayMs: 0
            },
            errorRetry: {
                maxNumRetry: 6,
                retryDelayMs: 1000,
                maxRetryDelayMs: 8000
            }
        }
    }
};

The stream stalls often and the bandwidth estimate is very low. The bandwidth is not correct, since with the same stream, when we change the configure to lowLatencyMode: false, the bandwidth sky rocket by a huge amount. I would be very grateful for the guidance with the best configure to improve the playback of the above low latency stream, without stall and correct bandwidth estimate. Thanks,

robwalch commented 2 months ago

~Are you using the latest release?~

We are using Hls.js version 1.4.12.

The latest release is v1.5.15. Please upgrade to the latest release. v1.5 has fix #5714 with among others since the latest patch improve Low-Latency HLS support.

config = {

How does this config compare to using the defaults (none at all)?

Have you tried the branch that supports preload hints (#6356)?

What platforms and browsers are you testing on?

Here is our stream: https://llhls-demo.ovenmediaengine.com/app/stream/llhls.m3u8

Note that there is only one bitrate variant in this asset so bandwidth estimation is completely inconsequential; there is nothing to switch to.

This stream plays fine in the latest release given enough network throughput and low round trip times with the default config.

maxBufferSize: 0,

Setting maxBufferSize to 0 will result in maxBufferLength being used and not exceeded when a low bitrate variant is selected. This has no effect for Low-latency live.

backBufferLength: 2,

Set this to infinity and let the browser handle buffer removal on append unless you are targeting smartTVs which tent to run out of memory before ejecting media from the buffer.

enableWorker: false,

👍 Disabling the worker helps reduce latency. That's the only setting you should need to add.

The biggest issues are that you are on an older version and you may not have the connectivity to the target needed to stream

robwalch commented 2 months ago

Here is our stream: https://llhls-demo.ovenmediaengine.com/app/stream/llhls.m3u8

I'm seeing some issues with PDT alignment across main variant and audio playlists where the difference between PDT tags is -0.5 seconds compared to the media timestamps of segments and parts. Correcting this discrepancy may help with false starts where audio part selection is off by one.