Как настроить мультикамерный стрим

Мультикамерная трансляция в Youtube

Как сделать прямой эфир на Youtube. FeelWorld LivePro L1, карты видеозахвата, камеры и микрофоны 📷🎙Подробнее

Многокамерная трансляция со смартфонов через SRT и vMixПодробнее

Как запустить онлайн трансляцию на YouTube. Оборудование для стрима. Обзор Hollyland Mars 400sПодробнее

Как запустить прямой эфир на YouTube из нескольких источников с помощью OBS StudioПодробнее

Решение для мультикамерной трансляции на iOS. Первая мобильная трансляция на канале.Подробнее

WARFACE — 5 вебок на РМ — Серьёзная команда ! МУЛЬТИКАМЕРНАЯ ТРАНСЛЯЦИЯПодробнее

Как сделать Мультикамерную трансляцию на Youtube? Чемодан со стрелками.Подробнее

OBS + iSpyServer=многокамерная трансляция на YouTubeПодробнее

Как пользоваться vMix? Наложение 10 слоев. Мультикамерная трансляцияПодробнее

Пример мультикамерной трансляции на 4 камерыПодробнее

Новая репетиционная база группы «День Победы» (мультикамерная On-line трансляция) Москва 2016Подробнее

Мультикамерная трансляция в Youtube — Дмитрий СидоринПодробнее

На дно! Прямая мультикамерная трансляция ЗБТ «World of Warships» (28.03.15) — MpexaПодробнее

На дно! Прямая мультикамерная трансляция ЗБТ «World of Warships» (28.03.15)Подробнее

Мультикамерная трансляция для DimCoffee — как это было?Подробнее

Источник

Стриминг множества RTSP IP камер на YouTube и/или Facebook

Как известно, у YouTube отсутствует фича захвата RTSP потока. Возможно, это сделано не случайно, а исходя из голой прагматики, чтобы люди не повесили на YouTube статическое видеонаблюдение за своими подъездами и не утилизировали его каналы, которые, как оказалось в пандемию, вовсе не резиновые. Напомним, что некоторое время назад имели место истории с ухудшением и ограничением качества стримов до 240p. Или есть еще одно предположение: стримы с IP камер — это зло для YouTube, потому что у них чуть более ноля зрителей, на которых не накрутишь миллион просмотров рекламы. Так или иначе, фича не представлена, и мы постараемся заполнить этот пробел — помочь YouTube осчастливить пользователей.

Допустим, мы хотим взять обычную уличную IP камеру, которая отдает H.264 поток по RTSP и перенаправить ее на YouTube. Для этого потребуется принять RTSP поток и сконвертировать в RTMPS поток, который принимает YouTube. Почему именно в RTMPS, а не RTMP? Как известно несекьюрные протоколы отмирают. HTTP предан гонениям, и его участь постигла другие протоколы, не имеющие буквы S — значит Secure на конце. От RTMP потока отказался Facebook, но спасибо, оставил RTMPS. Итак, конвертируем RTSP в RTMPS. Делаем это Headless способом (без использования UI), т.е. на сервере.

Для одного RTSP потока потребуется один YouTube аккаунт, который будет принимать поток. Но что делать если камер не одна, а много?

Да, можно насоздавать вручную несколько YouTube-аккаунтов, например, чтобы покрыть видеонаблюдением приусадебный участок. Но это с огромной вероятностью нарушит условия пользовательского соглашения. А если камер не 10, а все 50? Создавать 50 аккаунтов? А дальше что? Смотреть это как? В этом случае на помощь может прийти микшер, который объединит камеры в один поток.

Посмотрим, как это работает на примере двух RTSP камер. Результирующий поток mixer1 = rtsp1 + rtsp2. Отправляем стрим mixer1 на YouTube. Все работает — обе камеры идут в одном потоке. Здесь стоит заметить, что микширование — достаточно ресурсоемкая по использованию CPU операция.

При этом, так как мы уже имеем RTSP поток на стороне сервера, мы можем перенаправить этот поток на другие RTMP endpoints, не неся при этом дополнительных расходов по CPU и памяти. Просто снимаем трафик с RTSP стрима и тиражируем на Facebook, Twitch, куда угодно без дополнительного RTSP захвата и депакетизации.

