Hls видео как скачать


Альтернатива HLS для iOS Safari — потоковое видео через Websocket / Хабрахабр

Apple HTTP Live Streaming — широко распространенная технология для доставки видео на мобильные устройства, которая делает ставку на простоту, универсальность и проходимость. В качестве протокола доставки используется самый простой, доступный и проверенный протокол Интернета HTTP, что позволяет доставить видео практически на любое устройство или ПО в сети.

Ниже под катом рассматривается альтернатива — Websocket Streaming для iOS Safari и подробно описывается процесс тестирования.

Выигрывая в универсальности, технология HLS уступает в скорости доставки и отображения видео. Видеопоток разбивается на фрагменты (chunks), которые скачиваются по HTTP как обычные файлы, буферизуются и собираются в видео на стороне плеера. Основным недостатком является большая задержка воспроизведения видео — 5 и более секунд.

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

Аналогично с предзаписанным видео: 10 секунд буферизации ни на что не повлияют.

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

16+

Другой пример — видеочат с 'моделью'. Клиент пишет в чат 'bb, show me your tits' и совсем не ожидает того, что заказанная услуга придет не мгновенно… Последний случай особенно вопиющ, по мнению наших коллег, специализирующихся на таких видеочатах.

Вот как выглядит HLS-плеер на iOS Safari:

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

Неудобства возникают в том случае, когда от web-приложения требуется некоторая интерактивность. К подобным приложениям могут предъявляться следующие требования:

  • воспроизведение видео непосредственно на HTML-странице в браузере;
  • на этой же странице могут быть размещены другие элементы, например, чат.
В основном, к таким web-приложениям относятся вебинары, видеочаты и трансляции с возможностью одновременного обсуждения в чате (например, спортивное событие).

На первый взгляд, самое простое решение — сделать iOS приложение для такой задачи, например, трансляция+чат и отправить пользователей скачивать приложение. Однако, как показывает практика, не все пользователи любят/умеют делать дополнительные телодвижения: заходить на App Store, озадачиваться настройками безопасности, скачивать приложение, запускать его и, наконец, смотреть трансляцию. Гораздо проще и короче в этом случае выглядит путь “клик по ссылке в Safari” — “просмотр трансляции прямо в браузере”.

Итак, имеем два требования для iOS Safari:

  1. видео должно воспроизводиться с минимальной задержкой;
  2. видео должно воспроизводиться прямо в браузере средствами HTML5.
Оптимальным решением была бы поддержка технологии WebRTC. Действительно, применение технологии WebRTC решило бы проблему задержки и позволило бы играть поток прямо в браузере так, как это работает, например, в Android Chrome. К сожалению, поддержки WebRTC нет в iOS Safari и перспективы такой поддержки на данный момент весьма туманны.

Как обычно, когда нет поддержки от официального производителя, есть альтернативы, одна из которых — доставка видео на iOS Safari по протоколу Websockets и отрисовка этого видеопотока средствами браузера.

Websockets — в данном случае единственный доступный в iOS Safari протокол, способный обеспечить быструю доставку видеопотока. Протокол работает на основе TCP как и HTTP, но, в отличие от последнего, гораздо лучше подходит для передачи потоковых данных в силу того, что бинарные данные передаются внутри уже установленного соединения и нет лишних HTTP заголовков при их передаче.

В настоящей статье мы сравним классический подход с использованием HLS c вещанием того же живого потока по Websocket на iOS Safari, для этого настроим и протестируем обе технологии.

Браузер iOS Safari выбран не случайно. IE и Mac Safari поддерживают Flash, Chrome, FF и Opera поддерживают WebRTC. И только iOS-устройства ограничены использованием HLS, альтернатива которому рассматривается в настоящей статье.

Стриминг видео через Websocket назовем VoW (Video over Websockets), а плеер, который этот поток играет, — VoW-Player.

Подробно опишем тестирование HLS и VoW, включая установку всего необходимого инструмента.

Создаем два дроплета

Для чистоты эксперимента используем два разных виртуальных сервера Centos 6.5 64 bit, 1 GB RAM на digitalocean.

Заходим на oracle.com, скачиваем, распаковываем и устанавливаем JDK

