HLS против RTMP — сухая статистика. Вещание IP камер в формате HLS Hls вещание

Обработку, хранение и передачу видео для своего онлайн-проекта, а не использовать сайты вроде YouTube, он неизбежно приходит к вопросу о том, какой протокол передачи использовать для трансляции видео на устройства пользователей. Выбор невелик, т.к. есть ряд отраслевых стандартов, которые поддерживают те или иные устройства. Кроме того, выбор протокола во многом зависит от «класса» видео - живая трансляция или видео-по-запросу. От выбора протокола также зависит и выбор медиа-сервера, который будет двигателем вашей медиа-машины: будете ли ставить несколько разнородных серверов или построите сеть доставки на одном решении? Поэтому нужно взвесить всё и принимать решение исходя из критериев вашего бизнеса.

В общем, получается уравнение со многими неизвестными. Здесь немаловажна динамика процесса - а куда вообще идёт индустрия? Вдруг я вложусь в поддержку технологии, а она загнётся через год, ведь такое уже бывало. Или поставлю на модную технологию, а её никто не поддерживает?

Мы решили оценить, как менялась доля разных протоколов с течением времени - посмотреть в динамике весь процесс. Данные взяли за последний год.

Исходные данные

Для начала - кто мы такие, чтобы судить о долях рынка? Мы - разработчики веб-сервиса отчетности для медиа-серверов . На рынке работаем четвертый год и к нам приходят компании с разными инфраструктурами, разным количеством серверов и разными потребностями. Получается неплохой слепок состояния отрасли.

Мы сделали небольшой отчет, где можно выбирать диапазон дат и получать данные с графиком по количеству просмотров видео через разные протоколы.

В отчете даются данные по серверам:

  • Wowza Streaming Engine во всех версиях, начиная с 2.2 и до последних 4.х; бОльшая часть - 3.х.
  • Nimble Streamer , работающий с HLS, Smooth, HDS и progressive download - это наша разработка.
  • Windows Media Services - их буквально пару десятков, но они есть, и надо их учитывать
На момент написания статьи сервис обслуживает порядка 1000 серверов из 60 стран мира.

Отчет также периодически обновляется у нас в блоге, он доступен по соответствующему тегу .

Поехали

Отчет за июнь/июль 2014 выглядит примерно так. Из 1.4 миллиарда просмотров больше половины - это HLS. На втором месте - RTMP с четвертью просмотров. RTSP - примерно шестая часть. Остальные находятся в районе статистической погрешности.

Что было год назад за тот же период? Ситуация почти зеркальная. RTMP - почти две трети, RTSP и HLS делят второе и третье места. Правда, и база для измерений была меньше почти в 3 раза - «всего» 500 миллионов просмотров . Серверов в нашем сервисе тоже было поменьше, конечно.

Пройдемся между этими двумя точками.

Итак, июнь - август 2014 года, 3 месяца лета. 800 миллионов просмотров , но доли такие же, август изменений не привнёс.

Сентябрь - ноябрь 2013. Начался новый сезон, HLS начал отъедать долю RTMP. Всего 1.1 миллиарда просмотров , у RTMP примерно половина от общего числа, HLS - четверть.

Декабрь 2013 - февраль 2014. 1.4 миллиарда просмотров , из них на HLS приходится уже больше 40%. RTMP и RTMP делят второе и третье место с четвертью доли. Олимпиада в Сочи дала прирост числа просмотров и одновременно заставила провайдеров вспомнить обо всех клиентах со всеми их экзотическими или старыми девайсами, которые понимают только RTSP - отсюда и скачок этого протокола.

Обработку, хранение и передачу видео для своего онлайн-проекта, а не использовать сайты вроде YouTube, он неизбежно приходит к вопросу о том, какой протокол передачи использовать для трансляции видео на устройства пользователей. Выбор невелик, т.к. есть ряд отраслевых стандартов, которые поддерживают те или иные устройства. Кроме того, выбор протокола во многом зависит от «класса» видео - живая трансляция или видео-по-запросу. От выбора протокола также зависит и выбор медиа-сервера, который будет двигателем вашей медиа-машины: будете ли ставить несколько разнородных серверов или построите сеть доставки на одном решении? Поэтому нужно взвесить всё и принимать решение исходя из критериев вашего бизнеса.