Меня, как девопса, будет мучать совесть, если я не заскриптую то, что можно было бы заскриптовать. Автоматизации способствует наличие REST API для управления захватом видео с камеры и ретрансляцией.

Например, с помощью запроса:

можно захватить видеопоток от IP камеры.

позволит получить список захваченных сервером RTSP потоков.

Запрос для завершения RTSP сессии выглядит так:

Захватом и ретрансляцией видеопотоков можно управлять или с помощью простого браузера и любого удобного REST клиента, или с помощью минимального количества строчек кода встроить функционал управления сервером в свой web проект.

Давайте подробно рассмотрим, как это можно сделать.

Небольшой мануал, как с помощью минимального кода организовать Live трансляцию на YouTube и Facebook

В качестве серверной части мы используем demo.flashphoner.com. Для быстрого развертывания своего WCS сервера воспользуйтесь этой инструкцией или запустите один из виртуальных инстансов на Amazon, DigitalOcean или в Docker.

Предполагается, что у вас имеется подтвержденный аккаунт на YouTube и вы уже создали трансляцию в YouTube Studio, а так же создали прямую видеотрансляцию в своем аккаунте на Facebook.

Для работы Live трансляций на YouTube и Facebook нужно указать в файле настроек WCS flashphoner.properties следующие строки:

rtmp_transponder_stream_name_prefix= – Убирает все префиксы для ретранслируемого потока.

rtmp_transponder_full_url=true – В значении «true» игнорирует параметр «streamName» и использует RTMP адрес для ретрансляции потока в том виде, в котором его указал пользователь.

rtmp_flash_ver_subscriber=LNX 76.219.189.0 — для согласования версий RTMP клиента между WCS и YouTube.

Теперь, когда все подготовительные действия выполнены, перейдем к программированию. Разместим в HTML файле минимально необходимые элементы:

Подключаем скрипты основного API и JS скрипт для работы live трансляции, который мы создадим чуть позже:

Инициализируем API на загрузку web-страницы:

Добавляем нужные элементы и кнопки – поля для ввода уникальных кодов потоков для YouTube и Facebook, кнопку для републикации RTSP потока, div элемент для вывода текущего статуса работы программы и кнопку для остановки републикации:

Затем переходим к созданию JS скрипта для работы републикации RTSP. Скрипт представляет собой мини REST клиент.

Константа «url», в которую записываем адрес для запросов REST API . Замените «demo.flashphoner.com» на адрес своего WCS.

Константа «rtspStream» — указываем RTSP адрес потока с IP камеры. Мы для примера используем RTSP поток с виртуальной камеры.

Функция «init_page()» инициализирует основной API при загрузке web — страницы. Так же в этой функции прописываем соответствие кнопок вызываемым функциям и вызываем функцию «getStream», которая захватывает RTSP видеопоток с IP камеры:

Функция «getStream()» отправляет на WCS REST запрос /rtsp/startup который захватывает видеопоток RTSP адрес которого был записан в константу rtspStream

Функция «streamToYouTube()» републикует захваченный видеопоток в Live трансляцию на YouTube:

Эта функция отправляет на WCS REST вызов /push/startup в параметрах которого передаются следующие значения:

«streamName» — имя потока, который мы захватили с IP камеры. Имя потока соответствует его RTSP адресу, который мы записали в константу «rtspStream»

«rtmpUrl» — URL сервера + уникальный код потока. Эти данные выдаются при создании Live трансляции в YouTube Studio. В нашем примере мы жестко закрепили URL в коде, вы можете добавить для него еще одно поле на свою web страницу. Уникальный код потока указывается в поле «streamKeyYT» на нашей Web странице.

Функция «streamToFB» републикует захваченный видеопоток в Live трансляцию на Facebook:

Эта функция так же отправляет на WCS REST вызов «/push/startup» в параметрах которого передаются значения:

«streamName» — имя потока, который мы захватили с IP камеры. Имя потока соответствует его RTSP адресу, который мы записали в константу «rtspStream»

