Доставка конечным пользователям
В сегменте доставки видео конечным потребителям протокол UDP/RTP используется достаточно редко. Из распространенных систем, работающих на его основе, можно вспомнить только бесплатную медиаплатформу VLC, включающую медиаредактор и медиаплеер. Она получила популярность в основном потому, что позволяла простыми средствами решать множество насущных задач, таких как ретрансляция видео в локальную сеть, конвертация видеофайлов, просмотр YouTube без Flash-плеера (это было актуально 5—7 лет назад). Некоторые из этих функций востребованы и сейчас, но именно как платформа для получения видео из интернета VLС не слишком удобна и не очень надежна.
Основная масса коммерческих технологий доставки видео пользователю опирается на протокол ТСР/IP. Его надежность определяют две встроенные функции: повторный запрос пропущенных пакетов и выстраивание пакетов в нужном порядке. Тем не менее TCP/IP не обеспечивает постоянство скорости доставки — она напрямую зависит от загруженности маршрутизаторов, через которые проходит поток. Более того, у данного протокола есть ограничения по расстоянию.
Эти проблемы в определенной степени можно компенсировать протоколами, работающими поверх TCP/IP. Первым таким решением, получившим реальное распространение, стал протокол RTMP от Adobe, работающий на базе медиаплатформы Flash. Долгое время решение RTMP/Flash оставалось лидером рынка в области интернет-стриминга. Однако на роль по настоящему массовой технологии оно не годилось из-за высокой стоимости, сложности реализации, а также из-за того, что компания Adobe так полностью и не открыла его спецификацию. В результате лидирующие позиции заняли более дешевые технологии на базе стека TCP/IP/HTTP. Этот стек имел еще больше встроенных механизмов для доставки видео, но одновременно создавал еще больше препятствий для обеспечения ее качества.
TCP
TCP — это протокол с гарантией доставки и сохранения порядка следования пакетов. В исходном варианте протокола передающая сторона отправляет порцию данных и ждет подтверждения их получения от приемной стороны. Такая система сильно замедляет передачу данных, поэтому в более поздних версиях протокола они стали передаваться сериями, а приемное устройство — отправлять кумулятивные подтверждения о получении всей серии или ее части, если какие-то пакеты были потеряны.
Во времена расцвета RTMP/Flash, 12—15 лет назад, технологии на базе HTTP вообще не могли обеспечить полноценный стриминг, а только загрузку видео последовательными фрагментами с началом проигрывания после получения определенного количества фрагментов. Сегодняшние протоколы на базе HTTP, по сути, работают по тому же принципу, с той лишь разницей, что после множества оптимизаций это практически перестало быть заметно конечным пользователям. В хорошо отлаженных коммерческих сетях, использующих CDN в комбинации с небольшими кластерами доступа, видео доставляется с минимальными колебаниями качества. Поэтому современные технологии доставки видео на базе HTTP — HLS и MPEG-DASH — имеют полное право считаться стриминговыми.
Оптимизация проводилась по нескольким направлениям. Первое — сокращение цикла отправка/подтверждение за счет появления и оптимизации режима скользящего окна в протоколе TCP. Второе — введение адаптивной передачи. На уровне HTTP адаптивность реализована добавлением в клиентские устройства постоянного мониторинга качества видеопотока и возможности на лету запрашивать другой профиль видео. Этому способствует и совершенствование систем компрессии, в том числе появление новых ABR-кодеров, в которых профили видео формируются не по формальным параметрам потока, а по уровню качества картинки.
Последнее направление оптимизации, на котором сейчас сфокусированы усилия разработчиков, — сокращение времени от запроса услуги до начала воспроизведения видео. Этот вопрос сейчас решается в рамках стандарта CMAF, процесс подробно описан в статье «Ключевые причины реализации низкой задержки потокового видео». Цель разработчиков — довести стартовую задержку до 3 секунд, что сопоставимо с задержкой в вещательных сетях. Сегодня она может составлять 40 секунд и более. Отметим, что проблема связана именно со спецификой стандарта HTTP. В RTMP/Flash стартовая задержка на уровне вещательных сетей обеспечивалась без дополнительных усилий.
Профессиональная доставка видео по интернет-каналам
Повторимся, технологии HTTP-стриминга в сочетании с CDN могут предоставить почти такое же качество видеоуслуг, как в вещательных сетях, и проблема задержки старта тоже близка к разрешению. Тем не менее проблемы, связанные со спецификой работы протокола TCP/IP и непредсказуемостью качества каналов открытого интернета, не устраняются, а просто сводятся к минимуму за счет вышеописанных механизмов. Причем уровни качества обслуживания, сравнимые с теми, которые обеспечиваются при использовании VPN или выделенного оптоволокна, остаются недостижимыми. Поэтому, несмотря на надежность TCP/IP, для профессиональной доставки видео чаще используются технологии на базе RTP-протокола, специально разработанного для передачи аудио/видеотрафика в реальном времени. Чаще всего в IP/RTP-пакеты инкапсулируются транспортные пакеты MPEG-2 (до 7 в одном IP-пакете), но могут использоваться и другие транспортные форматы, например SDI.
PRO MPEG FEC
Система помехозащиты PRO MPEG FEC работает следующим образом. Пакеты выстраиваются в матрицу N*M, последовательно заполняя ряд за рядом, а затем для каждого ряда и для каждой колонки вычисляются помехозащитные коды. Коды в колонках защищают от разовых потерь, а коды в столбцах — от групповых. Степень защиты регулируется размерностью матрицы. В последней версии помехозащитного кода Pro-MPEG CoP #3 FEC добавлена возможность формирование матриц не из последовательных пакетов, а из периодически выбираемых из потока. Это повышает устойчивость к групповым ошибкам без увеличения объема контрольной информации, которая в среднем составляет около 30%.
Протокол RTP работает на базе UDP, но дополнительно передает информацию о порядковых номерах пакетов. Это позволяет восстановить порядок следования пакетов и выявить пропажи. Но для восстановления пакетов требуются дополнительные механизмы. Один из них —помехоустойчивое кодирование средствами PRO MPEG FEC. Достоинство этого метода заключается в низкой вносимой задержке, обусловленной только дополнительными вычислениями. Она составляет от 100 до 500 мс. Тем не менее помехоустойчивое кодирование хорошо подходит только для каналов с прогнозируемым или более-менее стабильным уровнем потерь, таких как вещательные. В условиях непредсказуемости состояния транспортного канала PRO MPEG FEC неэффективен. При плохом канале он может не сработать, а при хорошем — неоправданно загрузить линию передачей ненужных контрольных бит. Поэтому PRO MPEG FEC в основном используется для переброса с одной головной станции на другую, при сомнительном качестве выделенного IP-канала или при передаче по спутниковому каналу в IP-формате, где отсутствует обратная связь. Рассматривать это решение как надежный и эффективный способ доставки через открытый интернет нельзя.
Полноценные технологии на базе RTP для доставки видео через открытый интернет включают комплекс механизмов защиты от потерь. До недавнего времени в сегменте профессиональной доставки предлагались только корпоративные решения. Самое известное из них — от компании ZIXI. Им пользуется множество крупных студий и операторов. Это закрытое решение, и подробности его технической реализации неизвестны. Производитель сообщает только, что в технологии используется комбинация адаптивного помехоустойчивого кодирования, системы восстановления пакетов (Automatic Repeat reQuest, ARQ), параллельной доставки по нескольким каналам и бесшовного переключения при сбоях с одного канала на другой. Эти инструменты могут применяться в разных сочетаниях в зависимости от требований к параметрам передачи. Если приоритетна скорость доставки, то, по словам разработчиков, платформу несложно настроить так, что прохождение потока будет занимать менее секунды вне зависимости от расстояния между передатчиком и приемником. А при другой конфигурации платформа может гарантировать надежность доставки 99,9999 % в отношении джиттера и потерь. Этот показатель подтвержден тестами. Скорость доставки при такой надежности падает, но по-прежнему может составлять конкуренцию вещательным сетям. Использование ARQ позволяет оператору точно задать уровень задержки из диапазона, достижимого при требуемой надежности, например чтобы синхронизировать поток с другим, передаваемым по вещательному каналу. Платформа поддерживает конфигурации точка—точка или точка—многоточка.
Похожее решение предлагает компания VideoFlow. Оба они многократно проверены на практике и востребованы на рынке, так как расценки на них сопоставимы со стоимостью спутниковых каналов с такой же пропускной способностью.
Помимо них на рынке есть множество других решений для профессиональной доставки видео через интернет. Это протокол LRT разработки LiveU, платформа MultiPipe компании QARVA, Transporter от компании «Майкроимпульс». Большинство из них обеспечивают надежность работы за счет использования ARP и разбиения одного логического канала на несколько потоков с отправкой по разным маршрутам.
Но в любом развивающемся сегменте рано или поздно появляется потребность в индустриальных стандартах.
Протокол SRT
Первым общеотраслевым решением стал протокол SRT. Он был разработан компанией Haivision и исходно создавался ею для интеграции в кодеры и декодеры собственного производства. Однако потом было решено выложить спецификацию в открытый доступ. Протокол был опубликован в 2017 году и тогда же был основан Альянс SRT. Это придало стандарту статус индустриального, и безлицензионная технология SRT вскоре была взята на вооружение многими разработчиками аппаратуры. Сегодня число членов альянса перевалило за две сотни.
В отличие от большинства других систем, SRT не поддерживает множественные потоки передачи, и основная система восстановления пакетов, заложенная в протоколе, это ARP. Из функций SRT можно отметить возможность мультиплексирования, то есть организации нескольких SRT-соединений на одном UDP-порте, поддержку AES-шифрования, а также наличие трех режимов установления соединения: вызова, прослушивания и рандеву. В режиме вызова принимающая сторона отправляет запрос на получение информации от получателя, в этом случае общедоступный IP-адрес и открытый UDP-порт нужен только на передающей стороне. В режиме прослушивания инициатива принадлежит передатчику, а общедоступный IP и открытый UDP-порт требуется только на приемной стороне. Причем благодаря возможности мультиплексирования одного открытого порта достаточно даже при передаче множества SRT-потоков. Это упрощает конфигурирование системы. Режим рандеву предназначен для налаживания соединения между двумя сетевыми экранами или при размещении распределительного SRT-узла в облаке.
ARQ
В системах профессиональной доставки обычно используется протокол RTP в сочетании с системой Automatic Repeat reQuest (ARQ). При использовании ARQ приемник отправляет не подтверждение получения пакетов, а только запрос на повторную отправку неполученных. Причем окно для повторной отправки задается не сетевыми средствами, а оператором. Таким образом, по сравнению с TCP связка RTP/ARP позволяет увеличить скорость передачи и дает оператору возможность самому задать соотношение между скоростью и надежностью передачи. А по сравнению с PRO MPEG FEC, ARP дает большую задержку, но зато гораздо лучше работает в условиях непредсказуемого состояния канала.
Протокол RIST
Через год после появления Альянса SRT компании, имеющие корпоративные решения в области IP-доставки, создали еще один альянс для разработки более продвинутой технологии. Новый протокол получил название Reliable Internet Stream Transport (RIST), как и сам альянс. Он организован в рамках консорциума Video Services Forum, занимающегося разработкой и стандартизацией сетевых технологий для передачи медиа. К слову, в этот альянс в качестве ключевого участника входит и Haivision.
RIST задуман как многопрофильный стандарт, однако пока выпущен только базовый профиль. По функциональности он уступает SRT. В частности, не поддерживает мультиплексирование каналов на одном UDP-порту и имеет только один режим установления соединения (Push). В результате для передачи каждого потока приходится открывать по UDP-порту на приемнике и на передатчике. Кроме того, в отличие от SRT, базовый профиль RIST не поддерживает шифрование и файловую передачу. В то же время в протокол заложена передача множественных каналов. Она реализована в двух режимах. Один поддерживает разбиение логического канала на несколько физических, отправляемых разными маршрутами. Второй обеспечивает резервирование потоков и бесшовное переключение с одного на другой.
А схожи SRT и базовая версия RIST в том, что оба используют ARQ с настраиваемым соотношением между задержкой и защищенностью. Кроме того, они практически одинаковы в плане мониторинга потоков и сбора статистики. Однако у RIST есть все шансы опередить конкурента. Уже подготовлен основной профиль протокола, и живую демонстрацию его работы можно было увидеть на IBC-2019. При разработке профиля учитывались разные сценарии его применения, в том числе дистанционные интервью, сбор новостей из удаленных точек, передача видео в облако и передача мультикастовых трансляций.
Перечислим основные усовершенствования, появившиеся в этом профиле. Во-первых, добавилась поддержка мультиплексирования потоков на одном UDP-порту. Во-вторых, реализовано GRE-туннелированние (Generic Routing Encapsulation). GRE-шлюзы могут использоваться для организации двухстороннего обмена между RIST-устройствами базовой версии, умеющими взаимодействовать только в режиме Push. Шлюзы также могут применяться для передачи управляющих данных, например SNMP, для туннелирования мультикастового трафика и решения других задач. В-третьих, добавлены механизмы скремблирования, авторизации и аутентификации. Для скремблирования и авторизации выбран протокол DTLS, другими словами, версия TLS для UDP-протокола. Она адаптирована для приложений, чувствительных к временным задержкам. В рамках TLS могут использоваться разные алгоритмы шифрования, но в качестве основных для RIST предложены AES 128/256 бит.
Из других улучшений отметим оптимизацию транспортной полосы за счет исключения нулевых пакетов. Они не несут информации, но нужны для сохранения синхронизации. Поэтому перед передачей они заменяются метками и восстанавливаются на приемной стороне. Кроме того, добавлена возможность расширить заголовок RTP для увеличения цикла нумерации пакетов. Эта нумерация используется в ARQ при запросе потерянных пакетов, а при высокой скорости передачи стандартного цикла может не хватить.
Перспективы сосуществования SRT и RIST пока непонятны. С учетом того, что Haivision оказался одним из основных участников RIST, не исключен вариант слияния протоколов. Но может быть, каждый из них найдет свою нишу. Ясно одно — транспортные технологии для передачи видео через IP-сети с негарантированным качеством будут и дальше активно развиваться, а их доля во всех сегментах передачи медиа будет расти.
_________________________