Манифест hls что это
HLS (HTTP Live Streaming) — протокол, предназначенный для передачи мультимедиа (видео и аудио) по сети. Разработан в 2011 году компанией Apple.
Благодаря своим преимуществам, протокол HLS широко применяется провайдерами интернет-телевидения, а также онлайн-кинотеатрами, предоставляющими услуги «видео по запросу».
Преимущества HLS
Кроме того, для вещателей HLS прост в настройке, а его использование не предусматривает лицензионных сборов и отчислений.
Недостатки HLS
Основной недостаток протокола HLS проявляется при просмотре «живых» эфиров и заключается в отставании картинки, которую просматривает абонент на своём экране, от того, что происходит в реальности. Это связано с тем, что происходящее сначала при съёмке записывается, затем кодируется, передаётся через интернет на удаленные серверы и декодируется для последующего просмотра. На всё это, как правило, требуется порядка 20-60 секунд.
Как работает HLS
Трансляции по протоколу HLS осуществляются по принципу дробления потока на фрагменты.
Если трансляция медиа ведётся в режиме «по запросу», M3U-файл содержит ссылки сразу на все фрагменты фильма. В режиме «живой» трансляции (например, при просмотре классического телеканала) в M3U-файле есть только ссылки на несколько фрагментов, при каждом запросе клиентского проигрывателя к плейлисту его содержимое динамически обновляется, пополняясь новыми фрагментами.
Манифест 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? Дайте нам знать об этом в комментариях!
Какой бывает HTML5-стриминг (и почему mp4-стриминга не существует)
Нередко клиенты спрашивают, умеет ли наш сервер «mp4-стриминг в HTML5». В 99% случаев спрашивающий не понимает о чём говорит. В этом сложно винить клиентов: из-за путаницы с терминами, технической сложности и большого разнообразия вариантов стриминга запутаться очень легко.
В этой статье мы расскажем, какой бывает HTML5-стриминг, какие варианты хорошие, и почему, чёрт побери, нельзя говорить «mp4-стриминг».
▍Термины
HTML5-видео — это когда вы вставляете в веб-страницу тег и указываете ему какой-то src. HTML5-стриминг — это то же HTML5-видео, но когда в src не готовый файл, а постоянно обновляющийся видеопоток. Ролик на Ютубе — это HTML5-видео, трансляция в Твитче — HTML5-стриминг.
Тегу неважно, как видеопоток формируется и передаётся, и сможет ли браузер его проиграть. Главное, чтобы в src была ссылка на какой-то видеопоток. Говоря техническим языком, спецификация ничего не говорит о том, какие протоколы, транспорты и кодеки поддерживаются в HTML5-видео.
Протокол — это то, как два участника видеосвязи (почти всегда это клиент и сервер) обмениваются данными с целью получения данных. Клиентом называют того, кто приходит к серверу и инициирует сессию связи. Видеопоток может течь от сервера к клиенту (тогда это обычное проигрывание) или от клиента к серверу (тогда это публикация). Даже когда гигантский шкаф, жрущий электричество как многоквартирный дом приходит к маленькой IP-камере, то она будет сервером, а этот шкаф клиентом.
Протокол обычно подразумевает хотя бы команду Play (начать проигрывание), но иногда есть и расширенные варианты: пауза, продолжение, публикация, перемотка и т. п.
Примеры протоколов: RTSP, RTMP, HTTP, HLS, IGMP.
Транспорт, или транспортный контейнер, или контейнер — это то, как сжатое видео упаковывается в байты для передачи от одного участника к другому (по какому-то протоколу).
Примеры контейнеров: MPEG-TS, RTMP, RTP.
| Обратите внимание, что RTMP оказался и в протоколах, и в транспортах. Это потому, что в описании RTMP есть спецификация и того, что должны слать друг другу стороны, чтобы видео потекло (т. е. протокол), и того, как упаковывать видео (т. е. транспорт). Так бывает не всегда. Например в протоколе RTSP видео упаковывается в транспорт RTP. |
Кодек — многозначный термин. Здесь он означает способ сжать сырое видео. Разница между кодеком и транспортом в том, что кодек — это про подготовку видео, а транспорт — про передачу видео по протоколу. Видео, сжатое одним кодеком, можно пересылать по разными протоколам и разными транспортами. Большинство видеостриминговых серверов не залезают глубже кодированного видео и оперируют только протоколами и транспортами.
Примеры кодеков: h264, aac, mp3.
| Из-за того, что термин многозначный, возникает путаница с названиями. Например, H.264 — это стандарт того, как упаковать поток огромных сырых видеокадров в очень мало байтов, libx264 — это библиотека для сжатия по этому стандарту, а ещё есть одноимённый софт под Винду, который умеет декодировать h264 и проигрывать его на экране. |
Итак, в спецификации HTML5 не описаны протоколы, транспорты и кодеки. Поэтому авторы браузеров сами выбирают, что поддерживать, а под «HTML5-стримингом» подразумевают разные вещи.
При этом есть комбинации, которые поддерживаются значительной частью браузеров. Рассмотрим самые перспективные.
HLS — это h264-видео и 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 — обычно это h264/h265-видео и aac-аудио, упакованное в транспорт mp4, или vp8/vp9, упакованное в WebM, хотя стандарт и не привязан к конкретным кодекам, протоколам и транспортам. Как и в HLS, поток может разбиваться на сегменты, но это необязательно. Вместо плейлистов — MPD-манифест в XML.
MPEG-DASH во многом похож на HLS. Возможно, он даже популярнее, ведь такие гиганты как Ютуб и Нетфликс уже несколько лет используют его как основной способ раздачи контента.
MPEG-DASH хорош тем, что в большинстве браузеров работает нативно, через MSE (о том, что это такое, — чуть ниже). Для него даже нет реализации на Флеше — это честный, бескомпромиссный HTML5.
Определенно, MPEG-DASH — самый настоящий HTML5-стриминг, за ним будущее.
Когда стало ясно, что Флеш всё-таки умрёт (после сотни ложных похорон), ребром встал вопрос о том, что придёт ему на смену. Хорошо было бы получить в браузерах возможность проигрывать видео по качеству и удобству близко к тому, что умеет Флеш (а он это делает всё-таки хорошо).
Во Флеше давно появился очень удобный механизм для универсального проигрывания разных вариантов — 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 и содержащий внутри видео, сжатое кодеком h264/aac. И даже попытаться проиграть его. Это самый удобный, понятный и стандартный вариант проигрывания файлов. Лежит себе файлик на диске, nginx его отдает. Код, проигрывающий mp4 в браузерах достаточно хорош. Например, он умеет даже скачивать куски видео по необходимости (в отличие от Флеш-плеера, который скачивает видео целиком).
Вокруг h264 сложилось немало шумихи по поводу его «закрытости» и «несвободности». Так что есть «открытая» альтернатива, которую форсит Гугл — видеокодеки vp8 и vp9, упакованные в транспорт WebM. WebM — это подмножество транспорта mkv (a. k. a. Матрёшка), который очень похож на mp4 по сути, но отличается от него своей «бинарностью».
Именно отсюда растут ноги у такого явления как «mp4-стриминг», который устроен как WebM. Дело в том что в обычном mp4 в самом начале указывается размер всего контейнера. Поэтому, если мы хотим отдать по обычному mp4 прямой эфир, у нас ничего не получится. А чтобы всё-таки получилось и можно было создавать mp4 без фиксированного конца, придуман следующий ход: сначала пишется mp4 без кадров, а потом в конце подписываются блоками по несколько секунд фрагменты с кадрами. Это называется mp4 fragmented, или mp4 streaming.
По сути это никакой не стриминг, а костыль, позволяющий создать его видимость. Mp4 — отличный формат для скачивания видео, но негодный для стриминга, так что про него можно просто забыть и никогда не использовать термин «mp4-стриминг».
Динамическая упаковка в Службах мультимедиа версии 3
Службы мультимедиа Azure предоставляют встроенный сервер-источник и возможности упаковки для доставки содержимого в форматах протокола потоковой передачи HLS и MPEG DASH. В AMS конечная точка потоковой передачи выступает в качестве «сервера-источника», передающего отформатированное содержимое HLS и DASH на клиентские проигрыватели, поддерживающие потоковую передачу с переменной скоростью с использованием популярных форматов. Кроме того, конечная точка потоковой передачи поддерживает множество функций, таких как JIT, динамическая упаковка с защитой содержимого или без нее, для доступа ко всем основным устройствам (например, устройствам iOS и Android).
В настоящее время большинство браузеров и мобильных устройств на рынке поддерживают и распознают протоколы потоковой передачи HLS или DASH. Например, для iOS требуется, чтобы потоки доставлялись в формате HTTP Live Streaming (HLS), а устройства Android поддерживали HLS, а также MPEG DASH в определенных моделях (или с помощью проигрывателя уровня приложения Exoplayer для устройств Android).
В Службах мультимедиа конечная точка потоковой передачи (источник) — это служба динамической (JIT) упаковки и служба источника, которая может в реальном времени и по запросу доставлять содержимое непосредственно в клиентское приложение проигрывателя. Она использует один из распространенных протоколов потоковой передачи мультимедиа, упомянутых в следующем разделе. Динамическая упаковка — это возможность, которая по умолчанию предоставляется для конечных точек потоковой передачи.
Подготовка исходных файлов к доставке
Чтобы воспользоваться преимуществами динамической упаковки, вам необходимо кодировать свой мезонинный (исходный) файл в набор файлов MP4 (ISO Base Media 14496-12) с одной или несколькими скоростями. Вам нужен ресурс с закодированными MP4-файлами и файлами конфигурации потоковой передачи, которые Службы мультимедиа используют для динамической упаковки. Такой набор MP4-файлов позволит применять динамическую упаковку для передачи видео по протоколам потоковой передачи мультимедиа, как описано далее.
Динамическая упаковка служб мультимедиа Azure поддерживает только видео- и аудиофайлы в формате контейнера MP4. Звуковые файлы должны быть закодированы в контейнер MP4, а также использовать альтернативные кодеки, например Dolby.
Чтобы видео в закодированном ресурсе стали доступны для воспроизведения в клиентах, необходимо опубликовать ресурс с использованием указателя потоковой передачи и сформировать URL-адреса потоковой передачи с поддержкой HLS и DASH. Изменяя протокол, используемый в запросе формата URL-адреса, служба будет доставлять соответствующий манифест потоковой передачи (HLS, MPEG DASH)
В результате вам нужно только хранить и оплачивать файлы только в одном формате хранения (MP4), а службы мультимедиа выполнят сборку и будут обслуживать соответствующие манифесты HLS или DASH на основе запросов от клиентских проигрывателей.
Если вы планируете защитить содержимое с помощью динамического шифрования Media Services, см. раздел Потоковые протоколы и типы шифрования.
Доставка HLS
Динамическая упаковка HLS
Клиент потоковой передачи может указать следующие форматы HLS. Мы рекомендуем использовать формат CMAF для совместимости с последними проигрывателями и устройствами iOS. Для устаревших устройств доступны также форматы v4 и v3, просто измените строку запроса формата.
| Протокол | Строка форматирования | Пример |
|---|---|---|
| HLS CMAF (рекомендуется) | format=m3u8-cmaf | https://amsv3account-usw22.streaming.media.azure.net/21b17732-0112-4d76-b526-763dcd843449/ignite.ism/manifest(format=m3u8-cmaf) |
| HLS V4 | format=m3u8-aapl | https://amsv3account-usw22.streaming.media.azure.net/21b17732-0112-4d76-b526-763dcd843449/ignite.ism/manifest(format=m3u8-aapl) |
| HLS V3 | format=m3u8-aapl-v3 | https://amsv3account-usw22.streaming.media.azure.net/21b17732-0112-4d76-b526-763dcd843449/ignite.ism/manifest(format=m3u8-aapl-v3) |
Коэффициент упаковки HLS для VOD
Доставка DASH
Динамическая упаковка DASH
Клиент потоковой передачи может указать следующие форматы MPEG-DASH:
| Протокол | Строка форматирования | Пример |
|---|---|---|
| MPEG-DASH CMAF (рекомендуется) | format=mpd-time-cmaf | https://amsv3account-usw22.streaming.media.azure.net/21b17732-0112-4d76-b526-763dcd843449/ignite.ism/manifest(format=mpd-time-cmaf) |
| MPEG-DASH CSF (устаревший) | format=mpd-time-csf | https://amsv3account-usw22.streaming.media.azure.net/21b17732-0112-4d76-b526-763dcd843449/ignite.ism/manifest(format=mpd-time-csf) |
Доставка манифестов Smooth Streaming
Динамическая упаковка Smooth Streaming
Клиент потоковой передачи может указать следующие форматы Smooth Streaming:
https://amsv3account-usw22.streaming.media.azure.net/21b17732-0112-4d76-b526-763dcd843449/ignite.ism/manifest(format=fmp4-v20)
Для Smooth Streaming требуется, чтобы в вашем потоке присутствовали видео- и аудиоданные.
Рабочий процесс для потокового воспроизведения по запросу
Далее описаны этапы обычного рабочего процесса потоковой передачи в Службах мультимедиа, при котором динамическая упаковка используется с кодировщиком (цен. категория «Стандартный») в Службах мультимедиа Azure.
Отправьте входной файл например MP4, QuickTime, MOV или другого поддерживаемого формата. Этот файл также называется мезонинным или исходным. Список поддерживаемых форматов см. в статье Standard Encoder formats and codecs (Форматы и кодеки кодировщика ценовой категории «Стандартный»).
Закодируйте мезонинный файл в набор MP4-файлов с адаптивной скоростью в формате H.264 или AAC.
Если у вас уже есть закодированные файлы и требуется только скопировать их и выполнить потоковую передачу, используйте API CopyVideo и CopyAudio. В результате будет создан MP4-файл с манифестом потоковой передачи (ISM-файл).
Опубликуйте выходной ресурс, который содержит набор MP4-файлов с адаптивной скоростью. Публикация выполняется путем создания указателя потоковой передачи.
Создайте URL-адреса, которые предназначены для различных форматов (HLS, MPEG-DASH и Smooth Streaming). Конечная точка потоковой передачи возьмет на себя выдачу надлежащего манифеста и обработку запросов для всех форматов.
На приведенной ниже схеме показан рабочий процесс для потокового воспроизведения по запросу с динамической упаковкой.
Путь скачивания на представленном выше изображении нужен только для демонстрации того, что MP4-файл можно скачать напрямую через конечную точку потоковой передачи (источник), если в указателе потоковой передачи настроена политика потоковой передачи для скачивания.
Динамический упаковщик не изменяет файл. При необходимости вы можете использовать интерфейсы API хранилища BLOB-объектов Azure для прямого доступа к MP4 и поэтапной загрузки, если хотите обойти функции конечной точки потоковой передачи (источник).
Кодирование в MP4-файлы с адаптивной скоростью
В ресурсах по указанным ниже ссылкам показаны примеры кодирования видео с помощью Служб мультимедиа:
Просмотрите список поддерживаемых входных форматов и кодеков стандартного кодировщика.
Рабочий процесс для потоковой трансляции в реальном времени
В реальном событии можно задать сквозное кодирование (локальный динамический кодировщик отправляет поток с несколькими скоростями) или кодирования в реальном времени (локальный динамический кодировщик отправляет односкоростной поток).
Ниже описан типичный рабочий процесс для потоковой трансляции с динамической упаковкой.
На схеме показан рабочий процесс для потоковой трансляции с динамической упаковкой.
Сведения о потоковой трансляции в Службах мультимедиа версии 3 см. в статье здесь.
Видеокодеки, поддерживаемые для динамической упаковки
Динамическая упаковка поддерживает видеофайлы в формате файла контейнера MP4 и содержащие видео, закодированное с помощью H.264 (MPEG-4 AVC или AVC1) либо H.265 (HEVC, hev1 или hvc1).
С динамической упаковкой успешно протестирована трансляция видео с разрешением до 4K и частотой до 60 кадров в секунду.
Аудиокодеки, поддерживаемые для динамической упаковки
Динамическая упаковка также поддерживает аудиофайлы, которые хранятся в формате контейнера файла MP4, содержащего закодированный звуковой поток в одном из следующих кодеков:
AAC (AAC-LC, HE-AAC v1 или HE-AAC v2).
Dolby Digital Plus (Enhanced AC-3 или E-AC3). Для работы с динамической упаковкой закодированный аудиофайл должен храниться в формате контейнера MP4.
Потоковая передача содержимого Dolby Atmos поддерживается такими стандартами, как протокол MPEG-DASH с форматом потоковой передачи Common Streaming Format (CSF) или форматом Common Media Application Format (CMAF) фрагментированного MP4, а также через HTTP Live Streaming (HLS) со CMAF.
DTS
Кодеки DTS, поддерживаемые форматами упаковки DASH-CSF, DASH-CMAF, HLS-M2TS и HLS-CMAF:
Динамическая упаковка поддерживает несколько звуковых дорожек вывода с DASH или HLS (версии 4 или более поздней) для потоковой передачи ресурсов, у которых несколько звуковых дорожек на разных языках и с разными кодеками.
Чтобы работать с динамической упаковкой, для всех приведенных выше аудиокодеков закодированный аудиофайл должен храниться в формате контейнера MP4. Служба не поддерживает необработанные форматы файлов элементарного необработанного потока в хранилище BLOB-объектов (например, DTS, AC3).
Для упаковки аудиофайлов поддерживаются только файлы MP4 в расширении MP4A.
Ограничения
Ограничения для аудио в формате AAC 5.1 в iOS
Устройства Apple iOS не поддерживают аудиокодек AAC 5.1. Многоканальный звук нужно кодировать с помощью кодеков Dolby Digital или Dolby Digital Plus.
Подробные сведения см. в статье HLS authoring specification for apple devices (Спецификации по разработке с использованием HLS для устройств Apple).
Службы мультимедиа не поддерживают кодирование в цифровых форматах Dolby Digital, Dolby Digital Plus или Dolby Digital Plus с многоканальными форматами звука Dolby Atmos.
Звук Dolby Digital
Динамическая упаковка в Службах мультимедиа в настоящее время не поддерживает файлы, которые содержат звук Dolby Digital (AC3), так как компания Dolby объявила этот кодек устаревшим.
Манифесты
В динамической упаковке Служб мультимедиа динамически создаются манифесты клиентов потоковой передачи для HLS, MPEG-DASH и Smooth Streaming на основе запроса формата в URL-адресе.
Файл манифеста содержит потоковые метаданные, например тип дорожки (звук, видео или текст), имя дорожки, время начала и окончания, скорость (качество), языки дорожки, окно представления (скользящее окно фиксированной длительности), видеокодек (FourCC). Кроме того, он предписывает проигрывателю получить следующий фрагмент, предоставляя информацию о следующих доступных для воспроизведения фрагментах видео и их расположении. Фрагменты (или сегменты) — это фактические блоки видеосодержимого.
Примеры
Ниже приведен пример файла манифеста HLS, также называемого главным списком воспроизведения HLS:
MPEG-DASH
Ниже приведен пример файла манифеста MPEG-DASH, также называемого форматом описания представления мультимедиа (MPD) MPEG-DASH:
Smooth Streaming
Ниже приведен пример файла манифеста Smooth Streaming:
Именование дорожек в манифесте
Проигрыватель может использовать элемент Label для отображения в пользовательском интерфейсе.
Сигнальные звуковые описания дорожек
для определенной звуковой дорожки.
Манифест Smooth Streaming
Манифест DASH
Чтобы сигнализировать о звуковом описании, для манифеста DASH будут добавлены следующие два элемента:
Список воспроизведения HLS
Пример
Фильтрация динамических манифестов
Чтобы контролировать количество дорожек, форматы, скорость и окно времени презентации для передачи на проигрыватели, вы можете использовать динамическую фильтрацию с помощью динамического упаковщика Служб мультимедиа. Дополнительные сведения см. в статье Pre-filtering manifests with Dynamic Packager (Предварительная фильтрация манифестов с помощью динамического упаковщика).
Динамическое шифрование для DRM
Вы можете использовать динамическое шифрование, чтобы динамически шифровать содержимое в режиме реального времени или по требованию с помощью AES-128 или трех основных систем управления цифровыми правами (DRM): Microsoft PlayReady, Google Widevine и Apple FairPlay. Авторизованным клиентам также предоставляется служба доставки ключей AES и лицензий DRM. Чтобы узнать больше, ознакомьтесь со статьей о динамическом шифровании.
Widevine — это служба, которая предоставляется компанией Google Inc. и подпадает под условия предоставления услуг и политику конфиденциальности Google Inc.
Дополнительные сведения
Прочитайте статью сообщества Служб мультимедиа Azure, чтобы узнать, как задавать вопросы, оставлять отзывы и получать новости о Службах мультимедиа.
Требуется помощь?
Вы можете открыть запрос в службу поддержки, перейдя к разделу нового запроса на техническую поддержку.