В предыдущей статье я поверхностно рассмотрел общие принципы работы адаптивного вещания. В этой статье рассмотрю отдельно каждую из представленных технологий адаптивного вещания, а также расскажу с какими проблемами столкнулась компания 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). У этой системы есть ряд положительных моментов, в так же ряд проблем. Обо всем этом я расскажу в следующей статье.
Итак, краткие итоги: Каждая представленная технология имеет свои преимущества и конкурирует друг с другом, что должно положительно сказаться на развитие такого молодого направления как адаптивное вещание, ведь всем известно, что конкуренция двигатель прогресса.
Автор: AlexBazhenov
