How to implement one-to-many video streaming with minimal delay?

Question

FreeSWITCH

It is necessary to make streaming when one broadcasts a video stream and many people watch it. It is desirable to do everything with a minimum delay in playback.
Now I've set it up so FreeSwitch holds a video conference and broadcasts it via rtmp to nginx with nginx-rtmp-module where rtmp is converted to hls and distributed to browsers.
But so far I can not overcome the delay in playback. I have it now up to 40 seconds and I can’t figure out how to shorten it.

nginx rtmp section configuration

worker_processes  1;

rtmp {
           
    server {
    live on;
        listen 1935;
        chunk_size 512;
        buflen 1s;
        idle_streams off;
        
        application cam1 {
            live on;
            exec_options on;


         	record off;

            exec ffmpeg -i rtmp://localhost/cam1/$name
          -c:a libfdk_aac -b:a 32k   -c:v libx264 -b:v 128K -s 80x60    -f flv rtmp://localhost/hls/$name_low
          -c:a libfdk_aac -b:a 64k   -c:v libx264 -b:v 256k -s 160x120  -f flv rtmp://localhost/hls/$name_mid
          -c:a libfdk_aac -b:a 128K  -c:v libx264 -b:v 512K -s 320x240  -f flv rtmp://localhost/hls/$name_hi;
           
        }
          
    application hls {
      live on;
      hls on;
      hls_path /tmp/hls;
      hls_fragment 2s;
      hls_playlist_length 10s;
      #record off;
      hls_type live;
 
      hls_continuous on;

      hls_fragment_naming sequential;

      hls_nested on; 
                        hls_cleanup off;

      hls_variant _low BANDWIDTH=160000;
      hls_variant _mid BANDWIDTH=320000;
      hls_variant _hi  BANDWIDTH=640000;
    } 
    }
}

Note: As a result, I managed to reduce the delay. As it turned out, it was introduced by the `exec ffmpeg ... ` command, if there is no modification of the video itself with a decrease in quality, then my server starts to normally pull the broadcast with a delay of up to 10 seconds.

Answer 1

In general, I will answer again myself, there are 10 subscribers.
I managed to set up nginx so that the stream delay was about 7 - 9 seconds.
Here is the nginx config

worker_processes  1;

rtmp {
           
    server {
    live on;
        listen 1935;
        chunk_size 512;
        buflen 1s;
        idle_streams off;
        
        application stream {
            live on; 
         	record off;
 
      hls on;
      hls_path /tmp/hls;
      hls_fragment 1s;
      hls_playlist_length 6; 
      hls_type live;
  
      hls_fragment_naming sequential;

      hls_nested on;  
      dash on;
            dash_path /tmp/dash;
            
            dash_fragment 1s;
            dash_playlist_length 6;
            dash_nested on; 
        } 
    }
}

But this is not enough. If such a stream is fed to the player https://videojs.github.io/videojs-contrib-hls/ then the delay will be 15 - 18 seconds approximately.
But if you inject into the player code and before it transfers the contents of the index.m3u8 file to its bowels, cut this file so that instead of the last 6 elements in the playlist, leave the 2 newest video files, then the delay will be reduced to 7 - 9 seconds.

Answer 2

with hls you will not have a delay of less than 30-40s. low-latency now go rtmp/mse/webrtc. the latter works out of the box in friswitch via sipml5, but clients will need an account to dial extension'u