Oracle JDK можно скачать здесь.

Можно было бы установить и RPM, но простое копирование папки тоже работает.

tar -xvzf jdk-8u45-linux-x64.tar.gz mkdir /usr/java mv jdk1.8.0_45 /usr/java ln -sf /usr/java/jdk1.8.0_45 /usr/java/default ln -sf /usr/java/default/bin/java /usr/bin/java java -version java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) Качаем Wowza

Wowza будет принимать RTMP-поток и отдавать его как HLS. Скачиваем с сайта wowza.com. После этого нужно будет получить бесплатную лицензию разработчика.

Устанавливаем Wowza

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

chmod +x WowzaStreamingEngine-4.1.2.tar.bin ./WowzaStreamingEngine-4.1.2.tar.bin Запускаем Wowza

Сам сервер и административный интерфейс запускаются отдельно.

service WowzaStreamingEngine start service WowzaStreamingEngineManager start Заходим в админ интерфейс Wowza

После успешного запуска админка доступна на порту 8088. Логин и пароль были заданы во время установки.

Разрешаем подключения в настройках live > Incoming Security

По умолчанию RTMP-Publishing разрешен только по паролю. Разрешаем публиковать потоки всем желающим — опция ‘no authentication required’. Так будет проще тестировать, а позже всегда успеем закрыть доступ.

Качаем Wirecast Live Encoder

Выбор Wirecast был обусловлен тем, что он хорошо кодирует звук в AAC. Например, FMLE (Flash Media Live Encoder) под Windows 8 такого делать не умеет. FMLE под Mac умеет кодировать AAC, но Mac под рукой не оказалось.

К сожалению, с Wirecast-ом не получилось захватить видео с вебкамеры на Windows 8.1 64 bit, поэтому пришлось стримить видеоролик. Ниже дано описание процесса. На момент написания статьи использовалась версия Wirecast-6.0.4-64-bit.

Качаем sample.mp4 файл из каталога WowzaStreamingEngine/content на сервере

Видеоролик про зайца в формате MPEG4 идет в комплекте с Wowza. Скачиваем его на компьютер, где установлен Wirecast Encoder.

Открываем sample.mp4 файл в Wirecast

Добавляем ролик в Wirecast, просто выбрав его в файловой системе.

Запускаем воспроизведение sample.mp4 в Wirecast

Чтобы поставить ролик на воспроизведение, нужно нажать кнопку с изображением правой стрелки, которая находится прямо под зайцем. См. скриншот ниже.

Настраиваем Output Settings

Теперь задаем настройки кодирования. С этими настройками видео будет перекодировано и отправлено в сеть по протоколу RTMP.

Кодируем под мобильные устройства H.264 + AAC, задаем разрешение 320x240.

Настраиваем адрес RTMP-севрера

Здесь указываем адрес дроплета, на котором установлена Wowza. Имя потока: myStream.

Начинаем вещание потока

Нажимаем кнопку ‘Stream’ чтобы начать процесс перекодирования видео и отправку RTMP-потока на сервер. В правом верхнем углу появляется зеленый индикатор соединения.

Открываем админку Wowza в iOS Safari, приложение live

Если открыть админку не в iOS Safari, то при попытке получить УРЛы для воспроизведения по HLS будет выдана ошибка ‘Ваше устройство не поддерживает HLS’ или что-то похожее, поэтому заходим в админку в iOS Safari, выбираем приложение ‘live’ и кликаем по кнопке ‘Test Players’.

Кликаем по HLS-урлу и начинаем воспроизведение в Apple iPhone Safari

Никакого плеера там не оказалось, просто HTTP URL, с которого можно забрать видео по HLS. iOS Safari браузер открывает этот URL и включает внутренний HLS Player на воспроизведение видео. Получаем по HLS ролик, который стримит Wirecast в режиме Live.

Отметим, что задержка воспроизведения составляет около 25 секунд. Наверняка, это где-то можно тюнить, но ‘из коробки’ имеем то, что имеем.

Таким образом получаем следующую схему вещания HLS:

Схема достаточно простая: отправляем ролик по RTMP и раздаем по HLS.