В общем, получается уравнение со многими неизвестными. Здесь немаловажна динамика процесса - а куда вообще идёт индустрия? Вдруг я вложусь в поддержку технологии, а она загнётся через год, ведь такое уже бывало. Или поставлю на модную технологию, а её никто не поддерживает?

Мы решили оценить, как менялась доля разных протоколов с течением времени - посмотреть в динамике весь процесс. Данные взяли за последний год.

Исходные данные

Для начала - кто мы такие, чтобы судить о долях рынка? Мы - разработчики веб-сервиса отчетности для медиа-серверов . На рынке работаем четвертый год и к нам приходят компании с разными инфраструктурами, разным количеством серверов и разными потребностями. Получается неплохой слепок состояния отрасли.

Мы сделали небольшой отчет, где можно выбирать диапазон дат и получать данные с графиком по количеству просмотров видео через разные протоколы.

В отчете даются данные по серверам:

  • Wowza Streaming Engine во всех версиях, начиная с 2.2 и до последних 4.х; бОльшая часть - 3.х.
  • Nimble Streamer , работающий с HLS, Smooth, HDS и progressive download - это наша разработка.
  • Windows Media Services - их буквально пару десятков, но они есть, и надо их учитывать
На момент написания статьи сервис обслуживает порядка 1000 серверов из 60 стран мира.

Отчет также периодически обновляется у нас в блоге, он доступен по соответствующему тегу .

Поехали

Отчет за июнь/июль 2014 выглядит примерно так. Из 1.4 миллиарда просмотров больше половины - это HLS. На втором месте - RTMP с четвертью просмотров. RTSP - примерно шестая часть. Остальные находятся в районе статистической погрешности.

Что было год назад за тот же период? Ситуация почти зеркальная. RTMP - почти две трети, RTSP и HLS делят второе и третье места. Правда, и база для измерений была меньше почти в 3 раза - «всего» 500 миллионов просмотров . Серверов в нашем сервисе тоже было поменьше, конечно.

Пройдемся между этими двумя точками.

Итак, июнь - август 2014 года, 3 месяца лета. 800 миллионов просмотров , но доли такие же, август изменений не привнёс.

Сентябрь - ноябрь 2013. Начался новый сезон, HLS начал отъедать долю RTMP. Всего 1.1 миллиарда просмотров , у RTMP примерно половина от общего числа, HLS - четверть.

Декабрь 2013 - февраль 2014. 1.4 миллиарда просмотров , из них на HLS приходится уже больше 40%. RTMP и RTMP делят второе и третье место с четвертью доли. Олимпиада в Сочи дала прирост числа просмотров и одновременно заставила провайдеров вспомнить обо всех клиентах со всеми их экзотическими или старыми девайсами, которые понимают только RTSP - отсюда и скачок этого протокола.

Предоставление услуг IP-телевидения через сеть Интернет и локальные компьютерные сети приобретает всё более массовые формы. На территории стран СНГ почти не осталось крупных провайдеров не транслирующих видео через multicast в свои локальные сети, то-есть предоставляющие услугу IPTV . Но предоставление услуги тв за пределами своей локальной сети связанно с некоторыми аппаратными издержками и сложностью обеспечения необходимого качества вещания.

HTTP Live Streaming также известный как HLS , является протоколом связи реализованным компанией Apple. Его особенность в том, что общий поток разбивается на последовательность малых загрузочных файлов, каждая загрузка загружает один небольшой фрагмент транспортного потока. Когда поток воспроизводится, клиент может выбрать один из нескольких различных альтернативных потоков, содержащих тот же материал, записанных для различных скоростей передачи данных, что позволяет адаптироваться к доступной скорости передачи данных. В начале сеанса потоковой передачи, загружается расширенный M3U (m3u8) плэйлист, содержащий метаданные для различных подпотоков, которые доступны. Так как при запросах используются только стандартные операции HTTP, HTTP Live Streaming способен обходить любой брандмауэр или прокси-сервер, который пропускает стандартный HTTP-трафик, в отличие от UDP-протоколов, таких как RTP.

