Адаптивный битрейт что это
Технологии адаптивного вещания
В предыдущей статье я поверхностно рассмотрел общие принципы работы адаптивного вещания. В этой статье рассмотрю отдельно каждую из представленных технологий адаптивного вещания, а также расскажу с какими проблемами столкнулась компания Telebreeze при начале использования адаптивного вещания.
В общем-то их не так много, и вы сами уже догадываетесь какая первая – конечно, это Apple HTTP Adaptive Streaming (HLS).
1. Apple на славу постарался и уже относительно давно использует данную технологию на всех своих устройствах (операционные системы IOS и Mac), а также поддерживается последними версиями Android и большинством ТВ приставок.
HLS от компании Apple один из самых распространенных HTTP протоколов передачи видео, который уже доказал свою надежность и прошел проверку временем.
Конечно не идеально в нашем мире, но Apple как всегда на высоте. Вы не подумайте я не фанат Apple, я просто стараюсь судить объективно.
Итак, немного слов о передаче видео и аудио сигнала: Видеосигнал упаковывается в контейнер MPEG-2 TS, и используются весьма распространенные кодеки MPEG H.264 (видео) и AAC (аудио). Кодируется видео с разным битрейтом на выходе, и в итоге получается плейлист в формате m3u8. Для защиты контента от неавторизированного доступа, используется алгоритм AES-128, которые может зашифровать контент, передаваемый по HLS.
Вот так можно описать всю технологию Apple HTTP Adaptive Streaming (HLS).
2. Теперь рассмотрим не менее популярную технологию адаптивного вещания от компании Microsoft – Smooth Streaming.
Smooth Streaming это протокол, который поддерживается видеоплеером Silverlight, а также естественно операционными система Windows и Windows Phone.
Что такого есть у Microsoft, чего нет у Apple, или какими преимуществами обладает Smooth Streaming перед HLS. Хотя об этом можно поспорить, так как это сравнительно разные подходы к адаптивному вещанию, но все давайте рассмотрим в проекции одного направления. Самое большое преимущество — это более универсальный и расширяемый формат файла-манифеста (xml). Более меньшим преимуществом является то, что все сегменты видео упаковываются в самый распространенный на данный момент времени контейнер MP4.
Видео и аудио сигнал сначала сегментируются, а затем упаковывается в как говорилось выше в контейнер MP4 и распространяются по HTTP через web server и CDN. Используются кодеки H.264 (видео) и AAC (аудио).
В целом Windows продвигают свою концепцию весьма успешно, что говорит об их конструктивной конкуренции с Apple.
3. Вот мы и добрались до Adobe HTTP Dynamic Streaming (HDS), который является еще одним вариантом адаптивного вещания.
Как понятно из названия, данная технология создана компанией Adobe и поддерживается практически на любом персональном компьютере в мире.
Принцип работы похож на другие адаптивные системы HTTP-технологии. В связи с этим особые преимущества выделить сложно, можно только сказать, что HDS поддерживает только одну DRM-систему – Flash Access.
4. Еще хотелось бы рассмотреть тему Общего Стандарта Адаптивного Вещания.
Большая проблема на данный момент, которая стоит перед вещателями это постараться поддержать максимально возможное число решений на различных устройствах своих клиентов и использовать разные технологии. Это затратно и не всегда удобно.
И вот тут возникает потребность повсеместного внедрения единого стандарта вещания видео. Таким стандартом призвано стать MPEG-DASH (Dynamic Adaptive Streaming over HTTP), разработанный MPEG-LA и ISO, который они запустили в прошлом году.
Его можно назвать самым универсальным и совершенным протоколом вещания. У него есть использования манифест-файлов (xml) у Smooth Streaming, также присутствует поддержка большинства форматов контейнеров, и интеграция с UltraViolet (DRM-система), которая работает по принципу “Buy once, play it anywhere”. UltraViolet даст единую среду для кодирования всех устройств.
Каким бы универсальным ни была эта технология, и как бы она не продвигалась мировыми организациями-стандартизаторами, его внедрение ожидается в отдаленной перспективе. 
С какими же проблемами может столкнуться разработчик при реализации адаптивного вещания?
Одна из них – это какой же длины должен быть тот самый сегмент видео, который передается в потоке, и сколько должно быть таких вариантов потоков.
Если делать сегмент видео излишне коротким, то возрастает бесполезное расходование трафика. Почему так происходит, а потому что в каждом сегменте помимо видео сдержится так называемый overhead. В итоге получается, чем больше сегментов, тем больше и overhead, и именно это бесполезно расходует трафик.
Но здесь есть и обратная сторона медали, если делать сегмент видео слишком длинным, то качество сервиса снизиться в несколько раз, потому что пользователю придется ждать смены качества.
Универсального решения проблемы нет, так как баланс в этом случае находиться только методом проб и ошибок.
Параметры профилей кодирования будут зависеть от технологии адаптивного вещания, а также от страны и региона. И здесь длина сегмента и количество потоков должны подбираться под каждый соответствующий случай.
Мы, Telebreeze Corporation, используем HTTP Adaptive Streaming (HLS). У этой системы есть ряд положительных моментов, в так же ряд проблем. Обо всем этом я расскажу в следующей статье.
Итак, краткие итоги: Каждая представленная технология имеет свои преимущества и конкурирует друг с другом, что должно положительно сказаться на развитие такого молодого направления как адаптивное вещание, ведь всем известно, что конкуренция двигатель прогресса.
Хранение видео в Yandex.Cloud
Если вам нужно добавить на свой сайт видео, то может возникнуть вопрос, где его хостить и как потом раздавать. В этом посте разберем варианты и рассмотрим примеры использования Yandex Object Storage.
Формат MP4 знаком, наверное, всем. Но если мы хотим показывать видео на сайте эффективно, то стоит задуматься: лучшее ли это решение для нашей задачи — просто выложить все видео одним файлом MP4?
Протокол HLS (HTTP Live Streaming) был предложен в 2009 году и к настоящему времени де-факто стал стандартом в области адаптивного видеостриминга.
HLS был разработан Apple как замена их собственной разработки QuickTime Streaming Server, а также как альтернатива другому популярному на тот момент протоколу — Real-Time Messaging Protocol (RTMP). Этот протокол, выпущенный Adobe в 2002 году, использовал технологию Flash, чтобы передавать видео с низкой задержкой через интернет. Не смотря на то, что Flash давно «умер», RTMP до сих пор остается популярным протоколом для видеотрансляций.
Что же такое HLS?
Хотя HLS не так широко известен, но он, наряду с MPEG-DASH и SRT, остается одним из главных протоколов, которые обеспечивают доставку видео- и аудиоконтента в современном интернете. Велики шансы, что вы пользуетесь им каждый день, даже не задумываясь об этом. Особенно если вы — пользователь экосистемы Apple.
Хотя HLS и был разработан в Apple, он широко поддерживается и на других платформах: Linux, Windows, смартфонах с Android и iOS, OTT-устройствах, Smart TV, а также в браузерах Google Chrome, Safari, Android Browser, Microsoft Edge, Chrome for Android и Opera Mobile. На части платформ поддержка нативная, в других же она реализована через JS-плееры.
Тот факт, что потоковая передача HLS обычно осуществляется через видеоплеер HTML5, делает HLS универсальным и широко совместимым. Его часто называют «HTML5-видео», что не совсем точно. Видеоплеер HTML5 просто совместим с HLS.
Что значит «протокол»?
HLS — это протокол потоковой передачи видео. Но что это означает? Возможно, вы слышали термин «кодек», но важно отметить, что потоковый протокол — это не кодек. Протокол — это более широкая категория.
Потоковый протокол — это стандартизированный метод передачи видеоконтента между устройствами. Протокол может предполагать использование определенного кодека (или кодеков), который будет использоваться для сжатия и распаковки видео- и аудиоконтента.
Например, HLS поддерживает множество популярных кодеков:
Audio: AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, Apple Lossless, FLAC
Video: H.265, H.264
Преимущества HLS
HLS предназначен для обеспечения надежности и динамической адаптации к сетевым условиям путем оптимизации (т. е. ухудшения или улучшения) воспроизведения видео для доступных скоростей интернета. Кроме того, он «заботится» о разных аспектах, которые связаны с доставкой видеоконтента зрителям:
Стриминг с адаптивным битрейтом (Adaptive Bitrate Streaming) — HLS подстраивает качество видео под текущую скорость интернет-канала. Это позволяет авторам предлагать несколько видеопотоков в разном качестве, а плееру переключаться между ними незаметно.
Пример среднего битрейта видео (Кбит/с), источник: Apple
Совместимость со многими устройствами — HLS гарантирует, что ваш видеоконтент будет воспроизводиться на любом устройстве, которое может запустить совместимый плеер (например, HTML5).
Субтитры — HLS поддерживает скрытые субтитры. Это позволяет авторам встроить несколько потоков субтитров (например, на разных языках).
Возможность менять аудио дорожку — HLS поддерживает несколько потоков аудио, между которыми можно переключаться.
Возможность вставлять рекламу — HLS использует для этого технологии VPAID и VAST.
Масштабирование — HLS обладает высокой масштабируемостью для доставки видеофайлов и потокового контента через глобальные сети доставки контента (CDN). В отличие от протокола RTMP, который работает совместно с Flash Player, HLS может легко масштабироваться для доставки с помощью обычных веб-серверов через CDN. Распределяя рабочую нагрузку по сети серверов, CDN приспосабливаются к всплескам вирусной аудитории и гораздо большим, чем ожидалось, живым аудиториям. CDN также помогают улучшить качество просмотра, кешируя аудио- и видеосегменты. Для сравнения, поддержка CDN для RTMP быстро снижается. RTMP также требует использования выделенного сервера потоковой передачи, что делает его более ресурсоемким для развертывания.
Защита от пиратства — реализуется через поддержку большого количества технологий DRM.
Вот более подробный пост про то, как можно ограничить доступ к видео при помощи шифрования AES-128.
Недостатки HLS
HLS имеет некоторые ограничения, но они связаны с конкретными проектными решениями, которые были приняты при разработке протокола.
Часть этих ограничений связана с задержкой. HLS ставит во главу угла комфорт пользователя, а не низкую задержку, поэтому live-контент, который транслируется с использованием протокола HLS, не является достаточно «живым». Зритель увидит его с задержкой до 30 секунд. Таким образом, HLS — не лучший выбор для таких приложений, как веб-конференции или управление устройствами, где необходимо видео в реальном времени (камеры и дроны). В этом случае лучше использовать более быстрый потоковый протокол, например WebRTC (Web Real-Time Communications).
Задержка в HLS возникает из-за того, что протокол разбивает видео на множество многосекундных фрагментов (сегментов), которые обычно имеют длительность 2–6 секунд. И поскольку протокол HLS также должен буферизировать несколько таких небольших сегментов одновременно, задержка может составлять десятки секунд. Однако если задержка или плохие сетевые условия не являются проблемой, то HLS — это протокол, который вам нужен.
Итак, почему стоит использовать именно HLS?
С HLS создатели контента могут подготовить версии своего видео для нескольких различных интернет-каналов и условий воспроизведения: 3G, 4G, LTE, медленный публичный Wi‑Fi, быстрый домашний интернет.
Различные поставщики CDN постепенно отказываются от поддержки RTMP, заявляя, что его развертывание становится слишком дорогим. Вместо этого набирают популярность такие протоколы, как HLS, SRT и MPEG-DASH.
Adobe перестал поддерживать технологию, на которую опирается RTMP. Поэтому однажды ваш процесс потоковой передачи RTMP станет технологически устаревшим и потеряет поддержку со стороны производителя. Это лишь вопрос времени.
HLS оптимизирует доставку аудио и видео на обширный спектр мобильных, настольных, планшетных и OTT-устройств.
HLS позволяет доставлять видео по запросу с помощью шифрования и аутентификации.
HLS значительно снижает затраты на CDN. При этом он обеспечивает только оптимальный битрейт для клиентской сети и избегает сценария «частичного воспроизведения и полной загрузки», который присущ прогрессивной потоковой передаче HTTP. Например, когда всё видео представлено одним файлом MP4.
Apple App Store требует, чтобы приложения с десятиминутным (и более) видео использовали HLS.
Практическая часть
Надеюсь, я смог вас убедить, что сегодня для распространения видеоконтента через интернет стоит смотреть в сторону HLS.
Давайте теперь на примере рассмотрим способ, как нам использовать объектное хранилище в Yandex.Cloud.
Object Storage — это решение для хранения больших объемов данных за относительно небольшие деньги. Оно идеально подходит для чего-то вроде видеофайлов, которые, как правило, имеют довольно большой объем. Доступ к файлам (или объектам, как их часто называют) осуществляется через HTTP(S), что делает Object Storage отличным решением для хранения и обслуживания ваших HLS-видео.
Для начала нам понадобится бакет в хранилище. Если у вас его нет, то вот инструкция, как его создать.
Подготовка видео
Если у вас уже есть видео в формате HLS, то смело переходите к следующему разделу.
Если же его нет, то вам понадобится утилита ffmpeg, при помощи которой вы сможете конвертировать видео и аудио во множество форматов, в том числе HLS.
Установка ffmpeg
Скачайте последнюю версию отсюда.
Откройте консоль в папке.
Выполните команду brew install ffmpeg
Вызовите ffmpeg — вы должны будете увидеть информацию о версии ffmpeg.
Видео для примера
Возьмем какой-нибудь видеофайл и посмотрим информацию о нем:
В консоли появится приблизительно следующее:
Конвертация
Подготовим команду для конвертации видео:
Теперь подробно разберем, что означают все эти ключи:
-i sample.mp4 — задает sample.mp4 в качестве входного файла.
-vf «scale=w=1280:h=720:force_original_aspect_ratio=decrease» — масштабирует видео до максимальных размеров в пределах заданного разрешения 1280×720 с сохранением соотношения сторон.
-ac:a:0 2 — указывает, что если в первом аудиопотоке (a:0) больше двух каналов, нужно смиксовать их в стереосигнал.
-profile:v main — устанавливает профиль кодека H.264 в main (это означает включение поддержки всех современных устройств). Подробнее в статье.
-crf 20 — Constant Rate Factor, высокоуровневая настройка качества.
2 сек) — это важно, влияет на корректную нарезку на сегменты.
-sc_threshold 0 — не создавать ключевые кадры при смене сцены.
-hls_time 4 — указывает длину сегмента в секундах. Реальная длина будет зависеть от ключевых кадров.
-hls_playlist_type vod — добавляет тег #EXT-X-PLAYLIST-TYPE:VOD и сохраняет все сегменты в плейлист.
-hls_segment_filename sample/720p_%03d.ts — явным образом задает имена файлов для сегментов.
Утилита ffmpeg поддерживает несколько входных и выходных файлов и все результаты могут быть сгенерированы параллельно одной длинной командой.
Очень важно, чтобы помимо параметров разрешения и битрейта команды были идентичны, тогда результаты будут правильно выровнены, то есть ключевые кадры будут установлены в нужных местах, чтобы обеспечить плавное переключение между ними «на лету».
Мы создадим четыре версии с разрешениями:
1080p 1920×1080 (original)
Мастер-плейлист
HLS-плеер должен знать, что существует несколько версий нашего видео, поэтому мы создаем мастер-плейлист HLS, чтобы указать их и сохранить вместе с другими плейлистами и сегментами в файл playlist.m3u8.
Как правильно выбрать битрейт
Битрейт зависит в основном от разрешения и типа контента. При установке слишком низкого битрейта пикселизация изображения будет особенно видна в тех областях, где происходит быстрое движение. Когда битрейт слишком высок, выходные файлы могут быть чрезмерно большими без дополнительного значения.
Чтобы выбрать правильный битрейт, нужно понимать его содержимое. Видео с резкими движениями, например запись спортивных или новостных событий, потребует более высокого битрейта, чтобы избежать пикселизации. А для контента с плавными движениями в кадре, например, музыкального концерта или интервью, будет достаточно низкого битрейта без видимых изменений качества.
Вот некоторые хорошие значения по умолчанию:
Загрузка данных
Настройка бакета
Для того чтобы видеоплееры могли получить доступ к видеофайлам, необходимо указать настройки CORS в бакете.
Это максимально широкое правило для примера.
Все готово
Если вы хотите ограничить круг сайтов, куда можно будет встраивать видео, то прочитайте этот пост.
Теперь можно выкладывать видео на свой сайт.
В пример я добавил минимальный контрол для переключения уровня качества.
Вот использованный плеер и react-обертка. А вот альтернативный плеер.
Итак, в чем же плюс?
Если вы откроете консоль, то увидите, что после того как браузер загрузил несколько первых сегментов видео, загрузка приостанавливается. Это позволяет нам экономить трафик в тех случаях, когда пользователь открыл страницу с видео, начал просмотр видео и остановился. В этом случае нам не нужно загружать весь видеофайл целиком. Мы можем вовремя остановиться, а потом, если это понадобится (пользователь продолжит воспроизведение), загрузить остальное.
Применение технологий адаптивного HTTP-вещания для предоставления услуг OTT
Просмотр телевизионных программ на планшетном компьютере или смартфоне уже не является чем-то необычным и экзотическим, так же, как недавно вошло в нашу жизнь и IPTV. При этом абоненту не важны технические различия в технологиях доставки контента – он просто хочет смотреть любимые фильмы, видеозаписи и телепередачи где угодно, когда угодно и на любом устройстве, будь то планшет, смартфон или телевизор с сеттоп-боксом.
К сожалению, с точки зрения операторов ситуация выглядит несколько сложней. В традиционном IPTV сервер отправляет клиенту видео поток фиксированной пропускной способности. Протоколом транспортного уровня, как правило, является UDP или RTP, при этом большие значения джиттера и потери пакетов приводят к значительному ухудшению качества изображения. Более того, прохождение UDP/RTP-пакетов через межсетевые экраны в большинстве случаев затруднено, что делает невозможным использование данных протоколов для вещания IPTV-каналов через открытые (не принадлежащие одному оператору) сети.
Указанные ограничения не позволяют применять традиционные схемы IPTV-вещания для предоставления новых услуг – Television-Over-The-Top (OTT) и Multiscreen Delivery (вещание одного контента на различные типы оконечных устройств).
Что такое OTT и каковы его отличия от традиционного IPTV можно узнать в этой статье. Здесь упомянем лишь, что основным отличием OTT от IPTV является отсутствие привязки абонента к сети оператора – для просмотра телеканалов по технологии OTT нужны лишь компьютер (сеттоп-бокс), доступ в интернет с определенной пропускной способностью (обычно до 3 Мбит/с) и положительный баланс на счету абонента у OTT-провайдера.
Multiscreen Delivery позволяет пользователям получать доступ к контенту с различных оконечных устройств – персональных компьютеров, сеттоп-боксов, планшетных компьютеров и смартфонов. В общем случае, это может быть реализовано с помощью различных технологий, которые объединяются под одним названием – Adaptive HTTP Streaming (адаптивное вещание поверх протокола HTTP). При этом один входной видео поток преобразуется в несколько выходных, каждый из которых имеет разное разрешение (битрейт) и упакован в определенный контейнер, который затем разбивается на сегменты и передается по HTTP-протоколу. Каждая связка «разрешение + контейнер» предназначена для передачи по каналам с различной пропускной способностью. Например, потоки с низким битрейтом передаются на смартфоны и планшеты, которые обычно подключаются к интернету по относительно низкоскоростным беспроводным каналам и обладают небольшими ресурсами для декодирования, а потоки с большим битрейтом и высоким разрешением передаются на компьютеры и сеттоп-боксы, при этом битрейт потока может адаптивно изменяться в зависимости от доступной полосы пропускания или нагрузки на ЦП приемного устройства.
Основные области применения Multiscreen Delivery и Adaptive HTTP Streaming – это VOD и OTT, поэтому и рассматривать данные технологии следует совместно.
Общая информация о технологиях адаптивного HTTP-вещания
Рассмотрим цепь доставки контента от головной станции до абонента при организации услуг OTT (рисунок 1).
Прием
Прием каналов может выполняться из разных источников: спутники, наземное цифровое и аналоговое вещательное телевидение и т.д. На выходе головной станции (ГС), как и в традиционном IPTV, имеются MPEG-2 TS over IP multicast-потоки, передаваемые поверх UDP или RTP. Потоки на выходе ГС, как правило, сжаты с использованием различных кодеков и имеют разное разрешение.
Транскодирование
В данной схеме транскодеры выполняют функции изменения параметров входных потоков для совместимости с оконечными устройствами пользователей, а также подготавливают потоки к сегментации. Для этого транскодеры должны выполнять транскодирование входного видео потока с несколькими выходными профилями (как правило, для совместимости с большинством существующих технологий адаптивного HTTP-вещания, видеосигнал в выходном потоке должен быть сжат кодеком H.264).
С целью гибкой адаптации к изменяющимся параметрам передачи для каждого входного сигнала энкодер должен генерировать как можно больше выходных потоков с различным битрейтом (как правило, хватает 4, но их количество может быть увеличено до 16). В таблице 1 приведены скорости потоков с разным разрешением (ориентировочный битрейт указан для кодека H.264):
Кол-во точек по
горизонтали
Кол-во точек по
вертикали
Ориентировочный битрейт
видео потока*
*Примечание: битрейт потока зависит от разрешения видео, профиля и уровня сжатия, а также от реализации самого энкодера
На выходе транскодеров имеется по несколько (как правило, по 4) «копий» каждого входного потока, сжатых с различными профилями. Данные потоки передаются в традиционном контейнере MPEG-2 TS over IP поверх протоколов UDP или RTP.
«Упаковка» в контейнеры
«Упаковку» сигналов в контейнеры, определяемые технологией доставки контента на оконечные устройства пользователей (см. далее), осуществляет специальное устройство – Packager. Помимо «упаковки», Packager должен поддерживать следующие функции:
• Шифрование выходных сегментированных потоков с помощью DRM-системы, совместимой с определенной технологией доставки контента;
• Возможность использования в качестве исходных сигналов как live-потоков (для организации услуг OTT), так и отдельных файлов (для организации услуг VOD).
Packager принимает потоки от транскодера, извлекает из контейнеров MPEG-2 TS полезную информацию и инкапсулирует ее в контейнеры, определяемые технологиями доставки контента. Затем Packager разбивает каждый выходной поток на сегменты (в оригинале – «chunks»), сохраняет их на диске и присваивает каждому сегменту уникальный URL. Таким образом, каждый сегмент может быть загружен с Packager’а с помощью команды «GET» по протоколу HTTP. Форматы контейнеров, которые используются серверами сегментации и упаковки потоков, рассмотрены ниже.
CDN расшифровывается как Content Delivery Network (сеть доставки контента) и представляет собой совокупность кэширующих серверов, которые принимают (или запрашивают) сегменты всех потоков от Packager’а с одной стороны и терминируют TCP-сессии оконечных пользователей с другой. Сервера CDN располагаются как можно ближе к оконечным пользователям с целью разгрузить опорную сеть от трафика и предотвратить ее перегрузки в часы наибольшей нагрузки, а также обеспечить высокое качество услуг даже при большом количестве абонентов.
Клиент
Как было упомянуто, в качестве оконечных пользовательских устройств могут выступать персональные и планшетные компьютеры, сеттоп-боксы и смартфоны. Очевидно, что данные устройства могут работать под управлением различных операционных систем (ОС). На сегодняшний день, существует 4 основных технологии доставки контента на абонентские устройства через сеть интернет, которые используются разными ОС. Неудивительно, что разработчиками данных технологий являются основные игроки рынка IT-индустрии:
• Компания Apple®, со своим стандартом HLS;
• Корпорация Google™, продвигающая свою технологию WebM;
• Корпорация Microsoft® и ее стандарт Silverlight Smooth Streaming;
• Компания Adobe с технологией HTTP dynamic Streaming.
Данные компании достигли больших успехов в области телекоммуникаций и в интернете, но, тем не менее, на момент написания статьи, ни одна из указанных технологий не стала общепринятым мировым стандартом вещания контента в интернете. Более того, в настоящее время ведется активная разработка технологии MPEG-DASH (см. далее), которая в ближайшем будущем может принять статус стандарта в области телекоммуникаций.
Apple HLS
Компания Apple представила технологию HTTP Live Streaming (HLS) в июне 2009 года в iPhone OS 3.0, что делает HLS старейшей из указанных технологий. На данный момент, HLS является самым распространенным протоколом вещания в интернете и используется всеми устройствами компании Apple (iPhone, iPad, iPod и т.д.), а также некоторыми программами и сеттоп-боксами.
Принцип работы
Компания Apple пошла по пути использования проверенных стандартов цифрового вещания, немного изменив их под нужды вещания поверх сети интернет. HLS работает с сегментированными потоками или файлами, упакованными в контейнер MPEG-2 TS. Для сжатия видео и аудио потоков в HLS используются широко распространенные кодеки MPEG H.264 и AAC соответственно. Ставка здесь сделана на тот факт, что чем меньше изменений будет внесено в существующие стандарты и технологии, тем быстрее будет происходить интеграция HLS в существующие системы.
Процесс организации вещания по протоколу HLS можно представить следующим образом:
1.Выполняется сжатие видео сигнала, полученного с прямой трансляции или из файла, в формат H.264/TS с различным выходным битрейтом (используя различные профили сжатия);
2.Полученный поток сегментируется для получения коротких «кусочков» (в оригинале – «chunks») контента, длиной, как правило, 10 секунд каждый;
3.Генерируется файл-плейлист (в формате m3u или m3u8, см. рисунок 2), который содержит ссылки на каждый сегмент потока;
4.Пользователь выполняет загрузку сначала плейлиста, а затем сегментированного потока с обыкновенного HTTP-сервера.
| #EXTM3U #EXT-X-KEY:METHOD=NONE #EXT-X-TARGETDURATION:11 #EXT-X-MEDIA-SEQUENCE:494 #EXT-X-KEY:METHOD=NONE |
На рисунке 2 изображен пример файла-плейлиста протокола HLS. Плейлист содержит ссылки на 3 последних доступных сегмента. Тэг #EXT-X-MEDIA-SEQUENCE определяет последовательности для первого сегмента (505.ts), которая служит для совмещения отдельных сегментов из потоков с различными битрейтами (при адаптации к полосе пропускания канала). Тэг #EXT-X-TARGETDURATION:11 определяет длительность видео, передаваемого в сегментах (10 секунд); тэг #EXT-X-KEY:METHOD=NONE указывает на то, что сегменты передаются в незашифрованном виде. Тэги #EXTINF:10 несут информацию о длительности каждого сегмента.
Технология HLS позволяет выполнять вещание с адаптивно изменяющимся битрейтом, при этом решение о том, поток какого качества следует загружать в данный момент времени, принимает оконечное оборудование пользователя, а не видео сервер. Решение принимается на основании доступной полосы пропускания, что позволяет передавать через интернет видео с высоким уровнем качества:
1.Для каждого канала или файла генерируется индексный файл (см. рисунок 3) с указанием различных профилей (соответствующих потокам разного качества);
2.Оконечное пользовательское устройство выбирает поток с наиболее подходящим битрейтом на основании того, сколько времени требуется для загрузки одного сегмента;
3.Каждый сегмент содержит 10 секунд видео, поэтому приемное устройство может автоматически с интервалом 10 секунд адаптироваться к изменяющимся параметрам передачи.
| #EXTM3U #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=531475 mystic_S1/mnf.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=381481 mystic_S2/mnf.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=531461 mystic_S3/mnf.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=781452 mystic_S4/mnf.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1031452 mystic_S5/mnf.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1281452 mystic_S6/mnf.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1531464 mystic_S7/mnf.m3u8 #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3031464 mystic_S8/mnf.m3u8 |
На рисунке 3 приведен вариант индексного файла-плейлиста протокола HLS, который содержит ссылки на 8 профилей одного и того же потока/файла.
Поддержка
Стандарт HLS поддерживают все устройства Apple, на которые установлена ОС iOS 3.0 и выше: iPhone, iPad и iPod, а также компьютеры Macintosh под управлением ОС MacOS® X Snow Leopard. Клиенты HLS используют QuickTime® X player, разработанный компанией Apple. Т.к. до сих пор не существует версия QuickTime X Player для Windows, то, фактически, нет «официальных» клиентов для HLS, кроме устройств, выпущенных компанией Apple.
Тем не менее, принципы, положенные в основу функционирования HLS, достаточно просты, поэтому разработать клиентское ПО для HLS-вещания сравнительно нетрудно. Verimatrix, Widevine, NDS, Latens и SecureMedia являются примерами компаний, которые разработали клиентское ПО для воспроизведения видео, передаваемого по стандарту HLS, и интегрировали его в свои DRM-системы.
Кроме того, клиентская часть HLS реализовывается также производителями сеттоп-боксов. Например, компании Airties, Netgem и Amino выпускают абонентские приставки, способные воспроизводить видео, передаваемое с HLS-сервера, а сервер ViaMotion Origin компании Anevia позволяет выполнять вещание видео с использованием данного протокола.
Преимущества
HLS является простым и эффективным решением для организации адаптивного вещания в открытых сетях. Поддержку данного стандарта легко реализовать на приемных устройствах, что способствует его широкому внедрению в будущем.
Многие производители микросхем уже сейчас могут предоставить аппаратные решения для декодирования H.264, что позволяет использовать стандарт в мобильных устройствах благодаря низкому энергопотреблению и небольшой нагрузке на ЦП.
Наконец, использование контейнера MPEG-2 TS значительно упрощает интеграцию HLS в существующие системы цифрового телевидения.
Ограничения
Как отмечено выше, управление битрейтом потока осуществляется исключительно абонентским устройством. Данный «демократический» подход может стать источником некоторых проблем в том случае, если администратор хочет вручную настраивать качество видео для определенного контента.
Встроенная поддержка HLS отсутствует во всех основных WEB-браузерах.
Использование стандартов MPEG влечет за собой необходимость уплаты производителями устройств и ПО лицензионных отчислений, что является барьером для появления ПО с открытым кодом, поддерживающего HLS.
DRM-шифрование применяется к целому сегменту. Это значит, что заголовки транспортного потока MPEG-2 TS также шифруются, что влечет невозможность использования некоторых дополнительных функций.
Наконец, в HLS не существует возможности передавать более одной аудио дорожки в потоке. В iOS5 введена возможность выбора альтернативного потока аудио, однако в данном случае количество аудио дорожек ограничивается двумя, в то время как с помощью технологий Smooth Streaming и MPEG-DASH может передаваться неограниченное количество аудио потоков.
Microsoft Smooth Streaming
Smooth Streaming – это протокол вещания видео контента, который был представлен как расширение технологии Silverlight 3.0. Впервые его спецификации были опубликованы компанией Microsoft в сентябре 2009 года. В качестве видео и аудио кодеков компания Microsoft выбрала H.264 и AAC соответственно с целью обеспечения возможности простого аппаратного декодирования потоков HD-качества (720p/1080p). Тем не менее, Smooth Streaming также совместим с кодеками WMA, SMPTE VC-1, а также всеми остальными кодеками, которые поддерживаются контейнером 3GP.
Принцип работы
Smooth Streaming работает с контейнером PIFF (Protected Interoperable File Format), при этом общие принципы работы протокола весьма похожи на функционирование HLS: видео и аудио информация сжимается с использованием кодеков H.264 и AAC (или VC-1/WMA) соответственно, полученные потоки сегментируются, мультиплексируются в контейнер PIFF и распространяются по протоколу HTTP через web-сервер и CDN.
Для получения видео потока пользователь сначала загружает с сервера файл-manifest в формате XML, в котором содержится информация о доступных аудио и видео дорожках и их битрейте. Затем клиент запрашивает один или более сегментов, которые передаются поверх протокола HTTP. Подобно HLS, управление битрейтом в Smooth Streaming осуществляет клиентская сторона. Однако, в отличие от HLS, где ссылки на сегменты представлены в явном виде в файле-плейлисте, файл-manifest протокола MSS содержит информацию, которая позволяет клиентскому устройству сгенерировать ссылки на сегменты на основании данных синхронизации, содержащихся в потоке. Поэтому при вещании live-потоков клиенту не требуется периодически заново загружать файл-manifest. Ниже приведен формат запроса файла-manifest’а, а на рисунке 4 – его содержание:
В приведенном примере элементы t=”249…” указывают на временные метки сегментов, которые доступны и могут быть загружены с сервера. Данные записи конвертируются во временные метки в ссылках на загрузку сегментов. Загруженные сегменты содержат временные метки одного или двух следующих сегментов, таким образом, постоянное обновление файла-manifest’а не требуется.
При использовании данного протокола с VoD, файл-manifest сразу содержит информацию про временные метки для всех сегментов.
Ниже приведены примеры ссылок на аудио и видео дорожки потока:
Здесь параметр QualityLevel указывает на профиль (битрейт) текущего сегмента, а параметры video= и audio-eng= непосредственно указывают на сегменты, которые должны быть загружены.
Также следует отметить, что в Smooth Streaming относительно легко могут быть интегрированы DRM-системы. Более того, существует возможность использования нескольких уровней DRM в одном и том же файле.
Поддержка
Поддержка Smooth Streaming осуществляется компанией Microsoft, при этом спецификации протокола доступны в открытом виде. Некоторые производители вещательных серверов (например, Anevia) предлагают решения, полностью совместимые со спецификациями, выпущенными Microsoft. Также в 2011 году компания Microsoft выпустила клиентскую библиотеку Smooth Streaming для ОС iOS и Android.
Преимущества
Smooth Streaming поддерживает наличие нескольких аудио дорожек и нескольких дорожек субтитров в потоке. Для получения наиболее качественного изображения, плеер Microsoft Silverligh перед выбором потока с большим битрейтом анализирует возможности устройства. Также Smooth Streaming поддерживает интеграцию любой DRM, помимо Microsoft PlayReady. Положительным также является тот факт, что компания Microsoft предоставляет весьма подробные спецификации с большим количеством примеров, что значительно облегчает понимание функционирования и внедрение технологии.
Ограничения
Хотя технология Smooth Streaming разрабатывалась исключительно для вещания через web, сам плеер всегда управляется плагином Silverlight. Даже браузер Microsoft Internet Explorer требует установки дополнительного плагина для функционирования Smooth Streaming. Так же, как и в HLS, управление битрейтом выполняется исключительно с клиентской стороны, что делает невозможной «тонкую» ручную настройку сети. Наконец, Smooth Streaming использует патентованные аудио и видео кодеки, а поэтому за его использование, возможно, придется платить в будущем.
Adobe HTTP Dynamic Streaming
Технология Adobe Flash (ранее – Macromedia Flash) была представлена в 1996 году и, согласно информации компании Adobe, в 2010 году использовалась 98 % пользователями сети интернет в США.
Принцип работы
| USP 2006-07-24T07:15:00+01:00 0 video/mp4 live streaming |
Как видно, manifest-файл содержит загрузочную информацию (в оригинале – «bootstrap») и помогает плееру определить, с какого сегмента следует начинать воспроизведение. Также в данном файле содержится информация о доступных битрейтах.
HDS поддерживает видео кодеки H.264 и VP6 и аудио кодеки AAC и MP3. Ниже приведен формат запроса сегмента потока для протокола HDS:
Единственной системой DRM, интегрированной с HDS, является собственная система компании Adobe под названием Flash Access. Данная система обладает большим количеством функций и дает возможность гибко изменять параметры доступа к контенту, а также позволяет кодировать не только полезную нагрузку, но и информацию протоколов транспортного уровня. Недостатком данной системы является достаточно большая нагрузка на ЦП, что может привести к невозможности использования данной DRM на бюджетных сеттоп-боксах и других абонентских устройствах, которые не обладают достаточной производительностью.
Преимущества
На данный момент, практически любой компьютер в мире может воспроизводить потоки Adobe HDS. Данный стандарт для использования с VOD-приложениями достаточно полно и доступно описан компанией Adobe, кроме того, для HDS существуют подробные примеры написания исходного кода.
Ограничения
Единственной системой DRM, которая поддерживается HDS, является Flash Access. Несмотря на то, что HDS достаточно полно описан для использования с VOD-приложениями, нет практически никакой информации про использование DRM Flash Access (особенно с live-потоками). Подобно Apple HLS, нет возможности передавать более одной аудио дорожки с помощью HDS. Существуют бета-версии протокола, которые позволяют выбирать альтернативную аудио дорожку, но только для VOD-файлов, а не для live-потоков.
Google WebM
WebM был представлен компанией Google в мае 2010 года как полностью открытый стандарт, не требующий уплаты лицензионных отчислений при его использовании. Для того, чтобы это обеспечить, компания Google использовала видео кодек VP8, аудио кодек Vorbis и контейнер, известный под названием Matroska. Через несколько дней после анонсирования стандарта WebM, о его поддержке заявили более сорока производителей программного и аппаратного обеспечения, включая ARM, Intel, Mozilla Foundation и Opera Software.
Принцип работы
Функционирование стандарта WebM отличается от других технологий. При его использовании не требуется сегментирования исходной информации, т.к. с позиции WebM один медиа-поток представляется в виде одного файла.
Вещание live-потоков или VOD-файлов по протоколу WebM осуществляется следующим образом:
• Видео и аудио контент сжимается с помощью кодеков VP8 и Vorbis соответственно (одни и те же потоки или файлы энкодируются с различным битрейтом);
• Сжатый контент мультиплексируется в файл, который должен автоматически обновляться в случае live-вещания;
• Полученный WebM-файл попадает к абоненту через HTTP-сервер.
Необходимо отметить, что в данном случае повышается сложность реализации live-вещания, т.к. мультиплексирование потоков в контейнер должно выполняться непрерывно и конечный файл постоянно изменяется с течением времени. Это приводит к тому, что задача кэширования потоков, передаваемых по протоколу WebM, гораздо более сложна, чем кэширование отдельных сегментов видео файлов. Однако данный факт одновременно является и преимуществом WebM, т.к. его можно непосредственно использовать как формат хранения файлов.
Механизм реализации адаптивного вещания также сильно отличается от других решений. В данном случае сервер выбирает битрейт аудио и видео потоков перед мультиплексированием их в файл. Пакеты, готовые к отправке, помещаются в выходной буфер сервера.
Поддержка
WebM поддерживается практически всеми современными браузерами, работающими под ОС Windows, MacOS X и Linux OS. Также технология WebM поддерживается последними HD-телевизорами компании Sony и сеттоп-боксами “Revue” компании Logitech. Наконец, поддержка WebM была добавлена в ОС Android начиная с версии 2.3.3. Как известно, ОС Android используется многими производителями мобильных устройств, такими как Motorola, HTC, Samsung и Sony-Ericsson, поэтому технология WebM может стать весьма популярной уже в ближайшее время.
Преимущества
Выбор контейнера Matroska представляется весьма интересным решением: в нем используется двоичный формат EBML, произошедший от XML, что дает возможность расширять функционал контейнера без нарушения обратной совместимости со старыми версиями. Например, сейчас Matroska имеет систему меню (аналог разделов в формате DVD), поддерживает наличие нескольких аудио и видео дорожек, 3D-конент, субтитры и т.д. Более того, Matroska требует меньше пропускной способности для передачи служебной информации, чем контейнер TS, что очень важно при передаче видео на мобильные устройства. Также к преимуществам стоит отнести встроенную поддержку WebM основными web-браузерами.
Ограничения
Основным недостатком технологии WebM является небольшое количество доступных микросхем, поддерживающих аппаратное декодирование кодека VP8 (распространение мобильных устройств на платформе Nvidia Tegra 2, которая обладает поддержкой аппаратного декодирования как H.264, так и VP8, частично решает данную проблему). Вторым недостатком является отсутствие поддержки WebM сеттоп-боксами (решается установкой браузера Opera). Также существуют проблемы с кэшированием потоков WebM, которое может выполняться только с использованием специальных вещательных серверов и не может осуществлять традиционными методами. Официально, в WebM отсутствует поддержка DRM-систем. Тем не менее, при необходимости в контейнер Matroska может быть сравнительно легко добавлена поддержка шифрования. В связи с тем, что не так давно Google приобрела компанию Widevine, можно предположить, что в скором будущем в WebM появится поддержка DRM.
MPEG-DASH
Описанные выше технологии берут свое начало из рынка интернет-услуг и не имеют прямых корней в телекоммуникационной индустрии. Эту «брешь» заполнили организации MPEG-LA и ISO выпустив свой собственный стандарт по адаптивному вещанию поверх протокола HTTP – MPEG-DASH (Dynamic Adaptive Streaming over HTTP). Первая черновая спецификация протокола DASH была выпущена в феврале 2011 года.
Принцип работы
Функционирование протокола подобно уже описанным технологиям: существует manifest-файл формата XML, который выступает в роли плейлиста и содержит информацию описательного характера (как в Microsoft Smooth Streaming). Формат контейнера может быть одним из следующих:
• Файл формата ISO, похожий на контейнер MPEG-4 (фрагментированный MPEG-4 как в Smooth Streaming или Adobe Dynamic Streaming);
• MPEG-2 Transport Stream (как в HLS);
• Контейнер 3GP.
Протокол MPEG-DASH опционально может содержать дополнительную функцию: сегмент инициализации. Данный сегмент имеет формат MPEG2-TS и содержит отдельную программу, служебную информацию, относящуюся к данной программе (PAT, PMT), а также необязательную информацию о кодеке и DRM. Наличие сегмента инициализации дает возможность не дублировать данную информацию в последующих сегментах.
На рисунке 6 приведена последовательность формирования сегментированного потока (файла) в случае использования MPEG-DASH:
В MPEG-DASH используется DRM-система под названием UltraViolet, которая позволяет воспроизводить однажды приобретенный контент на любых устройствах (концепция «Buy once, play it anywhere»). Разработка данной системы осуществляется консорциумом под названием Digital Entertainment Content Ecosystem (DECE), в который входят более 70 членов, среди которых есть Sony, Microsoft, Google (Widevine), Adobe, Cisco, HP, IBM, Intel, Motorola Mobility (теперь Google), Samsung, LG Electronics и студии, производящие контент, такие как Warner Bros, NBC Universal, Fox, Paramount, Sony Pictures и Lionsgate.
Преимущества
С чисто технической точки зрения, MPEG-DASH является наиболее совершенным из всех описанных протоколов. Т.к. данный протокол продвигается организациями ISO и MPEG-LA, в будущем он вполне может стать стандартом в области телекоммуникаций. Также заслуживает внимания DRM-система UltraViolet со своей философией «Buy once, play anywhere», т.к. лишь небольшое количество пользователей используют оборудование одного производителя для воспроизведения контента.
Ограничения
С клиентской точки зрения, ограничение состоит в том, что на данный момент всего лишь несколько плееров могут корректно принимать и воспроизводить поток MPEG-DASH. Также, в настоящее время, спецификации протокола существуют лишь в черновом варианте. Наконец, компании Apple и Walt Disney являются противниками разработки и внедрения DRM-системы UltraViolet, что может стать препятствием на пути принятия стандарта.
Закрытие контента, управление абонентами и организация дополнительных услуг в OTT
Описанные технологии позволяют решить задачу доставки контента от места производства (хранения) к оконечному потребителю, однако они не позволяют контролировать доступ к контенту и выполнять его закрытие. Решение данных задач осуществляется соответственно с помощью промежуточного ПО и систем условного доступа. С коммерческой точки зрения, без использования промежуточного ПО и систем условного доступа теряется вообще всякий смысл организации услуг OTT, т.к. проконтролировать процесс доступа к контенту и его доставки становится практически невозможно.
Как и в традиционных сетях IPTV, при предоставлении услуг по технологии OTT задачи управления абонентской базой и организации дополнительных услуг решаются при помощи промежуточного ПО (Middleware). В данном случае функционирование Middleware осуществляется по протоколу HTTP и ничем не отличается от традиционных IPTV-сетей. Со стороны абонента используются либо сеттоп-боксы, интегрированные с Middleware определенного производителя, либо специальное ПО, которое устанавливается на компьютер, планшет или смартфон.
Неудивительно, что компании, занимающиеся разработкой IPTV Middleware, начали выпускать версии своего ПО и для сетей OTT. Примером может служить BeeSmart Middleware (рисунок 7), которое может быть использовано как в традиционных IPTV проектах, так и в OTT-решениях.
Закрытие контента при предоставлении OTT-услуг играет еще большую роль, чем в сетях IPTV. Т.к. в OTT контент передается по открытым, не принадлежащим провайдеру сетям, вероятность его «перехвата» посторонними лицами более высока, чем традиционном IPTV.
Как показано на рисунке 1, во всех описанных технологиях задача «закрытия» контента (скремблирование) выполняется Packager’ом с использованием DRM серверов сторонних производителей. Многие компании, занимающиеся разработкой систем закрытия контента для IPTV и DVB-сетей, начали выпускать решения и для OTT. Примером могут служить компании Verimatrix (рисунок 8) и Nagravision.
Normal 0 false false false RU X-NONE X-NONE MicrosoftInternetExplorer4
Решения ведущих мировых производителей в области организации адаптивного НТТР-вещания
Компания «ДЕПС» сотрудничает с ведущими фирмами-производителями OTT-решений в мире, среди которых отдельно следует отметить компании RGB Networks, Anevia и Envivio. Подходы к реализации задач адаптивного НТТР-вещания у данных компаний отличаются, а их программные и аппаратные продукты могут быть использованы операторами различного масштаба. Ниже рассмотрены подходы различных производителей к организации предоставления OTT-услуг.
Решение компании RGB Networks для организации адаптивного НТТР-вещания
Компания RGB Networks предлагает решение, наиболее подходящее для OTT-операторов крупного и среднего масштаба (от единиц до нескольких сотен каналов).
Подход компании RGB Networks практически не отличается от рассмотренной ранее модели (см. рисунок 9). Сигналы, принятые ГС IPTV, транскодируются с различным выходным битрейтом с помощью специализированной платформы RGB Video Multiprocessing Gateway (VMG). Затем «подготовленные» потоки подаются на сервер RGB TransAct Packager, который выполняет «упаковку» полученных потоков в контейнеры различного формата. TransAct Packager поддерживает выходные форматы Apple HLS, Microsoft Smooth Streaming, Adobe HDS и Adobe RTMP (который не работает поверх протокола НТТР и в данной статье не рассматривается). Потоки, транскодированные с различным битрейтом и «упакованные» в разные контейнеры, передаются затем на CDN сторонних производителей для доставки на клиентские устройства.
RGB VMG представляет собой специализированную модульную высокопроизводительную платформу для транскодирования потоков. VMG обладает богатыми возможностями по резервированию и большим количеством дополнительных функций (вставка рекламы, наложение изображений и пр.).
Программный продукт TransAct Packager может быть установлен на различные аппаратные платформы, однако компания RGB предоставляет свое аппаратное решение под названием Application Media Server (AMS), конфигурация которого подобрана и оптимизирована для выполнения специализированных задач Packager’а. Также следует отметить, что TransAct Packager может быть интегрирован с DRM-системами ведущих мировых производителей.
Кроме того, при организации HTTP-вещания оборудование RGB позволяет выполнять целевую вставку рекламы с использованием последних достижений в данной области. В этом случае вся аудитория телеканала разбивается на подгруппы (так называемые зоны), для каждой из которых транслируется свой рекламный блок. Количество абонентов в каждой из подгрупп может быть сколь угодно малым, что позволяет использовать время одного рекламного блока для трансляции одновременно нескольких рекламных роликов, предназначенных для различной целевой аудитории.
Механизм вставки рекламы при организации вещания поверх протокола HTTP показан на рисунке 10. Сегмент № 7 представляет собой рекламный блок (в реальной ситуации рекламный блок будет состоять из нескольких сегментов). В процессе вещания 2 клиентских устройства получают разные плейлисты, которые содержат ссылки на сегменты рекламных блоков: клиентское устройство № 1 будет воспроизводить исходный рекламный блок (сегмент, расположенный по ссылке «url7»), а клиентское устройство № 2 будет воспроизводить подменный рекламный блок (сегмент, расположенный по ссылке «url7’» на обычном HTTP-сервере).
Решение компании Anevia для организации OTT-услуг
Для организации адаптивного НТТР-вещания компания Anevia предлагает комплексное решение под названием ViaMotion (рисунок 11). Решение позволяет организовать вещание live-потоков и видео файлов на различные клиентские устройства поверх сети интернет. Серверы ViaMotion поддерживают HTTP-вещание с использованием технологий Microsoft Silverlight Smooth Streaming, Apple HTTP Live Streaming, Adobe Flash Video, Google WebM, а также MPEG DASH.
Комплексное решение состоит из нескольких серверов и предполагает использование оборудования сторонних производителей (рисунок 12).
Ключевое место здесь занимает ViaMotion Origin Server, который выполняет прием потоков, «упакованных» в стандартах Smooth Streaming и Apple HLS, формирование нескольких выходных профилей сжатия из одного входного и инкапсуляцию выходных потоков в контейнеры Smooth Streaming, HLS, HDS, MPEG-DASH и WebM. ViaMotion Origin Server работает с видео кодеком H.264.
В качестве CDN для OTT-услуг компания Anevia предлагает решение под названием ViaMotion Edge Server, который выполняет функции кэширования, резервирования и контроля доступа к контенту.
Для мониторинга услуг OTT предполагается использование сервера ViaMotion Probe, который позволяет выполнять измерения KPI и соответствия параметров услуг договору SLA.
Управление нагрузкой в больших сетях осуществляется с помощью сервера ViaMotion Balancer, который позволяет предотвратить перегрузку внешних каналов и равномерно распределить нагрузку среди всех доступных серверов.
Для контроля доступности услуг используется ViaManager Monitor, который позволяет выполнять мониторинг всех составных частей системы ViaMotion, а также оборудования сторонних производителей.
Как и в предыдущем случае, Anevia ViaMotion Origin Server поддерживает интеграцию с DRM-системами сторонних производителей.
Решение компании Envivio для организации Multiscreen Video Delivery
Для реализации данных задач компания Envivio предлагает решение, состоящее из двух основных компонентов: энкодера Envivio 4Caster C4 Gen III и медиа-процессора Envivio Halo 2 (рисунок 13).
Envivio 4Caster C4 Gen III является высокопроизводительным решением в области энкодирования/транскодирования потоков. Он служит для «подготовки» исходных сигналов и передачи их по опорной сети до пограничных устройств обработки Halo 2, которые выполняют «упаковку» потоков в контейнеры и передачу их на CDN. На данный момент, поддерживаются выходные форматы Apple HLS и Microsoft Smooth Streaming.
Компания Envivio разработала свой формат передачи видео потоков между энкодерами/транскодерами и медиа-процессорами под названием Envivio Genesis™ (рисунок 14). Вместо того, чтобы передавать по сети один и тот же поток, сжатый с несколькими различными профилями, формат Envivio Genesis™ позволяет передавать один поток максимального качества, который содержит небольшое количество служебной информации, необходимой для получения из него потоков, сжатых с более низкими профилями. Данный подход позволяет значительно снизить нагрузку на транспортные сети и уменьшить тем самым капиталовложения, необходимые для развертывания и эксплуатации сети.
Выводы
Адаптивное вещание поверх HTTP-протокола позволяет вывести услуги цифрового телевидения на качественно новый уровень. Существующее технические решения в данной области помимо самого телевидения позволяют предоставлять большое количество дополнительных услуг, а скорости абонентского доступа к сети интернет в Украине даже в небольших городах уже позволяют предоставлять OTT-услуги с приемлемым качеством.
Однако, к сожалению, на момент написания статьи рынок OTT-услуг в Украине еще не сформировался. Иными словами, компании, реально предлагающие услуги OTT в Украине, можно пересчитать на пальцах, а значительная доля потребителей в нашей стране пока не готова отказаться от традиционных услуг кабельного и вещательного телевидения в пользу OTT. Несмотря на это, в Америке и Западной Европе уже распространено явление, которое получило название «cord-cutting»: наблюдается постепенный отток абонентов цифрового телевидения и IPTV и увеличение доли абонентов OTT-провайдеров.
На наш взгляд, переход к OTT следует рассматривать не только как возможность получения дополнительных источников дохода (например, с помощью разбиения аудитории телеканала на несколько целевых групп и многократной продажи одного и того же рекламного блока нескольким рекламодателям), но и как неизбежную необходимость, возможность удержаться «на плаву». Как показывает практика, почти все новшества в телекоммуникационной индустрии, которые появляются на Западе, спустя некоторое время приходят и к нам, поэтому операторам уже сейчас следует позаботиться о том, чтобы гибко и своевременно реагировать на изменяющиеся условия рынка.
Глоссарий
3GP (формат файлов) – формат мультимедийного контейнера, определяемый Партнёрским Проектом Третьего поколения (англ. Third Generation Partnership Project (3GPP). Является упрощённой версией ISO 14496-1 Media Format, который похож на MOV, используемый QuickTime. Использует видео кодеки MPEG-4 или H.263 и аудио кодеки AMR-NB или AAC-LC.
AAC (Advanced Audio Coding) – патентованный формат сжатия аудио с меньшей потерей качества при кодировании, чем MP3 при одинаковых размерах. Является одним из наиболее качественных форматов, использующих сжатие с потерями, поддерживаемый большинством современного оборудования, в том числе портативного.
CAS (англ. Conditional Access System – Система условного доступа) – программно-аппаратный механизм для ограничения доступа к цифровым телепрограммам.
CDN (англ. Content Delivery Network – Сеть доставки контента) – географически распределённая сетевая инфраструктура, позволяющая оптимизировать доставку и дистрибуцию контента конечным пользователям в сети интернет. Использование контент-провайдерами CDN способствует увеличению скорости загрузки интернет-пользователями аудио-, видео-, программного, игрового и других видов цифрового контента в точках присутствия сети CDN.
H.264 или AVC (англ. Advanced Video Coding) – лицензируемый стандарт сжатия видео, предназначенный для достижения высокой степени сжатия видеопотока при сохранении высокого качества. Описан в документе MPEG-4 Part 10.
HDTV (англ. High-Definition Television – Телевидение высокой чёткости) – телевидение в высоком разрешении. Набор стандартов телевизионного вещания высокого качества, основанных на современных стандартах разложения изображения, значительно превышающих по разрешающей способности телевидение стандартной чёткости, и использующих новейшие цифровые стандарты сжатия цвета и звука.
HTTP (англ. HyperText Transfer Protocol – протокол передачи гипертекста) – протокол прикладного уровня передачи данных. Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
IP (англ. Internet Protocol) – межсетевой протокол. Относится к маршрутизируемым протоколам сетевого уровня семейства TCP/IP. Объединяет сегменты сети в единую сеть, обеспечивая доставку данных между любыми узлами сети.
IPTV (англ. Internet Protocol Television) – цифровое телевидение в сетях передачи данных по протоколу IP. Доставка контента до клиентского оборудования осуществляется поверх IP-сети оператора.
ISO (англ. International Organization for Standardization – Международная организация по стандартизации) – международная организация, занимающаяся выпуском стандартов.
KPI (англ. Key Performance Indicators) – Ключевые показатели эффективности.
Matroska – проект, нацеленный на создание открытого, гибкого, кроссплатформенного (включая аппаратные платформы) формата мультимедийного контейнера и набора инструментов и библиотек для работы с данными в этом формате. Проект основан на EBML (Extensible Binary Meta Language – расширяемый двоичный метаязык) – двоичном аналоге языка XML. Использование EBML позволяет расширять формат без потери совместимости со старыми программами.
Middleware – промежуточное программное обеспечение – широко используемый термин, означающий слой или комплект технологического программного обеспечения для обеспечения взаимодействия между различными приложениями, системами, компонентами.
MPEG-2 TS (англ. транспортный поток MPEG-2) – протокол передачи аудио и видео данных, описанный в стандарте MPEG-2 Часть 1. Представляет собой формат контейнера, который инкапсулирует пакеты элементарных потоков и других данных.
Multicast (англ. групповая передача) – специальная форма широковещания, при которой сетевой пакет одновременно направляется определённому подмножеству адресатов – не одному (unicast), и не всем (broadcast).
Multiscreen Delivery – вещание одного контента на различные типы оконечных устройств (телевизоры с возможностью подключения к сети интернет, абонентские приставки, компьютеры (в т.ч. планшетные), смартфоны).
OTT (англ. Over-the-Top Television) – доставка видеосигнала на приставку (компьютер, мобильный телефон) пользователя по неуправляемой сети (интернет). Отличается от услуг IPTV тем, что последние предоставляются абонентам через управляемую оператором сеть с гарантированным QoS (QoE).
Packager – специальное устройство, которое осуществляет «упаковку» сжатых аудио и видео потоков в контейнеры, определяемые технологией доставки контента на оконечные устройства пользователей.
PAT (Program Association Table – Таблица программ) – одна из сервисных таблиц контейнера MPEG-2 TS, содержит идентификаторы пакетов всех PMT.
PIFF (англ. Protected Interoperable File Format) – формат файлов, который используется для доставки и воспроизведения мультимедийного контента. Спецификации включают описание контейнера, шифрования и метаданных. Используется Microsoft Smooth Streaming.
PMT (англ. Program Map Table – Таблица структуры программ) – одна из сервисных таблиц контейнера MPEG-2 TS, содержит идентификаторы пакетов и основные характеристики элементарных потоков конкретной программы – видео, звука, дополнительных данных. Для каждой программы есть своя РМТ с собственным идентификатором пакета.
RTP (англ. Real-time Transport Protocol) – протокол транспортного уровня, используется при передаче трафика реального времени. Переносит в своём заголовке данные, необходимые для восстановления голоса или видеоизображения в приёмном узле, а также данные о типе кодирования информации (JPEG, MPEG и т. п.). В частности, в заголовке передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты.
SLA (англ. Service Level Agreement – Соглашение об уровне предоставления услуги) – термин, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон, а также согласованный уровень качества предоставления данной услуги.
SMPTE (англ. Society of Motion Picture and Television Engineers – Общество инженеров кино и телевидения) – организация, рекомендующая стандарты для кинематографии и телевидения. Разрабатывает стандарты международного значения, выпустила более 400 стандартов, технологических рекомендаций и конструкторской документации по телевидению, кинематографии, цифровому кино, звуку и медицинским изображениям.
UDP (англ. User Datagram Protocol) – протокол пользовательских дейтаграмм. Транспортный протокол для передачи данных в сетях IP без установления соединения. Не подтверждает доставку данных, не заботится о корректном порядке доставки данных и не повторяет отправку.
Unicast – однонаправленная (односторонняя) передача данных, передача пакетов единственному адресату.
URL (англ. Uniform Resource Locator) – Единый указатель ресурсов. Единообразный локатор (определитель местонахождения) ресурса, стандартизированный способ записи адреса ресурса в сети интернет.
VC-1 – видеокодек, изначально разработанный компанией Microsoft. Поддерживается технологиями HD-DVD и Blu-Ray, часто рассматривается как альтернатива H.264.
VoD (англ. Video on Demand – видео по требованию) – видео по запросу, система индивидуальной доставки абоненту телевизионных программ или видеофильмов по кабельной сети с мультимедиасервера.
Vorbis – свободный формат сжатия звука с потерями. По функциональности и качеству аналогичен таким кодекам как AAC, AC3 и VQF. Психоакустическая модель, используемая в Vorbis, по принципам действия близка к MP3 и подобным, однако математическая обработка и практическая реализация этой модели существенно отличаются, что позволило авторам объявить свой формат совершенно независимым от всех предшественников.
VP8 – видеокодек, созданный компанией On2 Technologies и имеющий открытый исходный код. Исходные коды VP8 открыты под лицензией, схожей с BSD, но дополненной передачей некоторых патентных прав.
XML (англ. eXtensible Markup Language – расширяемый язык разметки) – язык разметки, фактически представляющий собой свод общих синтаксических правил, текстовый формат, предназначенный для хранения структурированных данных и обмена информацией между программами.
Битрейт (англ. bit rate) – скорость прохождения битов информации по каналу связи. Термин битрейт используется в двух основных значениях: 1) характеристика канала или устройства – максимальное количество бит, которое можно передать в единицу времени; 2) величина потока данных, передаваемого в реальном времени (частный случай – битрейт сжатого звука или видео). Выражается битами в секунду (бит/c, bps), а также производными величинами с приставками кило- (кбит/с, kbit/s, kbps), мега- (Мбит/с, Mbit/s, Mbps) и т. д.
Джиттер (англ. jitter – дрожание) – разброс максимального и минимального времени прохождения пакета от среднего значения времени задержки (первая производная задержки прохождения данных по времени).
Контейнер (англ. container) – формат файла или потока, который определяет только способ сохранения данных (а не алгоритм кодирования). Контейнер определяет, сколько данных фактически может быть сохранено, вместе с тем он не определяет способ кодирования самих данных.
Плагин (англ. plug-in) – независимо компилируемый программный модуль, динамически подключаемый к основной программе, предназначенный для расширения и/или использования её возможностей. Плагины обычно выполняются в виде разделяемых библиотек.
Плейлист (англ. playlist – список воспроизведения) – список ссылок на файлы или фрагменты потока, которые должны быть загружены приемным устройством для воспроизведения контента.
Профиль сжатия – набор возможностей кодека, которые ориентируются на конкретные классы приложений.
Сеттоп-бокс (англ. Set Top Box, STB) – ресивер цифрового телевидения, устройство, которое принимает сигнал цифрового телевидения, декодирует его, преобразует в стандартный ТВ-сигнал и передает далее на экран телевизора. Ресиверы могут подключаться к спутниковой антенне, к сетям кабельного телевидения, к компьютерным сетям (WiFi, Ethernet) и т. д.
Скремблирование – это обратимое преобразование цифрового потока без изменения скорости передачи с целью получения свойств случайной последовательности («закрытия» контента). После скремблирования появление «1» и «0» в выходной последовательности равновероятны.
Скремблирование – обратимый процесс, то есть исходное сообщение можно восстановить, применив обратный алгоритм.
Тег (англ. tag) или дескриптор – элемент языка разметки гипертекста. В XML тег является элементом документа, а текст, содержащийся между начальным и конечным тегом – содержанием элемента.
Уровень сжатия – определенный набор ограничений, указывающих степень требуемой производительности декодера для профиля. Например, поддержка уровня в профиле будет указывать максимальное разрешение изображения, частоту кадров и битрейт так, что декодер можно будет использовать. Декодер, который соответствует данному уровню, обязан декодировать все потоки, которые кодируются для этого уровня и для всех более низких уровней.
Энкодирование (англ. Encoding) – процесс сжатия аналогового цифрового сигнала с использованием определенного кодека (например, MPEG-2, AVC для видео или MPEG-1 Layer 3 для аудио). Выполняется устройством под названием энкодер. Сжатый поток на выходе энкодера имеет гораздый меньший битрейт, чем на входе, что позволяет передавать его по открытым сетям на большие расстояния.