OBS и два места публикации: ретрансляция через свой сервер

Начнём с арифметики, потому что именно она чаще всего решает, нужен ли вам сервер посередине. Допустим, вы стримите с домашнего компьютера и выбрали для эфира видео около 6 Мбит/с, а звук добавляет ещё примерно 0,16 Мбит/с. Округлим до 6,2 Мбит/с. Это условный пример, а не измерение чьего-то канала, но он хорошо показывает порядок величин.

Если отправлять эфир на две площадки напрямую, OBS нужно запустить две независимые отправки, и исходящий трафик с рабочего места удвоится: около 12,4 Мбит/с. Если канал у вас заявлен как 20 Мбит/с на отдачу, на бумаге запас есть. Но на практике исходящий канал делят с вами видеозвонок в соседней комнате, облачная синхронизация, обновления и сама сеть провайдера, у которой скорость в вечерние часы не равна цифре из тарифа. Удвоение потока нужно не только каналу: каждая отдельная отправка требует своего кодирования, если вы настраиваете их с разными параметрами, и нагрузка на процессор растёт.

При ретрансляции схема другая. Из OBS уходит один поток, те же 6,2 Мбит/с, на ваш VPS. А дальше сервер, у которого исходящий канал не связан с вашей домашней квартирой, раздаёт копии на обе площадки. Для автора это означает, что нагрузка на домашний канал не зависит от числа получателей. Добавите третье место публикации — домашний трафик не изменится.

Посмотрим на запас внимательнее, на том же условном примере. Канал в 20 Мбит/с при двух прямых отправках по 6,2 Мбит/с оставляет около 7,6 Мбит/с на всё остальное: 20 − 12,4. При одном потоке на VPS остаётся около 13,8 Мбит/с: 20 − 6,2. Разница в 6,2 Мбит/с равна размеру самого эфира, и именно она уходит на вторую копию. Но важнее не среднее значение, а пики. Видеокодер выдаёт битрейт неравномерно: сцена с быстрым движением даёт всплески, и при двух отправках каждый всплеск удваивается. Если в этот момент соседняя синхронизация файлов займёт часть канала, пострадают сразу обе площадки.

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

Для сравнения возьмём три площадки. Прямая схема даёт уже 18,6 Мбит/с исходящего трафика (3 × 6,2), то есть почти весь канал в 20 Мбит/с. Схема с сервером по-прежнему отправляет из дома 6,2 Мбит/с, а три копии создаёт VPS. Это та самая точка, где напрямую ещё можно, но запаса уже нет.

Что на самом деле происходит с потоком на сервере

Представьте сервер как вокзальную стрелку. Поезд приходит один, а путей дальше несколько. Программа-ретранслятор принимает входящую публикацию и для каждой цели открывает собственное исходящее соединение. В документации MediaMTX эта возможность называется forward: она направляет входящий поток на другие серверы, включая RTMP и SRT (MediaMTX: пересылка потоков). Для перекодирования, фильтрации или смены протокола, как там же сказано, применяется FFmpeg.

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

Ещё одно следствие: на участке от OBS до сервера и на участках от сервера до площадок можно использовать разные протоколы. Например, до своего VPS удобно ехать по SRT, а дальше отдавать на площадки так, как каждая из них принимает. В руководстве OBS описано, что SRT поддерживает режимы caller, listener и rendezvous; в приведённой там схеме используется Custom service с SRT URL, а отдельное поле stream key остаётся пустым (OBS: SRT). Параметр latency в URL из этого руководства задаётся в микросекундах, так что при переносе значений из других инструкций легко ошибиться на три порядка.

Какая схема когда выгоднее

Таблица честно показывает и обратную сторону. Ретрансляция добавляет звено, а любое новое звено может сломаться. Если у вас одна площадка плюс запасная «на всякий случай», канал свободный, а эфиры редкие, две прямые отправки проще и надёжнее: вы не обслуживаете сервер. Сервер оправдан, когда домашний канал тесный, когда площадок больше двух или когда хочется управлять каждой целью независимо от компьютера с OBS.

Что должно быть независимым, а что общим

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

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

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

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

Второй случай: сбой на входе, между OBS и сервером. Здесь независимость заканчивается, потому что источник один. Если домашний интернет оборвался, обе площадки остались без картинки одновременно. Руководство OBS по SRT, к слову, не обещает автоматического переключения между двумя интернет-провайдерами, так что резервный канал придётся организовывать отдельно и отдельно же проверять.

