Как реализовать стриминг видео «Один-ко-многим» с минимальной задержкой?

Question

[Виктор]

Надо сделать стриминг когда один вещает видео поток а множество людей его смотрит. Желательно сделать всё с минимальной задержкой в воспроизведении.

Сейчас наладил это так FreeSwitch держит видеоконференцию и транслирует её по rtmp на nginx с nginx-rtmp-module там rtmp конвертируется в hls и раздаётся в браузеры.

Но пока не могу побороть задержку в воспроизведении. Она у меня сейчас до 40 секунд и ни как не могу понять как её сократить.

Конфигурация nginx rtmp секции

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;
		} 
    }
}

Примечание: В итоге задержку мне удалось уменьшить. Как выяснилось её вносила команда `exec ffmpeg ... ` если там не проводить модификации самого видео с уменьшением качества то мой сервер начинает нормально тянуть трансляцию с задержкой до 10 секунд.

Comments

[alex-1917]

хм, хотел бы я посмотреть на реализацию многие-к-одному)))

[Виктор]

alex-1917, Я подразумевал что смотрит трансляцию много человек, очень много.

[Виктор]

Кирилл Бородавченко, А как для webrtc трансляции наладить инфраструктуру чтоб одну трансляцию смотрело 1000+ человек? Я не нашёл бесплатных инструментов для этого, но если подскажите что искать буду очень рад.

[Максим Тимофеев]

Виктор, сам бы с удовольствием нашел такое решение. Но даже тех кто этим профессионально занимается, типа сервисов для вебинаров, все равно есть задержка и они не обещают 1000+.
Самая нормальная по качеству связи контора, на мой взгляд это imind, youtube думаю рассматривать не стоит ибо повторить их архитектуру точно не хватит денег или жизни.
Так вот у них максимум 500 участников при 1 лекторе. Задержка менее 40 секунд, но зависит от расстояния конечно. Если рядом - то секунд 20 есть. Если москва - чили - то и пару минут может быть.

[Владимир]

Виктор, сервера с толстым каналом в инет нужны вот и все - оригинальный стрим забирается серверами ретранслятароами с темже ffmpeg+nginx_rtmp, как балансировать нагрузку ? от банальной балансировки ДНС записями до сложной архитектуры с использованием LVS или другова програмного или аппаратного балансировщика

Answer 1

[Виктор]

В целом отвечу ещё сам раз есть 10 подписчиков.
Мне удалось настроить nginx так чтоб задержка стрима была около 7 - 9 секунд.

Вот конфиг nginx

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; 
        } 
    }
}

Но этого мало. Если такой стрим скормить плееру https://videojs.github.io/videojs-contrib-hls/ то задержка будет 15 - 18 секунд примерно.

Но если внедриться в код плеера и перед тем как он в свои недра передаст содержимое index.m3u8 файла этот файл обрезать чтоб вместо 6 последних элементов в плей листе оставить 2 самых новых файла видео то задержка сократится до 7 - 9 секунд.

Comments

[Антон Тихомиров]

О, потрясно, да, большое спасибо! А конкретно на задержку тут что влияет? dash_length или buf_size? Ибо в основном конфиг как конфиг. А насчет задержки - а важно чтобы прям в режиме реального времени секунда в секунду что ли шел? Просто для музыки, например, какая разница какая задержка, хоть час. Да и для стириминга 20 секунд по мне дак ничто. Другое дело когда частота служб каких-то аварийных, а тут-то)

[Виктор]

Антон Тихомиров, hls_fragment влияет и dash_fragment это длина фрагмента чем меньше тем меньше теоритически возможная задержка.
Но плеер воспроизводил стрим не с конца списка файлов а с начала. Таким образом на задержку влияло ещё dash_playlist_length и hls_playlist_length я пробовал ставить 3 тогда задержка получалась около 16 секунд если ставить 2 то начинало нестабильно работать так как nginx удаляет файлы которые вышли за пределы листа.

А вот если на клиенте искуственно укорачивать список воспроизведения до 2 последних фрагментов то влияние параметров playlist_length устраняется и в таком варианте оно работает.

Мне низкая задержка нужна так как я делаю вебинары с контентом 18+ и там "ведущему" пишут в чат люди и они не готовы ждать долго чтоб увидеть на видео реакцию на их сообщение.

[Антон Тихомиров]

А, ясно, благодарю! Ну да, конечно, вебинары же, точно, я что-то о своей музыке думаю) Действительно, вспомнил что проходил когда-то парочку, дак там вообще практически нулевая задержка, в чате пишут, и ведущий буквально через пару секунд (и то потому-что сообщений много) говорит "Вот, мол, Сергей пишет...", еще думаю надо же как у них все работает отлаженно, на удивление даже...

[Виктор]

Антон Тихомиров, Возможно там было на флеше сделано. В rtmp задержка меньше чем в hls или mpeg-dash. В hls я полагаю 6 секунд минимум. Но допускаю что можно что то выдумать и сократить до 4 секунд. Но не до 0.3 как это при работе с rtsp.

[Антон Тихомиров]

А, ну да, ну да, перед такими вебинарами обычно просят установить браузерное приложение. Беглый поиск ничего не дал, вспомнить не смог, ибо давно было, но могу поискать если нужно. А через приложение-то пробовали? Или не хотите просить юзеров его ставить?

[Виктор]

Антон Тихомиров, Да. Есть тематики где много людей сидят с телефонов. Там не чего такого не поставить.

Answer 2

[Wexter]

с hls у вас задержки меньше 30-40с не будет. low-latency сейчас идут rtmp/mse/webrtc. последний работает из коробки в фрисвиче через sipml5, только что клиентам нужна будет учётка для дозвона extension'у

Comments

[Philipp]

А разве WebRTC поддерживает broadcast/multicast?

[Wexter]

Philipp, не поддерживает

[Виктор]

Wexter, Я так почти и сделал. FreeSwitch получает видео поток от пользователя по webrtc правда через jssip. А потом пушит его по rtmp в nginx. У тех кто подключён по webrtc к FreeSwitch задержка и правда небольшая, и я бы и рад всех сразу к FreeSwitch подключать но только я не нашёл как его масштабировать на тот случай если один сервер перестанет тянуть всех участников одной конференции. (полагаю это вполне возможно, но вот готового решения что то не нашёл, а писать самому бюджет не позволит)

Поэтому и делаю с hls трансляцией так как механизм ретрансляции rtmp потока от сервера к серверу мне понятен и позволяет масштабировать решение на множество серверов.