Приветствую! 

Эта статья является консолидированным, обновленным и дополненным переизданием ранее написанных мной статей на эту же тему. Публиковались эти мини-заметки в закрытых бродкастерских комьюнити, поэтому ссылаться на них здесь я не буду.

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

Дисклеймер: Все описанные в статье действия — исключительно мой индивидуальный опыт.
Я не являюсь заслуженным и признанным специалистом ни в сфере стрим‑технологий, ни в сфере 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 по трансляциям.
Две упрощенных логических схемы демонстрируют как выглядит сигнальный тракт в трансляции.

Среди кандидатов были и другие решения, помимо 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 на эту тему, дублировать его здесь я не буду, т.к. он может устареть еще до публикации статьи.

Если кратко:

1. Регистрация аккаунта Google, его верификация, начальная его настройка.

2. Создание и оформление Youtube канала, получение разрешения на проведение трансляций на Youtube канале.

3. Переход в творческую студию, создать «Трансляцию».

4. Пункт «Управление» -> «Запланировать трансляцию».

5. Создать ключ потока трансляции и дать ему понятное имя.

6. Вставить ключ трансляции в видеокодере и запустить трансляцию в нем (что это такое - я расскажу далее).

7.  Запустить запланированную трансляцию в панели управления Youtube, когда в нее начнет попадать видеопоток по ключу.

Рекомендация: Делайте ключ трансляции для каждого отдельного стрима и называйте эти ключи корректно, чтобы не возникло путаницы.

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

Железо

Здесь пойдет разговор как раз про выбор архитектуры.

В сущности, есть два варианта:

1. Камеры, которые имеют на борту RTMP-encoder и транслируют поток на целевую площадку сами.

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

На этом же 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.

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

Итак, процесс выглядит следующим образом:

• Модуль NVDEC декодирует полученный видеопоток

• Основные вычислительные блоки обрабатывают изображение и рендерят финальную картинку

• Модуль NVENC кодирует исходящий видеопоток в трансляцию

Дальше – максимально упрощенная математика на очень абстрактном уровне:
Один стрим – это 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, чтобы при потере электроснабжения - компьютер включался сам при возвращении питания.

Самое главное - проверяйте комплектующие на длительную работоспособность и перегрев. Обязательно поменяйте термопрокладки, термопасту и обслужите остальные элементы систем охлаждения.

Если вы планируете оставлять сервер дома без присмотра - обязательно удостоверьтесь в его безопасности! Халатность может привести к пожару!
Это не шутки!

На данный момент актуальный сетап, который я использую – это домашний «сервер»:

В качестве камер я использую две 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.

Подготовка и настройка софтверной части

Для себя я определил три ключевых проблемы в этой области:

1. Периодические рандомные падения и вылеты OBS, 

2. Периодические перебои с энергоснабжением,

3. Временные перебои с интернет-подключением

Если последнее решилось в недавних обновлениях OBS, когда появился функционал автоматического переподключения при обрыве соединения, то первые две проблемы, увы, пришлось решать самому.

Мне было необходимо создать систему, в которой трансляция не прерывается, а в случае, если это происходит - восстанавливается всё самостоятельно, поскольку всё время, которое я проводил эксперименты над проектом, пришлось на карантин 2020 года - я, постоянно находясь дома, вынужденно и непрерывно мониторил состояние «DIY‑сервера», не отвалился ли интернет, не упала ли OBS, не вырубилось ли питание, и так по кругу. В случае, когда происходило падение OBS или вырубался сервер — приходилось ручками запускать OBS, выбирать нужные сцены, забивать настройки трансляций и запускать их снова и снова.

В какой-то момент мне это капитально надоело и встал вопрос, либо свернуть проект, либо всё-таки вспомнить, что сейчас 21-й век и всё, что приходится делать более 2-х раз - можно и нужно автоматизировать.

Решение, как оказалось позже, было довольно простым, хотя при беглом Google'инге я нашел не так уж и много готовых рецептов. Попробую поэтапно рассказать, как это реализовал я. 

