Когда использовать протокол HLS. Вещание IP камер в формате HLS Технология hls

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

Несмотря на то, что динамическая адаптация видеопотока уже сравнительно «старая» технология, существует множество мелких подробностей о том, как добиться лучшего результата. Чтобы и на серверной стороне попроще и подешевле, и чтобы такое видео было совместимо с как можно большим количеством клиентов (Web, iOS, Android, ну и не забываем про Smart TV).

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

Лирическое отступление (максимально кратко и просто про адаптивное видео):

Очевидно, самый простой вариант раздачи видео в интернете - это взять mp4 файл и выложить его на HTTP сервер. Этот вариант плох тем, что у нас всего 1 файл, а клиентов у нас великое множество и такое же множество качественных и не очень интернет-соединений. Если выложим видео 1080p с битрейтом 20 мегабит/с (Blueray качество), его не смогут смотреть смартфоны, а если выложим видео для смартфонов (скажем, 1 мегабит/c и 320x240), оно будет ужасно выглядеть на 55-дюймовом телевизоре.

Ну, раз 1 файл - плохо, давайте выложим десяток файлов, «нарежем» разного видео из одного исходника, будут все битрейты и все размеры кадра, от мобильного до 1080p, с битрейтом от 1 мегабита/c до 20. Прекрасно. Но есть проблемка. Один и тот же смартфон может быть как в домашнем Wi-Fi (то есть быстром), так и в ресторанном (то есть медленном). Одинаковые телевизоры бывают как у людей в Москве, так и у людей на Сахалине.

Тогда пусть плеер проверяет как-нибудь, какая пропускная способность у сети, и, померив ее, выбирает нужный файл для просмотра. Наконец, еще одна нерешенная задача - это как бы еще учесть тот факт, что фильм идет часа 2-3, а интернета то «много», то «мало». Запускать замер пропускной способности сети периодически? Этот способ сработает, но что делать когда нужно переключиться на более или менее «качественный» файл, во время «проседания» или «ускорения» сети? Чтобы это сделать быстро (да еще и не останавливая просмотр того, что уже успело накачаться), нужно заранее знать, с какого места в новом файле нужно запустить скачивание. К несчастью, соотношение смещения от начала файла к времени фильма очень часто нелинейное, из-за переменного битрейта. На быстрых сценах, когда, например, Джеймс Бонд преследует очередного врага, картинка меняется часто и битрейт высокий, а на плавной панораме безоблачного неба картинка почти не меняется и битрейт низкий.