Устанавливаем JDK на второй дроплет тем же способом, что и для Wowzatar -xvzf jdk-8u45-linux-x64.tar.gz mkdir /usr/java mv jdk1.8.0_45 /usr/java ln -sf /usr/java/jdk1.8.0_45 /usr/java/default ln -sf /usr/java/default/bin/java /usr/bin/java

Устанавливаем и настраиваем Web Call Server 4

Скачиваем и устанавливаем WCS4-сервер

wget http://flashphoner.com/download-wcs4-server.tar.gz tar -xvzf download-wcs4-server.tar.gz cd FlashphonerWebCallServer-4.0.1212 ./install.sh Установщик спросит два раза IP-адрес. Нужно указать IP-адрес дроплета оба раза.

IP адрес определяется например командой ifconfig.

В нашем случае это 46.101.139.106.

Получаем бесплатную лицензию и активируем ее после установки

cd /usr/local/FlashphonerWebCallServer-4.0.1212/bin ./activation.sh

Добавляем поддержку AAC-кодека в настройках и RTSP interleave mode

AAC — это mpeg4-generic. ‘Interleave mode’ добавляем на тот случай, если Wowza-сервер был сконфигурирован на работу RTSP через TCP.

mc -e /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties codecs =opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,vp8,h364,flv,h363,h363p,mpv rtsp_interleaved_mode=true

Запускаем сервер

Сервер запускается довольно долго на виртуалке. Ждем 1 минуту. Перед запуском желательно прописать в /etc/hosts IP адрес сервера и имя хоста (hostname). Без этого с запуском могут быть проблемы.

hostname wcs

service webcallserver start

Устанавливаем и запускаем Apache

Apache будет отдавать страничку с тестовым плеером.

yum install httpd service httpd start

Разворачиваем пример с VoW Player в web-каталоге

cd /var/www/html/ wget http://flashphoner.com/download-wcs4-client.tar.gz tar -xvzf download-wcs4-client.tar.gz

Указываем URL подключения к серверу и стрим, который нужно забрать

mc -e /var/www/html/examples/min/vow-player-min.js

Подключаемся к серверу через Websocket:

var url = "ws://46.101.139.106:8080";

Забираем поток с Wowza по RTSP:

var streamName = "rtsp://46.101.139.105:1935/live/myStream";

Открываем плеер в iOS Safari

Открывается простая HTML-страница: 46.101.139.106/examples/min/vow-player-min.html

На странице есть область отображения видео, две кнопки и область отображения текущих статусов воспроизведения.

Начинаем воспроизведение

Нажимаем ‘Play’ для того чтобы начать воспроизведение. Видим, что внутренний плеер iOS не подключается и видео воспроизводится непосредственно в теле HTML-страницы. Контролы ‘Play’ и ‘Pause’, а также блок статусов остаются на своих местах.

Так выглядит видео, растянутое на весь экран пальцами:

Если открыть ту же страницу в Google Chrome и применить Developer Tools, то можно увидеть HTML5 canvas — элемент, в который происходит отрисовка видео.

Если копнуть глубже и заглянуть во вкладку ‘Network’, можно увидеть множество Websocket Binary Frames, прилетающих с высокой скоростью, — это и есть тот видеопоток, который мы видим на HTML5 Canvas — элементе.

Задержка воспроизведения кардинально отличается от HLS и составляет всего около 3 секунд. Картинку видно четко. Артефакты отсутствуют. Аудио и видео отыгрывают синхронно без видимых недостатков.

В результате имеем следующую следующую схему вещания:

Интересно было бы также провести тесты расхода батареи. Есть основания полагать, что при VoW батарея садится быстрее, чем при штатном использовании HLS-плеера, хотя бы потому, что при HLS возможен аппаратный декодинг видео, а в VoW-плеере видео декодируется с помощью JavaScript.

В качестве итога нарисуем табличку различий данных технологий вещания.

Под сложностью настройки здесь понимается ввод дополнительного звена (WCS-сервер) и сам VoW-Player, что соответственно увеличивает время и сложность настройки системы.

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

HLS (iOS Safari)

VoW (IOS Safari, Windows Google Chrome)

Бесперебойную работу урлов не гарантирую.

