Apple hls что это

HLS (HTTP Live Streaming) — протокол, предназначенный для передачи мультимедиа (видео и аудио) по сети. Разработан в 2011 году компанией Apple.

Благодаря своим преимуществам, протокол HLS широко применяется провайдерами интернет-телевидения, а также онлайн-кинотеатрами, предоставляющими услуги «видео по запросу».

Преимущества HLS

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

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

Недостатки HLS

Основной недостаток протокола HLS проявляется при просмотре «живых» эфиров и заключается в отставании картинки, которую просматривает абонент на своём экране, от того, что происходит в реальности. Это связано с тем, что происходящее сначала при съёмке записывается, затем кодируется, передаётся через интернет на удаленные серверы и декодируется для последующего просмотра. На всё это, как правило, требуется порядка 20-60 секунд.

Как работает HLS

Трансляции по протоколу HLS осуществляются по принципу дробления потока на фрагменты.

На сервере медиафайл или поток кодируется в нужный формат (H.264, MP3, HE-AAC, AC-3) и формируется в .TS-файл MPEG-2.
.TS-файл разбивается на множество отрывков одинаковой длины, для них автоматически создаётся M3U/M3U8-файл, содержащий ссылки на фрагменты, а также информацию о каждом потоке и их качестве.
Устройство абонента отправляет на сервер запрос, получает M3U-файл, извлекает из него ссылки на медиа, «склеивает» все отрывки и начинает непрерывное воспроизведение подходящего по качестве и скорости потока.

Если трансляция медиа ведётся в режиме «по запросу», M3U-файл содержит ссылки сразу на все фрагменты фильма. В режиме «живой» трансляции (например, при просмотре классического телеканала) в M3U-файле есть только ссылки на несколько фрагментов, при каждом запросе клиентского проигрывателя к плейлисту его содержимое динамически обновляется, пополняясь новыми фрагментами.

Источник

Технологии адаптивного вещания

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

В общем-то их не так много, и вы сами уже догадываетесь какая первая – конечно, это Apple HTTP Adaptive Streaming (HLS).

1. Apple на славу постарался и уже относительно давно использует данную технологию на всех своих устройствах (операционные системы IOS и Mac), а также поддерживается последними версиями Android и большинством ТВ приставок.
HLS от компании Apple один из самых распространенных HTTP протоколов передачи видео, который уже доказал свою надежность и прошел проверку временем.
Конечно не идеально в нашем мире, но Apple как всегда на высоте. Вы не подумайте я не фанат Apple, я просто стараюсь судить объективно.
Итак, немного слов о передаче видео и аудио сигнала: Видеосигнал упаковывается в контейнер MPEG-2 TS, и используются весьма распространенные кодеки MPEG H.264 (видео) и AAC (аудио). Кодируется видео с разным битрейтом на выходе, и в итоге получается плейлист в формате m3u8. Для защиты контента от неавторизированного доступа, используется алгоритм AES-128, которые может зашифровать контент, передаваемый по HLS.
Вот так можно описать всю технологию Apple HTTP Adaptive Streaming (HLS).
2. Теперь рассмотрим не менее популярную технологию адаптивного вещания от компании Microsoft – Smooth Streaming.
Smooth Streaming это протокол, который поддерживается видеоплеером Silverlight, а также естественно операционными система Windows и Windows Phone.
Что такого есть у Microsoft, чего нет у Apple, или какими преимуществами обладает Smooth Streaming перед HLS. Хотя об этом можно поспорить, так как это сравнительно разные подходы к адаптивному вещанию, но все давайте рассмотрим в проекции одного направления. Самое большое преимущество — это более универсальный и расширяемый формат файла-манифеста (xml). Более меньшим преимуществом является то, что все сегменты видео упаковываются в самый распространенный на данный момент времени контейнер MP4.
Видео и аудио сигнал сначала сегментируются, а затем упаковывается в как говорилось выше в контейнер MP4 и распространяются по HTTP через web server и CDN. Используются кодеки H.264 (видео) и AAC (аудио).
В целом Windows продвигают свою концепцию весьма успешно, что говорит об их конструктивной конкуренции с Apple.
3. Вот мы и добрались до Adobe HTTP Dynamic Streaming (HDS), который является еще одним вариантом адаптивного вещания.
Как понятно из названия, данная технология создана компанией Adobe и поддерживается практически на любом персональном компьютере в мире.
Принцип работы похож на другие адаптивные системы HTTP-технологии. В связи с этим особые преимущества выделить сложно, можно только сказать, что HDS поддерживает только одну DRM-систему – Flash Access.
4. Еще хотелось бы рассмотреть тему Общего Стандарта Адаптивного Вещания.
Большая проблема на данный момент, которая стоит перед вещателями это постараться поддержать максимально возможное число решений на различных устройствах своих клиентов и использовать разные технологии. Это затратно и не всегда удобно.
И вот тут возникает потребность повсеместного внедрения единого стандарта вещания видео. Таким стандартом призвано стать MPEG-DASH (Dynamic Adaptive Streaming over HTTP), разработанный MPEG-LA и ISO, который они запустили в прошлом году.
Его можно назвать самым универсальным и совершенным протоколом вещания. У него есть использования манифест-файлов (xml) у Smooth Streaming, также присутствует поддержка большинства форматов контейнеров, и интеграция с UltraViolet (DRM-система), которая работает по принципу “Buy once, play it anywhere”. UltraViolet даст единую среду для кодирования всех устройств.
Каким бы универсальным ни была эта технология, и как бы она не продвигалась мировыми организациями-стандартизаторами, его внедрение ожидается в отдаленной перспективе.