HLS основан на HTTP. HLS также определяет стандартный механизм шифрования с использованием AES и способ распределения ключа безопасности с использованием HTTPS или HTTP-куки, которые вместе обеспечивают простую систему защиты авторских прав.

Принцип работы HLS

Теперь выясним в чём же преимущества и недостатки этой технологии. Преимущества несомненны и очевидны. Это, в первую очередь, адаптивность скорости передачи данных к свойствам линии и принимающего устройства, во-вторых, встроенные механизмы защиты авторских прав. В-третьих, не требуется роутер с ограничением ширины multicast-потока по WI_FI, что помогало бы избежать поглащения всей ширины канала multicast-потоками, в случае вещания IP-телевидения c помощью multicast. Также не требуется дополнительное устройство с функцией UDP-proxy для конвертации multicast-потока в HTTP, что часто требуется для мобильных устройств, хотя сказывается на аппаратной нагрузке на роутера или другое устройство осуществляющее функцию UDP-proxy в локальной сети абонента. Стандарт HLS стал довольно распространён и поддерживается почти всеми современными видео плэерами и приставками для IPTV.

IPTV приставка

Существенным минусом является наличие у абонентов мультимедийных приставок и smart-tv приставок с устаревшими прошивками или устаревших конструкций, которые не поддерживают стандарты HLS или же поддерживают их некорректно. Также одной из проблем является невозможность правильно выбрать качество для стабильной трансляции в условиях изменения характеристик линии в интервалах времени меньших, чем длительность запрашиваемого видеофрагмента.

Для организации онлайн трансляций в реальном режиме времени, видео по запросу (vod), а также для осуществления записи видео-потоков можно использовать nginx вместе с модулем nginx-rtmp-module.

Медиа серверы

На сегодняшний день существуют несколько популярных медиа серверов, о которых вы можете подробнее почитать в одной из . Медиа серверы необходимы для создания онлайн трансляций в реальном режиме времени.

Существуют как платные, так и бесплатные медиа серверы, включающие в себя разные функции. Сегодня мы поговорим об одном бесплатном и довольно неплохом решении.

Ngnix-rtmp

Базовый функционал медиа сервера, также можно реализовать с помощью бесплатного программного обеспечения — модуля Ngnix-rtmp-module, который на данный момент поддерживает такие потоковые протоколы как RTMP и HLS.

Таким образом, с помощью Ngnix-rtmp (веб сервер Ngnix + модуль Ngnix-rtmp-module), можно организовать вещание по RTMP и HLS на устройства пользователей. Сводную таблицу протоколов и устройств, которые их поддерживают, можно посмотреть в статье . Также в одной из будущих своих статей я планирую сделать сравнительную таблицу функционала модуля Ngnix-rtmp-module и других медиа серверов.

Онлайн трансляция по протоколу HLS

Сегодня мы рассмотрим, как с помощью модуля Nginx-rtmp-module организовать простейшую трансляцию с адаптивным битрейтом по протоколу HLS. В первую очередь нам необходимо скачать исходные коды веб-сервера Nginx с официального сайта. Все команды, представленные ниже исполнялись в Linux.

  • wget http://nginx.org/download/nginx-1.4.1.tar.gz

Извлечь файлы из архива.

  • tar -zxvf nginx-1.4.1.tar.gz

Скачать zip архив с исходными файлами модуля nginx-rtmp-module и извлечь файлы из архива.

  • wget https://github.com/arut/nginx-rtmp-module/archive/master.zip

Теперь нам необходимо скомпилировать nginx с модулем nginx-rtmp-module , для этого при конфигурации nginx нужно указать в опции —add-module расположение исходных файлов nginx-rtmp-module , а также необходимо указать дополнительную опцию with-http_ssl_module .

./configure —add-module=/home/nginx/nginx-rtmp-module-master —with-http_ssl_module

