Круглосуточная трансляция CCTV IP Камеры на Youtube
Приветствую!
Эта статья является консолидированным, обновленным и дополненным переизданием ранее написанных мной статей на эту же тему. Публиковались эти мини-заметки в закрытых бродкастерских комьюнити, поэтому ссылаться на них здесь я не буду.
За время, которое прошло с момента написания последней статьи, изменились частично и аппаратная, и софтверная части проекта, что неизбежно привело к необходимости провести ряд изменений и в статьях на эту тему. Необходимо было исправить ранее допущенные ошибки и внести дополнения, поэтому было принято решение написать единую статью со всеми нюансами, с которыми я столкнулся.
Дисклеймер: Все описанные в статье действия — исключительно мой индивидуальный опыт.
Я не являюсь заслуженным и признанным специалистом ни в сфере стрим‑технологий, ни в сфере IT, поэтому решения применялись максимально простые, топорные и в меру надежные.
Главное условие состояло в том, чтобы я смог это сделать сам с минимальным участием извне, и чтобы я смог это воспроизвести без помощи. Возможно, некоторые вещи сделаны либо крайне нерационально, либо избыточно сложно, но это работает.
«Если это тупо, но работает — это не тупо.»
Я искренне стараюсь не растекаться мыслью по древу, но в то же время пытаюсь вести повествование так, чтобы были понятны мои выводы и причины принятия определенных решений. Одну из тем, а именно распределение нагрузки на отдельные потоки и ядра процессора, а так же на отдельные GPU я намеренно не стал включать, поскольку эта ветвь эволюции оказалась тупиковой в моей задаче и развивать её не имеет смысла. Пока что…
В статье я буду двигаться по пути размышлений и действий, к которым эти размышления привели и которые я предпринимал в процессе. Местами я буду перескакивать во времени и в последовательности ради удобства повествования. Прошу мне это простить. =)
Идея
В 2020 году, когда всё и все были закрыты на карантин, мне очень захотелось вернуться к реализации проекта, вдохновленного некогда популярным EarthCAM. Когда мы все были ограничены в перемещениях — было очень приятно иметь возможность поглазеть хотя бы через цифровые глаза на окружающий мир. Естественно, я не стал замахиваться на весь мир. Решил начать со своего Жилого Комплекса на окраине Москвы.
Идея была простая (а простота — это надёжность) — разместить несколько камер в жилом комплексе на разных домах и транслировать картинку в сеть, чтобы соседи могли видеть, что происходит в жилом комплексе, в соседних дворах и переулках не покидая дом.
Я вспомнил, что ранее интересовался вопросом, тема была мне более-менее близка (ох как же я ошибался), интерес к проекту разгорелся с новой силой, и я взялся за работу.
Аналогичные проекты, которые мне удавалось найти с похожей концепцией и идеей:
See Jackson Hole https://www.youtube.com/@Seejh
Очень уютный проект инсталяторов CCTV в небольшом городкеLarryRos https://www.youtube.com/@LenskLR
Приятный проект с камерами в небольшом городе в глубинкеMobotix Webcams Russia https://www.youtube.com/@msbud2
Санкт-Петербург, этим всё сказаноEarthCam https://www.youtube.com/@earthcam
Неповторимый оригиналNYC Timescape, человек который снимает таймлапс длиной в 30 лет, и который недавно обзавёлся онлайн трансляцией
https://www.youtube.com/@NYCTimescapeЛегендарный — San Francisco FOG Cam https://www.fogcam.org/
И, разумеется, первый и самый важный проект профессоров из Кембриджа — камера наблюдения за кофеваркой! (Классику нужно знать!)
Да, и годовой таймлапс я уже тоже успел снять. Он есть на канале проекта на Youtube. Качество получилось так себе, но сам факт меня не может не радовать. Много ли таймлапсов длиной в год вообще снято? Вот именно =)
В целом — таких проектов довольно много, каждый реализован по-своему, у каждого свой способ, и своя история. Перечислять все не имеет смысла, но наиболее приятные для меня я отметил.
Начало
«Хочу транслировать уличные камеры 24×7»
Задачи:
Непрерывная трансляция видео с CCTV камер на какую-либо платформу.
Обязательная возможность интеграции в эти трансляции некоторой графики (плашки, заглушки, возможно рекламные интеграции, возможно интеграция иного контента)
Возможность мониторинга в реальном времени состояния трансляции и состояния системы
Обеспечение быстрого развертывания софта на базе компьютера с WIN10 и GPU Nvidia (объяснюсь по этому поводу ниже)
Организация непрерывности получения видеопотока с камер или минимизация времени простоя
Минимизация ограничений с точки зрения выбора IP камер уличного видеонаблюдения
Максимизация количества транслируемых камер внутри одной физической машины
Минимальное количество и сложность оборудования в местах размещения камер
Кандидаты
Забегая вперед — скажу, что я выбрал OBS Studio. Почему — рассказано в одном из следующих пунктов статьи.
Глобально было два варианта:
Разница более менее интуитивно понятна — это просто вопрос подхода. Далее следует разъяснение:
Видеокодер — это ПО или отдельное устройство, которое преобразовывает видеоконтент в цифровой формат для потоковой передачи на целевую платформу. Далее следует гугловское видео о том, что такое видеокодер (энкодер).
Существует множество как программных (ПО), так и аппаратных решений. В гайде Google по трансляциям есть целый список. Эти приложения и устройства одобрены, а значит протестированы, Youtube’ом и, что более важно, широко используются среди стримеров.
Список аппаратных и программных видеокодеров и мобильных версий видеокодеров.
В роли целевой платформы может быть либо ваш собственный сервер, где вы развернули сайт с плеером и будете откручивать свою трансляцию, либо это может быть любая платформа, которая имеет такой функционал, например Youtube, Rutube, Twitch и тому подобные.
Следующие изображения взяты из гайда Google по трансляциям.
Две упрощенных логических схемы демонстрируют как выглядит сигнальный тракт в трансляции.
Игровой контент и простые трансляции В таких случаях достаточно внешнего микрофона, веб-камеры и наушников. Геймеры также могут использовать дополнительное оборудование, в том числе зеленый экран.
Изображение из гайда Google
Профессиональные трансляции Для высококачественных трансляций может потребоваться несколько микрофонов и камер, микшеры, а также аппаратные видеокодеры.
Изображение из гайда Google
Среди кандидатов были и другие решения, помимо OBS Studio.
Например Raspberry Pi устройства и аналогичные мини-компьютеры, или же просто аппаратные кодировщики видео. От них я был вынужден отказаться либо в силу необходимости изучать «Линукс для чайников», либо в силу полной немощности этих мини-пк в области решаемых задач.
Дополнительная причина отказа от взаимодействия с RASPBERRY будет логической ссылкой на причины выбора определенной архитектуры проекта. Это пункт «Железо» в статье.
TLDR: В общем и целом — оказалось экономически не выгодно использовать Raspberry Pi. Каждая отдельная коробка в месте размещения камеры — стоит денег, принимающий сервер нужно собрать, обслуживать и содержать, в итоге вместо 1 устройства в месте размещения (камера) и 1 сервера на моей стороне, получается по 2 устройства в каждом месте размещения (камера и Raspberry) и два сервера у меня (сервер принимающий RTMP потоки от Raspberry и непосредственно транслирующий видео-контент на платформу сервер). Далее я расшифрую сказанное рассказывая об архитектуре.
Что касается софта: разумеется, я гарантирую, в комментариях сейчас появится человек из неповторимой и прекрасной секты группы FFMPEG-Enthusiast:
FFMpeg был отвергнут мной по двум причинам: избыточность, сложность и избыточная сложность.
Вообще там еще тысяча и одна причина. И все они перечислены в видео выше.
Я просто не хочу создавать себе сложности на ровном месте. Есть более простое для меня (это важно, для меня) решение, а сэкономленное на изучении с софта с нуля время я перераспределю иным образом.
В качестве второй альтернативы я рассматривал Vmix. Отличный и проверенный бродкастерами по всему миру программный видео-микшер и видео-кодер, но, к сожалению, он почему-то постоянно терял поток с IP камер, что приводило к фризу видео в эфире. Дополнительным ограничением был тот факт, что Vmix является платным софтом, и его использование без лицензии может повлечь определенные последствия.
В качестве третьего варианта я рассматривал довольно интересное решение DATARHEI | Restreamer. Практически идеальный вариант, но он не умеет в оверлеи типа плашек Donation Alerts, и самое плохое — он кривой. Все что может в нем навернуться и упасть — падает. Он нестабилен, он лагает, он плохо работает и так далее. Даже с учетом его преимуществ — он все равно постоянно рушится и стрим может скоропостижно закончиться в любой момент. Хотя его достоинств я не отрицаю.
Так же среди решений я натыкался на множество разнообразного NVR софта типа BlueIRIS. Многие, кто слышал или видел мой проект задавали мне вопрос: «Ты что, пытаешься сделать из Youtube’a облачный видеорегистратор, да еще и бесплатный?»
Нет. Совсем нет. Это возможность просто и быстро дать доступ неподготовленным людям к камерам, которые показывают, что вокруг них происходит, не более того. Задача видеорегистратора — обеспечение безопасности. Здесь же задача другая. Хотя, врать не буду, несколько раз мои камеры помогали решить спорные ситуации, попадавшие в их поле зрения. Несколько спорных ситуаций с ДТП решились в пользу наших соседей благодаря наличию видео и возможности без проблем эти видео получить и отсмотреть.
Я все же я склоняюсь к тому, что мой проект — это не попытка сэкономить на полноценном NVR с рашаренным доступом к потоку с камер, а все таки бродкастерский проект.
Что значит NVR?
NVR — это сокращение от Network Video Recorder. Устройство является частью системы пересылки и хранения видеоинформации, получаемой с IP-камер.
Платформа
Здесь изначально, еще в 2020-м году, был выбран Youtube. Безальтернативно, увы.
Плюсы:
Бесконечные трансляции
Неограниченное количество одновременных трансляций на одном канале (мой рекорд 24 одновременных стрима, рекорд который я видел лично — это 54 одновременных стрима.
Удобство для пользователей
Практически идеальный плеер
Два сервера (для основного и резервного потока)
Удобная, хоть и не идеальная, система мониторинга трансляций
Неограниченное ничем количество пользователей, смотрящих трансляцию.
Недостатки:
Битрэйт, а значит и качество, трансляции ограничены 6.000 кбит/с, но для трансляции CCTV камеры — этого более чем достаточно.
Требуется пройти верификацию, чтобы получить возможность вести прямые эфиры
Бесконечные трансляции дают возможность просмотреть только последние 12 часов в плеере. (То есть тут уже точно ни о каком бесплатном облачном NVR сервисе из Youtube’a не идёт речь).
Все эти плюсы при полном отсутствии необходимости содержать свой сервер (пусть и арендованный облачный) для размещения трансляции в интернете. Уже есть отличное, надежное, готовое, а главное — бесплатное решение.
Ни одна другая бесплатная платформа не предлагала такого набора возможностей — как Youtube, да и платные тоже, да и платных особо не было и нет. Сейчас, спустя уже больше 3-х лет, я все еще остаюсь при своём мнении на этот счет.
Главная сложность: Обязательная непрерывность транслируемого видеопотока.
Если видеопоток не будет поступать достаточно долго (по разным данным от 4 до 6 часов), то трансляция будет завершена автоматически со стороны Youtube.
И более того, это справедливо для «запланированных трансляций». Если использовать дефолтную опцию «Начать трансляцию» и запускать простую «трансляцию» сразу — то она завершится чуть ли ни через считанные минуты после того, как перестанет поступать видеопоток.
Как сделать:
Есть официальный гайд от Youtube | Google на эту тему, дублировать его здесь я не буду, т.к. он может устареть еще до публикации статьи.
Если кратко:
Регистрация аккаунта Google, его верификация, начальная его настройка.
Создание и оформление Youtube канала, получение разрешения на проведение трансляций на Youtube канале.
Переход в творческую студию, создать «Трансляцию».
Пункт «Управление» → «Запланировать трансляцию».
Создать ключ потока трансляции и дать ему понятное имя.
Вставить ключ трансляции в видеокодере и запустить трансляцию в нем (что это такое — я расскажу далее).
Запустить запланированную трансляцию в панели управления Youtube, когда в нее начнет попадать видеопоток по ключу.
Рекомендация: Делайте ключ трансляции для каждого отдельного стрима и называйте эти ключи корректно, чтобы не возникло путаницы.
Поздравляю, у вас теперь идет трансляция, которая (хочется верить) не закончится скоропостижно.
Железо
Здесь пойдет разговор как раз про выбор архитектуры.
В сущности, есть два варианта:
1. Камеры, которые имеют на борту RTMP-encoder и транслируют поток на целевую площадку сами.
Плюсы | Минусы |
-Автономность и Децентрализация -Нет необходимости открывать порты для доступа к камерам в местах размещения, т.к. камера сама забрасывает свой видеопоток на сервера целевой платформы. | -Отсутствие контроля -Ненадежность RTMP-encoder«a камеры -Невозможность интеграции контента в стрим -Необходимость всё равно открывать порты на месте размещения камеры, чтобы получать доступ в её web-морду и иметь возможность с ней что-то делать. |
2. Камеры не имеют на борту RTMP-encoder«a. Видеопоток с камер забирается сервером и уже на сервере кодируется и отправляется на платформу.
Плюсы | Минусы |
-Централизованное управление, мониторинг -Возможность удалённого управления сервером. -Возможность интеграции любого дополнительного контента в стрим. -Возможность обеспечить резервирование интернет-подключения и электропитания, как следствие централизации. -Можно использовать облачный сервер (!!!) -Возможности автоматизации ряда функций | -Сложности организации работы сервера -Вынужденная необходимость обеспечения резервирования интернета и электричества -Необходимо обеспечить удаленный доступ к серверу, чтобы иметь возможность управлять им удаленно. -Необходимость пробрасывать порты и открывать доступ «снаружи» к камерам на местах их размещения, чтобы иметь возможность забирать с них видеопоток и управлять ими. |
От идеи транслировать видео напрямую с камер я отказался сразу.
Краеугольной и концептуальной проблемой становится доступ к камерам, он осложнен в обоих вариантах. Не в последнюю очередь я отказался от первого варианта и с точки зрения надежности. Как минимум — не выполняется добрая половина изначального пула условий, хотя бы с точки зрения отсутствия возможности мониторинга состояния трансляции. В какой-то момент у вас прекратится подача видеопотока на целевую платформу, а вы об этом узнаете уже тогда, когда трансляция прекратилась.
Мои первые потуги в этой области были очень забавными. Трансляция длиной 2,5 часа, потом целых 300 часов, а потом аженно 1500 часов без перерыва. Но каждый раз обрывалось все скоропостижно и внезапно, увы. Приходилось начинать заново.
Было принято решение использовать некий абстрактный сервер для того, чтобы получать видеопоток с камер, и уже на сервере его кодировать и отправлять на целевую платформу.
По части железа — собирал свой «чудо-сервак» из того, что было. Для меня главнее и важнее было выбрать не само железо, а выполнение условия на старте: использование среды Windows поскольку я испытываю полное Linux-бессилие. Поэтому все варианты с Raspberry Pi были отброшены незамедлительно. С рядом других (врать не буду, довольно ожидаемых, и неожиданных в то же время х_х) нюансов в части железа я столкнулся уже позже, и вот почему.
У нас есть камера, сервер и Youtube. Пройдёмся по процессу по шагам:
Камера снимает происходящее и кодирует видеопоток в кодек h.264.
Сервер забирает видеопоток с камеры при помощи протокола RTSP (в таком варианте IP камеры отдают видеопоток в большинстве случаев)
Сервер декодирует видеопоток, накладывает на него некую графику, оверлеи, плашки или что либо другое, рендерит получившуюся картинку.
Сервер кодирует видеопоток тем же кодеком h.264 для трансляции на Youtube и отправляет по ключу трансляции видеопоток на сервер Youtube«а при помощи RTMP протокола.
Нас интересует в большей степени часть, происходящая на сервере, а именно:
Декодирование входного видео, компиляция сцены, рендеринг и кодирование исходящего.
Изначально я использовал процессор AMD FX8320 + GTX 550Ti. Видеокарта была нужна только для ускорения рендеринга «сцены», а для декодирования входящего видеопотока и кодирования исходящего видеопотока в стрим использовался процессор, но низкая производительность и высокий нагрев вынудили меня начать смотреть в сторону GPU Decode/Encode, то есть декодирования и кодирования видеопотока при помощи видеокарты.
Процессор AMD FX8320 не позволял декодировать более 4-х входящих RTSP потоков в FullHD/30 кадров в секунду. GTX 550Ti невозможно использовать для HW Decode/Encode видео в принципе. Она старовата для таких фокусов.
Nvenc и Nvdec
В то же время почти все GPU Nvidia, после момента времени, получили на борту аппаратные модули кодирования и декодирования видео, известные как NVENC (Nvidia Encoder) и NVDEC (Nvidia Decoder). Разные модели имею разные возможности в этой части.
На сайте Nvidia Developer по ссылке можно ознакомиться с матрицей возможностей видеоадаптеров NVIDIA в этой части: Video Encode and Decode GPU Support Matrix
Video Encode and Decode GPU Support Matrix
На этом же Dev портале мне удалось найти информацию о производительности видеоадаптеров в задаче encode/decode в «кадрах в секунду». К несчастью, 99% тестов GPU проводимых обзорщиками никак не затрагивает тему NVENC и NVDEC, поэтому мы знаем всё о FPS в играх, и ничего о производительности в каких-либо других задачах.
Согласно информации из документации NVidia, условная RTX 3090 может декодировать 742 кадра в секунду в разрешении 1080Р (4:2:0, 8 bit) при помощи своего аппаратного NVDEC модуля.
Кодировать кодеком NVENC эта же видеокарта может 810 кадров в секунду в самом низком пресете качества. Все данные взяты из ресурса NVIDIA DOCS HUB по ссылке: NVIDIA Video Codec SDK v12.
NVIDIA Video Codec SDK v12.1 Application Note — NVENC Capabilities
NVIDIA Video Codec SDK v12.1 Application Note — NVDEC Capabilities ^
Важное уточнение: В связи с тем, что модуль кодирования и декодирования видео в графическом адаптере отделен от основного вычислительного модуля — кодирование и декодирование видеопотока напрямую не связано с процессом рендеринга, поэтому нагрузка распределена между кодирование, декодированием и рендерингом и эти задачи могут выполнять одновременно без особых затруднений.
Итак, процесс выглядит следующим образом:
Модуль NVDEC декодирует полученный видеопоток
Основные вычислительные блоки обрабатывают изображение и рендерят финальную картинку
Модуль NVENC кодирует исходящий видеопоток в трансляцию
Изображение с сайта Nvidia Developer
Дальше — максимально упрощенная математика на очень абстрактном уровне:
Один стрим — это 30 кадров в секунду декодирования и 30 кадров в секунду кодирования потока. Согласно данным из таблицы о возможностях GPU Nvidia серии 3000 — можно предположить, что одна RTX 3090 в состоянии обеспечить 24 стрима одновременно в разрешении 1080p и частоте кадров 30 к/с.
В ближайшее время я планирую расшириться до трансляции 8 камер одновременно, и заменить видеокарту на RTX3060 в тестовом режиме. Хочу убедиться в том, что действительно могу рассчитывать на 20+ потоков трансляции внутри одной машины и иметь хотя бы минимальный оверхед по ресурсам.
Что касается остального железа:
Поскольку почти все сложные задачи здесь ложатся на GPU — процессор я поменял только с целью снижения энергозатрат и снижения рабочих температур.
На данный момент используется Intel Core i7 4770k. Вся машина потребляет ровно 100 ватт/ч в рабочем режиме уже более полутора лет.
Оперативная память — тоже не является проблемой. Стоят 4 модуля по 4 Gb обычной оперативки DDR3. 16 гигабайт хватает за глаза. Каждый отдельный инстанс трансляции употребляет не более 500 мб оперативной памяти.
Материнская плата: Любая материнка с поддержкой WoL (Wake On Lan) для возможности удаленного включения в случае нужды и возможностью установки Power State, чтобы при потере электроснабжения — компьютер включался сам при возвращении питания.
Самое главное — проверяйте комплектующие на длительную работоспособность и перегрев. Обязательно поменяйте термопрокладки, термопасту и обслужите остальные элементы систем охлаждения.
Если вы планируете оставлять сервер дома без присмотра — обязательно удостоверьтесь в его безопасности! Халатность может привести к пожару!
Это не шутки!
Сгоревший китайский некачественный райзер питания процессора.
Чуть не привел к пожару сервера в новогоднюю ночь 2021–2022 года.
На данный момент актуальный сетап, который я использую — это домашний «сервер»:
CPU | Intel Core i7 4770k |
RAM | 16 Gb Kingston HyperX |
GPU | GTX770 4 GB OC |
HDD | Toshiba 2006 года выпуска |
PSU | CHIEFTEC 650 Ватт |
MB | Gigabyte Z-87 HD rev. 3 |
OS | Windows 10 Pro |
В качестве камер я использую две IP камеры совершенно разного уровня.
Одна — ранее была составной частью банкомата и работает до сих пор скорее «вопреки», а не «благодаря».
Вторая — Omny A55N28. Отличная железка, высокое качество, широкий угол. Правда за несколько лет эксплуатации я допустил ужасные ошибки, которые привели к повреждению этой камеры, и теперь она тоже «страдалец».
Видеопоток обеих камер, который я забираю — получаю через RTSP.
Разрешение 1920×1080
Частота кадров 30 к/сек
Битрейт 8000 кбит/сек
Софт
Выбор видеоэнкодера
В качестве софта была выбрана простая и удобная OBS Studio, в настоящий момент это OBS ver. 29.1.3. (Указана последняя версия, для которой всё вышеописанное тестировалось и проверено на предмет работоспособности).
Что из себя представляет OBS. Это программный видеомикшер и видеоэнкодер. Как раз то, что мне нужно. Минимальные сложности, максимум функционала. Отличная поддержка, прекрасное и обширное комьюнити и так далее.
Из плюсов:
OBS — это полноценный полнофункциональный программный видео-микшер. Этот пункт полностью закрывает задачу в части обеспечения возможности интеграции дополнительного контента внутрь трансляции в любой момент.
OBS поддерживает «ключи» при запуске. То есть ей можно задать параметры, с которыми она будет запускаться, например сразу при запуске приложения будет запускаться трансляция, приложение будет сворачиваться в трэй, будет отключаться превью для экономии ресурсов и так далее. Описание этих параметров и их способ применения я описывал в одной из предыдущих статей и обязательно распишу эту деталь здесь.
Так же бонусом является возможность запускать несколько разных, полностью независимых друг от друга инстансов (экземпляров) OBS, которые будут идентифицируемы в системе и которые можно мониторить отдельно друг от друга, что тоже крайне полезно. На этом пункте остановлюсь подробнее, поскольку я нашел для себя более удобный и более качественный способ решить задачу с запуском нескольких инстансов OBS чем тот, что я использовал в предыдущей статье.
Кодирование видеопотока
В моём Гранд-Плане была идея о 24 видео потоках трансляции на одном сервере.
К сожалению, бюджет проекта колеблется около нуля, а потребительская линейка GPU NVIDIA, которые являются пределом доступного для меня железа на этом проекте позволяют обрабатывать не более 3-х, а с недавнего времени благодаря широкому жесту от NVidia — 5 потоков кодирования видео одновременно.
Ограничение это сугубо программное, и методы его обхода уже давно известны и широко применяются в индустрии.
Способ простой: Патч 1337 Nvidia NVENC and NvFBC patches for Windows Nvidia drivers.
Гуглится прямо по этому текстовому запросу, но вот ссылка на всякий случай (ссылка на софт под WIN).
Сначала скачиваете подходящую версию драйвера, потом патч-тул, потом сам патч драйвера.
Патчите драйвер — вуаля! Более подробная инструкция на страничке проекта на GitHub.
Теперь количество потоков кодирования ограничено только возможностями GPU.
Подготовка и настройка софтверной части
Для себя я определил три ключевых проблемы в этой области:
Периодические рандомные падения и вылеты OBS,
Периодические перебои с энергоснабжением,
Временные перебои с интернет-подключением
Если последнее решилось в недавних обновлениях OBS, когда появился функционал автоматического переподключения при обрыве соединения, то первые две проблемы, увы, пришлось решать самому.
Мне было необходимо создать систему, в которой трансляция не прерывается, а в случае, если это происходит — восстанавливается всё самостоятельно, поскольку всё время, которое я проводил эксперименты над проектом, пришлось на карантин 2020 года — я, постоянно находясь дома, вынужденно и непрерывно мониторил состояние «DIY‑сервера», не отвалился ли интернет, не упала ли OBS, не вырубилось ли питание, и так по кругу. В случае, когда происходило падение OBS или вырубался сервер — приходилось ручками запускать OBS, выбирать нужные сцены, забивать настройки трансляций и запускать их снова и снова.
В какой-то момент мне это капитально надоело и встал вопрос, либо свернуть проект, либо всё-таки вспомнить, что сейчас 21-й век и всё, что приходится делать более 2-х раз — можно и нужно автоматизировать.
Решение, как оказалось позже, было довольно простым, хотя при беглом Google’инге я нашел не так уж и много готовых рецептов. Попробую поэтапно рассказать, как это реализовал я.
Итак, задачи: Запуск двух инстансов (копий) OBS Studio со своими конфигурациями. Автоматизация запуска OBS при перезагрузке сервера. Автоматизация перезапуска OBS в случае краша или зависания приложения.
Добавление источника видео в OBS, сборка «сцены», создание профиля трансляции
Добавление источника
На базовом уровне для того, чтобы получить видео с IP камеры в OBS нужно сделать всего 2 действия:
Открыть OBS
Добавить в доке Sources (Источники) — Media Source
Добавление источника видео в разделе SOURCES
Параметры добавляемого Media Source
Чтобы добавить сетевой источник видео, а именно IP Камеру — нужно снять галочку с чекбокса «Локальный файл» и вставить ссылку на поток камеры.
В общем виде ссылка выглядит так: rtsp://login: password@192.168.1.222:554/1/1
Ссылка на RTSP поток камеры может отличаться в зависимости от модели камеры.
Общий смысл простой: протокол, логин, пароль, @(at) далее IP адрес камеры, далее порт 554 — это стандартный RTSP порт, и далее выбор канала и потока внутри камеры. По умолчанию первый поток — является основным. Если камера расположена в вашей локальной сети — всё взлетит мгновенно.
Если камера расположена в другой сети — вам нужно убедиться, что на камеру проброшен 554-й порт для получения от нее видеопотока и проброшен 80-й порт (или 443-й если того требует камера) для доступа к ее WEB интерфейсу. Возвращаясь назад к выбору архитектуры — это одна из причин. Чаще всего обеспечить доступ из WAN к камере проще, чем поставить на месте её размещения дополнительную коробку RASPBERRY PI для того, чтобы она перегоняла RTSP в RTMP, а потом ставить у себя RTMP сервер, чтобы принимать поток от камеры.
Об этом я писал в части статьи про архитектуру и причины отказа от ряда альтернативных решений задачи.
Сцены
Теперь подробнее поговорим о сборке сцены и о том что это такое.
Главное окно OBS Studio
Сцена — это набор материалов (картинки, видео, музыка, анимации). Всё, из чего состоит итоговая, финальная картинка, которую вы транслируете — это и есть сцена.
В приложении можно заранее собрать несколько «Сцен», как в театре, буквально, для того, чтобы производить глобальные изменения в транслируемой картинке нажатием одной кнопки. Но это тема для отдельной статьи.
Сама сцена состоит из «Источников», они же «Инпуты» или «Сурсы/Сорсы». Они расположены во второй вкладке нижней Док‑Панели.
Это сам контент, который мы послойно добавляем в нашу сцену и собираем финальную картинку. Здесь могут быть видео, фото, анимации, захват окна приложения, захват игры, трансляция получаемого по ссылке медиа‑контента, практически всё, что угодно. Эти самые источники можно свободно перемещать по холсту, и трансформировать. Не забывайте, что логика «Слоёв» здесь тоже работает, поэтому слой, который ниже — будет и визуально «под» теми слоями, которые выше.
Итак, вы добавили нужный источник видео-потока, а именно камеру, в свою сцену.
Сцена собрана. Теперь нужно её сохранить и на всякий случай экспортировать.
Окно Коллекции Сцен.
В верхней части окна нажимаем: «Scene Collection‑ Rename» и задаём сцене имя, например «CAM1SC» (Камера 1 Коллекция сцен).
Важное условие! Название сцены не должно содержать пробелов, подчеркиваний и дефисов, а так же должно быть только на английском языке. По моему опыту — нарушение условия может всё поломать на следующих этапах.
Теперь о профилях трансляции.
В то время, как коллекция сцен включает в себя сцены, их «источники» и прочее, что связано именно с входящим контентом, всё, что касается настроек энкодера, настроек качества записи, разрешения выходного видеопотока, битрейта, частоты кадров и в том числе ключа потока, что для меня критично, записывается в «Профиль» (Profile).
Адрес сервера, который будет принимать ваш поток трансляции и окно ввода ключа трансляции
Настройки кодировщика видео-потока.
Настройки «холста» и исходящего видеопотока (разрешение и частота кадров)
Все эти параметры записываются в отдельный «Профиль». Их так же можно экспортировать в виде папки и сохранить в надежное место. Итого я создал профиль, который называется CAM1PROFILE.
По умолчанию все эти настройки хранятся по адресу ниже, но позже мы это изменим.C:\Users\Username\AppData\Roaming\obs-studio
.
В подпапке «basics» — профили и сцены
В самой папке есть глобальный файл global.ini, в котором содержатся настройки самого приложения. А в том числе и:
Размер окна
Положение док-панелей
Настройки рендерера приложения (Direct3D 11 или Open GL) (Это тема для отдельной статьи, если эта будет одобрена к публикации и возникнет необходимость объяснить, что это и зачем это).
Задержка и количество попыток переподключения в случае потери соединения с интернетом.
Окно дополнительных настроек OBS Studio.
Кстати, здесь же в Advanced Settings нужно указать количество попыток переподключения к серверу, на который отправляется ваш видеопоток, а так же задержку переподключения. Это один из важных этапов автоматизации процесса. Не игнорируйте его.
По умолчанию OBS запускается с последней Сценой и Профилем, которые были использованы в пос