RIST: вещательный стандарт-альтернатива

Последняя проверка: 2026-05-21 по VSF Technical Recommendation TR-06-1:2018 (Simple Profile), TR-06-2:2020 с обновлением июнь 2024 (Main Profile), TR-06-3:2021 с обновлением 2023 (Advanced Profile), TR-06-4 Part 3 (RIST Relay, 2023), IETF RFC 4585 (RTCP feedback для NACK), IETF RFC 8086 (GRE-in-UDP), SMPTE ST 2022-1/-2/-7 и эталонной реализации libRIST на VideoLAN.

TL;DR

Reliable Internet Stream Transport, сокращённо RIST, – это открытый мульти-вендорный протокол contribution, который профессиональная вещательная индустрия выбирает, когда контракт или процесс требует формально опубликованную спецификацию, а не реализацию от одного вендора, превратившуюся в де-факто стандарт. RIST поставляется как три накладывающихся профиля (Simple, Main, Advanced), опубликованных Video Services Forum под номерами TR-06-1, TR-06-2 и TR-06-3, плюс семейство дополнительных спецификаций TR-06-4; все они бесплатно скачиваются и опираются на RFC IETF. Протокол работает поверх UDP и Real-time Transport Protocol, восстанавливает потерянные пакеты при помощи NACK-based ARQ, агрегирует несколько каналов сети для пропускной способности или резервирования, и (в профилях Main и Advanced) шифрует и туннелирует поток через DTLS поверх GRE-in-UDP. В 2026 году вы выбираете RIST вместо SRT, когда нужно прогонять несжатый SMPTE ST 2110 через открытый интернет, когда тендерные документы требуют опубликованную открытую спецификацию или когда совместимость двух вендоров важнее размера экосистемы вокруг протокола.

Зачем эта статья

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

Статья – канонический справочник Блока 3 по RIST: что именно содержат три профиля, как работает уровень надёжности на NACK, почему broadcast-инженерам нужна передача SMPTE ST 2110 через открытый интернет, чем link bonding в RIST отличается от SRTLA, и какие три вопроса задать перед выбором RIST или SRT для новой линии. К концу вы сможете защитить решение «мы берём RIST» в тендерном комитете и не наступить на самые частые грабли при настройке.

Что такое RIST – на одной странице

Reliable Internet Stream Transport, сокращённо RIST, – это протокол прикладного уровня, который работает поверх UDP и Real-time Transport Protocol (RTP) и даёт приложению четыре свойства, которых ни у UDP, ни у RTP по отдельности нет: надёжную доставку, шифрование (в профилях Main и Advanced), агрегацию нескольких каналов и настраиваемую верхнюю границу end-to-end задержки. Video Services Forum, сокращённо VSF, в 2017 году сформировал RIST Activity Group, чтобы закрыть пробел в открытых спецификациях, который SRT и проприетарный продукт Zixi на тот момент закрывали одно-вендорными реализациями. VSF опубликовал первый профиль, TR-06-1 (Simple), в октябре 2018; второй, TR-06-2 (Main), – в марте 2020; третий, TR-06-3 (Advanced), – в 2021. Каждый профиль – строгое надмножество предыдущего: приёмник Main декодирует отправителя Simple, приёмник Advanced – любого. Спецификации бесплатно скачиваются с сайта VSF. Никаких членских взносов, никаких лицензионных платежей, никаких роялти.

Механически RIST работает поверх UDP – обычно на порту, который выбирает оператор; распространённое соглашение – порт 1968 для Simple Profile и порт 4755 (выделенный IANA для DTLS-over-GRE-in-UDP) для Main Profile. Сессия начинается с потока RTP-пакетов с порядковыми номерами в одну сторону и обратного канала RTCP – в другую. Когда приёмник замечает пропущенный номер последовательности, он отправляет negative acknowledgement (NAK) через RTCP, прося отправителя повторить пропущенный пакет. Если ретрансляция пришла в пределах согласованного окна задержки, приёмник вставляет пакет на нужное место и отдаёт собранный поток приложению; если опоздала – фиксирует дыру и идёт дальше.

