Опубликовано в журнале ТКТ #05 (721) 2020
Передача видео через общедоступные сети
Современные технологии позволяют передавать высококачественное видео в режиме реального времени через публичный интернет. На сегодняшний день доступно множество запатентованных коммерческих решений, но эти отдельные системы подразумевают значительную ежемесячную плату за использование и ограничены в работе только с совместимыми устройствами – как правило от одного поставщика. SRT-протокол (Secure Reliable Transport) – это протокол передачи данных с открытым исходным кодом и гибкой спецификацией, находящийся в свободном доступе, который работает так же или даже лучше, чем другие аналогичные запатентованные решения, но в то же время обеспечивает возможность работы между устройствами разных производителей. Пользователи SRT-протокола могут выбирать наилучшие продукты для своих конкретных потребностей, в то же время они могут обмениваться видеопотоками с другими организациями и избегать «привязки» к конкретным поставщикам услуг и производителям оборудования.
Описание технологии SRT
Рисунок 1.
Всякий раз, когда видеотрансляция передается из одного места в другое, она подвержена битовым ошибкам и потере пакетов данных. Для видео профессионального качества эти ошибки могут привести к значительному ухудшению итогового качества, даже при уровне потерь, который обычно встречается при передаче через сеть интернет. На рисунке 1 показано, насколько сильно ухудшается качество передаваемого изображения даже при относительно небольшом уровне потери пакетов данных. Для исправления ошибок при передаче данных через сеть обычно используются два метода: метод прямой коррекции ошибок FEC (Forward Error Correction) и автоматический запрос повторной передачи ARQ (Automatic Repeat reQuest). Они оба используются в современных системах передачи видео. На рисунке 2 показано, как оба метода влияют на передачу пакетов данных через сеть.
Рисунок 2.
Алгоритм FEC добавляет специальные данные к передаваемому цифровому потоку, представляющие собой информацию, которую приемник впоследствии может использовать для восстановления поврежденных или отсутствующих пакетов. Одним из недостатков систем на основе алгоритма FEC является то, что дополнительные пакеты данных отправляются всегда – независимо от того, нужны ли они получателю или нет. Поэтому если линия связи работает безошибочно, дополнительный трафик, используемый для передачи пакетов FEC, используется напрасно. Второй недостаток заключается в том, что максимальная потеря пакетов данных, которая может быть допущена, связана с пропускной способностью сети, выделенной дополнительно для передачи данных восстановления FEC, и ограничена этим значением.
Алгоритм ARQ работает путем установления двусторонней связи между источником передачи видео и местом назначения. Каждому исходящему пакету данных присваивается уникальный порядковый номер, и получатель использует его, чтобы определить, все ли входящие пакеты были приняты корректно и в правильном порядке. Если пакеты потеряны при передаче, получатель создает список порядковых номеров отсутствующих пакетов и автоматически передает запрос отправителю для повторной передачи. В случае передачи через сети с высоким уровнем ошибок (как это может произойти в интернете в определенное время суток или при возникновении сбоев) этот процесс может повторяться несколько раз. Для работы ARQ-алгоритма требуется кэширование данных в месте отправки (для временного хранения пакетов в случае их повторной передачи) и наличие буфера данных в месте приема, чтобы упорядочить пакеты в правильном порядке перед их отправкой в декодер.
SRT-технология использует ARQ-алгоритм прежде всего потому, что он хорошо справляется с типами ошибок, которые наиболее часто возникают при передаче данных через интернет. Там преобладают случайные потери пакетов данных. С помощью ARQ-алгоритма эти ошибки могут быть легко исправлены посредством простой повторной передачи пакетов данных, которые не поступили к получателю. Если пакеты, содержащие битовые ошибки, поступают в приемник, они распознаются как отсутствующие пакеты и отправителю предлагается повторно передать их. В качестве дополнительного преимущества, SRT-протокол проставляет метки времени с высоким разрешением в каждом пакете, что позволяет точно воспроизводить видеопотоки на выходе приемника. Это гарантирует, что последующие устройства и программы смогут правильно декодировать видео- и аудиопотоки. Каждый пакет, отправляемый SRT, использует UDP-формат пакетов данных, который обеспечивает передачу пакетов с малыми задержками по времени. Большинство сетей передачи видео в режиме реального времени, разработанных для профессиональных приложений, используют UDP формат, поскольку он предлагает стабильную и легко воспроизводимую систему передачи пакетов данных с постоянной пропускной способностью. Это противоположно непредсказуемым TCP-соединениям, например HTTP-протоколу.
Что не так с потоковой передачей по HTTP-протоколу?
Многие современные медиа-сервисы, обеспечивающие в том числе передачу видео в режиме реального времени, транслируют данные через публичный интернет с использованием технологии потоковой передачи видео по HTTP протоколу. Примерами могут служить сервисы Netflix, YouTube и другие медиасети.
Может показаться, что потоковая передача видео по HTTP протоколу является жизнеспособным решением для всех типов приложений, но у него есть несколько недостатков. Прежде всего, это значительная задержка по времени при реализации потоковой передачи видео. Сквозная задержка длительностью до 30 секунд – не редкость в подобных решениях из-за большого количества этапов обработки данных и множества промежуточных буферов на пути прохождения данных. При таких временных запаздываниях часть профессиональных применений автоматически отпадает.
Кроме того, величина задержки не фиксирована: при хороших условиях работы сети задержки могут уменьшаться, но, когда условия плохие – они могут резко возрасти. Это связано с основой протокола, используемого для HTTP передачи видео и известного как TCP-протокол. TCP требует, чтобы все байты потока были полностью доставлены в их первоначальном порядке. Теоретически, при передаче видео несколько потерянных байтов могут быть исправлены или в худшем случае проигнорированы. С TCP-протоколом это сделать невозможно; вместо этого протокол будет продолжать повторять попытку отправки отсутствующих данных столько времени, сколько на это потребуется. Это и приводит к частому появлению замороженных кадров и надписи «буферизация».
Третья особенность TCP-протокола может быть не всегда заметна, но при этом очень важна для видеоприложений. Она заключается в автоматическом сбросе скорости передачи пакетов данных, когда происходит перегрузка сети. Такое поведение уместно с целью снижения общей нагрузки на сеть, но оно не подходит для передачи видеотрансляций, которые не способны выдержать снижение ниже своей номинальной скорости.
В целом, TCP-протокол играет важную роль в доставке видео пользователям, но описанные особенности делают его непригодным для передачи видеотрансляций в режиме реального времени для многих профессиональных задач.
Как происходит соединение по протоколу SRT?
Каждое SRT-соединение между двумя устройствами начинается с процедуры установления контакта и обмена важной информацией о текущих возможностях.
Три различных режима установления контакта предоставляются устройствам для установки связи друг с другом и передачи сведений, необходимых для отправки и получения пакетов. Первый – это режим вызывающего абонента (Caller), когда конечная точка SRT-соединения пытается подключиться к удаленному устройству по известному адресу и номеру UDP-порта. Второй – это режим прослушивания (Listener), в котором SRT-устройство непрерывно мониторит входящий трафик на наличие определенного адреса и номера порта, ожидая соединения с вызывающим устройством. Третий – это режим «встречи» (Rendezvous), где оба участника SRT-соединения одновременно действуют как в вызывающем (Caller), так и в прослушивающем (Listener) режиме, чтобы упростить установление соединения через определенные типы межсетевых экранов. После завершения процедуры установления контакта вызывающее и ожидающее устройство обмениваются информацией о своих возможностях и конфигурации. Оба устройства должны знать об общей временной задержке прохождения данных по линии связи, чтобы установить корректные размеры буфера данных для компенсации задержки при повторной передаче пакетов. Пропускная способность линии связи также может быть оценена и сообщена, чтобы определить требуемую степень сжатия видео для комфортного прохождения потока через сеть в пределах ее пропускной способности. При желании поток может быть закрыт паролем с использованием технологии 128/256-битного AES-шифрования.
SRT справляется с сетевыми задержками
Благодаря гибкой, адаптивной системе управления буфером данных, SRT-протокол может хорошо работать в сети с диапазоном задержек от нескольких миллисекунд до нескольких секунд, таким образом справляясь с передачей любого контента в частной сети или в глобальном интернете.
Легкое прохождение сетевых экранов
Ни одна современная организация, связанная со средствами массовой информации, не позволяет корпоративным системам иметь неограниченный доступ к интернету или из него. Сетевые экраны защищают сетевые устройства, такие как ПК и серверы, от нежелательных внешних подключений и атак. Процедура установления контакта, используемая SRT-протоколом, поддерживает исходящие соединения без необходимости открытия постоянных и опасных внешних портов в брандмауэре, тем самым поддерживая корпоративную политику безопасности.
Точная синхронизация видеопотоков
Многие сжатые форматы видео чувствительны к сбоям, вызванным изменениями синхронизации между различными частями потоков данных. В SRT-протоколе в каждом пакете данных есть временная метка высокого разрешения, назначенная отправителем, которая может быть использована получателем для точного воссоздания временных соотношений видеопотоков независимо от изменений и задержек в сети. Кроме того, во время процедуры установления контакта конечные устройства SRT-потока устанавливают стабильный профиль сквозной задержки, устраняя необходимость наличия собственных буферов данных у промежуточных устройств, чтобы справляться с изменяющимися задержками при передаче потоков данных.
Центральный сервер не требуется
Некоторые запатентованные системы по передаче медиаданных требуют использования централизованного сервера между отправителем и получателем, что увеличивает стоимость системы и временную задержку. SRT-соединения могут быть установлены непосредственно между двумя устройствами – в этом случае центральный сервер не нужен. Но при желании SRT-протокол может быть реализован и с использованием централизованных серверов и точек ретрансляции, например в таких приложениях как облачные системы сбора данных.
Принят ведущими поставщиками услуг
С тех пор, как SRT стал доступным в качестве технологии с открытым исходным кодом в 2017 году, сотни компаний одобрили этот проект, поддержав SRT Alliance. Это консорциум поставщиков и конечных пользователей, который совместно работает над повышением осведомленности в отрасли и принятием SRT-технологии в качестве общего стандарта для передачи видео с низкой задержкой через интернет. В число наиболее значимых членов SRT Alliance входят Ateme, Avid, Brightcove, Eurovision, Haivision, Harmonic, Limelight, MediaKind, Microsoft, NetInsight, Telestream, Sencore и Wowza.SRT-протокол был принят и ведущими в отрасли платформами с открытым исходным кодом, такими как VLС, Gstreamer, Wireshark, Ffmpeg, OBS Studio, Libav. Протокол SRT используется тысячами организаций по всему миру в ряде различных приложений. В число конечных пользователей входят Comcast, ESPN, Fox News, Microsoft, NBC Sports, NFL и Tencent.
SRT – это открытый стандарт, в настоящее время поддерживаемый сообществом большого количества активных поставщиков технологий, обеспечивающий разнообразие продуктов и позволяющий избежать рисков и затрат, связанных с привязкой только к одному поставщику. В этом сообществе энтузиастов многие решения, предназначенные для самого широкого спектра профессиональных приложений, теперь поддерживают SRT стандарт, включая IP-камеры, кодеры, декодеры, шлюзы, OTT- и CDN- платформы.
Как первоначальный разработчик протокола SRT, компания Haivision также является одним из основателей SRT Alliance и проекта SRT Open Source для потоковой передачи видео с низкой задержкой по времени. Компания Haivision предлагает ряд различных технологических решений, предназначенных для многих типов приложений для передачи медиаданных.
Александр Грицук,
Haivision
