Управление ffmpeg-процессами

[Adelf]

Есть задачка. Организовать трансляцию на ютуб по трем каналам в течении 72 часов почти непрерывно.
ffmpeg отлично справляется с задачей, но нужен некий менеджер всего этого. Чтобы все эти три процесса он мониторил, по расписанию запускал новые процессы(когда надо сменить источник трансляции) и, вероятно, иметь какой-то интерфейс, чтобы можно было видеть общий статус всего и вероятно управлять всем.
Честно говоря, у меня сомнения... php демон? как управлять процессами?
У меня почему-то возникло желание юзать чтото другое, а не PHP

 

[флоппик]

nginx-rtmp-module

В продакшне юзал, но не под большими нагрузками.

 

[Adelf]

так я ж на ютуб... проблема только в управлении этими ffmpeg процессами. Их будет три.

 

[флоппик]

А он как раз умеет ретрансляцию: https://github.com/arut/nginx-rtmp-module/wiki/Directives#relay

 

[флоппик]

т.е. тебе нужно ретрансляцию с локалхоста + обработчики на on_connect и on_done и все. Не?

https://github.com/arut/nginx-rtmp-module/wiki/Directives#respawn

 

[Adelf]

мм... дело в том что это ретрансляция. с записанных файлов поэтому без ffmpeg не получится. а так да... если бы была только локальная трансляция, но неплохо бы подошло. а в моем случае это кажется лишней проксей не?

 

[флоппик]

supervisord ? )

 

[флоппик]

мм... дело в том что это ретрансляция. с записанных файлов поэтому без ffmpeg не получится. а так да... если бы была только локальная трансляция, но неплохо бы подошло. а в моем случае это кажется лишней проксей не?

Вообще ему без разницы на источник, он может быть и локальным статическим файлом, да. Но тогда да, если это не прям трансляция, то я бы к supervisor написал просто конфиг, да.

 

[fixxxer]

По описанию похоже, что тут хорошо подойдет cfengine. Но с его конфигурацией есть риск сломать мозг

 

[Adelf]

ну... с supervisord не все так просто. допустим если он упал, то продолжить надо с того места где упало. По крайней мере клиенты требуют. С помощью своего софта имея расписание можно как-то подсчитать нужный отступ.

 

[michelle]

А как насчет VLC?

 

[Adelf]

@michelle, да там тоже самое. Надо за процессом следить и контролировать ffmpeg или VLC - неважно.

 

[флоппик]

... продолжить надо с того места где упало. ... имея расписание можно как-то подсчитать нужный отступ.

О сколько нам открытий чудных готовит разных кодеков и контейнеров дивный мир... )

 

[Adelf]

Ну вероятно я слишком большую задачу взял, первый запуск у нас через 2 недели уже. Но они хотят регулярно такое делать. И хотят пригодную для этого систему.
Про кодеки и т.д. - потестим. у нас там вроде все более-менее стандартизовано.
@fixxxer, читаю доки cfengine Вероятно ты прав... может подойти. Но прав и про мозг

 

[AnrDaemon]

Если нужна безусловная устойчивость, то запускать две (допустим) трансляции, параллельно, и переключать при падении.
Вместо "высчитывания".

 

[Adelf]

Упала одна. Подключили другую. Теперь у нас одна параллельная трансляция. Как оживить вторую?

 

[Adelf]

Вдруг кому пригодится.
От первого решения в лоб - ffmpeg стримит файл на ютуб - пришлось отказаться после первого же теста. Малейший дисконнект по сети - и ffmpeg докладывает об ошибке и умирает.
Отработало все так:
php скрипт по расписанию запускает ffmpeg стримить все три канала на локальный nginx с модулем rtmp. Если процесс перезапускают, то php рассчитывает отступ и продолжает трансляцию с нужного места. Но такое за все 72 часа на трех каналах случилось лишь однажды(логи еще не смотрел почему) - все перезапустилось нормально. Все-таки на локальный стримить - сложно упасть.
Вторая задача - рестримить с nginx-rtmp на ютуб. rtmp модуль умеет и сам. Но с дичайшими лагами. Не знаю причины. Вероятно, виновато то, что некоторые товарищи решили что им прямо необходимо для видео 720p битрейт 10000 kbit/s(притом что там и 1000 достаточно было бы).
В итоге рестримил тем же ffmpeg. С одного rtmp(локального) на другой(ютубовский). Тут все было идеально.

Получилось по два процесса на каждый канал. Все управлялось supervisor-ом.

P.S. Спасибо, @флоппик !

P.P.S Ах да. Насчет второго запасного канала. У ютуба есть возможность стримить на бэкап-урл. Т.е. если упадет основной источник, то, похоже, он подхватит бекаповый... Так что на будущее решили стримить одно и тоже с двух разных серверов - на основной и бекап-каналы ютуба. Думаю для надежности - это самое то.

P.P.S. Забыл еще об одной неприятной вещи - когда стримишь на локальный проиграл полностью один файл и хочешь сразу начать стримить другой - все ок, но второй процесс ffmpeg страшно недоволен тем что тайминг поменялся - "было over 9000 секунд, а теперь все опять с нуля?" Так что пришлось перезапускать второй процесс.

// Ugly hack. We should restart restream process during it fails to handle files switching on base stream
exec('supervisorctl restart ' . $this->stream->getName() . '-restream');

 

[WMix]

на 720p рекомендовано 5 - 6 мбит/с

 

[Adelf]

@WMix, ютуб еще недавно рекомендовал 1000-2500. Где-то неделю назад повысил до 1000-4000(все-таки стриминговое видео...).
Да там снято было так, что и 500 хватило бы если честно) Камеры не очень наверно были.

 

[WMix]

ютюб как бабы - нафик качество, главное размер