SRT проиграл RTMP на длинном международном плече

SRT-поток от удалённого производства рассыпался и замирал. Международное плечо было длинным, RTT держался около 183 мс.

Сначала я выставил SRT latency в 1000 мс. Потом искал ошибку в настройках сервера. Оба диагноза оказались неверными: запас по задержке не лечит маршрут, на котором транзитные сети фильтруют или ухудшают UDP.

Протокол с лучшей репутацией бесполезен, если транспортная сеть не даёт ему работать. Выбирать нужно под реальный маршрут.

SRT создан для работы с потерями, но у него есть базовое условие — UDP должен проходить. На этом маршруте условие не выполнялось.

RTMP поверх TCP пошёл по тому же пути чисто. На контрольной точке он держался уже 22+ минуты без зависаний и повреждений, затем выдержал боевую работу.

Резерв, который не понадобился

Заодно я поднял на существующем VDS в Амстердаме Mist-релей: SRT на входе, RTMP на выходе. На сборку и проверку портов ушло около часа.

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

Три правила после проверки:

→ соответствие транспорту важнее моды на протокол → зрительская сторона всё это время была вне риска: HLS работает поверх TCP → во время события транспорт не переключают; решение принимают до первого свистка