При этом используются разные протоколы и стандарты, описанные в техническом документе BBC «A scalable distribution system for broadcasting over IP networks», который лег в основу данного материала.
Рассмотрим особенности каждого типа сетей. Пропускная способность администрируемых сетей и загрузка их каналов контролируются оператором, которому также известны возможности всех сетевых устройств. Это упрощает передачу медиа по администрируемым сетям и делает ее более предсказуемой, чем в открытом Интернете. В администрируемых сетях широкое распространение получил протокол DVB-IPTV, определяющий способ передачи по IP однопрограммных транспортных потоков MPEG-2 TS.
Стандарт DVB-IPTV
Однако пакеты MPEG-2 TS разрабатывались для вещательных сетей и не оптимальны для IP-среды. Они предназначены для переноса видео по каналу связи, квазисвободному от ошибок, и предполагают использование тактового сигнала, жестко синхронизированного с вещательным источником. В то же время IP-сети имеют другие параметры надежности передачи данных. Они пакетнокоммутируемы, и чтобы эффективно взаимодействовать с сетевыми протоколами нижнего уровня, пакеты мультиплексируются в транспортные потоки асинхронно. Это может приводить к перегрузке линий, задержкам, джиттеру и даже к потерям — в случае перегрузки буферов памяти сетевых устройств. При этом предполагается, что транспортный протокол более высокого уровня обнаружит потерю пакетов и позволит их восстановить, если этого требует конкретное приложение.
Для передачи одного потока множеству ресиверов одновременно применяется технология multicast, которая поддерживается большинством современных маршрутизаторов. Однако пока IP-multicast широко используется только с одним протоколом транспортного уровня, а именно UDP (User Datagram Protocol), имеющим только рудиментарные механизмы выявления ошибок и восстановления данных.
Для частичного преодоления этих недостатков спецификация DVB-IPTV предписывает использование протокола RTP (Real-time Transport Protocol). Он поддерживает функции, отсутствующие в UDP, в частности нумерацию последовательности пакетов и присвоение им временных меток, позволяющих восстанавливать временную синхронизацию в приемнике. Кроме того, спецификация предписывает использование аудиовизуального профиля RTP, исходно разработанного для телеконференций, и формат полезной нагрузки, позволяющий передавать до семи пакетов MPEG-2 TS в одной IP-датаграмме.
Чтобы обойти принципиальную ненадежность IP-сети, DVB-IPTV также предписывает использование FEC (Forward Error Correction) и хорошо масштабируемый сервис повторной передачи, позволяющий отдельным приемникам запрашивать потерянные RTP-пакеты.
Вторая категория сетей — это ОТТ, подразумевающая передачу данных через открытый Интернет. Наложенная (Over the Top) инфраструктура в значительной мере позволяет компенсировать неопределенность поведения сети. Но так как неопределенностей в Интернете значительно больше, чем в администрируемых сетях, то для ОТТ разрабатываются специальные технологии передачи.
Стандарты OTT-стриминга
OTT-медиастриминг изначально был основан на корпоративных стандартах. Обычно в них использовался формат unicast в сочетании со стандартными протоколами передачи и управления медиапотоками, в том числе RTP и RTSP.
Выбор unicast объясняется тем, что multicast поддерживают не все сетевые устройства. Это резко усложняет масштабирование услуг, так как в этом случае либо головная станция должна иметь возможность тиражирования потоков, либо для этой цели в распределительной сети должны быть установлены специальные прокси-серверы. Ни то, ни другое не является оптимальным решением.
Другим фактором, тормозящим успешное развитие технологий первого поколения, была ограниченная доступность клиентских плееров для приема сервисов на разных платформах.
Еще одна проблема первых стриминговых технологий — предоставление клиенту потока с фиксированной скоростью передачи. Даже если технология предусматривала формирование нескольких потоков, выбор оптимальной скорости выполнялся в начале сессии и затем уже не менялся. При улучшении состоянии канала в процессе передачи скорость оказывалась ниже возможной, а ухудшения были чреваты заторами. Ненадежность IP-сетей, особенно потеря пакетов, случающаяся из-за заторов трафика, могут вызывать остановку воспроизведения и перезагрузку из-за попыток клиента заново заполнить буфер памяти. Клиентское приложение может застраховаться от таких проблем, откладывая начало воспроизведения, но временной запас не может быть «длиною в жизнь», особенно в онлайн-трансляциях.
Адаптивный стриминг
Колебания пропускной способности каналов особенно заметны в беспроводных сотовых сетях, и неслучайно адаптивный стриминг начал развиваться одновременно с массовым распространением смартфонов. Суть адаптивного стриминга заключается в том, что потоки готовятся с несколькими вариантами скоростей и клиент может динамически переключаться на оптимальный вариант с учетом текущего состояния канала. Чтобы картинка сохраняла непрерывность в условиях динамической адаптации к состоянию канала, необходимо согласовать точки переключения между потоками.
Появился ряд корпоративных технологий, в которых адаптивный стриминг сочетается с применением HTTP. Наибольшее распространение получила технология HTTP Live Streaming (HLS) от Apple. Изначально потоки там сегментировались в форме пакетов MPEG-2 TS, что определяло точки и механизм переключения с одного потока на другой. В системах Smooth Streaming от Microsoft и HTTP Dynamic Streaming (HDS) от Adobe используются фрагментированные MP4-файлы (формальное название ISO Base Media File Format). Перечисленные компании вместе с консорциумом 3GPP разработали стандарт динамического адаптивного стриминга, в который вошли различные механизмы, заложенные в корпоративных технологиях. Этот стандарт появился в начале 2015 года и получил название MPEG-DASH. А еще через год консорциум MPEG стандартизировал контейнер на базе фрагментированных MP4-файлов. Стандартизированный вариант получил название Common Media Application Format (CMAF). Заметим, что CMAF используется не только в MPEG-DASH, он был принят и в качестве одного из контейнеров для HLS. Это обещало сильно упростить сосуществование этих двух технологий, так как позволило упаковывать видео- и аудиопотоки в одинаковые контейнеры. Казалось бы, HLS и MPEG-DASH должны теперь различаться только файлами, описывающими компоненты потока и их место в структуре. Однако разработчики HLS и DASH не смогли договориться об использовании общего метода скремблирования видео. В результате сегодня существует два варианта Common Encryption, один из них используется в DRM PlayReady и WideWine, а второй — в FairPlay от Apple. Без решения этой проблемы общие транспортные потоки можно создать только для открытого контента.
Для всех технологий второго поколения характерно использование стандартных аудио- и видеокодеков, таких как H.264 AVC и AAC, которые аппаратно декодируются современными мобильными устройствами. Пока не очень понятно, станет ли H.265/HEVC столь же повсеместно распространенным стандартом или интерес к кодекам без лицензионных отчислений, таким как VP9, ограничит его применение. Распространение разных кодеков пока вынуждает желающих доставлять контент на все устройства готовить потоки с разным форматами сжатия.
Еще одна проблема, связанная со снижением эффективности использования TCP-окна при передаче на большие расстояния, была решена организацией кэширующих серверов, размещаемых ближе к пользователям.
Кэширование стало целесообразным после того, как все технологии перешли на протокол HTTP и его стали поддерживать все элементы цепочки передачи. Для должного масштабирования услуги сторонние CDN обычно устанавливают кэширующие серверы в магистральной сети интернет-провайдеров и берут плату за передаваемые объемы с контент-провайдеров.
Некоторые крупные контент-провайдеры устанавливают собственные кэширующие серверы — это позволяет им напрямую контролировать и качество услуг, и стоимость их распространения.
Стандарты multicast-стриминга
Когда один поток должен быть доставлен множеству приемников, multicast позволяет сделать этот процесс в CDN более эффективным, так как тиражирование может выполняться низкоуровневыми протоколами, реализованными в сетевых маршрутизаторах, а не высокоуровневыми приложениями.
IETF (Internet Engineering Task Force) создал подборку механизмов для надежной доставки стримингового медиа через multicast — IP-сети. Учитывая, что разные приложения требуют разных условий передачи, рабочая группа Reliable Multicast Transport регламентировала набор составных элементов multicast-протоколов, которые могут разными способами комбинироваться между собой. Она также разработала инструкции по формированию протоколов из этих составных элементов. Эти решения технически сильные, но сложны для качественной реализации. Кроме того, они отличаются от решений на базе HTTP, которые поддерживаются всеми веб-браузерами. И, в довершение всего, необходимые механизмы поддерживают не все маршрутизаторы. Тем не менее отдельные готовые протоколы уже внедрены в некоторые платформы.
Можно выделить три таких протокола:
• Asynchronous Layered Coding (ALC) — обеспечивает надежность передачи за счет применения FEC.
• File Delivery over Unidirectional Transport (FLUTE) — использует ALC для доставки карусели файлов через multicast.
• NACK-oriented Reliable Multicast (NORM) — еще один протокол, использующий сигнализацию о потере данных, поступающую от приемника, с поддержкой multicast. В качестве опции он поддерживает и FEC.
Протокол NORM включен в открытую спецификацию CableLabs «Multicast-assisted adaptive bit rate» для сетей КТВ. Flute вошел в состав Multimedia Broadcast/Multicast (MBMS) и может использоваться для доставки MPEG-DASH по сетям LTE. Кроме того, версия FLUTE под названием ROUTE включена в стандарт цифрового эфирного телевидения ATSC 3.0 в качестве протокола multicast-доставки пакетов MPEG-DASH.
Работа над поисками оптимальных алгоритмов доставки медиаконтента продолжается. Возможности современных устройств воспроизведения позволяют экспериментировать с вариантами разбиения медиапотоков на составные части и их доставки абонентам. Однако задача масштабирования доставки, особенно когда речь идет о живых трансляциях, остается проблематичной и требует продвинутых решений, усложняющих всю инфраструктуру.
_________________________Подпишитесь на канал «Теле-Спутника» в Telegram: перейдите по инвайт-ссылке или в поисковой строке мессенджера введите @telesputnik, затем выберите канал «Теле-Спутник» и нажмите кнопку +Join внизу экрана.