Формат на проводе – тот же RTP, который используют WebRTC, VoIP и IPTV multicast: это сознательный выбор VSF ради максимальной совместимости с существующим вещательным железом. Формат NAK – это generic NACK по RFC 4585 (битовая маска на 17 подряд идущих номеров) плюс APP-RTCP-пакет, определённый в RIST, для Range NACK (одно сообщение, запрашивающее произвольно длинный диапазон). Потерянные пакеты ретранслируются по тикам таймера RTCP, а не на каждое отдельное событие потери, так что путь с 5 % потерь восстанавливается одной пачкой ретрансляций, а не 50 индивидуальными round-trip-ами. Это вся архитектура в 200 словах.

Нажмите, чтобы увеличить

Краткая история RIST

История важна, потому что объясняет, под что именно оптимизирован RIST. Примерно в 2016 году в профессиональном broadcast сошлись три проблемы. Первая: проприетарные протоколы (Zixi, VideoFlow, ActionStreamer, QVidium, DVEO Dozer) решили задачу надёжного транспорта через открытый интернет, но каждая реализация была чёрным ящиком, каждая лицензия – платной, и любые два вендора требовали отдельного интеграционного проекта, чтобы заговорить друг с другом. Вторая: Haivision открыл исходники SRT в 2017 году и собрал SRT Alliance – это было полезно, но SRT всё равно оставался эталонной реализацией одного вендора с устаревшим IETF-драфтом. Третья: broadcast-инженеры, пишущие тендеры в Европе и Латинской Америке, не могли указать в документации номер репозитория на GitHub – им нужен был номер опубликованной спецификации.

VSF – некоммерческий орган стандартизации, основанный в 1997 году для нормирования транспорта видео-по-IP – в 2017 году собрал RIST Activity Group, чтобы решить все три проблемы сразу. В группу вошли производители broadcast-оборудования (Cobalt Digital, Net Insight, Nevion, Zixi, VideoFlow, DVEO, Sencore, Cyanview, Aviwest, EVS), интернет-платформы (Microsoft Azure, AWS Elemental) и ветераны органов стандартизации. Техническую архитектуру решили быстро: RTP поверх UDP для совместимости с существующим железом, RTCP NACK для ARQ – чтобы переиспользовать RFC 4585, и публикация по профилям – чтобы вендоры могли наращивать совместимость инкрементально, а не ждать готовой полной спецификации годами.

Simple Profile, TR-06-1, был опубликован в октябре 2018 года. Он определил базовую точку совместимости: пакетизация RTP, ARQ на NACK, бондинг по SMPTE 2022-7. Main Profile, TR-06-2, вышел в марте 2020 – добавил GRE-in-UDP туннелирование по RFC 8086, шифрование DTLS 1.2, аутентификацию по PSK, мультиплекс множества потоков в одном туннеле, подавление NULL-PID и обход NAT. Main Profile был обновлён в июне 2024 года добавлением универсальных механизмов аутентификации (сертификаты с открытым ключом и TLS-SRP). Advanced Profile, TR-06-3, вышел в 2021 – расширил концепцию туннеля до передачи произвольных IP-поток включая SMPTE ST 2110, SMPTE ST 2022-6 и сырой MPEG-TS поверх UDP. Дополнительные спецификации TR-06-4 вышли в 2023–2024 годах и добавили RIST Relay (SIP-подобный прокси, через который RIST-эндпоинты встречаются за межсетевыми экранами, не открывая входящих портов).

Эталонная реализация, libRIST, лежит на сайте VideoLAN под лицензией BSD-2-Clause. Это та самая C-библиотека, которую используют VLC 4, FFmpeg, GStreamer, OBS Studio (через плагин), Upipe, TSDuck и Wireshark, чтобы говорить на RIST. Общая база реализации – причина того, что RIST plug-fests на IBC и NAB стабильно показывают рабочую совместимость трёх-четырёх вендоров одновременно: каждый вендор линкует одну библиотеку под своим UI.

