что значит hls в видео
Что значит hls в видео
Плюсы и минусы HTTP Live Streaming
HLS (HTTP Live Streaming) — это протокол для передачи видео с адаптивным битрейтом. Первоначально разработанный Apple для яблочных систем, сегодня HLS стал самым используемым протоколом для передачи потокового медиа. В этой статье — всё про его особенности.
Как работает HTTP Live Streaming
Протокол HLS разбивает поток медиаданных на небольшие фрагменты, а затем создает специальный файл — манифеста: там хранится информация об этих фрагментах. Плеер периодически перезапрашивает манифест: если в файле появляются новые фрагменты, он загрузит и воспроизведет их. При этом благодаря адаптивному битрейту качество видео подстроится в зависимости от размера экрана или пропускной способности соединения с интернетом.
HLS исторически поддерживает такие кодеки медиа, как h.264, AAC или MP3. Относительно недавно этот список дополнил и кодек видео h.265. Аналогичным образом работают протоколы MPEG-DASH, Microsoft Smooth Streaming и Adobe HTTP Dynamic Streaming (HDS).
Преимущества протокола HLS
Доставка на любые устройства
Microsoft Smooth Streaming и Adobe HTTP Dynamic Streaming (HDS) HLS поддерживают большинство браузеров и мобильных устройств. В перспективе MPEG-DASH тоже может получить широкую поддержку, но пока что он не поддерживается устройствами Apple. Остальные два протокола, Microsoft Smooth Streaming и Adobe HTTP Dynamic Streaming (HDS), сегодня совсем не распространены.
Запись и прямой эфир
Протокол HLS поддерживает как прямые трансляции, так и просмотр записей. Благодаря технологии манифеста и фрагментации, перемотка работает быстро и доступна одновременно с возможностью переключиться в прямой эфир. Это важное преимущество перед протоколами RTMP и WEBRTC, ориентированными только на прямой эфир.
Управление цифровыми правами
Протокол HLS поддерживает управление цифровыми правами (DRM). Технология позволяет отследить незаконное использование контента — как записей, так и прямого эфира. При этом инфраструктура управления цифровыми правами достаточно проста.
Неограниченная аудитория
Протокол HLS очень хорошо масштабируется на любое количество зрителей с использованием сервисов CDN и гарантирует бесперебойную доставку контента в любую точку мира.
Недостатки протокола HTTP Live Streaming
Любые технологии не идеальны, и HLS не исключение. Один из наиболее распространенных вопросов — латентность.
Задержки HLS
Латентность — это промежуток между тем, когда событие происходит в реальном мире, и тем, когда зрители смогут его увидеть, смотря прямой эфир. Это время необходимо на оцифровку изображения и звука, подготовку нескольких вариантов для адаптивного битрейта и доставку в плеер через интернет.
Но цель HLS — максимальная совместимость с клиентскими устройствами, а не минимизация абсолютной задержки. Поэтому типовое значение задержки — 10-25 секунд.
Обычно это проблема для узкой аудитории клиентов — например, для геймеров и любителей спорта. В этих ситуациях скорость важна. Тем не менее, большинство пользователей могут легко игнорировать небольшую задержку потока, потому что это никак не влияет на качество полученной информации.
Можно ли решить вопрос с латентностью?
Протокол HLS продолжает развиваться. Летом 2019 года компания Apple разработала расширение LHLS — оно позволяет достичь задержки менее 2 секунд. В перспективе эта модификация будет поддерживаться практически всеми плеерами и мобильными устройствами.
В Facecast мы также разработали варианты потоковой передачи HLS с низкой задержкой. Наше решение уменьшит задержку до 10 секунд или меньше. Оно соответствует современным стандартам безопасности браузера посредством доставки HTTPS и позволит охватить все мобильные устройства.
Мы надеемся, что в ближайшем будущем мы сможем предложить это решение для пользователей публичной версии для тарифа Профи и выше.
Вывод
HLS — это мощная технология, которая стала отраслевым стандартом. Надеемся, эта статья познакомила вас с основами этой технологии, принципами ее работы, ее преимуществами и недостатками.
Есть вопросы о HLS? Дайте нам знать об этом в комментариях!
HLS против RTMP — сухая статистика
Если кто-то решил сделать самостоятельно обработку, хранение и передачу видео для своего онлайн-проекта, а не использовать сайты вроде YouTube, он неизбежно приходит к вопросу о том, какой протокол передачи использовать для трансляции видео на устройства пользователей. Выбор невелик, т.к. есть ряд отраслевых стандартов, которые поддерживают те или иные устройства. Кроме того, выбор протокола во многом зависит от «класса» видео — живая трансляция или видео-по-запросу. От выбора протокола также зависит и выбор медиа-сервера, который будет двигателем вашей медиа-машины: будете ли ставить несколько разнородных серверов или построите сеть доставки на одном решении? Поэтому нужно взвесить всё и принимать решение исходя из критериев вашего бизнеса.
В общем, получается уравнение со многими неизвестными. Здесь немаловажна динамика процесса — а куда вообще идёт индустрия? Вдруг я вложусь в поддержку технологии, а она загнётся через год, ведь такое уже бывало. Или поставлю на модную технологию, а её никто не поддерживает?
Мы решили оценить, как менялась доля разных протоколов с течением времени — посмотреть в динамике весь процесс. Данные взяли за последний год.
Исходные данные
Для начала — кто мы такие, чтобы судить о долях рынка? Мы — разработчики веб-сервиса отчетности для медиа-серверов. На рынке работаем четвертый год и к нам приходят компании с разными инфраструктурами, разным количеством серверов и разными потребностями. Получается неплохой слепок состояния отрасли.
Мы сделали небольшой отчет, где можно выбирать диапазон дат и получать данные с графиком по количеству просмотров видео через разные протоколы.
Отчет также периодически обновляется у нас в блоге, он доступен по соответствующему тегу.
Поехали
Отчет за июнь/июль 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 — отсюда и скачок этого протокола.
Март — май 2014. 1.9 миллиарда просмотров и HLS уже безоговорочный лидер с более чем половиной рынка. RTMP уверенно держит четверть, остальные заняли те доли, которые мы видели на первой диаграмме.
Как это всё понимать?
HLS (HTTP Live Streaming) на сегодня стал стандартом де-факто в мире потоковой передачи видеоданных для потребительских устройств. Изначально сделанный для девайсов одной фруктовой компании, быстро набрал популярность на других устройствах — десктопах, STB, а также Андроидах — начиная с версии 4 они начали понимать этот протокол.
RTMP остается незаменим там, где требуется передача данных близко к реальному масштабу времени. HLS даёт некоторую задержку при соединении, чтобы скачать первый чанк с данными, а в случае с RTMP отображение начинается практически сразу. В целом, это наиболее совершенный протокол передачи медиа в реальном времени, несмотря на все неоднозначности в реализации (каждый новых вендор добавляет свои особенности), более трудоёмкое развёртывание и масштабирование относительно HLS.
RTSP по-прежнему используется как fallback для старых Андроидов.
Отдельно хочется сказать про MPEG-DASH — несмотря на все усилия индустрии, переход на него происходит со скрипом. Конечно, рано или поздно произойдет плавный переход со всех HTTP-based протоколов — HLS, HDS, SmoothStreaming — на него, но пока это лишь планы.
Интересна и доля Progressive download, на котором работает видео на немалом количестве сайтов. Технически очень простой, он позволяет начать раздачу видео-по-запросу практически безо всяких специальных медиа-серверов. Поскольку Вовза по этому протоколу не работает, его долю стало возможным отследить только по мере установки нашего Nimble Streamer на сервера клиентов. Текущие 20М+ просмотров за 2 месяца лета — не предел, и фактическая доля этого протокола совершенно точно выше. Хотя, у него есть и ограничения, которые оставляют ему относительно небольшую нишу.
Если есть вопросы по сбору данных или их интерпретации — задавайте.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
HLS (HTTP Live Streaming)
| Разработан: | Apple Inc |
|---|---|
| Семейство: | HTTP |
| Назначение протокола: | протокол передачи видео |
| Основные реализации (клиенты): | IOS,Safari,Google Chrome,QuickTime Player |
| Основные реализации (серверы): | Adobe Media Server, Nginx Plus, Wowza Streaming Engine |
| Основные расширения: | .m3u8 |
| Вступил в силу с: | Май 2009 |
Содержание
История
Архитектура
Для передачи аудиовидеоданных по протоколу HLS используется транспортный поток MPEG-2 TS, в котором видео закодировано в формате AVC (H.264), аудио – AAC.
В основе адаптивного стриминга лежит использование потоков с одинаковым содержимым медиаданных, но разным битрейтом (см. рисунок 3):
Особенности
HTTP Live Streaming предоставляет механизмы для обеспечения масштабируемости и адаптируемости сети, что позволяет сделать качество воспроизведения в беспроводных сетях с высокой пропускной способностью и низким качеством воспроизведения на 3G-сетях, где пропускная способность снижается. HTTP Live Streaming также обеспечивает защиту от ошибок, создавая различные потоки видео, чтобы использовать их, если есть какие-либо ошибки в сегменте.HLS потоки могут нести обобщенные метаданные ID3 как отдельный PID в транспортном потоке.
Масштабируемость
Для того, чтобы сделать систему масштабируемой и адаптируемой к пропускной способности сети, видео-поток кодируется в разных качествах. Таким образом, в зависимости от скорости пропускной способности и передачи данных по сети, видео будет воспроизведено на разных уровнях качества. Для реализации этого, система должна кодировать видео в различных качествах и генерировать индексный файл, который содержит расположение различных уровней качества. Программное обеспечение клиента управляет различными качествами, что делает запросы в максимально возможном качестве в пределах пропускной способности сети. Таким образом, более низкое качество просмотра будет в сетях 3G и высочайшее качество просмотра видео у Wi-Fi.
Доступность
Для поддержания потока HLS включает в себя функции для восстановления после отключения.Для достижения этой цели несколько потоков хранятся в индексном файле в таком же качестве. Если клиент не может загрузить поток, он пытается загрузить следующий, повторяя до тех пор,пока рабочий поток не будет найден или все потоки не подойдут.
Примеры серверной реализации
Ниже приведены примеры серверных решений, поддерживающие HLS. (см. рисунок 5)
Клиенты
Преимущества и недостатки HLS
Преимущества HLS
Передача медиаданных по технологии HLS имеет следующие преимущества:
Недостатки HLS
Некоторые отрицательные стороны HLS:
Этапы создания и упаковки видео для HLS
Простота в использовании HLS позволяет легко кэшировать отдельные сегменты, а также раздавать сам HLS практически с любой серверной платформы. Для этого существуют 3 шага:
Например, если у вас есть исходный файл movie.mp4 (предполагаем, что его битрейт не ниже 2000К), тогда достаточно будет запустить ffmpeg примерно так (ключи обозначают что звуковую дорожку можно взять как есть, а видео битрейт изменить):
Шаг 2. Создание однобитрейтных плейлистов. Следующим этапом является создание набора из плейлиста m3u8 и сегментов *.ts. Важно, чтобы сегменты получились синхронными между разными битрейтами. При этом, к сожалению, мастер-плейлист затем нужно будет создавать руками, в этом может помочь пакет HTTP Live Streaming Tools (для macOS). В него входит несколько программ, из которых нам пригодятся две: mediafilesegmenter и variantplaylistcreator. Первая превращает mp4 файл в плейлист m3u8 и «нарезает» сегменты, вторая собирает несколько однобитрейтных плейлистов в мастер-плейлист.
Возвращаясь к примеру, создаем три плейлиста из трех файлов полученных на предыдущем шаге.
Шаг 3. Сборка в единый мастер. Для этого используется variantplaylistcreator. Запускается он таким образом (для нашего примера):
Хранение видео в Yandex.Cloud
Если вам нужно добавить на свой сайт видео, то может возникнуть вопрос, где его хостить и как потом раздавать. В этом посте разберем варианты и рассмотрим примеры использования Yandex Object Storage.
Формат MP4 знаком, наверное, всем. Но если мы хотим показывать видео на сайте эффективно, то стоит задуматься: лучшее ли это решение для нашей задачи — просто выложить все видео одним файлом MP4?
Протокол HLS (HTTP Live Streaming) был предложен в 2009 году и к настоящему времени де-факто стал стандартом в области адаптивного видеостриминга.
HLS был разработан Apple как замена их собственной разработки QuickTime Streaming Server, а также как альтернатива другому популярному на тот момент протоколу — Real-Time Messaging Protocol (RTMP). Этот протокол, выпущенный Adobe в 2002 году, использовал технологию Flash, чтобы передавать видео с низкой задержкой через интернет. Не смотря на то, что Flash давно «умер», RTMP до сих пор остается популярным протоколом для видеотрансляций.
Что же такое HLS?
Хотя HLS не так широко известен, но он, наряду с MPEG-DASH и SRT, остается одним из главных протоколов, которые обеспечивают доставку видео- и аудиоконтента в современном интернете. Велики шансы, что вы пользуетесь им каждый день, даже не задумываясь об этом. Особенно если вы — пользователь экосистемы Apple.
Хотя HLS и был разработан в Apple, он широко поддерживается и на других платформах: Linux, Windows, смартфонах с Android и iOS, OTT-устройствах, Smart TV, а также в браузерах Google Chrome, Safari, Android Browser, Microsoft Edge, Chrome for Android и Opera Mobile. На части платформ поддержка нативная, в других же она реализована через JS-плееры.
Тот факт, что потоковая передача HLS обычно осуществляется через видеоплеер HTML5, делает HLS универсальным и широко совместимым. Его часто называют «HTML5-видео», что не совсем точно. Видеоплеер HTML5 просто совместим с HLS.
Что значит «протокол»?
HLS — это протокол потоковой передачи видео. Но что это означает? Возможно, вы слышали термин «кодек», но важно отметить, что потоковый протокол — это не кодек. Протокол — это более широкая категория.
Потоковый протокол — это стандартизированный метод передачи видеоконтента между устройствами. Протокол может предполагать использование определенного кодека (или кодеков), который будет использоваться для сжатия и распаковки видео- и аудиоконтента.
Например, HLS поддерживает множество популярных кодеков:
Audio: AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, Apple Lossless, FLAC
Video: H.265, H.264
Преимущества HLS
HLS предназначен для обеспечения надежности и динамической адаптации к сетевым условиям путем оптимизации (т. е. ухудшения или улучшения) воспроизведения видео для доступных скоростей интернета. Кроме того, он «заботится» о разных аспектах, которые связаны с доставкой видеоконтента зрителям:
Стриминг с адаптивным битрейтом (Adaptive Bitrate Streaming) — HLS подстраивает качество видео под текущую скорость интернет-канала. Это позволяет авторам предлагать несколько видеопотоков в разном качестве, а плееру переключаться между ними незаметно.
Пример среднего битрейта видео (Кбит/с), источник: Apple
Совместимость со многими устройствами — HLS гарантирует, что ваш видеоконтент будет воспроизводиться на любом устройстве, которое может запустить совместимый плеер (например, HTML5).
Субтитры — HLS поддерживает скрытые субтитры. Это позволяет авторам встроить несколько потоков субтитров (например, на разных языках).
Возможность менять аудио дорожку — HLS поддерживает несколько потоков аудио, между которыми можно переключаться.
Возможность вставлять рекламу — HLS использует для этого технологии VPAID и VAST.
Масштабирование — HLS обладает высокой масштабируемостью для доставки видеофайлов и потокового контента через глобальные сети доставки контента (CDN). В отличие от протокола RTMP, который работает совместно с Flash Player, HLS может легко масштабироваться для доставки с помощью обычных веб-серверов через CDN. Распределяя рабочую нагрузку по сети серверов, CDN приспосабливаются к всплескам вирусной аудитории и гораздо большим, чем ожидалось, живым аудиториям. CDN также помогают улучшить качество просмотра, кешируя аудио- и видеосегменты. Для сравнения, поддержка CDN для RTMP быстро снижается. RTMP также требует использования выделенного сервера потоковой передачи, что делает его более ресурсоемким для развертывания.
Защита от пиратства — реализуется через поддержку большого количества технологий DRM.
Вот более подробный пост про то, как можно ограничить доступ к видео при помощи шифрования AES-128.
Недостатки HLS
HLS имеет некоторые ограничения, но они связаны с конкретными проектными решениями, которые были приняты при разработке протокола.
Часть этих ограничений связана с задержкой. HLS ставит во главу угла комфорт пользователя, а не низкую задержку, поэтому live-контент, который транслируется с использованием протокола HLS, не является достаточно «живым». Зритель увидит его с задержкой до 30 секунд. Таким образом, HLS — не лучший выбор для таких приложений, как веб-конференции или управление устройствами, где необходимо видео в реальном времени (камеры и дроны). В этом случае лучше использовать более быстрый потоковый протокол, например WebRTC (Web Real-Time Communications).
Задержка в HLS возникает из-за того, что протокол разбивает видео на множество многосекундных фрагментов (сегментов), которые обычно имеют длительность 2–6 секунд. И поскольку протокол HLS также должен буферизировать несколько таких небольших сегментов одновременно, задержка может составлять десятки секунд. Однако если задержка или плохие сетевые условия не являются проблемой, то HLS — это протокол, который вам нужен.
Итак, почему стоит использовать именно HLS?
С HLS создатели контента могут подготовить версии своего видео для нескольких различных интернет-каналов и условий воспроизведения: 3G, 4G, LTE, медленный публичный Wi‑Fi, быстрый домашний интернет.
Различные поставщики CDN постепенно отказываются от поддержки RTMP, заявляя, что его развертывание становится слишком дорогим. Вместо этого набирают популярность такие протоколы, как HLS, SRT и MPEG-DASH.
Adobe перестал поддерживать технологию, на которую опирается RTMP. Поэтому однажды ваш процесс потоковой передачи RTMP станет технологически устаревшим и потеряет поддержку со стороны производителя. Это лишь вопрос времени.
HLS оптимизирует доставку аудио и видео на обширный спектр мобильных, настольных, планшетных и OTT-устройств.
HLS позволяет доставлять видео по запросу с помощью шифрования и аутентификации.
HLS значительно снижает затраты на CDN. При этом он обеспечивает только оптимальный битрейт для клиентской сети и избегает сценария «частичного воспроизведения и полной загрузки», который присущ прогрессивной потоковой передаче HTTP. Например, когда всё видео представлено одним файлом MP4.
Apple App Store требует, чтобы приложения с десятиминутным (и более) видео использовали HLS.
Практическая часть
Надеюсь, я смог вас убедить, что сегодня для распространения видеоконтента через интернет стоит смотреть в сторону HLS.
Давайте теперь на примере рассмотрим способ, как нам использовать объектное хранилище в Yandex.Cloud.
Object Storage — это решение для хранения больших объемов данных за относительно небольшие деньги. Оно идеально подходит для чего-то вроде видеофайлов, которые, как правило, имеют довольно большой объем. Доступ к файлам (или объектам, как их часто называют) осуществляется через HTTP(S), что делает Object Storage отличным решением для хранения и обслуживания ваших HLS-видео.
Для начала нам понадобится бакет в хранилище. Если у вас его нет, то вот инструкция, как его создать.
Подготовка видео
Если у вас уже есть видео в формате HLS, то смело переходите к следующему разделу.
Если же его нет, то вам понадобится утилита ffmpeg, при помощи которой вы сможете конвертировать видео и аудио во множество форматов, в том числе HLS.
Установка ffmpeg
Скачайте последнюю версию отсюда.
Откройте консоль в папке.
Выполните команду brew install ffmpeg
Вызовите ffmpeg — вы должны будете увидеть информацию о версии ffmpeg.
Видео для примера
Возьмем какой-нибудь видеофайл и посмотрим информацию о нем:
В консоли появится приблизительно следующее:
Конвертация
Подготовим команду для конвертации видео:
Теперь подробно разберем, что означают все эти ключи:
-i sample.mp4 — задает sample.mp4 в качестве входного файла.
-vf «scale=w=1280:h=720:force_original_aspect_ratio=decrease» — масштабирует видео до максимальных размеров в пределах заданного разрешения 1280×720 с сохранением соотношения сторон.
-ac:a:0 2 — указывает, что если в первом аудиопотоке (a:0) больше двух каналов, нужно смиксовать их в стереосигнал.
-profile:v main — устанавливает профиль кодека H.264 в main (это означает включение поддержки всех современных устройств). Подробнее в статье.
-crf 20 — Constant Rate Factor, высокоуровневая настройка качества.
2 сек) — это важно, влияет на корректную нарезку на сегменты.
-sc_threshold 0 — не создавать ключевые кадры при смене сцены.
-hls_time 4 — указывает длину сегмента в секундах. Реальная длина будет зависеть от ключевых кадров.
-hls_playlist_type vod — добавляет тег #EXT-X-PLAYLIST-TYPE:VOD и сохраняет все сегменты в плейлист.
-hls_segment_filename sample/720p_%03d.ts — явным образом задает имена файлов для сегментов.
Утилита ffmpeg поддерживает несколько входных и выходных файлов и все результаты могут быть сгенерированы параллельно одной длинной командой.
Очень важно, чтобы помимо параметров разрешения и битрейта команды были идентичны, тогда результаты будут правильно выровнены, то есть ключевые кадры будут установлены в нужных местах, чтобы обеспечить плавное переключение между ними «на лету».
Мы создадим четыре версии с разрешениями:
1080p 1920×1080 (original)
Мастер-плейлист
HLS-плеер должен знать, что существует несколько версий нашего видео, поэтому мы создаем мастер-плейлист HLS, чтобы указать их и сохранить вместе с другими плейлистами и сегментами в файл playlist.m3u8.
Как правильно выбрать битрейт
Битрейт зависит в основном от разрешения и типа контента. При установке слишком низкого битрейта пикселизация изображения будет особенно видна в тех областях, где происходит быстрое движение. Когда битрейт слишком высок, выходные файлы могут быть чрезмерно большими без дополнительного значения.
Чтобы выбрать правильный битрейт, нужно понимать его содержимое. Видео с резкими движениями, например запись спортивных или новостных событий, потребует более высокого битрейта, чтобы избежать пикселизации. А для контента с плавными движениями в кадре, например, музыкального концерта или интервью, будет достаточно низкого битрейта без видимых изменений качества.
Вот некоторые хорошие значения по умолчанию:
Загрузка данных
Настройка бакета
Для того чтобы видеоплееры могли получить доступ к видеофайлам, необходимо указать настройки CORS в бакете.
Это максимально широкое правило для примера.
Все готово
Если вы хотите ограничить круг сайтов, куда можно будет встраивать видео, то прочитайте этот пост.
Теперь можно выкладывать видео на свой сайт.
В пример я добавил минимальный контрол для переключения уровня качества.
Вот использованный плеер и react-обертка. А вот альтернативный плеер.
Итак, в чем же плюс?
Если вы откроете консоль, то увидите, что после того как браузер загрузил несколько первых сегментов видео, загрузка приостанавливается. Это позволяет нам экономить трафик в тех случаях, когда пользователь открыл страницу с видео, начал просмотр видео и остановился. В этом случае нам не нужно загружать весь видеофайл целиком. Мы можем вовремя остановиться, а потом, если это понадобится (пользователь продолжит воспроизведение), загрузить остальное.