Итак, задачи: Запуск двух инстансов (копий) OBS Studio со своими конфигурациями. Автоматизация запуска OBS при перезагрузке сервера. Автоматизация перезапуска OBS в случае краша или зависания приложения.

Добавление источника видео в OBS, сборка "сцены", создание профиля трансляции

Добавление источника

На базовом уровне для того, чтобы получить видео с IP камеры в OBS нужно сделать всего 2 действия:

1. Открыть OBS

2. Добавить в доке 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 сервер, чтобы принимать поток от камеры.
Об этом я писал в части статьи про архитектуру и причины отказа от ряда альтернативных решений задачи.

Сцены

Теперь подробнее поговорим о сборке сцены и о том что это такое.

Сцена - это набор материалов (картинки, видео, музыка, анимации). Всё, из чего состоит итоговая, финальная картинка, которую вы транслируете — это и есть сцена.
В приложении можно заранее собрать несколько «Сцен», как в театре, буквально, для того, чтобы производить глобальные изменения в транслируемой картинке нажатием одной кнопки. Но это тема для отдельной статьи.

Сама сцена состоит из «Источников», они же «Инпуты» или «Сурсы/Сорсы». Они расположены во второй вкладке нижней Док‑Панели.

Это сам контент, который мы послойно добавляем в нашу сцену и собираем финальную картинку. Здесь могут быть видео, фото, анимации, захват окна приложения, захват игры, трансляция получаемого по ссылке медиа‑контента, практически всё, что угодно. Эти самые источники можно свободно перемещать по холсту, и трансформировать. Не забывайте, что логика «Слоёв» здесь тоже работает, поэтому слой, который ниже — будет и визуально «под» теми слоями, которые выше.

Итак, вы добавили нужный источник видео-потока, а именно камеру, в свою сцену.
Сцена собрана. Теперь нужно её сохранить и на всякий случай экспортировать.

В верхней части окна нажимаем: «Scene Collection‑ Rename» и задаём сцене имя, например «CAM1SC» (Камера 1 Коллекция сцен).

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

Теперь о профилях трансляции.

В то время, как коллекция сцен включает в себя сцены, их «источники» и прочее, что связано именно с входящим контентом, всё, что касается настроек энкодера, настроек качества записи, разрешения выходного видеопотока, битрейта, частоты кадров и в том числе ключа потока, что для меня критично, записывается в «Профиль» (Profile).

Все эти параметры записываются в отдельный "Профиль". Их так же можно экспортировать в виде папки и сохранить в надежное место. Итого я создал профиль, который называется CAM1PROFILE.

По умолчанию все эти настройки хранятся по адресу ниже, но позже мы это изменим.
C:\Users\Username\AppData\Roaming\obs-studio.
В подпапке "basics" - профили и сцены
В самой папке есть глобальный файл global.ini, в котором содержатся настройки самого приложения. А в том числе и:

• Размер окна

• Положение док-панелей

• Настройки рендерера приложения (Direct3D 11 или Open GL) (Это тема для отдельной статьи, если эта будет одобрена к публикации и возникнет необходимость объяснить, что это и зачем это).

• Задержка и количество попыток переподключения в случае потери соединения с интернетом.

Кстати, здесь же в Advanced Settings нужно указать количество попыток переподключения к серверу, на который отправляется ваш видеопоток, а так же задержку переподключения. Это один из важных этапов автоматизации процесса. Не игнорируйте его.

По умолчанию OBS запускается с последней Сценой и Профилем, которые были использованы в последний раз.

Настройки кодирования видео-потока

Вставлять сюда полный гайд по особенностям настроек кодировщика видео-потока я не буду по той же причине, по которой не вставил сюда содержимое гайда по запуску трансляции ня Youtube. Он может устареть до публикации статьи.

Остановлюсь не нескольких важных деталях:

