SRT-трансляция через VPS: резервная связь для выездного мероприятия

Представьте площадку за городом: выступает спикер, камера снимает, кодировщик исправно отправляет поток. И вдруг на несколько секунд мобильная сеть «задумывается». Сигнал не пропал совсем, но пакеты идут то с опозданием, то пачками, то не идут вовсе. Зритель в этот момент видит либо замерший кадр, либо рассыпавшиеся квадраты, либо просто крутящееся колёсико. Всё, что можно сделать заранее, чтобы такой эпизод остался незамеченным или хотя бы пережил его без катастрофы, и составляет предмет этой статьи.

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

Путь одного кадра: из чего складывается время до зрителя

Начнём с того, что «задержка» в трансляции не одна. Между объективом и экраном зрителя стоит цепочка этапов, и каждый добавляет своё.

1. Захват и кодирование: камера отдаёт кадр, кодировщик собирает группу кадров и сжимает их. Часть времени уходит на накопление, и оно зависит от настроек кодека.
2. Транспорт от площадки до сервера: это та часть, где работает SRT и где вам важен параметр latency.
3. Обработка на VPS: приём, возможная запись, пересылка дальше.
4. Доставка от сервера к площадке-получателю: платформа трансляции, свои буферы и своя схема раздачи зрителям.
5. Буфер плеера у зрителя: его вы обычно не контролируете.

Параметр latency в SRT относится ко второму этапу. В руководстве OBS по SRT он задаётся прямо в адресе подключения и выражается в микросекундах (OBS: SRT). Это важная мелочь: если вы по привычке впишете «120», ожидая миллисекунды, получите совсем не то, что хотели. Сто двадцать миллисекунд записываются как 120000, две секунды как 2000000. Прежде чем ехать на площадку, стоит один раз проверить единицы на тестовом подключении.

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

Обмен секунд на устойчивость

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

Рассудим на условных числах, не претендующих на результат реального замера. Допустим, пакет идёт от площадки до VPS и обратно за 60 мс. Чтобы запросить повтор и получить его, нужен минимум один такой круг, а на практике желательно иметь запас на несколько попыток, потому что повторный пакет тоже может потеряться. Окно в 120 мс даёт ровно одну попытку без запаса, и любое заметное ухудшение превратит её в лотерею. Окно в 400 мс даёт несколько попыток подряд. Окно в 2 секунды переживёт уже заметные провалы, но и зритель увидит событие позже.

Теперь представим два вида «плохой сети». Первый: редкие одиночные потери пакетов на фоне нормального канала. Для них вполне достаточно скромного запаса, кратного RTT. Второй: короткие периоды, когда связь почти исчезает на секунду-две, например при переключении сотовой вышки или при перегрузке соты толпой на мероприятии. Здесь запас, измеряемый несколькими RTT, не поможет: нужно окно, сравнимое с самим провалом, а это уже секунды задержки.

Вот почему «поставить максимум» не работает как универсальный ответ. Большое окно лечит второй тип проблем, но вы платите за него всегда, даже когда сеть идеальна. Для конференции со слайдами и вопросами из зала лишние две секунды могут быть безобидны. Для прямого эфира с интерактивом, где ведущий отвечает на сообщения чата, они превращаются в неловкие паузы. А для трансляции, где картинка нужна на экране на самой площадке, они могут быть и вовсе недопустимы, но это уже вопрос к схеме показа, а не к SRT.

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

Теперь разберём ситуацию, ради которой статья затевалась: у вас два мобильных канала (или мобильный и проводной) и в какой-то момент рабочий начинает отказывать. Важно сразу не принять желаемое за действительное. Руководство OBS по SRT описывает схему подключения и параметры, но автоматического переключения между двумя интернет-провайдерами не обещает (OBS: SRT). То есть за переключение отвечает то, что стоит у вас на площадке: роутер с несколькими SIM, агрегатор каналов, ручная перекоммутация. Сам по себе SRT и VPS этого не делают.

Что при этом происходит с потоком? Попробуем проследить эпизод на условной временной диаграмме. Числа здесь придуманы для объяснения и не являются результатом испытания.

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

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

Режимы подключения и роль VPS

Теперь о том, зачем здесь вообще VPS. SRT поддерживает режимы caller, listener и rendezvous (OBS: SRT). Практический смысл различий такой: тому, кто слушает, нужен доступный снаружи адрес и порт. Мобильный канал на площадке обычно скрыт за оператором с трансляцией адресов, и принимать входящие подключения на нём неудобно. Поэтому логично, что слушает сервер с постоянным публичным адресом, а кодировщик на площадке подключается к нему как caller. Именно эту роль и берёт на себя VPS: это стабильная точка, куда стекается поток независимо от того, какой SIM-картой он сегодня шёл.

В OBS схема выглядит так: выбирается Custom service, в поле сервера вписывается SRT URL, а поле stream key остаётся пустым (OBS: SRT). Параметр latency указывается внутри этого адреса. Конкретные значения подбираются репетицией, а не берутся из статьи.

