Манифест hls что это

Манифест 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.

Кодек — многозначный термин. Здесь он означает способ сжать сырое видео. Разница между кодеком и транспортом в том, что кодек — это про подготовку видео, а транспорт — про передачу видео по протоколу. Видео, сжатое одним кодеком, можно пересылать по разными протоколам и разными транспортами. Большинство видеостриминговых серверов не залезают глубже кодированного видео и оперируют только протоколами и транспортами.

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

Итак, в спецификации 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 для VOD

Доставка DASH

Динамическая упаковка DASH

Клиент потоковой передачи может указать следующие форматы MPEG-DASH:

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

Требуется помощь?

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

Источник