Ранее я упоминал о том, что перешел на GPU-кодирование видео, поэтому в качестве кодировщика выбираю, очевидно, NVENC H.264.
На данный момент есть альтернативные варианты GPU-энкода. Например кодировщик AV-1 в видеокартах INTEL. отличный вариант с точки зрения качества конечного видео.

Пресет качества P1 (Самое низкое качество, самая высокая скорость кодирования) я выбрал по двум причинам:
1. Экономия ресурсов
2. Отсутствие необходимости использовать более высококачественный пресет.
Источник видео - не самая хорошая IP камера и получаемый от нее поток очень мало теряет в качестве даже на самом низком пресете. Разумеется, если ресурсы позволяют - можете выбрать более высококачественный пресет.

Строка GPU отвечает за выбор видеокарты, которая будет использоваться для кодирования видео.

Важная оговорка: речь именно про кодирование видео. В диспетчере задач это будет отображено как VIDEO ENCODE! Если вы таким способом запускаете множество потоков кодирования — следите за уровнем загрузки кодировщика. В случае перегрузки — OBS выдаст предупреждение «Кодировщик перегружен».

Загрузка видеокарты в секции «3D» в диспетчере задач — это именно рендеринг сцены.
Если будет необходимо — раскрою эту тему в отдельной статье.

Параметры запуска

C Этим пунктом очень кратко, ибо говорить тут особо не о чем, но и не упомянуть невозможно: Список параметров, которые позволяют запускать OBS с заранее определенными «настройками». Начать эфир сразу после запуска, отключить уведомление о потерянных файлах, начать запись сразу после запуска и так далее.

Полный список этих параметров находится в Wiki по OBS
Ссылка: https://obsproject.com/wiki/Launch-Parameters
Теперь я вернусь на один логический шаг назад, к разделению потоков трансляции и использованию нескольких копий OBS одновременно.

Создание нескольких копий (инстансов) OBS одновременно

Чтобы создать несколько экземпляров, которые не будут зависеть друг от друга - ранее я использовал только параметр запуска  “--multi”, который по сути просто пропускает окно подтверждения при запуске второй и следующих копий OBS и делал копии установочных папок с OBS, а также пронумеровал EXE файлы как obs64(n).exe для каждого инстанса, где n является номером инстанса и его же уникальным id для отслеживания в системе.

Проблема заключалась в том, что часть важных параметров приложения находилась в общей папке WINDOWS C:\Users\Username\AppData\Roaming\obs-studio, в том числе подпапка с коллекцией сцен (это «что мы стримим»), папка профилей кодирования («куда и как мы стримим») и, самое главное, файл global.ini. Как я уже упоминал ранее - этот файл отвечает за глобальные настройки конфигурации приложения.

Сама OBS подтягивает последние настройки из последнего успешного запуска.

Запуск множества копий OBS при такой организации неизбежно вызывал разнообразные ошибки, т.к. разные инстансы с минимально, но отличными друг от друга настройками и конфигурациями ссылались на общий global.ini файл, и по своей определенной логике перезаписывали его при перезапусках, перезагрузках, крашах и так далее. В итоге это приводило к ошибкам при старте разных инстансов. То не те настройки подтянулись, то не тот конфиг, то не тот профиль, а иногда отключалась блокировка проверки наличия обновлений. В общем - система оказалась не рабочая.

Теперь я использую более практичный вариант – Portable Версию приложения.
Для этого нужно скачать zip архив с актуальной версией приложения OBS на GITHUB, или установить приложение в любую удобную папку. Для себя я сделал следующим образом:
В корне диска создал папку “OBS” внутри неё создал папку OBS_«№», где №- это номер инстанса (копии) приложения, внутри установочной папки приложения нужно создать файл: portable_mode.txt

После этого запустить приложение, и все дополнительные подпапки создадутся внутри этой директории.

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

В директории config\obs-studio\basic– будет две папки, одна со сценами, вторая с профилями кодирования. Об этой части я писал выше. Файл global.ini тоже будет внутри папки config.