Что делать дальше с принятым потоком? Здесь на сцену выходит MediaMTX, который в своей документации описывает пересылку. Опция forward позволяет направлять входящий поток на другие серверы, включая RTMP и SRT, а для перекодирования, фильтрации или смены протокола, которых сам forward не делает, применяется FFmpeg (MediaMTX: пересылка потоков). Это значит, что VPS получает устойчивый вход с площадки, а на площадку-получатель (например, платформу вещания) отдаёт уже по её правилам. Благодаря этому две части маршрута перестают зависеть друг от друга: нестабильный мобильный участок заканчивается на вашем сервере, а дальше идёт уже поток по нормальному каналу датацентра.

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

Буфер не заменяет второй источник картинки

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

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

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

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

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

Запись на сервере: страховка от другого рода неприятностей

Даже при идеальной трансляции у организаторов часто возникает потребность сохранить материал целиком: для нарезки, для повторной публикации, для архива. MediaMTX умеет записывать принятый поток: параметр record включает запись, recordSegmentDuration определяет длительность сегментов, recordDeleteAfter задаёт возраст автоматического удаления, а значение 0s это удаление отключает (MediaMTX: запись). Последний нюанс стоит запомнить особенно: если вам нужно хранить записи, а не только временно, явно проверьте, что автоматическая чистка не включена в том виде, в котором вы её не ожидаете.

Теперь про границы надёжности записи. Документация различает небольшие части и завершённые сегменты, и при сбое последняя часть может быть потеряна. Кроме того, запись на локальный диск и загрузка готовых файлов в удалённое хранилище это отдельные действия (MediaMTX: запись). Практический вывод: файл на диске VPS ещё не архив. Если сервер будет потерян вместе с диском, потеряются и записи, а наличие нескольких дисков или RAID вопрос копии не закрывает; об этой путанице подробно говорит материал «Миф: RAID — это уже резервная копия». Значит, после мероприятия завершённые сегменты стоит переносить на независимое хранилище, а длительность сегмента выбирать с мыслью о том, сколько минут вы готовы потерять в худшем случае.

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

Какие ресурсы нужны серверу

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

Тарифы VPS MAATRIX предлагают разные стартовые точки: Ba с 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe, Uab с 2 vCPU, 4 ГБ и 80 ГБ, Heka с 4 vCPU, 8 ГБ и 160 ГБ, а также более крупные Maat и Djed. Эти цифры отправная точка для теста, но не обещание ёмкости. Разумный путь такой: для одного потока с пересылкой без перекодирования начать с небольшого тарифа и посмотреть нагрузку на репетиции; если планируется перекодирование или несколько камер, брать запас по процессору и смотреть, как ведёт себя система под реальной нагрузкой. Доступны локации UK, US, RU и FR, а оплата возможна картой РФ и через СБП, с автоматическим созданием VPS в течение пары минут после оплаты. Выбор локации стоит делать по RTT от площадки: чем короче круг, тем меньше окна нужно на одну попытку повтора. Эти значения проверяются замером с самой площадки, а не по карте.

Репетиция, которая что-то доказывает

Теперь соберём всё в план репетиции. Её цель не в том, чтобы убедиться, что «в целом работает», а в том, чтобы измерить конкретные величины и увидеть конкретное поведение при отказе.

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

1. Измерьте базовую картину. Запустите поток с умеренным окном и понаблюдайте минут двадцать-тридцать, записывая RTT и заметные дефекты картинки. Это ваш уровень «нормальной» сети.
2. Подберите окно по базе. Если RTT 60 мс, а дефектов нет, возможно, хватит нескольких RTT. Добавляйте запас, пока редкие потери не перестанут проявляться, и не больше.
3. Устройте контролируемый отказ. Отключите рабочий канал физически: выньте SIM или отключите питание модема. Запишите по секундомеру, сколько времени проходит от отключения до возвращения картинки, и как выглядит эпизод на приёмнике.
4. Повторите с разными окнами. Сравните, при каком окне эпизод становится незаметным, при каком заметным, а при каком сессия рвётся и требует переподключения.
5. Проверьте восстановление после обрыва. Нужно ли оператору что-то нажимать? Возобновляется ли пересылка на платформу сама? Что происходит с записью: закрылся ли сегмент корректно?
6. Проверьте худший сценарий. Что видит зритель, если отказ длится минуту? Есть ли заставка, есть ли человек, который знает, что делать?

По итогам у вас будет не абстрактное «задержка 2 секунды», а таблица вида «такая длительность провала при таком окне выглядит так». Именно она и определяет решение, а не общие рекомендации.

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

Выбор задержки под сценарий, а не под страх

Остаётся последний шаг: превратить измерения в решение. Хороший вопрос здесь не «какая задержка надёжнее», а «что допустимо показать зрителю в худшем случае и сколько секунд отставания я готов заплатить за это».

Рассмотрим три условных сценария.

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

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

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

Во всех трёх случаях логика одна. Сначала определите, какое поведение эфира допустимо в плохой момент: незаметная пауза, видимый дефект на секунду, заставка или полная остановка. Потом посмотрите на измеренные провалы и найдите окно, при котором результат укладывается в допустимое. Если ни одно окно не подходит, значит, проблема не в настройке SRT, а в схеме связи или источнике, и тратить время на подкручивание latency бессмысленно. Тогда нужно либо усиливать канал, либо менять ожидания, либо добавлять резерв источника.

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