Удобный способ удерживать это в голове: RIST начинался как проект органа стандартизации – сначала спецификация, потом реализации против неё – и порядок ровно противоположен тому, как делался SRT. Документация RIST полностью живёт в опубликованных документах TR-06; libRIST – добросовестная имплементация спецификаций, а не источник истины. Именно из-за этого порядка RIST выбирают броадкастеры с формальной процедурой закупок.

Как RIST восстанавливает потерянные пакеты

Механизм надёжности тот же, что у SRT – selective retransmission в окне задержки – но формат проводов и формат сообщения обратной связи отличаются. Понимание того, как это работает, – разница между правильной настройкой RIST и сгоревшей линией contribution в реальном эфире.

Отправитель пакетирует медиапоток (обычно multi-programme MPEG-TS, иногда SMPTE ST 2022-6 SDI-over-IP) в RTP-пакеты, присваивает каждому 16-битный номер последовательности и отправляет с исходной скоростью через UDP. Приёмник читает UDP-датаграммы, извлекает RTP-payload, проверяет номер последовательности и пишет содержимое в буфер переупорядочивания, размер которого равен настроенному бюджету задержки. Буфер переупорядочивания и задаёт верхнюю границу задержки RIST: всё, что приходит позже бюджета, отбрасывается.

Когда приёмник видит пропуск в номерах последовательности – пакет 46 пришёл, потом 48, а 47 отсутствует – он не паникует сразу. RTCP feedback отправляется по таймеру, а не на каждое событие потери, потому что отправка одного NAK на каждый потерянный пакет залила бы обратный канал на линии с большими потерями и потратила бы round-trip на каждый отдельный пакет. Вместо этого приёмник копит до 17 подряд идущих пропущенных номеров, упаковывает их в одно Generic NACK сообщение (RFC 4585 §6.2.1) и отправляет на следующем тике RTCP. Если пропуск больше 17 пакетов – например, кратковременный обрыв канала уронил 200 пакетов – приёмник использует расширение Range NACK из RIST (APP-RTCP-пакет, определённый в TR-06-1 §6.4), чтобы запросить весь диапазон одним сообщением.

Отправитель получает NAK, ищет запрошенные номера в своём буфере ретрансляций (обычно вдвое больше согласованного бюджета задержки) и шлёт каждый запрошенный пакет как новую RTP-датаграмму. Ретрансляции несут тот же номер последовательности, что и оригиналы – это позволяет приёмнику вставлять их обратно в буфер переупорядочивания на нужное место. Если ретрансляция пришла в окне задержки, приёмник пишет её в буфер и приложение пропуска не видит. Если опоздала – приёмник фиксирует дыру, декодер делает error concealment (или дропает кадр), и остальной поток течёт дальше.

Два проектных решения тут важны. Первое: RIST не отправляет положительных подтверждений. SRT использует и ACK, и NAK; RIST – только NAK. Компромисс: NAK-only экономит полосу обратного канала (никакого ACK-трафика на каждый пакет) ценой того, что отправитель не знает, жив ли приёмник, пока приёмник явно не пришлёт RTCP receiver report по стандартному 5-секундному интервалу. На практике это нормально для медиатранспорта – приложение замечает пропавший поток в течение секунд в обоих случаях – но именно это архитектурная причина, по которой SRT и RIST не могут делить формат на проводе. Второе: RIST наследует поле временной метки из RTP и использует его для компенсации джиттера независимо от переупорядочивания по номерам. Playout-буфер приёмника расщеплён с буфером ретрансляций: jitter smoothing работает на временных метках, переупорядочивание – на номерах, а пропущенный дедлайн ретрансляции выкидывает пакет из обоих конвейеров.