ВАЖНО! Обязательно нумеруйте папки с инстансами OBS и exe файл этого инстанса соответственно! Нужда в нумерации exe файла не исчезла. Это самый простой способ идентификации отдельных инстансов в системе. Я называю папки OBS_номер_инстанса и obs64(номер_инстанса).exe.

В эту же папку вы можете установить все необходимые для вашего проекта плагины, которые будут использоваться. Все настройки плагинов будут ассоциированы только с тем инстансом OBS, в который они установлены. Файлы конфигурации этих плагинов так же будут внутри папки инстанса. Проверено для одного из самых полезных в моём случае плагинов -  Advanced Scene Switcher.

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

Для страховки можно сохранить «готовый портативный инстанс OBS» в облако, а также сохранить в облако отдельно «общую для всех инстансов» папку «Basic», в которой будет храниться полный набор сцен и профилей кодирования (разумеется пронумерованных соответственно их инстансам), чтобы простым дублированием Портативной версии OBS вы могли быстро развернуть нужное количество инстансов на вашем сервере за считанные минуты.

Далее вы создаете файл с расширением .bat, в котором прописываете адрес директории отдельных инстансов и их параметры запуска. Например:

Мы транслируем 12 разных уличных камер в 12 разных трансляций на Youtube.
У каждой камеры свой ip адрес, и к ним ведут разные ссылки на их поток, а это отдельная настройка источника контента в сцене (Media Source), соответственно в каждом инстансе будет своя сцена, со своим источником (Media Source) который забирает в инстанс свою камеру.
Так же напомню, что у каждой трансляции свой ключ потока, который записан в Profile – профиль кодирования. Я буду упоминать об этом, чтобы эта информация зафиксировалась, и вы помнили, где какой пул параметров записан.

Нам нужно, чтобы:
Инстанс OBS#1 был запущен из директории C:\OBS\OBS_1\bin\64bit с помощью файла obs64(1).exe, с профилем кодирования CAM1_Profile и сценой CAM1SC, так же нужно, чтобы трансляция запускалась сразу после запуска инстанса, и инстанс сворачивался в трэй (лоток), а не в панель задач, и так же должно быть пропущено окно подтверждения при запуске множества копий OBS Studio.

Чтобы реализовать этот функционал есть 2 варианта:  

• Прописать в ярлыке OBS нужные параметры.

• Создать ".BAT" файл с небольшим скриптом, который будет запускать OBS с нужными нам параметрами. Забегая вперед - этот вариант наиболее предпочтителен в нашем случае.

Создаём текстовый файл. Открываем любым редактором и пишем в нем следующий текст:

cd "C:\OBS\OBS_1\bin\64bit"
start obs64(1).exe --profile "CAM1PROFILE" --collection "CAM1SC" --startstreaming --multi --minimize-to-tray
exit

Упрощенные для понимания комментарии для тех, кто совсем не понимает, что делаем на этом этапе.

@Echo off - сделает невидимым выполнение всех следующих команд.
cd "C:\OBS\OBS_1\bin\64bit" - в кавычках ваш путь к "exe" файлу OBS
start obs64(1).exe - команда для запуска OBS.

ВАЖНО! В моем случае мне пришлось переименовать EXE файл для упрощения идентификации процесса в системе на последнем этапе. Если вы будете таким образом запускать только 1 копию OBS - можете убрать цифру в скобках и оставить просто obs64.exe. 
Если вы не будете запускать другую копию OBS — всё это не имеет смысла, т.к. OBS запускается с последними настройками, которые были до краша/вылета/падения. В Вашем случае достаточно просто перейти на следующий пункт гайда и сразу забросить в упомянутую в нем папку ярлык OBS.

Расшифровка остальных параметров запуска:

Теперь, сохраняем текстовый файл, называем его "OBS_Stream_Camera_1" и меняем ему расширение на ".bat". Когда вы кликните дважды на этот файл, то OBS запустится с именно с этими параметрами. 

