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, – это открытый мультивендорный протокол для передачи контента, который профессиональная вещательная индустрия выбирает, когда контракт или процесс требуют формально опубликованную спецификацию, а не реализацию одного вендора, превратившуюся в де-факто стандарт. 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-ориентированного ARQ, агрегирует несколько сетевых каналов для увеличения пропускной способности или резервирования, а также (в профилях Main и Advanced) обеспечивает шифрование и туннелирование потока через DTLS поверх GRE-in-UDP. В 2026 году вы выбираете RIST вместо SRT, когда нужно передавать несжатый SMPTE ST 2110 через открытый интернет, когда тендерные документы требуют опубликованную открытую спецификацию или когда совместимость между двумя вендорами важнее размера экосистемы вокруг протокола.

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

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

Статья – канонический справочник Блока 3 по RIST: что включают три профиля, как работает уровень надёжности на основе NACK, зачем инженерам по вещанию нужна передача 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. В 2017 году Video Services Forum (VSF) создал RIST Activity Group, чтобы закрыть пробел в открытых спецификациях, который на тот момент заполняли одно-вендорные реализации SRT 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 включает стандартный NACK по RFC 4585 (битовая маска на 17 последовательных номеров пакетов) и APP-RTCP-пакет, определённый в RIST, для Range NACK (одно сообщение, запрашивающее произвольный диапазон потерянных пакетов). Ретрансляция потерянных пакетов происходит по таймеру RTCP, а не при каждом отдельном случае потери – поэтому на канале с 5 % потерь восстановление происходит одной группой ретрансляций, а не 50 отдельными round-trip’ами. Это вся архитектура – в 200 словах.

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

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

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