Арифметика, вслух, с реалистичными числами. Допустим, у контрибуции 80 мс round-trip и 2 % средних потерь пакетов. Рекомендуемая настройка задержки – не меньше 4× RTT, то же правило большого пальца, что у комьюнити SRT, потому что худший сценарий восстановления выглядит так: приёмник ждёт время пары пакетов, чтобы убедиться в потере, отправляет NAK на следующем тике RTCP (до одного интервала), NAK летит половину RTT до отправителя, отправитель ретранслирует, ретрансляция летит половину RTT обратно. С 80 мс RTT безопасная настройка задержки – 320–400 мс; промышленные деплои часто работают на 500 мс, чтобы оставить запас на случай, когда первая ретрансляция тоже потерялась.

Правило 4× RTT, теперь со стороны RIST

Арифметика правила 4× RTT – та же, что в SRT. Оба протокола основаны на NAK с одним раундом ретрансляции на потерю, оба целят на восстановление двух-трёх попыток ретрансляции внутри бюджета. RIST добавляет одну деталь. Поскольку NAK отправляется по таймеру RTCP, а не в момент детектирования потери, задержка детекта на приёмнике RIST может быть больше, чем на приёмнике SRT. Интервалы планирования RTCP обычно 100–500 мс на малом потоке (RFC 3550 §6.2 вычисляет интервал по числу участников и доле полосы); на узком потоке с fast-feedback профилем (RFC 4585 §3.4) интервал может упасть до 5 мс и ниже, но дефолт большинства установок libRIST – 100 мс.

Это значит, что приёмник RIST на дефолтном интервале RTCP заметит потерю в течение ~50 мс после появления пропуска, отправит NAK в следующие 100 мс, а отправитель ретранслирует ещё через половину RTT. Полное время восстановления на пути с 80 мс RTT попадает в диапазон 150–250 мс – чуть медленнее, чем 100–180 мс у SRT. Для большинства линий contribution разница незаметна; для линий, где вы выжали бюджет задержки ниже 300 мс, она имеет значение, и операторы RIST крутят интервал RTCP вниз (через параметр min-interval в libRIST), чтобы сравняться с SRT. Дефолтный компромисс – меньше NAK-сообщений на обратном канале; затюнинговый – быстрее восстановление ценой более занятого feedback-канала.

Настройка – прямой компромисс между glass-to-glass задержкой и устойчивостью, идентичный тому, что выбирают операторы SRT. Правильная настройка – самое маленькое значение, которое выдерживает худший наблюдаемый RTT с запасом на джиттер. Это находят измерением, а не догадкой.

Бондинг каналов – seamless redundancy vs load sharing

RIST поддерживает два различных режима multi-link, которые выглядят похоже, но решают противоположные задачи. Их путаница – самая частая архитектурная ошибка при проектировании бондингового пути contribution.

Seamless Redundancy использует SMPTE ST 2022-7. Отправитель шлёт полную копию RTP-потока в каждом доступном канале – два канала значат две копии, три канала – три копии. Каждая копия несёт идентичные номера последовательности и временные метки. Приёмник слушает все каналы, дедуплицирует пакеты по номеру и отдаёт первый пришедший пакет приложению. Если канал упал полностью, приёмник просто продолжает работу на выживших; если пакет потерян в одном канале, но пришёл в другом – приёмник потери не замечает. ARQ не нужен для отказа канала, потому что резервирование сквозное.

Цена – пропускная способность: источник 6 Мбит/с по двум каналам seamless redundancy обходится в 12 Мбит/с egress. Польза – отказ канала невидим зрителю. Два различных пути ISP между удалённой площадкой и центральным узлом, запущенные в seamless redundancy, дают ближайшее, что открытый интернет может предложить вместо выделенной линии.

Load Sharing использует RIST-специфичный механизм бондинга, который распределяет RTP-пакеты по нескольким каналам. Источник 12 Мбит/с, разделённый между двумя равными каналами, превращается в две доли по 6 Мбит/с – по одной на канал. Приёмник слушает оба канала, переупорядочивает пакеты по номеру и запускает ARQ через тот канал, который меньше всего загружен, когда нужно послать NAK. Если канал упал, ARQ восстанавливает пропущенные пакеты через выжившие; на короткое время агрегированная полоса делится пополам и пакеты могут проскакивать через error concealment, потом путь стабилизируется на оставшемся канале.