make install

  • Если все прошло без ошибок, можно приступать к настройке сервера. По умолчанию сервер устанавливается в директорию /usr/local/nginx . Конфигурационный файл сервера nginx.conf, находится в директории /usr/local/nginx/conf . Рассмотрим подробнее секцию rtmp:server конфигурационного файла. Параметр listen указывает порт на котором сервер будет принимать rtmp запросы.
  • Далее мы открываем секцию для настройки приложения testlive. Здесь мы указываем, что у нас live-поток - параметр live on, включаем поддержку протокола hls для этого приложения – параметр hls on.
  • С помощью параметра hls_path мы задаем директорию в которой буду располагаться чанки (кусочки) потока. Для того чтобы чанки (кусочки) для каждого видео потока располагались в отдельной директории необходимо подключить директиву hls_nested on .
  • Далее с помощью параметра allow publish мы разрешаем публиковать потоки с своего компьютера, а с помощью параметра deny publish all запрещаем всем остальным публиковать видео.
  • Теперь рассмотрим секцию http:server . В параметре listen необходимо указать на коком порту сервер будет принимать http запросы. Мы указываем порт 8080. И из примера конфигурационного файла перенести секцию http:server:location /hls . Посмотреть более подробную информацию по всем директивам конфигурационного файла можно по адресу: https://github.com/arut/nginx-rtmp-module/wiki/Directives.
  • Настало время запустить сервер. Для этого необходимо перейти в директорию /usr/local/nginx/bin и выполнить команду ./nginx .

Теперь рассмотрим один пример. Мы отправляем на сервер три видео-потока:

  • test1 с битрейтом 256 кбит/с,
  • test2 с битрейтом 512 кбит/с,
  • test3 с битрейтом 1024 кбит/с.

Наша задача, чтобы клиент, использующий протокол HLS (устройства: Mac, iPad, iPhone) мог динамически переключаться между потоками, в зависимости от качества Интернет соединения. Для этого нам необходимо в директории /usr/local/nginx/html создать файл с расширением m3u8 , например playlist.m3u8 , со следующим содержимым:

#EXTM3U

#EXT-X-VERSION:3

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=256000,RESOLUTION=640×480

hls/test1/index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=512000,RESOLUTION=640×480

hls/test2/index.m3u8

#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1024000,RESOLUTION=640×480

hls/test3/index.m3u8

Просмотр трансляции

Для просмотра видео-потоков необходимо в веб-страницу сайта встроить следующий код.

- ip-адрес вашего nginx сервера.

[название плейлиста] - название файла, созданного в предыдущем пункте (playlist.m3u8).

Ниже, приведен пример простейшего конфигурационного файла nginx.conf.

worker_processes 1;