Третий случай самый коварный: сервер работает, вход принят, но одна из целей молча отвергает данные. Здесь мы подходим к одному из главных различий, которое стоит запомнить.

Принятый вход — не доказательство эфира

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

Поэтому мысленно разделите три уровня:

• вход на сервер: OBS подключился, битрейт идёт;
• выход на цель: сервер установил соединение с площадкой и отправляет данные;
• эфир на площадке: трансляция действительно отображается в кабинете и открывается как у зрителя.

Первые два уровня можно наблюдать на своей стороне, третий — только на самой площадке. Ни один из них не заменяет другие. Если площадка принимает поток, но кабинет показывает «нет сигнала» или «проблемы с видео», значит, поток дошёл, но не прошёл проверку, часто из-за параметров кодека или частоты ключевых кадров.

Перепаковка и перекодирование: где проходит граница

Когда говорят «сервер раздаёт поток», легко представить, что он что-то делает с видео. На самом деле в простейшем случае он ничего с видео не делает: берёт уже закодированные пакеты и переупаковывает их в другой транспортный формат. Это дёшево по процессору, потому что сжатие и распаковка не происходят. Пересылка одного и того же видео на две цели таким способом почти не нагружает машину; основной расход — сетевой.

Совсем другое дело — перекодирование. Если одной площадке нужен меньший битрейт, другой требуется иной кодек или вы хотите добавить фильтр, видео придётся распаковать и сжать заново. Документация MediaMTX для таких задач предлагает использовать FFmpeg или GStreamer вместе с самим сервером (MediaMTX: перекодирование). Там же подчёркнуто важное: смена транспортного протокола сама по себе не делает видеокодек совместимым с браузером. Сменить «обёртку» значит только сменить обёртку.

Разницу удобно увидеть на примере двух площадок с разными требованиями. Допустим, площадка А принимает ваши 6 Мбит/с как есть, а площадке Б вы хотите отдавать только около 3 Мбит/с, например потому, что её зрители смотрят в основном с мобильных устройств. Для А хватит перепаковки: пакеты идут сквозным путём, процессор почти свободен. Для Б видео нужно распаковать и сжать заново с новым битрейтом, и это работа кодировщика на сервере, причём непрерывная, пока идёт эфир. Суммарный исходящий трафик сервера при этом составит около 9,2 Мбит/с (6,2 для А и примерно 3 для Б, звук не считаем отдельно), но главная цена здесь не сеть, а вычисления.

Второе следствие: перекодированная ветка добавляет задержку. Кодеру нужно накопить кадры, прежде чем выдать сжатый результат, поэтому зрители Б будут видеть картинку чуть позже зрителей А. Если у вас интерактивный эфир с чатом, где ведущий отвечает на сообщения, эту разницу стоит измерить на тестовом просмотре и решить, допустима ли она. А если вы только меняете протокол, например принимаете SRT и отдаёте RTMP, видеокодек остаётся прежним, и прежние требования площадки к нему остаются в силе. Как отмечено в документации MediaMTX, одна смена протокола совместимость кодека не создаёт.

Практический смысл различия вот в чём. Пока обе площадки устраивает один и тот же видеопоток, вы платите сетью, а не процессором. Как только вам нужны разные версии, вы начинаете платить вычислениями, и ресурсы сервера становятся главным ограничением. Именно тут выбор тарифа VPS перестаёт быть формальностью.

Как ресурсы связаны с режимом

В линейке VPS MAATRIX есть тарифы от Ba с 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe до Djed с 16 vCPU и 32 ГБ. Эти цифры — отправная точка для вашего собственного теста, а не обещание, что такой-то тариф вытянет столько-то потоков. Логика выбора простая:

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

Расположение сервера тоже влияет: у площадок есть собственные точки приёма, а задержка от вашего VPS до них складывается с задержкой от вас до VPS. В публичном предложении MAATRIX перечислены локации UK, US, RU и FR; выбирайте ближайшую к вам и к точкам приёма площадок, а сравнивайте по тестовому эфиру, а не по карте.

Как наблюдать за каждым выходом отдельно