Чтобы справиться с этой задачей, необходимо заранее проиндексировать все файлы (составить пары «время сцены в фильме / позиция от начала файла». Эти пары называют сегментами. После этого можно будет, зная текущее время просмотра, определить, из какого места в другом файле можно скачать следующий сегмент. Для «бесшовного» переключения сегменты из разных битрейтов выравнивают по времени.

Конечно, все эти функции уже давно реализованы практически во всех современных устройствах. Несколько разных битрейтов и размеров кадра для одного и того же фильма упаковываются в определенный формат, информация о том, что в каких файлах и где лежит описывается в специальном файле-дескрипторе (его часто называют манифестом). Клиент перед просмотром скачивает файл манифест и «понимает», откуда что ему качать, где какой размер видео и какой битрейт находится на сервере.

Плохая новость состоит в том, что в современном мире этот простой подход реализован разными компаниями в разное время и по разному. Вот список наиболее известных и распространенных способов адаптивной раздачи видео по HTTP:

• HTTP Live Streaming (или HLS, придуман Apple, используется во многих устройствах)
• HTTP Dynamic Streaming (сокращенно Adobe HDS)
• MPEG-DASH (стандарт опубликован в конце января)
• Smooth Streaming (изобретен в Microsoft)

Стоит еще отметить, что иногда (в форматах HDS и Smooth Streaming) вместо прямых ссылок из манифестов используется специальная схема адресации сегментов, когда сервер по этой специальной схеме «вычисляет», какой же файл запрашивает клиент и чтобы такую схему поддержать, делается еще и серверный манифест.

Посмотрим подробнее на подготовку адаптивного видео на примере HLS, как наиболее просто устроенного и наиболее широко поддерживаемого устройствами формата.

Манифестом в HLS служит группа плейлистов из одного «мастер-плейлиста» и нескольких «плейлистов потока». Проще всего будет показать это на примере. Допустим, у нас есть очень короткий фильм (всего 3 сегмента по 10 секунд, для простоты), для которого мы сделали 3 битрейта видео- 500 kbps , 1000 kbps и 2000 kbps . В файловой системе сервера он может быть расположен например так:

/master-playlist.m3u8 /500K/ /500K/playlist-500K.m3u8 /500K/segment0.ts /500K/segment1.ts /500K/segment2.ts /1000K/ /1000K/playlist-1000K.m3u8 /1000K/segment0.ts /1000K/segment1.ts /1000K/segment2.ts /2000K/ /2000K/playlist-2000K.m3u8 /2000K/segment0.ts /2000K/segment1.ts /2000K/segment2.ts

Файл master-playlist.m3u8 внутри выглядит так (некоторую информацию я убрал для простоты изложения):

#EXTM3U #EXT-X-STREAM-INF:BANDWIDTH=500,CODECS="mp4a.40.2, avc1.640028",RESOLUTION=640x480 500K/playlist-500K.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1000,CODECS="mp4a.40.2, avc1.640028",RESOLUTION=640x480 1000K/playlist-1000K.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=2000,CODECS="mp4a.40.2, avc1.640028",RESOLUTION=640x480 2000K/playlist-2000K.m3u8

Те, кто знаком с форматом m3u без труда поймут что тут к чему. В файле содержится три строки-ссылки на другие плейлисты m3u8, а в комментированной значком "#" строке над каждой ссылкой указаны данные соответствующего битрейта. BANDWIDTH, CODECS, RESOLUTION - в общем термины говорят сами за себя. Легко заметить, что отличается только BANDWIDTH, хотя в реальности там все параметры могут быть разными. Задача клиента - понять по этим параметрам, какой плейлист ему в данный момент годится.

Допустим, клиент знает, что у него сейчас «хороший» интернет и предпочитает высокий битрейт (2000К). Клиент выкачивает плейлист 2000K/playlist-2000K.m3u8, который внутри выглядит следующим образом:

#EXTM3U #EXT-X-TARGETDURATION:10 #EXT-X-VERSION:3 #EXT-X-MEDIA-SEQUENCE:0 #EXT-X-PLAYLIST-TYPE:VOD #EXTINF:9.8849, segment0.ts #EXTINF:9.9266, segment1.ts #EXTINF:9.9266, segment2.ts #EXT-X-ENDLIST

Видны ссылки на отдельные сегменты, их длительность в секундах указана строкой выше, для нулевого сегмента, например: "#EXTINF:9.8849". Скачав этот плейлист, клиент начинает проигрывание с первого сегмента по третий. Во время просмотра сегмента обычно качается следующий и так далее. Если клиент почувствует, что очередной сегмент выкачивается слишком медленно, клиент может остановить закачку и начать качать такой же сегмент (для того же места в фильме) из другого плейлиста, например, 500K/playlist-500K.m3u8. Когда скорость интернета восстановится, клиент может опять переключиться на закачку сегментов из плейлиста 1000K или 2000K.

Простота HLS позволяет раздавать его практически с любой серверной платформы (серверной «логики», собственно, при раздаче никакой и не требуется). Отдельные сегменты при необходимости легко кэшируются любым доступным образом.

Теперь посмотрим, какие инструменты доступны для создания и упаковки видео в HLS. Этот процесс состоит из трех основных этапов:

Этап 1. Подготовка исходных файлов (.mov или.mp4 с H.264) с нужным битрейтом и размером кадра.

Тут есть множество вариантов, но самый очевидный - это использовать бесплатный ffmpeg . Есть и множество видеоредакторов с GUI, для MacOSX и Windows. Для примера, описанного выше на этом этапе вам нужно получить три файла.mp4 или.mov, со средними битрейтами 500К, 1000К и 2000К. Важно брать для всех них один и тот же исходник, чтобы в конце всего процесса получились сегменты, одинаковые по времени.

Например, если у вас есть исходный файл movie.mp4 (предполагаем, что его битрейт не ниже 2000К), тогда достаточно будет запустить ffmpeg примерно так (ключи обозначают что звуковую дорожку можно взять как есть, а видео битрейт изменить):

$ ffmpeg -i movie.mp4 -acodec copy -vb 500K movie-500K.mp4 $ ffmpeg -i movie.mp4 -acodec copy -vb 1000K movie-1000K.mp4 $ ffmpeg -i movie.mp4 -acodec copy -vb 2000K movie-2000K.mp4

Этап 2. Создание однобитрейтных плейлистов.

Дальше нужно из каждого movie-*K.mp4 сделать набор из плейлиста m3u8 и сегментов *.ts. Важно, чтобы сегменты получились синхронными между разными битрейтами. Скажу сразу, ffmpeg умеет «нарезать» mp4 в m3u8 + сегменты, но только в рамках одного битрейта. К сожалению, мастер-плейлист потом придется создавать руками. Это не очень сложно (в минимальном варианте достаточно любого текстового редактора), но если вы случайно являетесь Apple iOS или OSX разработчиком, то могу посоветовать пакет HTTP Live Streaming Tools (для MacOSX). В него входит несколько программ, из которых нам пригодятся две: mediafilesegmenter и variantplaylistcreator . Первая превращает mp4 файл в плейлист m3u8 и «нарезает» сегменты, вторая собирает несколько однобитрейтных плейлистов в мастер-плейлист.

Итак, создаем три плейлиста из трех файлов полученных на предыдущем шаге (предполагается, что файлы movie-*.mp4 лежат в текущей папке).

$ mkdir 500K $ mediafilesegmenter -I -f 500K -B segment movie-500K.mp4 $ mkdir 1000K $ mediafilesegmenter -I -f 1000K -B segment movie-1000K.mp4 $ mkdir 2000K $ mediafilesegmenter -I -f 2000K -B segment movie-2000K.mp4

Небольшие пояснения:

Ключ -I требует создавать специальный файл (variant plist), который потребуется позже в программе variantplaylistcreator.

Ключ -f 500K обозначает каталог (500K), в который должны складываться “нарезанные” сегменты.

Ключ -B segment сообщает как должны называться файлы сегментов (префикс, который будет дополнен цифрой и расширением.ts).

На этом этапе у вас должны образоваться 3 папки, заполненные файлами сегментов, 3 файла-плейлиста по одному в каждой папке и 3 файла с расширением.plist. Однобитрейтные плейлисты по умолчанию называются prog_index.m3u8. Можно заодно проверить, как они воспроизводятся на клиентах, для этого нужно выложить их на HTTP сервер и запустить на клиенте просмотр на любой из этих prog_index.m3u8.

Этап 3. Собираем три отдельных плейлиста в единый мастер.

Для этого используется variantplaylistcreator . Запускается он так (для нашего примера):

Variantplaylistcreator -r -o movie.m3u8 \ 500K\prog_index.m3u8 movie-500K.plist \ 1000K\prog_index.m3u8 movie-1000K.plist \ 2000K\prog_index.m3u8 movie-2000K.plist

Ключ -r требует указывать так называемые resolution tags (размер кадра видео). Вообще он не обязателен, но если вы упаковываете в один мастер-плейлист несколько видео с разным разрешением (допустим, мобильное качество, 480p и 1080p), то стоит его указать. В этом случае клиент прямо из мастер-плейлиста узнает, какие разрешения доступны.

Ключ -o movie.m3u8 обозначает имя выходного файла (мастер-плейлиста).

Остальные части командной строки - это пары плейлист-plist для каждого битрейта, которые были получены на предыдущем этапе.

Теперь у нас появился мастер-плейлист movie.m3u8 . Можно выкладывать текущий каталог и подкаталоги на HTTP сервер и запускать на клиенте просмотр файла movie.m3u8. Кстати, файлы *.mov больше не нужны, для сокращения занятого под контент места их можно убрать из папки.

На этом у меня пока все, но если данная тема интересна уважаемому сообществу, могу ее продолжить и в будущих постах рассказать, как добавить в HLS альтернативные звуковые дорожки и субтитры, а также как из HLS сделать MPEG-DASH совместимый со Smart TV. Спасибо за внимание.

Предоставление услуг 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 или же поддерживают их некорректно. Также одной из проблем является невозможность правильно выбрать качество для стабильной трансляции в условиях изменения характеристик линии в интервалах времени меньших, чем длительность запрашиваемого видеофрагмента.

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

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

Что такое HLS

HLS расшифровывается как HTTP Live Streaming – протокол для потоковой передачи медиа данных через интернет. HLS нарезает видео контент в формате MP4 на короткие 10-секундные блоки, чанки. Эти короткие фрагменты доставляются по HTTP, что делает протокол совместимым с большинством устройств и файерволов.

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

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

История создания HLS

Изначально HLS был запущен компанией Apple летом 2009 года вместе с IРhone 3. Предыдущие модели IРhone испытывали проблемы с онлайн вещанием, из-за того, что иногда переключались между Wi-Fi сетями и мобильной передачей данных.

Перед выходом HLS, главным стриминговым медиа протоколом Apple был Quicktime Streaming Server. Хороший сервис, но так как он использовал нестандартные порты для передачи данных, его RTSP протокол периодически блокировался файерволами. В купе с медленным интернетом это привело к отказу от данного протокола. Но уроки, полученные при его реализации, очень пригодились в разработке HLS. Техническая сторона

HLS поток создается на лету и хранится на HTTP сервере. Видео файлы, как упомянули выше, делятся на короткие фрагменты с расширением.ts – MPEG2 Transport Stream.

HTTP сервер также создает плейлист файл с расширением.M3U8 (также называемый манифестом), который служит для индексирования всех видео чанков. Этот плейлист файл указывает на дополнительные индексные файлы для каждого из существующих качеств вещания. Даже если вы решите вещать, используя одно качество, «манифест» все равно будет создан.

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

Обзор стриминговых протоколов

Каждый из созданных ранее протоколов являл собой реализацию какой-либо инновации в медиа стриминге. Были и «войны форматов», как HD-DVD с Blu-Ray и противостояние Betamax с VHS. HLS лидер онлайн вещания, но так было не всегда и не факт, что сохранится в будущем.

RTMP или Real-Time Messaging Protocol, протокол потоковой передачи данных в реальном времени. Был создан Macromedia в середине 2000 для доставки аудио и видео контента. Часто его называют просто Flash. Позже Macromedia объединилось с Adobe Inc, который продолжает развивать RTMP как полуоткрытый протокол.

В течение прошедшего десятилетия RTMP был основным способом вещания через интернет. Только с появлением HLS его доля стала уменьшаться. На сегодняшний день большинство онлайн видео платформ работают с входящим RTMP потоком. Другими словами, вы вещаете в RTMP, который, затем, онлайн видео платформа кодирует в HLS и доставляет конечным зрителям. Правда, многие операторы CDN начинают отказываться от поддержки RTMP - пруф

Протокол для стриминга следующего поколения, разработанный Adobe называется HDS - HTTP Dynamic Streaming. Он совместим с плагином для проигрывания Flash, но частота его использования сильно уступает распространенному HLS.

Для устройств и браузеров, которые поддерживают Flash, HDS будет лучшим выбором. Он дает минимальную задержку при вещании, как и HLS разделяет медиа файлы небольшие фрагменты, поддерживает шифрование и DRM.

Microsoft Smooth Streaming

Microsoft создал свой протокол онлайн вещания, Microsoft Smooth Streaming. MSS также использует адаптивный битрейт, чтобы доставлять контент в наилучшем возможном качестве. Вещание с адаптивным битрейтом было представлено в 2008 году. С помощью MSS вещали Летние Олимпийские Игры 2008 года. Основным пользователем данного типа вещания является платформа XBox One. При этом, MSS один из наименее популярных протоколов сегодня.

MPEG-DASH

Одним из последних значимых решений в сфере стриминговых протоколов является MPEG-DASH, где DASH означает Dynamic Adaptive Streaming over HTTP, Динамическое Адаптивное Вещание через HTTP. Преимущество MPEG-DASH в том, что он признан единым международным стандартом вещания медиа через НТТР. На данный момент, он еще не широко распространен и далеко не все компании вещания поддерживают его. Но, по общему мнению, через несколько лет именно этот стандарт станет самым популярным протоколом вещания.

MPEG-DASH не зависит от вида кодека, вы можете использовать любой из них для пересылки медиа с помощью этого протокола – Н.264, HEVC/H.265, VP10

Когда же использовать HLS для онлайн вещания

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

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 часа или перемотать на начало футбольного матча без обращения по специальными архивным ссылкам.

Для организации онлайн трансляций в реальном режиме времени, видео по запросу (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 серверу, пишите. Если вам нужно что-то настроить или получить консультацию по медиа-серверам и мультимедийным системам, также можете обращаться ко мне и нашей команде через .