Цена – короткий сбой при отказе канала и операционная сложность обеспечения нескольких каналов. Польза – агрегированная полоса равна сумме отдельных каналов: 4 Мбит/с мобильный uplink + 4 Мбит/с Wi-Fi вместе несут 8 Мбит/с поток. Для мобильной контрибуции из машины или с рюкзачного кодера со связкой LTE-модемов load sharing – доминирующий паттерн.

Нажмите, чтобы увеличить

Механическое правило большого пальца: seamless redundancy удваивает полосу на проводе, но устраняет отказ канала; load sharing держит полосу постоянной, но допускает короткий глитч при отказе канала. Оба режима совместимы по SMPTE 2022-7 на проводе, поэтому приёмник load sharing и приёмник seamless redundancy могут говорить с отправителем, настроенным в любом из режимов, если совпадает количество копий.

Main Profile – шифрование, туннелирование, мультиплекс

Simple Profile даёт надёжный транспорт без шифрования. Это приемлемо для частной выделенной линии, но не приемлемо для пути через открытый интернет. Main Profile это чинит, оборачивая весь обмен RTP-и-RTCP в туннель GRE-in-UDP – однострочное описание, которое скрывает четыре отдельных механизма, о каждом из которых стоит знать.

Обёртка GRE-in-UDP взята из IETF RFC 8086, опубликованного в марте 2017 года. GRE – Generic Routing Encapsulation – это туннельный IP-протокол 1990-х, который заворачивает любой IP-payload в другой IP-заголовок; вариант «in-UDP» из RFC 8086 кладёт GRE-туннельный трафик внутрь UDP-датаграммы, чтобы он мог пройти NAT и фаерволы. RIST Main Profile использует эту обёртку, чтобы мультиплексировать произвольное число RTP-потоков плюс in-band управляющий канал через один UDP-порт. Накладные расходы – постоянный per-packet заголовок ~24 байта, что на типичных 1300-байтных MPEG-TS-кадрах – около 1,8 %; ощутимый налог, но плата за то, чтобы получить все возможности Main Profile в одном пакете.

Шифрование DTLS 1.2 едет поверх обёртки GRE-in-UDP. Datagram Transport Layer Security, сокращённо DTLS, – UDP-дружественная версия TLS, которую тот же WebRTC использует для своего data plane; RIST наследует те же cipher suites (AES-128-GCM по умолчанию; AES-256-GCM доступен для регуляторных режимов, требующих этого) и ту же семантику обмена ключами (Diffie-Hellman с аутентификацией сертификатом). DTLS полностью двунаправленный, поэтому один и тот же handshake аутентифицирует и шифрует и control plane, и media plane сразу. Выделенный IANA UDP-порт для DTLS-over-GRE-in-UDP – 4755. Откройте этот порт в фаерволе.

PSK-аутентификация – более лёгкая альтернатива DTLS на сертификатах, включённая в Main Profile именно для multicast-сценария, где каждому приёмнику нужен один и тот же ключ. Парольная фраза настраивается на каждом отправителе и каждом приёмнике вне канала; протокол выводит общий ключ через PBKDF2 и шифрует payload GRE-туннеля напрямую. Это режим, который спутниковые вещатели используют для one-to-many доставки; DTLS на сертификатах – режим unicast-контрибуции.

Мультиплексирование in-band управления делает Main Profile операционно отличным от Simple. Один туннель GRE-in-UDP несёт произвольное число медиапотоков (каждый с тегом RTP synchronization source identifier) плюс control-канал, который занимается аутентификацией, ротацией ключей, рекламой потоков и удалённой диагностикой. Одна дыра в фаерволе, один проброс порта, одно соединение – жизнь операционной команды становится заметно проще. Обновление TR-06-2 от июня 2024 добавило универсальный интерфейс аутентификации, который позволяет удалённой ingest-точке принимать либо сертификат с открытым ключом, либо TLS-SRP credential без повторного handshake.