Проделываете всю процедуру второй раз для второго комплекта настроек.

Во втором BAT файле указываете второй комплект сцена+профиль.

Для того, чтобы реализовать последний этап, заранее переименуйте в двух папках двух отдельных инстансов OBS exe-файлы как OBS64(1).exe и OBS64(2).exe. В каждом bat'нике ссылайтесь на свой exe'шник, находящийся в своей папке. 

Теперь у вас есть два .bat файла, которые обращаются каждый к своему exe файлу OBS внутри своей папки. Каждый для своего инстанса OBS. У каждого свой профиль с ключом потока и набор источников.

Автоматизация запуска OBS при перезагрузке сервера

Этот этап крайне простой и крайне короткий.

Нажимаем Win+R.
Откроется окно "Выполнить".

Пишем там команду: 

shell:common startup

Откроется папка внутри Windows с расположением:

С:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

В эту папку необходимо поместить оба BAT файла, которые были созданы на предыдущем шаге.

Теперь при запуске системы будет происходить выполнение этих BAT'ников, и следовательно - запуск двух инстансов OBS с заранее прописанной конфигурацией. Согласно содержимому BAT файлов - трансляция так же будет начинаться незамедлительно.
При необходимости - можно добавить задержку.

Автоматизация перезапуска OBS при вылете приложения

Для этого нам понадобится сделать, в сущности, всего лишь 2 действия:

1. Создать 2 Watchdog'а в виде BAT файлов, которые будут проверять выполняется ли условие: есть ли в системе работающий процесс с участием файлов obs64(1).exe и obs64(2).exe, для этого мы как раз и переименовали exe'шники ранее. Так, в системе будет отображаться два отдельных приложения с соответствующими названиями. OBS64(1).exe - для первого инстанса OBS, который кодирует 1-ю трансляцию, и OBS64(2).exe - для второго инстанса OBS, который кодирует 2-ю трансляцию. Простейший способ идентификации нужного инстанса в системе без необходимости вычленять process id и прочих сложностей.

2. Автоматизировать запуск BAT файлов Watchdog'и по расписанию через планировщик задач Windows.

Первый этап

Создаем текстовый файл со следующим текстом:

Set ProcessName=obs64(1).exe
TaskList /FI "ImageName EQ %ProcessName%" 2>nul|Find /I "%ProcessName%">nul||(
Start "" "С:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\OBS_Stream_Camera_1.bat"
)

Сохранитесь и измените расширение файла на ".bat".

Краткий комментарий:

Set ProcessName=obs64(1).exe - здесь указано имя процесса, который мы отслеживаем.
Start "" "С:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\OBS_Stream_Camera_1.bat" - здесь мы указываем какой BAT файл запускать в случае, если искомый процесс не обнаружен в системе.

Создайте второй bat файл, который будет мониторить второй exe'шник OBS и ссылаться на запуск второго bat'ника под второй инстанс трансляции.

Назовите bat'ники Watchdog_1 и Watchdog_2, например. Я обозвал их так для удобства.
Сохраните их в ту же папку с названием, например WATCHDOGS в папке для всего проекта OBS в корне диска.

Второй этап

Жмём «Win+R»

В поле ввода вбиваем:

taskschd.msc - Откроется окно планировщика Windows. 

Жмем «Создать задачу...»

Вводим имя, например Watchdog.

Описание - по вкусу. Можете оставить комментарий, чтобы не забыть.

Переключатель в положение "Выполнять только для пользователей вошедших в систему" и "Выполнить с наивысшими правами".

Переходим во вкладку "Триггеры". Жмем "Создать".

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

Переходим во вкладку "Действия". Жмем "Создать".

Здесь мы выбираем сначала Watchdog_1.bat, потом жмем "ОК", и добавляем второе действие, запуск Watchdog_2.bat.

Теперь переходим во вкладку "Параметры".

Выставляем такие параметры. Жмем «ОК».