«rtmpUrl» — URL сервера + уникальный код потока. Эти данные можно найти на странице Live трансляции в Facebook в секции Live API. Url сервера в этой функции мы указали в коде, как и для функции републикации на YouTube. Уникальный код потока берем из поля «streamKeyFB» на Web странице.

Функция «stopStream()» отправляет RTSP запрос «/rtsp/terminate» который прекращает захват потока с IP камеры на WCS и соответственно прекращает публикации на YouTube и Facebook:

Полные коды HTML и JS файлов рассмотрим немного ниже.

Итак. Сохраняем файлы и пробуем запустить.

Последовательность действий для тестирования

Создаем Live трансляцию в YouTube Studio. Копируем уникальный код видеопотока:

Открываем созданную ранее HTML страницу. Указываем в первом поле уникальный код видеопотока, который мы скопировали на YouTube:

Создаем Live трансляцию в своем аккаунте на Facebook. Копируем уникальный код видеопотока.

Возвращаемся на нашу web страничку, вставляем скопированный код во второе поле и нажимаем кнопку «Start republish

Теперь проверяем работу нашей републикации. Снова переходим в YouTube Studio и на Facebook, ждем несколько секунд и получаем превью потока.

Для завершения републикации нажмите кнопку «Stop»

Теперь, как и обещали, исходные коды примера полностью:

Листинг HTML файла «rtsp-to-rtmp-min.html»

Листинг JS файла «rtsp-to-rtmp-min.js»:

Для минимальной реализации требуется совсем немного кода. Конечно для итогового внедрения функционала еще потребуется небольшая доработка напильником — добавить стили на web страницу и разные проверки на валидность данных в код JS скрипта. Но это работает.

Ссылки

WCS на Amazon EC2 — Быстрое развертывание WCS на базе Amazon

WCS на DigitalOcean — Быстрое развертывание WCS на базе DigitalOcean

WCS в Docker — Запуск WCS как Docker контейнера

Трансляция WebRTC видеопотока с конвертацией в RTMP — Функции сервера по конвертации WebRTC аудио видео потока в RTMP

HTML5-трансляции с RTSP-IP камер — Функции сервера по воспроизведению RTSP видеопотоков

Источник

Cтрим с несколькими камерами из подручных материалов

Всё началось с того, как при мне с помощью OBS Studio и какой-то программки для анимации обоев рабочего стола сделали из логотипа видеологотип (который еще и под текущую играющую музыку анимировался). В тот момент я понял что OBS Studio может НАМНОГО больше, чем просто стримить игры. После более близкого знакомства с OBS Studio, она претендует на место самой крутой программы, которую я когда-либо встречал.

Мне предстояло стримить небольшой ивент для друзей, но поскольку у меня есть оборудование для хорошего звука и желание делать круто, я озадачился организацией стрима с отдельным звуком и несколькими камерами. Стрим по разным причинам получился такой себе, но после этого опыта, я вроде бы представляю как надо. И хочу поделиться. Вот.

Идея заключается в том, чтобы найти 2-3 беспроводных оператора, которые ходят по разным площадкам мероприятия, общаются с людьми, снимают движуху, и т.д. (ну, как у серьезных ребят, короче). А кто-то сидит, коммуницирует с ними по рации, и формирует из всего этого (и еще чего-нибудь, например, сдержимого всякого рода окошек/мониторов/проекторов) интересный видеоконтент, который не скучно смотреть.

Также можно объединять экраны нескольких компьютеров в один стрим, возможно это может быть полезно для игр. Хотя скорее всего конкретно для этой задачи есть и другие технологии.

Зачем?

Потому что это позволяет делать очень круто и сильно сместить технологический потолок качества стрима практически задаром.

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

При наличии еще чего-нибудь, можно сделать хороший звук, хотя бы на стационарных камерах (которые могут быть любыми относительно качественными вэбками).

А при наличии еще одной ЭВМ на линуксе (говорят, даже Raspberry Pi ок для ≤3 потоков), можно немного разгрузить основной комп и его сеть для обработки и отправки стрима.

Общепризнанный протокол для видеостриминга — RTMP. Попытки юзать что-то еще ведут к диким лагам, это была моя главная ошибка.