Отдельная благодарность зайцу Big Buck Bunny. Без него не вышло бы такого красочного повествования.

habrahabr.ru

Готовим адаптивное видео для HTTP Live Streaming / Хабрахабр

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

habrahabr.ru

Когда использовать протокол HLS | Boomstream

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

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

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

HDS

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

boomstream.com

Какой бывает HTML5-стриминг (и почему mp4-стриминга не существует)

Нередко клиенты спрашивают, умеет ли наш сервер «mp4-стриминг в HTML5». В 99% случаев спрашивающий не понимает о чём говорит. В этом сложно винить клиентов: из-за путаницы с терминами, технической сложности и большого разнообразия вариантов стриминга запутаться очень легко.

В этой статье мы расскажем, какой бывает HTML5-стриминг, какие варианты хорошие, и почему, чёрт побери, нельзя говорить «mp4-стриминг».

▍Термины

HTML5-видео — это когда вы вставляете в веб-страницу тег <video> и указываете ему какой-то src. HTML5-стриминг — это то же HTML5-видео, но когда в src не готовый файл, а постоянно обновляющийся видеопоток. Ролик на Ютубе — это HTML5-видео, трансляция в Твитче — HTML5-стриминг.

Тегу <video> неважно, как видеопоток формируется и передаётся, и сможет ли браузер его проиграть. Главное, чтобы в src была ссылка на какой-то видеопоток. Говоря техническим языком, спецификация ничего не говорит о том, какие протоколы, транспорты и кодеки поддерживаются в HTML5-видео.

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

Протокол обычно подразумевает хотя бы команду Play (начать проигрывание), но иногда есть и расширенные варианты: пауза, продолжение, публикация, перемотка и т. п.

Примеры протоколов: RTSP, RTMP, HTTP, HLS, IGMP.

Транспорт, или транспортный контейнер, или контейнер — это то, как сжатое видео упаковывается в байты для передачи от одного участника к другому (по какому-то протоколу). Примеры контейнеров: MPEG-TS, RTMP, RTP.

Обратите внимание, что RTMP оказался и в протоколах, и в транспортах. Это потому, что в описании RTMP есть спецификация и того, что должны слать друг другу стороны, чтобы видео потекло (т. е. протокол), и того, как упаковывать видео (т. е. транспорт). Так бывает не всегда. Например в протоколе RTSP видео упаковывается в транспорт RTP.
Кодек — многозначный термин. Здесь он означает способ сжать сырое видео. Разница между кодеком и транспортом в том, что кодек — это про подготовку видео, а транспорт — про передачу видео по протоколу. Видео, сжатое одним кодеком, можно пересылать по разными протоколам и разными транспортами. Большинство видеостриминговых серверов не залезают глубже кодированного видео и оперируют только протоколами и транспортами.

Примеры кодеков: h364, aac, mp3.

Из-за того, что термин многозначный, возникает путаница с названиями. Например, H.264 — это стандарт того, как упаковать поток огромных сырых видеокадров в очень мало байтов, libx264 — это библиотека для сжатия по этому стандарту, а ещё есть одноимённый софт под Винду, который умеет декодировать h364 и проигрывать его на экране.

Итак, в спецификации HTML5 не описаны протоколы, транспорты и кодеки. Поэтому авторы браузеров сами выбирают, что поддерживать, а под «HTML5-стримингом» подразумевают разные вещи.

При этом есть комбинации, которые поддерживаются значительной частью браузеров. Рассмотрим самые перспективные.

▍HLS

HLS — это h364-видео и aac- или mp3-аудио, упакованное в транспорт MPEG-TS. Поток разбивается на сегменты, описанные в m3u8-плейлистах, и раздается по HTTP. HLS поддерживает мультибитрейтные потоки, Live/VOD. Вариант очень простой, но в то же время имеет много деталей, из-за чего на разных устройствах работает по-разному.

Разработали HLS в Эппле, поэтому изначально он работал только в Сафари на iOS и MacOS. Даже Сафари на Windows не умел играть HLS (когда еще была версия под Win).

Тем не менее, сейчас HLS умеют проигрывать все телевизионные приставки и даже почти все устройства на Андроиде.