VSF – некоммерческий орган стандартизации, основанный в 1997 году для нормирования видеотрансляции по IP. В 2017 году он создал группу RIST Activity Group, чтобы одновременно решить все три ключевые проблемы. В неё вошли производители оборудования для вещания (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-идентификаторов программ (NULL-PID) и обход NAT. В июне 2024 года Main Profile был обновлён за счёт добавления универсальных механизмов аутентификации – сертификатов с открытым ключом и 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-фестах в рамках IBC и NAB стабильно демонстрируется совместимость трёх–четырёх вендоров одновременно: каждый из них использует одну и ту же библиотеку, интегрированную в собственный интерфейс.

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

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

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

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

Когда приёмник обнаруживает пропуск в номерах последовательности – например, пришёл пакет 46, затем 48, а 47 отсутствует – он не реагирует немедленно. RTCP-обратная связь отправляется по таймеру, а не на каждое событие потери, поскольку отправка отдельного 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. Такой компромисс позволяет экономить пропускную способность обратного канала – не нужно отправлять ACK на каждый пакет – но ценой этого становится то, что отправитель не может знать, жив ли приёмник, пока тот явно не пришлёт RTCP receiver report по стандартному интервалу в 5 секунд. На практике это вполне приемлемо для медиатранспорта – приложение замечает пропавший поток в течение нескольких секунд в обоих случаях – однако именно эта архитектурная особенность объясняет, почему SRT и RIST не могут использовать общий формат на проводе. Второе: RIST наследует поле временной метки из RTP и использует его для компенсации джиттера независимо от переупорядочивания по порядковым номерам. Буфер воспроизведения приёмника разделён с буфером ретрансляций: сглаживание джиттера работает на основе временных меток, а переупорядочивание – на порядковых номерах. Если пакет не успевает попасть в дедлайн ретрансляции, он удаляется из обоих конвейеров.

Арифметика вслух, с реалистичными числами. Допустим, у соединения задержка round-trip составляет 80 мс, а средние потери пакетов – 2 %. Рекомендуемая задержка буферизации – не менее 4× RTT, то же правило, что и в сообществе SRT: худший сценарий восстановления выглядит так. Приёмник ждёт время, достаточное для получения пары пакетов, чтобы убедиться в потере, затем отправляет NAK на следующем тике RTCP (в пределах одного интервала). NAK добирается до отправителя за половину RTT, отправитель выполняет ретрансляцию, и она возвращается обратно за ещё одну половину RTT. При RTT в 80 мс безопасная задержка буферизации – 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. Полное время восстановления на линии с RTT 80 мс составляет 150–250 мс – немного медленнее, чем 100–180 мс у SRT. Для большинства contribution-каналов эта разница незаметна; на линиях, где задержка снижена до 300 мс и ниже, она становится существенной, и операторы RIST уменьшают интервал RTCP (через параметр min-interval в libRIST), чтобы сравняться по скорости с SRT. Стандартный компромисс – меньшее количество NAK-сообщений в обратном канале; оптимизированный режим – более быстрое восстановление за счёт большей нагрузки на канал обратной связи.

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

Бондинг каналов – бесшовная избыточность против распределения нагрузки

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 Мбит/с – по одному на канал. Приёмник отслеживает оба канала, восстанавливает порядок пакетов по номерам и отправляет 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-полезный груз в другой IP-заголовок. Вариант «in-UDP» из RFC 8086 помещает трафик GRE-туннеля внутрь UDP-датаграммы, что позволяет ему проходить через NAT и межсетевые экраны. RIST Main Profile использует эту обёртку для мультиплексирования произвольного числа RTP-потоков и in-band управляющего канала через один UDP-порт. Накладные расходы составляют постоянный заголовок около 24 байт на пакет – при типичных размерах MPEG-TS-кадров в 1300 байт это около 1,8 %. Это ощутимая плата, но она оправдана возможностью использовать все функции Main Profile в одном пакете.

Шифрование DTLS 1.2 работает поверх обёртки GRE-in-UDP. Datagram Transport Layer Security (DTLS) – это версия TLS, адаптированная для работы с UDP, которую WebRTC использует в своём data plane; RIST применяет те же наборы шифров (по умолчанию – 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 и напрямую шифрует полезную нагрузку GRE-туннеля. Это режим, который спутниковые вещатели используют для доставки one-to-many; DTLS на сертификатах применяется в unicast-режиме контрибуции.

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

Самая частая ошибка при настройке 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 Profile работает с произвольными IP-нагрузками – включая несжатые студийные форматы из семейств SMPTE ST 2110 и SMPTE ST 2022-6 SDI-over-IP. Механизм ARQ на уровне туннеля в Advanced Profile применяется к сырым IP-пакетам, а не к внутреннему протоколу, что позволяет использовать в качестве внутреннего протокола любой, способный работать поверх IP.

Это важно, потому что современная вещательная инфраструктура переходит с SDI на IP-сети ST 2110 внутри объекта, и естественный следующий вопрос – «каким протоколом передавать 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 %. Поскольку полезная нагрузка непрозрачна (сырые IP), приёмник Advanced Profile не распознаёт внутренний протокол – он воспринимает данные как сырые байты, применяет ARQ и передаёт их в сетевой интерфейс так, будто они пришли напрямую. Для приёмника ST 2110 за декодером RIST Advanced Profile такой опыт неотличим от прямой оптической линии.

Обновление TR-06-3 от 2023 года добавило более продвинутые опции коррекции ошибок при передаче (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 размещается в облаке, оба эндпоинта инициируют исходящие соединения, и два потока встречаются посередине. Именно такую архитектуру используют компании, занимающиеся удалённой съёмкой, когда ни один из концов не контролирует свою сеть.

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

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

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

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

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

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

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

Реалистичный бюджет задержки – передача новостей в формате remote через RIST

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

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

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

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

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

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

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

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

Reorder-буфер ниже 4× RTT. На LAN-соединении с RTT в 30 мс 120 мс могут показаться избыточными, но как только путь проходит через Wi-Fi-точку доступа с эпизодическими всплесками джиттера до 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 – стандарт для производственных задач: DTLS-шифрование, туннелирование GRE через UDP, мультиплексирование потоков, обход NAT.
• Профиль Advanced – единственная опубликованная спецификация, способная передавать SMPTE ST 2110 по открытому интернету.
• Выбирайте RIST вместо SRT, если закупки требуют опубликованную спецификацию или необходим несжатый транспортный протокол.

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

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