Теперь раз в час будут запускаться два скрипта, которые проверяют, запущена ли OBS или нет. Если одна или обе копии OBS не запущены - то скрипты это увидят и запустят соответствующие bat'ники для запуска OBS с нужным набором Профиль+Сцены.

Могу вас поздравить, если вы всё сделали правильно - всё будет успешно работать. В моём случае всё сработало довольно просто и легко. 

Проверки и тесты показали, что сервер работает успешно, в случае обрывов электричества или вылетов OBS восстанавливается самостоятельно. 

Автоматизация отключения OBS в случае зависания процесса obs64.exe

В продолжение предыдущей части, я решил, что не перестраховался еще в одном проблемном месте. 

Это место - Глухое зависание процесса obs64.exe.

В ряде случаев, особенно при работе OBS в качестве энкодера в облаке, эта проблема может тихо и незаметно прекратить трансляцию и усложнить вам жизнь. Сам неоднократно сталкивался с этим, что вызывало "Баттхерт", особенно если происходили такие зависания несколько раз в день.

Дисклеймер: Несмотря на то, что проблема рандомных зависаний OBS существует, во время тестов мне стоило огромных трудов заставить OBS зависнуть. Живучая зараза, как оказалось.

Проблема:

OBS наглухо зависла, процесс в состоянии "Не отвечает". Трансляция, вероятнее всего, тоже не идет. Очевидное решение – принудительно завершить задачу, запустить трансляцию заново и ждать следующего повторения.

Решение:

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

1. Убеждаемся в том, название exe файла OBS позволяет его однозначно идентифицировать в системе, например так, как это сделал я: OBS64(1).exe и OBS64(2).exe.

2. Создаем WatchDog BAT-файл со скриптом, смысл которого таков:
   «Если приложение с именем OBS64(1).exe в статусе "Не отвечает" - убиваем процесс.»

3. Автоматизируем запуск этого BAT файла по расписанию через Планировщик Windows.

4. Не забываем подключить и автоматизировать запуск еще одного BAT-файла, который будет проверять, запущено ли приложение OBS64(1).exe, и если не запущено - будет стартовать его самостоятельно.

Первый этап

Создадим текстовый файл.
В нём пишем следующий текст:

@echo off
taskkill /im obs64(1).exe /FI "Status eq NOT RESPONDING" /f
exit

Кратко о содержимом:

@Echo off - аргумент, чтобы на экран не выводилась командная строка
taskkill - собственно то, что нам и требуется сделать, убить процесс.
/im - образ, приложение, которое мы ищем.
/FI - фильтр, которым мы проверяем условие. В нашем случае: Статус равно "Не отвечает".
/f - параметр Форсированного выхода из приложения, предотвращает все диалоговые окна при закрытии приложения, максимально быстрый и жесткий выход. Обязательно использовать его, чтобы скрипт не встал на диалоге "А вы действительно хотите выйти из приложения??"
exit - выход.

Сохраняем документ, переименовываем его. Я, например назвал файл: NotResponding_Watchdog.bat

Второй этап

Теперь переходим в предыдущую часть статьи, и полностью проходим Этап 2.

Вам просто нужно автоматизировать запуск этого BAT-файла по расписанию, раз в, скажем, 15 минут. Желательно выстроить последовательность в планировщике Windows так, чтобы Таск-Киллер запускался за 5 минут до того, как запускается WatchDog процесса. То есть:

Таск-Киллер убивает зависшую OBS, а через 5 минут второй скрипт, увидев, что OBS не запущена - запускает её согласно условиям из предыдущей статьи.
В целом – можно в этот же скрипт проинтегрировать шаг «Запуск нужного инстанса OBS, в случае если процесс был убит», но я уже не помню достоверно, почему я решил оставить более простой вариант.

Автоматизация переподключения OBS Studio к камере, в случае потери видеопотока

Проблема: 