Самая частая ошибка конфигурации Main Profile – оставить согласование шифрования в режиме «permissive», что позволяет неправильно настроенному отправителю подключиться через Simple Profile (без шифрования) без предупреждения. Промышленные деплои должны настраивать приёмник на требование Main Profile и явный отказ соединениям Simple Profile – в API libRIST это параметр profile=main и соответствующее правило фаервола на порту 4755.

Advanced Profile – передача SMPTE ST 2110 через открытый интернет

Advanced Profile – то, что делает RIST действительно отличным от SRT, и причина, по которой фрейминг «RIST – вещательно-уровневая альтернатива» в этой статье корректен. Где Simple и Main несут один или несколько медиапотоков, упакованных в RTP, Advanced несёт произвольные IP-payload – включая семейство несжатых студийных форматов SMPTE ST 2110 и SMPTE ST 2022-6 SDI-over-IP. ARQ на уровне туннеля в Advanced работает на сырых IP-пакетах, а не на внутреннем протоколе, так что внутренний протокол может быть чем угодно, что бегает по IP.

Это важно, потому что современный вещательный плант переходит с SDI на ST 2110 IP-сети внутри объекта, и логичный следующий вопрос – «каким протоколом нести ST 2110 между объектами?». Честный ответ для большинства путей – выделенная линия: несжатые битрейты ST 2110 1,5–25 Гбит/с на канал слишком велики для открытого интернета. Но для сценариев remote production, где у вас есть пара сотен мегабит пропускной способности интернета (стадион с оптикой, удалённая студия со связкой корпоративного широкополосного канала) и нужно нести несколько essence-стримов ST 2110 плюс ancillary data и PTP-тайминги – RIST Advanced Profile единственная опубликованная открытая спецификация, которая делает всё разом.

Механически Advanced Profile определяет режим reduced-overhead encapsulation, который убирает большую часть заголовка GRE-in-UDP и добавляет всего 8-байтовый тег плюс 8-байтовый номер последовательности для трекинга ARQ. Налог на заголовок падает с ~1,8 % в Main Profile до примерно 0,6 %. Поскольку payload непрозрачен (сырые IP), приёмник Advanced Profile не понимает внутренний протокол – он видит сырые байты, прогоняет ARQ и отдаёт их в принимающий сетевой интерфейс так, будто они пришли натурально. Для приёмника ST 2110 за декодером RIST Advanced Profile опыт неотличим от прямой оптической линии.

Обновление TR-06-3 от 2023 добавило более продвинутые опции forward error correction (LDPC-коды и Raptor-коды вместе с оригинальным XOR FEC из SMPTE 2022-1), уплотнило согласование NAT keep-alive и прояснило связь со спецификациями TR-06-4. Комбинация Advanced Profile и TR-06-4 Part 3 (RIST Relay, опубликован июль 2023) даёт вещателям способ соединить два эндпоинта RIST через фаерволы без открытия входящих портов с обеих сторон – Relay сидит в облаке, оба эндпоинта набирают наружу, и два потока встречаются посередине. Это архитектура, которую remote-production компании используют, когда ни один из концов не контролирует свою сеть.

RIST vs SRT – какое решение реально имеет значение

Оба протокола решают одну задачу. Оба работают на UDP. Оба используют NACK-based ARQ с настраиваемым бюджетом задержки. Оба поддерживают шифрование, мульти-канальный бондинг и contribution-задержку меньше секунды. Честное сравнение – не по технике (она примерно эквивалентна), а по трём операционным вопросам, которые задаст инженер по закупкам.

