Новое время предъявляет новые требования к скорости передачи данных и надёжности доставки, а объём передаваемого контента продолжает расти. Когда необходимо использовать публичный интернет для передачи видео высокого качества, операторы и контент-провайдеры неизбежно сталкиваются со следующими проблемами:
- доставка не гарантирована, при этом видео на приёмной стороне может терять кадры и содержать артефакты, рассинхронизацию и замирания;
- многие решения обладают высокой задержкой и не применимы для прямой трансляции мероприятий;
- хочется использовать канал любой пропускной способности или даже несколько каналов;
- контент должен быть защищён, чтобы его никто не украл;
- реализация должна быть простой, при этом протокол должен быть совместим с другими устройствами и ПО.
Многие вендоры, контент-провайдеры, операторы и вещатели заходят в тупик: какие протоколы поддерживать и внедрять в свои кодеры, плееры, приставки и плейауты? В последнее время большой популярностью пользуются протоколы гарантированной доставки данных с минимальной задержкой: RIST и SRT. Но какой же из них выбрать?
Что общего у RIST и SRT?
Оба протокола предназначены для передачи видео с низкой задержкой через общедоступные интернет-сети. SRT изначально был разработан компанией Haivision для применения в их собственных кодерах и декодерах, а в 2017 году стал открытым протоколом для доставки видео в реальном времени. Замечу, компания Haivision — не только разработчик проекта SRT и основатель SRT Alliance, но и член альянса RIST Forum (входит в Video Services Forum).
Разработка RIST стартовала в том же 2017 году. Многие компании применяли разные реализации RIST в своих продуктах, но их решения были не совместимы между собой.
И RIST, и SRT имеют одинаковый уровень шифрования, а также поддерживают вещание высокобитрейтных потоков и Forward Error Correction (SMPTE 2022-1). Оба протокола поддерживают Pre-Shared Key до 256 битов и автоматический запрос повторной передачи пакетов (ARQ), умеют обходить брандмауэр и позволяют балансировать между надёжностью доставки и задержкой.
Сегодня оба протокола реализованы в виде библиотеки с открытым исходным кодом, что позволяет быстрее и проще запускать вещание, а также не зависеть от решения конкретного производителя в отличие от использования проприетарных решений, таких как Zixi.
SRT и RIST присутствуют во многих популярных решениях и фреймворках, например AWS Media Connect, Nimble Streamer, VLC, gstreamer, ffmpeg, wireshark (через плагины). Библиотеки librist и libsrt доступны для всех трёх операционных систем: Windows, Linux и MAC.
В чем разница между протоколами?
SRT изначально был разработан одной компанией на базе UDT (UDP-based Data Transfer Protocol) — широко известного и зарекомендовавшего себя протокола передачи файлов. UDT значительно быстрее TCP и легко конфигурируется. Но, в отличие от файлов, медиаданные значительно больше по объёму и очень восприимчивы к потерям. SRT отлично себя показывает при низком или среднем проценте потерь пакетов, скажем, не более 10–12%. Основной целью SRT было заменить устаревший RTMP, который Amazon перестала поддерживать, а Flash плагины перестали поддерживаться браузерами.
RIST же был совместной разработкой группы экспертов из разных компаний, занимающихся доставкой видеоконтента (ассоциация Video Service Forum и группа технических представителей разных медиакомпаний, образовавших позднее RIST Forum). RIST базируется на протоколах RTP, RTCP и SMPTE-2022 (транспортный поток через IP) и некоторых других интернет-стандартах (RFC). Изначально RIST разрабатывался для передачи видеоконтента и во многом учёл опыт прошлых разработок открытых и проприетарных протоколов для стриминга. RIST способен восстанавливать до 55% регулярных и до 86% кратковременных потерь.
Даже старые плееры, транскодеры, медиасерверы или анализаторы умеют работать с RIST на базовом уровне, принимая RTP, однако с SRT они работать не смогут.
Различаются подходы при авторизации. SRT использует только PSK (pre-shared keys), который предоставляет приемлемый уровень безопасности, но который подходит не всем вещателям. RIST тоже использует PSK, но при этом его можно дополнить SRP (Secure Remote Password) протоколом для дополнительной защиты. Также RIST может работать в режиме DTLS на базе авторизации с помощью сертификата, что является фундаментальным требованием большинства вещателей.
Для обхода брандмауэра в SRT используется концепт рукопожатий caller/listener без настройки перманентных правил, также для этой цели у SRT есть специальный режим rendezvous. Принцип базируется на функции отслеживания соединения у сетевых экранов. В RIST же для обхода брандмауэра используются RTCP сообщения.
Отличаются и методы переотправки потерянных пакетов. SRT не всегда подходит к узким интернет-каналам, потому что при большом количестве ошибок может забить весь канал переотправкой пакетов. Тогда как RIST умеет снижать потребление канала при подобной переотправке. Для реализации ARQ протокол RIST использует только NACK, тогда как в SRT используется и NACK и ACK для подтверждения получения.
SRT умеет работать только в режиме «точка-точка», тогда как у RIST реализован подход «точка — много точек», включая multilink поддержку и мультикаст реализацию. SRT базируется на открытом исходном коде библиотеки c примером реализации от одной конкретной компании, тогда как RIST базируется на открытых спецификациях с участием в разработке группы компаний. В проекте librist активно участвуют добровольцы в качестве тестировщиков и технических писателей.
Почему стоит выбрать SRT?
SRT перевещает потерянные пакеты как можно быстрее, поэтому, если нет ограничения канала по ширине, качество контента будет лучше, а его задержка — ниже.
На сегодняшний день SRT уже успел завоевать определённые позиции на рынке, а также сформировать свой альянс компаний-разработчиков, которые поддерживают этот протокол и используют его в своих решениях. SRT — это проект с открытым исходным кодом, вокруг которого собралось немалое комьюнити. Сейчас альянс насчитывает уже более 450 компаний, включая недавно присоединившихся AWS, OBS и Sony.
SRT также хорошо работает с передачей большого объёма данных, но резко снижает или вовсе теряет свою эффективность при потерях в 15% и более, что подтверждается различными исследованиями.
Сегодня SRT всё ещё более распространён, нежели RIST, поэтому он более эффективен в плане совместимости с потенциальным окружением. SRT, в отличие от RIST, уже присутствует в таких популярных решениях, как OBS Studio и Wowza.
Релиз версии SRT 1.5 был запланирован на 2020 год, но на момент написания статьи ещё официально не вышел. В нём разработчики обещают реализовать бондинг, поддержку C++ 11, двусторонний обмен метаданными, а также улучшить оценку пропускной способности и поддержку мультикаста.
Подробно про SRT я уже писал в статье о низкой задержке и протоколах ее реализации.
Почему стоит выбрать RIST?
RIST умеет вещать в режиме IP multicast, что позволяет значительно экономить трафик и сетевые ресурсы. RIST поддерживает вещание нескольких потоков параллельно (multistream multiplexing), при этом требуется единственный UDP порт. Возможно бесшовное переключение между копиями потока по резервным каналам связи (seamless switching without glitching по широко используемому стандарту SMPTE 2022-7). На приёмной стороне RIST объединяет несколько потоков в один общий поток (link aggregation / bonding).
Поскольку RIST построен на базе RTP, то подавляющее количество устройств, умеющих принимать этот протокол, уже в какой-то степени умеет работать и с RIST (за исключением способности обрабатывать повторную передачу пакетов и другие киллер-фичи RIST).
RIST умеет экономить трафик для повторной передачи пакетов, чтобы добиться стабильности вещания, и избавляться от оверхеда трафика, отсекая нулевые пакеты (паддинг или стаффинг). RIST оптимизирован для передачи высокобитрейтных видео через расширение RTP заголовка, что позволяет увеличить цикл нумерации пакетов с 16 бит до 32. Также RIST считается более надёжным в плане безопасности, так как может работать не только в режиме PSK (Pre-Shared Key), но и использовать DTLS шифрование на базе сертификатов, что считается гораздо более безопасным методом, который используется большинством банков. RIST умеет восстанавливать до 25% потерь с оверхедом в 100% и до 50% потерь с оверхедом в 200%. Во время тестирования на выставке Virtual NAB в 2020 году RIST справился с мгновенными потерями в 86%, при этом все пакеты были доставлены (рис.1).
Enhanced/Advanced profile сейчас в разработке. В нём стоит ожидать улучшенную систему управления полосой передачи данных, адаптивный битрейт, сжатие без потерь, оптимизацию управления созданными каналами вещания, поддержку гибридного вещания, как это реализовано в HbbTV и ATSC 3.0, и прочее (рис. 2). Релиз расширенного профиля планируется уже в 2021 году.
Заключение
Совместимость в видео индустрии всегда играла глобальную роль. Для этого придумывались и утверждались стандарты, которые могли объединять разных производителей в рамках одной инфраструктуры, где проприетарные технологии всегда рискуют быть узким горлышком для продвижения проекта.
Производить контент в доступной для всех партнёров, клиентов, операторов, постпродакшна и зрителей форме — ключевое требование к любому вещателю. Но со временем у вещателей растут требования не только к совместимости, но и к удобству использования, задержке, минимизации используемой полосы при возможности вещать контент ультравысокого качества, возможности вещать в открытых сетях с большим количеством потенциальных потерь, безопасности, авторизации, простоте в настройке и управлении. В ответ на эти требования возникают новые технологии и протоколы, одни из которых — гости этого сравнения. Оба протокола уже широко применяются: в SRT альянс на момент написания статьи входит более 450 компаний, а в RIST Forum — более 130, но кто завоюет рынок в средне- и долгосрочной перспективе, пока можно только гадать. Возможно, настанет время, когда SRT и RIST будут объединены в единый протокол, ведь несмотря на их различия, они преследуют похожие цели и близки по функциональным характеристикам.
Ниже привожу комментарий одного из основных разработчиков библиотеки с открытым исходным кодом librist Гийса Пескенса (Gijs Peskens) по поводу сравнения RIST и SRT:
«Полагаю, что главная причина того, что мне нравится RIST, — его простота. Я бы мог всего за полчаса объяснить суть протокола простого профиля, и даже быстрее, если человек разбирается в видеопотоках и сетевых технологиях. С точки зрения эксплуатации, мы выбрали RIST, потому что простой профиль поддерживает мультикаст (чего не было у SRT тогда, и я не уверен, есть ли сейчас), кроме того, протокол обратно совместим с обычными RTP приемниками.
Если немного углубиться в подробности, то RIST изначально разрабатывался как протокол для передачи видео, преимущественно MPEG-TS, и основан на существующих технологиях, используемых в доставке видео/сетях, как RTP и GRE, а также использует Adaptive Retry reQuests, чтобы сообщать отправителю о потере пакетов.
Что касается libRIST, которую я помогаю поддерживать, мы недавно выпустили первый стабильный релиз, и сейчас работаем над основой для версии 0.3, в которой будут реализованы полнодуплексная связь, контроль доступа на основе сертификатов и многое другое».
Автор
Виталий Сутурихин — руководитель отдела интеграции и сопровождения Elecard с 2015 года. Опыт работы в сфере информационных технологий более 15 лет.