Раз «входящий поток идёт» ничего не доказывает про площадки, наблюдение надо строить по выходам. Рабочая схема из трёх слоёв выглядит так.

1. Состояние на сервере. Для каждой цели смотрите, установлено ли исходящее соединение и не переподключается ли оно постоянно. Частые переподключения к одной цели при спокойной второй — признак проблемы именно с этой площадкой: ключом, адресом или лимитом.
2. Кабинет площадки. Откройте панель управления трансляцией на каждой площадке. Многие показывают состояние входящего сигнала и предупреждения о параметрах видео. Это единственный источник правды о том, принят ли сигнал с их стороны.
3. Глаза зрителя. Откройте публичную страницу эфира на втором устройстве или в окне без вашей авторизации. Только так видно, что картинка и звук действительно доходят и что страница доступна.

Отдельно проверьте звук. Распространённая ситуация: видео есть, а дорожка звука на одной из площадок отсутствует или рассинхронизирована, потому что что-то на пути обработало её иначе. На входе сервера этого не видно.

Чтобы наблюдение не превращалось в ручное разглядывание шести окон, заведите короткую таблицу состояния для каждого эфира. По строке на цель, три столбца по числу уровней: вход на сервер, выход на цель, эфир у зрителя. Заполняйте её в трёх точках: за несколько минут до начала, через пять минут после старта и перед концом. Расхождение между столбцами и есть диагностика. Если у цели зелёные вход и выход, но у зрителя пусто, ищите причину на стороне площадки: параметры видео, статус трансляции, ошибку в настройках кабинета. Если выход красный при зелёном входе, проблема в соединении сервера с этой площадкой, ключе или адресе приёма.

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

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

Практический разбор: что идёт не так и как это понять

Разберём три ситуации на условном примере с двумя площадками, А и Б.

Картинка есть на Б, на А нет, вход на сервер в порядке. Смотрим исходящее соединение к А. Если оно устанавливается и тут же рвётся, проверяем адрес приёма в кабинете А и актуальность секрета: ключ мог смениться после предыдущего эфира. Если соединение держится, а кабинет А ругается на параметры, дело в видео: частота ключевых кадров, кодек, битрейт. Тогда либо меняем настройки в OBS для всех, либо для А готовим отдельную перекодированную ветку.

На обеих площадках картинка дёргается. Причина, скорее всего, выше по течению: нагрузка на домашний канал или процессор рабочего компьютера, либо нестабильная связь с VPS. Здесь помогает параметр задержки SRT: большая буферизация лучше переносит потери пакетов ценой большей задержки. Не забывайте, что в руководстве OBS значение latency задаётся в микросекундах.

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

Что вынести с рабочего места

Теперь можно ответить на исходный вопрос: когда ретрансляция через VPS полезнее двух прямых отправок. Она выигрывает, когда ваш исходящий канал тесен или нестабилен, когда площадок может стать больше, а также когда вы хотите, чтобы сбой одной цели не затрагивал остальные и чтобы за каждой можно было следить отдельно. Она проигрывает по простоте: вы получаете ещё одну систему, которую надо настроить, обновлять и держать в голове.

Полезно разделить работу на то, что лучше держать дома, и то, что лучше отдать серверу. Дома остаётся то, что связано с вами лично: сцена, камеры, микрофон и единственное кодирование видео. Серверу отдаём размножение: умножение потока на число площадок, независимые переподключения, наблюдение за каждым выходом. Если позже понадобятся разные версии видео для разных мест, перекодирование тоже можно вынести на сервер, но уже с осознанным выбором тарифа по результатам замера.

Сервер для такой задачи удобно арендовать как обычный VPS: у MAATRIX это NVMe-диски, процессоры AMD EPYC и root-доступ, а создание машины происходит автоматически после оплаты. Начните с малого тарифа, проведите тестовый эфир, посмотрите на загрузку процессора и трафик — и только потом решайте, достаточно ли выбранных ресурсов. Если вам интересна сходная логика для другой задачи, где публикация должна уходить в своё место в срок, взгляните на разбор о собственной площадке для раскрытия информации.

Итоговый выбор простой: держите дома то, что нельзя вынести, и выносите на сервер то, что растёт вместе с числом площадок. Один исходящий поток из квартиры — это не просто экономия мегабит, а граница, за которой рост аудитории и числа мест публикации перестаёт зависеть от вашего домашнего интернета.