Справедливости ради, стоит отметить проприетарную технологию NewTek NDI (спасибо, Alexsey), которая вроде как круче, чем RTMP. Однако, для нашего юз-кейса, использование NDI потребует немало лишних денег.

Оказывается, принять RTMP-стрим и перенаправить его в OBS Studio — проще простого. Надо всего-то скомпилировать nginx с кастомным модулем и написать конфиг. Но об этом позже.

По-хорошему, надо делать как-то так:

То-есть не давать мобилкам Интернет, чтобы они не тратили ресурсы ни на что кроме стрима.
Но ежели хороший вайфай с Интернетом уже есть (а лишней точки доступа на 5GHz нет), то можно не брезговать и юзать существующие соединения. Однако, отправлять конечный стрим всё-таки желательно с другого соединения, или, в крайнем случае, с того же, но через провод.

Если есть необходимость принимать стримы с камер и отправлять конечный стрим через один и тот же вайфай, тщательно протестируйте стабильность (и учтите, что она сильно снизится если на этот вайфай полезет толпа девайсов).

Как поднять RTMP-сервер?

Лучше делать это на линуксе, чтобы не испытывать проблем со всякими MINGW/MSYS. И на отдельном железе (не обязательно мощном). Либо в докере, тогда можно скипнуть этот раздел, ибо докерфайл уже есть. Через WSL тоже можно, но надо будет вручную пробросить TCP-порт 1935 в файрволе.

Вот отличный мэнуал How to set up your own private RTMP server using nginx, и в доке тоже годно написано. Краткий пересказ в вольном стиле:

Качаем последнюю Mainline версию исходников отсюда:

Качаем последнюю версию RTMP-модуля:

Если свалится не дойдя до Configuration summary , исправляем проблемы.
Эта команда настроит Ваш стримерский nginx жить в /usr/local/nginx/ и запускаться по команде sudo /usr/local/nginx/sbin/nginx . Таким образом nginx из репозитория ничего не почувствует. Это можно поменять, изучив ./configure —help .

В принципе через make install в данном случае безопасно, но всё-таки не надо так.

В конец добавляем конфиг RTMP-сервера:

При желании, можно настроить HTTP-сервер на отображение статистики.
В доке описано что еще можно настроить, там действительно очень много всего. Если Вы знаете как сделать лучше, буду рад добавить раздел про конфигурацию сервера с материалом из комментариев.

Что делать с RTMP-сервером?

Отправить на него стрим с мобильной приложухи по адресу rtmp://[ваш локальный IP]:1935/live/habr где live — это имя RTMP-приложения в конфиге nginx, а habr — это Stream Key, который надо менять для разных камер.

Если Вы настроили показ статистики (и не забыли поменять путь к файлу stat.xsl ), проверить что стрим пришёл (по адресу http://localhost:8080/stat).

Подключить ко всем стримам OBS Studio.

Очевидно, что сервер может быть не только локальным, но и доступным из внешки, что позволит делать всё то же самое, но не через вайфай, а через Интернет. Можно сделать свой аналог инстаграмовских групповых стримов, ну и вообще, безграничные возможности ))

Есть еще пара вещей, которые я познал на ошибках и хотел бы поделиться:

1. Можно и нужно менять целевой битрэйт конечного стрима по ходу трансляции, и подстраиваться под возможности соединения. Restream, например, рисует крутые графики, по которым понятно на сколько надо понижать. Есть Pull Request на автоподбор битрэйта, но он заглох ((
2. Существует такой параметр Keyframe Interval, и он должен быть больше секунды (это надо вручную задавать в Advanced-версии настроек Output). Restream об этом рассказывает только после окончания стрима, UX на высоте! ))
3. Есть еще один крайне полезный Pull Request, в котором я поучаствовал, и за который активно топлю, но он тоже выглядит заглохшим, хотя мэйнтейнер про него недавно вспомнил и переосмыслил. Лайкните, плиз, если Вам тоже кажется, что отсутствие кнопки Monitor на аудио-каналах — это ужасно.

Вот теперь точно всё, спасибо за внимание ^_^

Для тех кто попытается всё-таки сбилдить nginx для вездесущей венды, вот грабли по которым я прошелся, тот еще квест оказался, я не зря этого процесса так опасался:

Источник