Первый вопрос: требует ли процесс опубликованную открытую спецификацию? Ответ «да» указывает на RIST. Документы TR-06 – скачиваемые PDF с номерами разделов; тендерный ответ может ссылаться на них как на нормативный референс и пройти процедуру закупки без единого звонка. IETF-драфты SRT истекли в 2022 году, и де-факто спецификация протокола теперь – исходный код libsrt и SRT Alliance Deployment Guide – внушающие доверие инженерные артефакты, но не спецификации в формальном смысле, который требуют отделы закупок broadcast.

Второй вопрос: требует ли процесс мульти-вендорную совместимость по спецификации, а не только по реализации? RIST спроектирован под этот случай: каждый документ TR-06 содержит критерии соответствия для совместимости, и VSF проводит ежегодные plug-fests на IBC и NAB, где вендоры доказывают, что могут разговаривать друг с другом. SRT достигает того же другим способом: каждый вендор линкует libsrt, поэтому по построению все реализации ведут себя одинаково. Если вас волнует «может ли кодер Net Insight говорить с декодером Cobalt Digital», оба протокола отвечают «да»; если ваш вопрос – «если Haivision завтра закроется, смогу ли я получить соответствующую реализацию SRT из clean-room rewrite», спец-first модель RIST даёт более комфортный ответ.

Третий вопрос: нужно ли вам нести SMPTE ST 2110 или SMPTE ST 2022-6 через открытый интернет? RIST Advanced Profile – единственный опубликованный протокол, который это делает. SRT – нет. Если процесс хоть как-то касается несжатой студийной essence, решение принято.

Для всего остального – публичная contribution MPEG-TS или H.264/H.265 потоков, моно-вендорные или близкие к моно-вендорным среды, contribution из OBS, FFmpeg или облачного кодера – экосистема SRT примерно в 4–5 раз больше, чем у RIST, интеграция быстрее, и дефолтный ответ – SRT. Haivision Broadcast Transformation Report 2024 измерил долю SRT 68 % среди вещателей; эквивалентная цифра RIST, опубликованная VSF в 2024 году, – примерно 14 %, сконцентрирована в средах с формальными закупками (национальные вещатели, регулируемые государственные процессы, общественное вещание Европы). Обе цифры растут год от года; они не антагонистичны.

Нажмите, чтобы увеличить

Реалистичный бюджет задержки – remote news contribution через RIST

Арифметика end-to-end для реалистичного сценария. Условия: новостная группа в Берлине отправляет 6-Мбит/с H.264 поток на master control в Лондон по одному пути в открытом интернете с 80 мс RTT и 2 % средних потерь. Группа использует RIST Main Profile с шифрованием DTLS и бюджетом задержки 400 мс. Хотим узнать glass-to-glass задержку, которую увидит домашний зритель.

Кодер берёт секунду камерного входа и выдаёт 6-Мбит/с H.264-стрим в обёртке MPEG-TS. Конвейер кодера – захват, scaling, кодирование, пакетизация – обычно имеет внутреннюю задержку 150–250 мс; возьмём 200 мс. MPEG-TS-пакеты заходят в отправителя RIST, который пакетит их в RTP, добавляет заголовок DTLS-payload и оборачивает результат в GRE-in-UDP-датаграмму. Overhead отправителя RIST маленький – меньше 5 мс на современном CPU – но сам буфер отправителя гасит часть джиттера перед передачей; считаем 50 мс.

Датаграмма пролетает 80 мс RTT через открытый интернет, что составляет 40 мс в одну сторону. Приёмник пишет пакет в буфер переупорядочивания; буфер 400 мс глубиной, поэтому пакет сидит в нём полные 400 мс, прежде чем уйти в декодер. Декодер тратит ещё 100–150 мс на декодирование и отдачу следующему этапу (DVE, брендинг, master control switcher). Выход master control затем перекодируется для доставки зрителям, что добавляет ещё одну encoder-задержку и packager-задержку, прежде чем эстафету перехватит конвейер LL-HLS или LL-DASH.