Но не всё гладко. Производители сторонних плееров плюнули на стандарт Эппла в части донесения разных аудиодорожек и добавили проигрывание всего что есть в обычном MPEG-TS: mpeg2 video, mpeg2 audio и т. п. Из-за этого приходится отдавать разные форматы плейлистов для разных плееров.

▍MPEG-DASH

MPEG-DASH — обычно это h364/h365-видео и aac-аудио, упакованное в транспорт mp4, или vp8/vp9, упакованное в WebM, хотя стандарт и не привязан к конкретным кодекам, протоколам и транспортам. Как и в HLS, поток может разбиваться на сегменты, но это необязательно. Вместо плейлистов — MPD-манифест в XML.

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

MPEG-DASH хорош тем, что в большинстве браузеров работает нативно, через MSE (о том, что это такое, — чуть ниже). Для него даже нет реализации на Флеше — это честный, бескомпромиссный HTML5. Определенно, MPEG-DASH — самый настоящий HTML5-стриминг, за ним будущее.

▍MSE

Когда стало ясно, что Флеш всё-таки умрёт (после сотни ложных похорон), ребром встал вопрос о том, что придёт ему на смену. Хорошо было бы получить в браузерах возможность проигрывать видео по качеству и удобству близко к тому, что умеет Флеш (а он это делает всё-таки хорошо).

Во Флеше давно появился очень удобный механизм для универсального проигрывания разных вариантов — appendBytes. Суть в том, что пользовательский код сам как хочет скачивает кадры сжатого видео, упаковывает в оговоренный контейнер (с Флешем это flv) и засовывает в видеопроигрыватель. Т. е. протокол и транспорт реализуются в пользовательском коде, запускаемом в браузере.

MSE (Media Sources Extensions) — это расширение спецификации HTML5, которое позволяет делать то же, что делает appendBytes во Флеше. К сожалению, MSE намного сложнее как в понимании, так и в реализации.

MPEG-DASH, созданный на его базе, ещё хитрее, поэтому работать с ними то ещё удовольствие: тонны XML, парсинг бинарных контейнеров в Яваскрипте, непродуманные на этапе дизайна вопросы нарезки на сегменты — всё как мы любим, всё что нужно для единой безглючной реализации во всех браузерах.

Интересно, что MSE работает не только с MPEG-DASH, но и с HLS. Существует реализация hls.js, которая скачивает HLS-плейлисты, скачивает MPEG-TS-сегменты, перепаковывает их в нужный для MSE формат и играет через MSE. Эппл даже сделала шаг в сторону совместимости с MPEG-DASH — использование mp4-контейнеров в HLS.

К концу 2017 года Флеш скорее всего умрёт окончательно, и уже сегодня можно смело начинать проект с MPEG-DASH.

▍WebRTC

Во Флеше была сделана годная попытка в одной технологии реализовать и риалтайм-общение, и массовый броадкастинг. К сожалению, в HTML5 так не вышло. Для просмотра трансляций у нас есть MSE, а для видеозвонков — WebRTC.

WebRTC — это SIP в браузере: способ организовать аудио- и видеоканал и канал данных между двумя браузерами при посредничестве сервера.

Технология не предназначена для стриминга, но в принципе может и его, так что было бы неправильно забыть про него. WebRTC тоже считается HTML5, потому что вроде как ничего кроме Яваскрипта в браузере не требует. Зато требует наличия последних версий обоих популярных браузеров, а с Эджем пока вообще не совместимо.

Путаницу в понимании WebRTC вносит его использование в торрент-доставке телевидения. Суть в том, что браузеры через WebRTC организуют сеть каналов данных, а дальше по этой сети раздаются HLS- или MSE-сегменты видео, а проигрывание происходит через Флеш или MSE. Т. е. WebRTC — для доставки, MSE — для проигрывания. Важно не путать это с использованием WebRTC для проигрывания видео.

▍Так что там с mp4-стримингом?