С какими же проблемами может столкнуться разработчик при реализации адаптивного вещания?
Одна из них – это какой же длины должен быть тот самый сегмент видео, который передается в потоке, и сколько должно быть таких вариантов потоков.
Если делать сегмент видео излишне коротким, то возрастает бесполезное расходование трафика. Почему так происходит, а потому что в каждом сегменте помимо видео сдержится так называемый overhead. В итоге получается, чем больше сегментов, тем больше и overhead, и именно это бесполезно расходует трафик.
Но здесь есть и обратная сторона медали, если делать сегмент видео слишком длинным, то качество сервиса снизиться в несколько раз, потому что пользователю придется ждать смены качества.
Универсального решения проблемы нет, так как баланс в этом случае находиться только методом проб и ошибок.
Параметры профилей кодирования будут зависеть от технологии адаптивного вещания, а также от страны и региона. И здесь длина сегмента и количество потоков должны подбираться под каждый соответствующий случай.

Мы, Telebreeze Corporation, используем HTTP Adaptive Streaming (HLS). У этой системы есть ряд положительных моментов, в так же ряд проблем. Обо всем этом я расскажу в следующей статье.

Итак, краткие итоги: Каждая представленная технология имеет свои преимущества и конкурирует друг с другом, что должно положительно сказаться на развитие такого молодого направления как адаптивное вещание, ведь всем известно, что конкуренция двигатель прогресса.

Источник

Apple 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 для iOS Safari — потоковое видео через Websocket

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

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

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

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

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

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

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

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

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

воспроизведение видео непосредственно на HTML-странице в браузере;
на этой же странице могут быть размещены другие элементы, например, чат.

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

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

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

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

HLS — Apple HTTP Live Streaming

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

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

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

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

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

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

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

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

Заходим в админ интерфейс 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, задаем разрешение 320×240.

Настраиваем адрес 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.

VoW — Video over Websockets

Устанавливаем JDK на второй дроплет тем же способом, что и для Wowza

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

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

Установщик спросит два раза IP-адрес.
Нужно указать IP-адрес дроплета оба раза.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нажимаем ‘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, что соответственно увеличивает время и сложность настройки системы.

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

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

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

Источник