Новое время предъявляет новые требования к скорости передачи данных и надёжности доставки, а объём передаваемого контента продолжает расти. Когда необходимо использовать публичный интернет для передачи видео высокого качества, операторы и контент-провайдеры неизбежно сталкиваются со следующими проблемами:
554 просмотров
- доставка не гарантирована, при этом видео на приёмной стороне может терять кадры и содержать артефакты, рассинхронизацию и замирания;
- многие решения обладают высокой задержкой и не применимы для прямой трансляции мероприятий;
- хочется использовать канал любой пропускной способности или даже несколько каналов;
- контент должен быть защищён, чтобы его никто не украл;
- реализация должна быть простой, при этом протокол должен быть совместим с другими устройствами и ПО.
Многие вендоры, контент-провайдеры, операторы и вещатели заходят в тупик: какие протоколы поддерживать и внедрять в свои кодеры, плееры, приставки и плейауты? В последнее время большой популярностью пользуются протоколы гарантированной доставки данных с минимальной задержкой: 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, двусторонний обмен метаданными, а также улучшить оценку пропускной способности и поддержку мультикаста.
Почему стоит выбрать 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).
Рис.1. Успешное восстановление всех пакетов при мгновенных потерях в 86% в RIST
Enhanced/Advanced profile сейчас в разработке. В нём стоит ожидать улучшенную систему управления полосой передачи данных, адаптивный битрейт, сжатие без потерь, оптимизацию управления созданными каналами вещания, поддержку гибридного вещания, как это реализовано в HbbTV и ATSC 3.0, и прочее (рис. 2). Релиз расширенного профиля планируется уже в 2021 году.
Рис. 2. Дорожная карта RIST
Заключение
Совместимость в видео индустрии всегда играла глобальную роль. Для этого придумывались и утверждались стандарты, которые могли объединять разных производителей в рамках одной инфраструктуры, где проприетарные технологии всегда рискуют быть узким горлышком для продвижения проекта.
Производить контент в доступной для всех партнёров, клиентов, операторов, постпродакшна и зрителей форме — ключевое требование к любому вещателю. Но со временем у вещателей растут требования не только к совместимости, но и к удобству использования, задержке, минимизации используемой полосы при возможности вещать контент ультравысокого качества, возможности вещать в открытых сетях с большим количеством потенциальных потерь, безопасности, авторизации, простоте в настройке и управлении. В ответ на эти требования возникают новые технологии и протоколы, одни из которых — гости этого сравнения. Оба протокола уже широко применяются: в 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 лет.
Источник: vc.ru
Что представляет собой протокол SRT?
Определение защищенного (Secure) надежного (Reliable) транспортного (Transport) протокола
SRT (Secure Reliable Transport) — это бесплатный протокол передачи потокового видео с открытым исходным кодом, который обеспечивает безопасную передачу сигнала с низкой задержкой в «шумящих» или непредсказуемых (с потерями) сетях, таких как публичный интернет. SRT использует интеллектуальный механизм пакетной ретрансляции ARQ (Automatic Repeat reQuest) поверх потока данных UDP для защиты от потери пакетов и колебаний пропускной способности, а также для обеспечения качества вашего live-видео.
Высококачественное live-видео с низким уровнем задержки
Популярность использования потокового видео в коммерческих организациях, государственных учреждениях, школах и оборонной промышленности стремительно растет. Многие протоколы решают задачи совместимости при передаче потокового видео очень большому количеству зрителей, потребляющих контент с различных устройств и приборов. Однако одним из лучших способов использования ресурсов, уже имеющихся в помещениях различных организаций, а также значительных инвестиций провайдеров сервисов в «облачные» технологии, является обеспечение инструментов потокового вещания видео с низкой задержкой и высокой надежностью.
SRT использует наилучшие аспекты протокола User Datagram Protocol (UDP), такие как низкая задержка, но при этом добавляет проверку ошибок, чтобы соответствовать надежности протокола Transmission Control Protocol/Internet Protocol (TCP/IP). Несмотря на то, что TCP/IP обрабатывает все профили данных и является оптимальным для своей работы, SRT может быть использован специально для высокопроизводительной передачи видео.
Для передачи видео по IP с высоким качеством
Какие общие сферы применения SRT?
Лидеры ИТ-сферы среди корпоративных и государственных компаний особенно рады SRT, поскольку он является жизнеспособной заменой протокола обмена сообщениями в реальном времени (RTMP). RTMP — это потоковый протокол на базе TCP, изначально разработанный для работы с плеерами Adobe Flash и до сих пор используемый в качестве протокола для потокового видео в реальном времени.
Основная функция RTMP заключается в доставке контента от энкодера к онлайн видеохосту. Известный своей потоковой передачей с низкой задержкой и минимальными возможностями буферизации, RTMP часто использовался вещательными компаниями для трансляции прямых эфиров в режиме реального времени. Однако, поскольку RTMP не может передавать видеоконтент HEVC, он не является идеальным для новых приложений. SRT, в отличие от RTMP, не зависит от кодеков и может передавать любой тип видеоконтента.
В чем суть преимуществ использования протокола SRT?
Потоковая трансляция видео через Интернет может быть сложной задачей из-за непредсказуемых состояний сети, включая нестабильное соединение, ограничение пропускной способности и проблемы с задержкой. SRT поддерживает:
- Видео высокого качества. SRT разработан для защиты от дрожания, потери пакетов и колебаний пропускной способности из-за перегруженности в «шумных» сетях для обеспечения наилучшего качества изображения. Это достигается благодаря передовым технологиям повторной передачи с низкой задержкой, которые компенсируют потерю пакетов и управляют ею. SRT может выдерживать до 10% потери пакетов без ухудшения качества потока.
- Низкая задержка. Даже при наличии сетевых проблем видео и аудио доставляется с низкой задержкой. В нем сочетаются преимущества надежности доставки TCP/IP и скорости UDP.
- Надежная сквозная передача. Стандартное для отрасли 128/256-битное шифрование AES обеспечивает защиту контента при передаче через Интернет. SRT обеспечивает упрощенный обход брандмауэра.
- Эффективное использование Интернета. Поскольку SRT обеспечивает безопасность и надежность, то публичный Интернет становится доступным для расширенного спектра приложений потоковой передачи, таких как потоковая передача на облачные сайты (например, одновременное вещание в несколько социальных сетей, таких как Facebook Live, YouTube, Twitch и Periscope, с помощью мультиоблачной платформы LiveScale omnicast с одной прямой видеотрансляции), потоковая передача или удаленное вещание всего содержимого видеостены или участков видеостены, представляющих интерес и многое другое.
- Совместимость. Пользователи могут смело внедрять SRT во все рабочие процессы потоковой передачи видео и аудио, зная, что продукты разных производителей будут работать вместе без проблем.
- Открытый исходный код. Протокол нового поколения с открытым исходным кодом, не требующий лицензионных отчислений, позволяет создавать экономически эффективные, совместимые и перспективные решения.
Какие общие области применения SRT?
SRT также решает проблемы безопасности и фокусируется на производительности видео — даже через общественную интернет-инфраструктуру. Общие области применения SRT включают:
- дистанционное вещание,
- онлайн видеоплатформы,
- информационные сети доставки контента,
- корпоративные системы управления видеоконтентом,
- компании, предоставляющие оборудование, программное обеспечение и услуги инфраструктуры потокового интернет-вещания.
Что такое Alliance SRT?
Созданный в 2017 году SRT Alliance — это сообщество лидеров отрасли и разработчиков, целью которого является поддержка свободной доступности и совместного развития протокола SRT. Matrox Video и Magewell является членами SRT Alliance.
- Matrox решения для стриминга и KVM
- Как подключить Magewell Eco Capture M.2
- Обзорное видео семейства Magewell USB Capture
Источник: euclid.ru
Что такое SRT протокол
В этом туториале мы расскажем как работает протокол SRT, в чем его особенность и отличия от других протоколов передачи видео.
Что такое SRT протокол?
SRT — это протокол передачи видео в реальном времени. На текущий момент, SRT — наиболее продвинутый способ передачи видео, по сравнению с другими. Он имеет большое количество тонких настроек, и позволяет организовать видео трансляции с минимальным количеством потерь данных. SRT поддерживает современные кодеки, такие как H.265, что существенно помогает экономить трафик.
Для начала разберемся, на чем основана передача данных видео в современном мире и что конкретно лежит в основе протокола SRT.
По состоянию на август 2021 года в интернете существует 2 способа организации передачи данных : передача данных может быть основана на транспортном протоколе TCP или на протоколе UDP.
Передача, основанная на протоколе UDP
UDP позволяет передавать видео пакеты в реальном времени, но не гарантирует их доставку получателю.
В условиях плохой сети данные часто отбрасываются по дороге, так и не достигнув получателя. Это может быть связано например с тем, что канал получателя слишком маленький не удовлетворяет техническим требованиям для получения пакетов данных.
Передача, основанная на протоколе TCP
Что касается передачи, основанной на TCP — это контролируемое решение, но к сожалению, этот метод не позволяет организовать трансляцию в реальном времени. Протоколы передачи видео, использующие TCP, такие как RTMP или HLS отправляют кусочки видео и ждут, пока TCP полностью не подтвердит получение каждого фрагмента. Такая процедура подтверждения занимает много времени. Задержка этих протоколов составляет не менее 10 секунд, что для большинства вещательных компаний и телевидения в прямом эфире не приемлемо.
Чтобы обойти эти проблемы, компанией Haivision был разработан протокол SRT. SRT — полностью управляемое решение отправки данных, обеспечивающее контроль восстановления потерянных пакетов и при этом работающее в реальном времени.
Рассмотрим преимущества протокола SRT более подробно:
1. Поддержка современных кодеков сжатия
HEVC (так же известный как H.265) — это более современный по сравнению с H.264 кодек для сжатия видео. Основное отличие состоит в том, что HEVC (H.265) позволяет еще сильнее сократить размер файла и тем самым уменьшить необходимую для передачи полосу пропускания.
Уменьшая полосу пропускания, мы снижаем нагрузку на клиентов, расположенных за пределами NAT. Кроме того, снижаются затраты на передачу данных облачных провайдеров, таких как Amazon Web Services или Microsoft Azure, где взимается плата за каждый переданный гигабайт.
При этом, чем выше разрешение видео, тем сильнее работает сжатие, а значит мы экономим больше ресурсов.
2. Мощный механизм контроля восстановления потерянных пакетов
SRT протокол оснащен системой восстановления потерянных пакетов, работающей в реальном времени. Всякий раз, когда пакет не доходит до получателя, протокол запрашивает пакет еще раз. Благодаря продуманной архитектуре протокола у пакета есть небольшой запас времени на восстановление в буфере получателя незадолго до воспроизведения. Таким образом пользователь получает точную последовательность видео фреймов и небольшое сетевое дрожание не отражается на качестве воспроизведения видео.
3. Гибкая настройка под особенности сети
Протокол SRT позволяет регулировать практически все его архитектурные элементы, так что можно подобрать правильные настройки для каждой конкретной ситуации.
В сетях с высоким пингом решением проблемы будет правильно подобранная задержка. В сетях с ограниченным каналом решением становится регулирование максимальной пропускной способности. В сетях со “слабыми” устройствами отправителя или приемника решением становится регулирование размеров буфера отправителя или приемника. И так далее.
4. Поддержка аппаратных видео энкодеров и декодеров
Сегодня протокол SRT уже стандарт для большинства производителей аппаратной видео техники. Транспорт видео между физическим энкодером и декодером по SRT позволяет существенно снизить не только задержку на передачу данных, но и также затраты на вычисления, предоставив их отдельным устройствам.
5. Мощная защита данных
SRT из коробки передает данные в зашифрованном виде, о чем говорит его аббревиатура “Secure Reliable Transport”. Также SRT протокол позволяет опционально шифровать сеансы дополнительным паролем, чтобы исключить возможность атаки mitm (man in the middle).
6. Поддержка многоканальной аудио передачи
С SRT можно передавать до 8 каналов аудио одновременно. Такая функциональность может быть полезна, если например нужно в одном видео потоке организовать синхронный перевод на несколько языков.
Протокол SRT и Callaba Cloud
Протокол SRT, разработанный компанией Haivision— это блестящая технология и инновация, очень значительное улучшение для всей видеоиндустрии. Мы разрабатываем Callaba Cloud на его основе, чтобы люди могли использовать протокол SRT в полной мере в своих проектах. Мы хотим, чтобы наши пользователи могли организовывать трансляции максимально хорошего качества и оставлять своей аудитории только приятные впечатления от просмотра.
В каких случаях Callaba Cloud подойдет вам
1. Если вы хотите организовать трансляцию по SRT.
Callaba Cloud поддерживает такие популярные программы как OBS Studio, vMix, Larix Broadcaster, Larix ScreenCaster. Также полностью поддерживаются аппаратные видео энкодеры и декодеры.
2. Когда нужно организовать гео-распределенную маршрутизацию видео потоков. Например, передать видео в другой регион с минимальной задержкой.
3. Если нужно подключить большое количество вещателей/стримеров или зрителей. Callaba Cloud поддерживает сетевую маршрутизацию на неограниченное количество серверов.
4. Для рестрима входящих SRT потоков в соц. сети.
Callaba Cloud поддерживает все современные соц сети, такие как Youtube, Twitch, Facebook и многие другие. Можно организовать вещание в несколько соц. сетей одновременно.
5. Если вы хотите записывать ваши SRT потоки и не иметь ограничений по количеству записываемых данным. Callaba Cloud в связке с AWS позволяет выделить столько места на диске, сколько вам необходимо.
Источник: callabacloud-ru.medium.com