Increasing lag in Live streams

Hello community, how are you all?

So, We have a working live stream, working fine now even in Chromecast.

We have however the know issue with latency.

We run the live streams in 2x 8 core with 16Gb ram each. These are dedicated.

What we have noticed is that although we manage to start the stream with a latency of about 6 seconds, this latency keeps creeping up, no matter what, until reaching between 15 to 18 seconds (measured!).

No matter how idle or busy the servers are, no matter if we through more CPU or memory, it will always have some extra latency.

I would say that 5 seconds could be acceptable, but it seems to be impossible to reduce as things are.

Another effect that we have notice is that for come consumers, the stream seems to start playing from the very beginning. This seems to be eased with reducing drastically the hls_playlist_length parameter.

These are the rtmp settings we are using:

# RTMP configuration
rtmp {
    server {
        listen 1935; # Listen on standard RTMP port
        chunk_size 3000;
	buflen	100ms;

        # This application is to accept incoming stream
        application kLive {
                live on; # Allows live input from above

            	# ADAPTIVE BITRATE SUPPORT
		# Once the stream is alive, transcode for adaptive streaming
            	# This single ffmpeg command takes the input and transforms
            	# the source into 4 different streams with different bitrate
            	# and quality. The scaling done here respects the aspect
            	# ratio of the input.

		# This is commented by default as it is CPU and RAM intensive
		# If you opt to enable it, ensure you have sufficient resources.

            	exec /opt/kaltura/bin/ffmpeg -i rtmp://vod.xxxx.com:1935/$app/$name -async 1 -vsync -1
 -preset veryfast -crf 23 -f flv rtmp://vod.xxxxx.com:1935/kLive/$name_high
                        -c:v libx264 -b:v 1920k -b:a 128k -vf "scale=1280:trunc(ow/a/2)*2" -tune zerolatency -preset veryfast -crf 23 -f flv rtmp://vod.xxxxx.com:1935/kLive/$name_hd720
                        -c copy -f flv rtmp://vod.xxxxx.com:1935/kLive/$name_src;

                dash on;
                #dash_path /var/tmp/dashme;
		dash_path /opt/kaltura/web/content/tmp/dashme/;

                hls on; # Enable HTTP Live Streaming

		# Needed for Chromecast to be able to cast live streams
		hls_base_url https://vod.xxxxxxxxx.com:8443/hlsme/;

            	# Instruct clients to adjust resolution according to bandwidth
            	hls_variant _low BANDWIDTH=288000; # Low bitrate, sub-SD resolution
            	hls_variant _mid BANDWIDTH=448000; # Medium bitrate, SD resolution
            	hls_variant _high BANDWIDTH=1152000; # High bitrate, higher-than-SD resolution
            	hls_variant _hd720 BANDWIDTH=2048000; # High bitrate, HD 720p resolution
            	hls_variant _src BANDWIDTH=4096000; # Source bitrate, source resolution

                hls_cleanup on;
                hls_sync 100ms;
                hls_fragment 2s;
		hls_playlist_length 5s;
		hls_path /opt/kaltura/web/content/tmp/hlsme/;


                # Define the two scripts that will run when recording starts and when it finishes
                exec_publish /opt/kaltura/bin/create_live_entry.php $args;
                exec_record_done /opt/kaltura/bin/upload_live_recording.php $args $path;


        }
    }

Does anyone have a good recommendation to lover the latency time to something close to 5 seconds?

Is there any supported WebRTC that currently works or is implementable?

Many thanks in advance.

Hello,

If you are using the default Live configuration You will get that. You need to shorten the playlist lenght but ALSO the hls segment duration accordingly. Remember to do it in exact integer fragments.

For instance, if your manifest is 30secs and each segment is 10s long, you will get something between 10 and 20s delay. But if our manifest is only 12s and you segments 4s, your delay will be shorter.

We have used it extensively and it’s better to stick to something like 10s delay instead to trying to push any further.

Another trick we felt performed better was to split the ffmpeg script into multiple nginx execs so they execute simultaneously. Maybe is just a placebo but we felt that the different flavors were more in sync.

I hope this helps,

David