Рандомные перезагрузки камер, отвали сети, глюки некоторых камер и просто их особенности вызывает периодическую потерю OBS’кой видеосигнала с камеры.
Это может выражаться в двух вариациях: черный экран или фриз последнего поступившего кадра.

Размышления:

В целом эта проблема связана с нюансами трансмиссии видео через UDP и TCP. Поскольку актуальная версия OBS поддерживает возможность настройки FFMpeg параметров источника видеосигнала – эту задачу, вроде как, по заверениям гуру, можно решить прописав корректные настройки FFMPEG декодера видеопотока в настройках Media Source.

К сожалению, в моем случае, уж не знаю до конца из-за особенностей ли IP камеры, которая ранее была установлена внутри банкомата и в целом является довольно странным девайсом, или же из-за моих кривых рук и полного непонимания принципа работы с параметрами FFMpeg – этот способ не сработал.

Решение:

В качестве решения задачи, по совету сообщества OBS- я применил плагин Advanced Scene Switcher. Ссылка на GitHub

Этот плагин дает обширные возможности для автоматизации и самое главное -решает мою задачу в 3 клика.

Задачи:

1. Установить плагин в папки каждого инстанса OBS

2. Настроить детектирование потери видеопотока с камеры

3. Задать действие, которое будет выполняться в случае потери видео

Постараюсь кратко пройти эти пункты.

1. Открываем окно плагина в OBS

   

2. Переходим во вкладку “MACRO”

   

3. Создаём макрос с удобным для понимания названием:

   

4. Создаем условие для макроса. Суть условия:
   Если Видео из Источника «Камера 1» Не изменяется

   

5. Создаем правило, которое будет выполняться при соблюдении условия:
   Суть правила такова, что в случае выполнения условия – настройки источника MEDIA SOURCE будут обновляться, что вызовет переподключение к потоку камеры. Возможно есть более правильный способ, но иные варианты в моём случае не сработали.
   

   

6. Выставляем время проверки условия максимальное, которое возможно для снижения нагрузки, и жмем START. Так же убеждаемся, что параметр On Startup of OBS стоит “Start the scene switcher if it was running”, чтобы он запускался автоматически в случае перезапуска OBS. После этого Автоматика будет делать всё за вас.

   

Теперь раз в N-миллисекунд будет проверяться условие из макроса. Я выставил 9999.
Если картинка на видео источнике застынет или будет показывать черный экран – настройки источника обновятся и поток с камеры перезапустится.
При желании можно добавить вывод уведомления об этом.

Финал

Это моя первая статья на Хабре, и несмотря на то, что IT специалистом я и не являюсь, я уверен, что эта статья найдёт свою аудиторию. Для меня было важно записать все этапы и шаги, которые я сделал, чтобы тем, кто прочтёт статью не пришлось долго и нудно собирать разрозненные клочки информации в сети по крупицам. Здесь собраны 3,5 года жизни моего Pet-project'a и я доволен результатом. Более того, я считаю, что этой информацией стоит поделиться с сообществом.

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

В целом – задача решена. Степень автоматизации процессов на сервере, транслирующем видео с камер наблюдения в сеть достаточна для моей задачи и моих целей. Теперь я надеюсь на расширение проекта и увеличение пула камер. Неравнодушные к проекту товарищи, друзья и сочувствующие помогли собрать немного донатов на покупку камер.
В дальнейшем, как я писал выше, буду пытаться купить RTX 3060 и расширить возможности.
На данный момент – полтора года эфира на Youtube. Трансляция, которая идет сейчас - запущена 12 января 2022 года, спустя несколько дней после несостоявшегося пожара, который я упоминал в статье.

Если у вас есть вопросы или уточнения – готов обсудить в комментариях.

Ссылка на проект

Ссылка на канал в ТГ, куда я пишу время от времени про приключения этого проекта:
https://t.me/nashservachokluchi (Не реклама, просто заметки, которые я писал в большей степени для себя в процессе работы, чтобы не забыть что-то важное).

Спасибо, что уделили время прочтению этого «научного труда» =)