От стекла камеры до выхода декодера приёмника contribution: 200 мс кодер + 50 мс буфер отправителя + 40 мс сеть + 400 мс reorder + 150 мс декодер = 840 мс. Добавьте distribution-сторону (кодер + packager + LL-HLS-конвейер + буфер плеера), и получите примерно 4 секунды общего glass-to-glass для домашнего зрителя – типично для современной remote news через LL-HLS. RIST-хоп даёт 690 мс этого итога; LL-HLS distribution – остальное. Единственное число, которое надо запомнить: 400 мс reorder-буфер – он доминирующий вклад на стороне contribution и тот рычаг, которым крутят, когда уровень потерь на пути меняется.

Где здесь Фора Софт

Фора Софт с 2005 года поставляет видеостриминг, WebRTC, OTT, телемедицину, e-learning, видеонаблюдение и AR/VR – 239 проектов и считаем. Мы видим RIST чаще всего в двух категориях продуктов: broadcast-смежные OTT-платформы, где заказчик мигрирует со спутникового contribution на интернет-контрибуцию и нуждается в опубликованной спецификации, чтобы удовлетворить требование закупок, и инструменты для remote production, где contribution-путь – один из нескольких уровней надёжности в мульти-вендорной архитектуре. Для greenfield-контрибуции вне этих категорий SRT остаётся дефолтом в проектах, которые мы делаем. Правильный ответ обусловлен задачей, а не протоколом, и работа выбора – это работа задать три вопроса выше и честно на них ответить.

Типичные грабли

Смешение профилей на отправителе и приёмнике без проверки. Приёмник Main Profile по умолчанию примет отправителя Simple Profile (Simple – строгое подмножество Main), но соединение будет нешифрованным. Промышленные приёмники должны быть настроены на явное требование Main Profile и отказ Simple. Безопасный дефолт – параметр libRIST profile=main на приёмнике.

Reorder-буфер ниже 4× RTT. Соблазнительно на LAN-пути с 30 мс RTT, где 120 мс кажутся избыточными, но как только путь проходит через Wi-Fi access point с эпизодическими 200-мс всплесками джиттера, буфер слишком мелкий, чтобы восстановить хотя бы одну ретрансляцию, и поток глитчит каждые несколько секунд.

Путаница seamless redundancy и load sharing. Двухканальная связка, настроенная на одном конце как load sharing, на другом как seamless redundancy, не работает: приёмник увидит удвоенные номера последовательности и будет переупорядочивать бесконечно. Выберите один режим, настройте оба конца одинаково.

Забывают, что порты зависят от профиля. Simple Profile обычно использует порт 1968 (год начала работ над RTP в Bell Labs – маленькая внутренняя шутка VSF). Main Profile обычно использует порт 4755 (выделенный IANA для DTLS-over-GRE-in-UDP). Они не взаимозаменяемы.

Считают интервал RTCP feedback фиксированным параметром. Он настраивается; на путях с узкой задержкой его крутят вниз до 5–10 мс, чтобы сравняться с SRT по скорости восстановления, ценой более насыщенного обратного канала. В libRIST это параметр --rtcp-interval на стороне приёмника.

Главное

• RIST – открытая мульти-вендорная альтернатива SRT: то же семейство, другое управление.
• Три профиля: Simple TR-06-1, Main TR-06-2, Advanced TR-06-3. Каждый – строгое надмножество предыдущего.
• Main Profile – производственный дефолт: DTLS-шифрование, GRE-in-UDP туннель, мультиплекс потоков, обход NAT.
• Advanced Profile – единственная опубликованная спецификация, способная нести SMPTE ST 2110 через открытый интернет.
• Берите RIST вместо SRT, когда закупки требуют опубликованную спецификацию или процессу нужен несжатый транспорт.

Что читать дальше

• SRT: профессиональный стандарт contribution через открытый интернет – вторая половина современного выбора.
• Выбор протокола contribution в 2026: дерево решений – полный фреймворк выбора протокола, включая RIST.
• Что такое ingest и почему это самый рискованный хоп конвейера – открывающая статья Блока 3, задающая рамки для каждого протокола в главе.