server {

listen 1935;

application testlive {

live on;

hls on;

hls_path /tmp/hls;

hls_nested on;

allow publish 10.10.146.148;

deny publish all;

server {

listen 8080;

server_name rtmp_test;

charset utf-8;

location / {

root html;

index index.html index.htm;

location /hls {

types {

application/vnd.apple.mpegurl m3u8;

alias /tmp/hls;

Заключение

Эта статья была написана и опубликована совместно c моим коллегой Евгением Петровым. Мы используем данный модуль (Ngnix-rtmp) в разных проектах. Если у кого-то появятся вопросы по Ngnix-rtmp, Wowza серверу, пишите. Если вам нужно что-то настроить или получить консультацию по медиа-серверам и мультимедийным системам, также можете обращаться ко мне и нашей команде через .

Flussonic Media Server поддерживает раздачу видео по протоколу HLS.

Многие из доступных возможностей нестандартны для HLS, но мы поддерживаем их для вашего удобства.

Поддерживаемые кодеки: H264, H265, MPEG2 video, AAC, MP3, MPEG2 audio, AC-3.

Flussonic Media Server позволяет получать по HLS прямой эфир, видео по запросу, видео из архива (catchup и timeshift).

Простое воспроизведение HLS

Если у вас есть простой live поток или файл (одно видео, один звук), то URL для воспроизведения через HLS очень простой:

http://flussonic-ip/STREAMNAME/index.m3u8

где flussonic-ip - это пример адреса + порта вашего Flussonic Media Server.

Flussonic Media Server также принимает playlist.m3u8 в конце URL для обратной совместимости с другими серверами.

Когда вы начинаете работать с мультиязычными или мультибитрейтными контентом, все становится сложнее.

Мультиязычный HLS

Если вы хотите воспроизвести ваш мультиязычный поток на iPhone, вам нужно использовать тот же http://192.168.2.3:8080/STREAMNAME/index.m3u8

Но если вы хотите посмотреть мультиязычный поток используя VLC или приставку, нужно включать video.m3u8.

URL для плеера: http://flussonic-ip/STREAMNAME/video.m3u8

Это связано с тем, что, согласно требованиям Apple HLS, для каждого отдельного языка нужно указывать отдельный плейлист с audio only вариантом. В MPEG-TS другой механизм: рядом с видео укладываются все аудиодорожки, и плеер сам выбирает, что будет проигрывать. Чтобы видео можно было посмотреть на iPhone, оно должно соответствовать требованиям Apple. Но VLC и приставки, в нарушение стандарта HLS, ожидают старый вариант MPEG-TS, преобразованный в HLS. Поэтому нужно включать video.m3u8 .

Добавление «Audio only» для Apple

Apple требует, чтобы у всех ваших потоков был вариант без видео, только звук.

Они считают, что если пользователь смотрит видео по 3G и, оказавшись в зоне неуверенного приема, лучше у него будет только звук, чем буфферизация.

Вы можете включить эту опцию в Flussonic Media Server:

stream ort { url udp: // 239.0.0.1 : 1234 ; add_audio_only ; }

Помните, что это может сделать ваш index.m3u8 адрес невоспроизводимым в VLC или приставке. В таком случае используйте video.m3u8 .

Отдельные битрейты для приставок

Когда у вас есть мультибитрейтный мультиязычный контент и вы хотите проиграть его на приставке, которая не поддерживает мультибитрейтный HLS плейлисты, вы можете запросить с Flussonic Media Server отдельные плейлисты с одним видео и всеми звуковыми дорожками, как с опцией mono:

http: // flussonic - ip / STREAMNAME / video1 . m3u8

Этот плейлист не мультибитрейтный, в нем URL до сегментов, в которых первая видео дорожка и все доступные звуковые дорожки.

Если вы хотите доставлять мультиязычные мультибитрейтные потоки на приставки, не понимающие стандарт Apple для мультиязычности, используйте video.m3u8:

http: // flussonic - ip / STREAMNAME / video . m3u8

Это мультибитрейтный плейлист, который отдает список плейлистов с разными качествами: video1.m3u8, video2.m3u8 и т.д.

DVR catchup playback

Когда ваш поток уже записан на сервере нашим DVR , вы можете воспроизвести видео через HLS, используя время начала и конца передачи (например, из EPG).

http: // flussonic - ip / STREAMNAME / archive -1508403742-3600 . m3u8

Этот плейлист будет т.н. variant, если в потоке будет больше одной звуковой дорожки или больше одного битрейта. Он будет давать список сегментов начиная с UTC 1362504585 (2013, Март, 5, 17:29:45 GMT) и один час вперед.

Mono URL даст список сегментов содержащих все дорожки в mpeg-ts:

http: // flussonic - ip / STREAMNAME / mono -1362504585-3600 . m3u8

Более конкретный videoN плейлист даст список сегментов с N видео дорожкой и всеми звуковыми дорожками:

http: // flussonic - ip / STREAMNAME / video1 -1362504585-3600 . m3u8

и variant видео плейлист со списком videoN плейлистов:

http: // flussonic - ip / STREAMNAME / video -1362504585-3600 . m3u8

Rewind playlist

Есть специальный плейлист "rewind-N.m3u8" с большим «скользящим» окном, позволяющий перематывать и ставить на паузу HLS потоки на долгие часы.

http: // flussonic - ip / STREAMNAME / rewind -7200 . m3u8

7200 - длина HLS плейлиста в секундах. Это означает, что ваши клиенты могут поставить эфир на паузу на 2 часа или перемотать на начало футбольного матча без обращения по специальными архивным ссылкам.