Любой современный браузер скорее всего сможет по протоколу HTTP запросить файл, упакованный в транспорт mp4 и содержащий внутри видео, сжатое кодеком h364/aac. И даже попытаться проиграть его. Это самый удобный, понятный и стандартный вариант проигрывания файлов. Лежит себе файлик на диске, nginx его отдает. Код, проигрывающий mp4 в браузерах достаточно хорош. Например, он умеет даже скачивать куски видео по необходимости (в отличие от Флеш-плеера, который скачивает видео целиком).

Вокруг h364 сложилось немало шумихи по поводу его «закрытости» и «несвободности». Так что есть «открытая» альтернатива, которую форсит Гугл — видеокодеки vp8 и vp9, упакованные в транспорт WebM. WebM — это подмножество транспорта mkv (a. k. a. Матрёшка), который очень похож на mp4 по сути, но отличается от него своей «бинарностью».

Именно отсюда растут ноги у такого явления как «mp4-стриминг», который устроен как WebM. Дело в том что в обычном mp4 в самом начале указывается размер всего контейнера. Поэтому, если мы хотим отдать по обычному mp4 прямой эфир, у нас ничего не получится. А чтобы всё-таки получилось и можно было создавать mp4 без фиксированного конца, придуман следующий ход: сначала пишется mp4 без кадров, а потом в конце подписываются блоками по несколько секунд фрагменты с кадрами. Это называется mp4 fragmented, или mp4 streaming.

По сути это никакой не стриминг, а костыль, позволяющий создать его видимость. Mp4 — отличный формат для скачивания видео, но негодный для стриминга, так что про него можно просто забыть и никогда не использовать термин «mp4-стриминг».

▍Выводы

  • Хорошие варианты HTML5-стриминга: MPEG-DASH и HLS. Они подходят и для мобильных устройств, и для ПК, и для приставок.
  • Флеш всё-таки умрет, и MSE уже сейчас занимает его место.
  • WebRTC — HTML5 технология, в первую очередь, для общения, а не для телевизионного вещания.
  • Не приносите в веб старые кодеки и не пытайтесь доставлять mp2video и mp2audio по HLS, даже если ваш плеер это умеет.
  • Никогда не говорите «mp4 стриминг». Пожалуйста.

habrahabr.ru

Как открыть HLS файлы - Файлы с расширением HLS

Что обозначает расширение HLS?

автор: Jay Geater, главный писатель по вопросам технологий

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

До того, как вы сможете открыть файл HLS, вам необходимо выяснить, к какому виду файла относится расширения файла HLS.

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

Ответ:

Файлы HLS имеют Uncommon Files, который преимущественно ассоциирован с Binary Data.

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

Как открыть ваш файл HLS:

Самый быстрый и легкий способ открыть свой файл HLS — это два раза щелкнуть по нему мышью. В данном случае система Windows сама выберет необходимую программу для открытия вашего файла HLS.

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

Если ваш ПК открывает файл HLS, но в неверной программе, вам потребуется изменить настройки ассоциации файлов в вашем реестре Windows. Другими словами, Windows ассоциирует расширения файлов HLS с неверной программой.

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

Загрузки программного обеспечения, связанные с расширением файла HLS:

* Некоторые форматы расширений файлов HLS можно открыть только в двоичном формате.

Скачать FileViewPro для открытия ваших файлов HLS прямо сейчас

HLS Инструмент анализа файлов™

Вы не уверены, какой тип у файла HLS? Хотите получить точную информацию о файле, его создателе и как его можно открыть?

Теперь можно мгновенно получить всю необходимую информацию о файле HLS!

Революционный HLS Инструмент анализа файлов™ сканирует, анализирует и сообщает подробную информацию о файле HLS. Наш алгоритм (ожидается выдача патента) быстро проанализирует файл и через несколько секунд предоставит подробную информацию в наглядном и легко читаемом формате.†

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

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

Ваш файл анализируется... пожалуйста подождите.

Имя файла:

Размер файла:

Прервать

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

Об авторе: Джей Гитер (Jay Geater) является президентом и генеральным директором корпорации Solvusoft — глобальной компании, занимающейся программным обеспечением и уделяющей основное внимание новаторским сервисным программам. Он всю жизнь страстно увлекался компьютерами и любит все, связанное с компьютерами, программным обеспечением и новыми технологиями.

www.solvusoft.com


Смотрите также