Расширение файла hls

The Future of Live Streaming

Before wrapping things up, let’s recap our discussion of some of the advantages of the HLS streaming protocol. First, there is no special infrastructure required to deliver HLS content. In fact, any standard web server or CDN will function well. Additionally, firewalls are much less likely to block content using HLS.


In terms of technical functionality, HLS will play video encoded with the H.264 or HEVC/H.265 codecs. It then chops video into 10-second segments. Remember, latency for delivery tends to be in the 30-second range. However, Dacast now has a solution for low-latency HLS live streaming that reduces latency to 10 seconds or less.

The HLS protocol also includes several other built-in features. For example, HLS is an adaptive bitrate streaming protocol. This means that the client device and server dynamically detect the internet speed of the user, and then adjust video quality in response. 

Other beneficial HLS features include support for embedded closed captions, synchronized playback of multiple streams, advertising standards (i.e., VPAID and VAST), DRM, and more.

While HLS is the current gold standard for live streaming, it won’t stay that way indefinitely. We expect MPEG-DASH to become increasingly popular in the coming years. 

As that shift takes place, we’ll see other changes as well, such as the transition away from h.264 encoding to h.265/HEVC. This new compression standard provides much smaller file sizes, making 4K live-streaming a real possibility.

However, that time isn’t here yet. For now, it’s important to stick with the established standards to reach as many users as possible on their devices. In other words, HLS is the streaming protocol of the present.

Как CMAF решает вопросы задержки

MPEG Common Media Application Format (MPEG-CMAF) — это стандартизированный медиаконтейнер, недавно введенный для упрощения масштабного распространения OTT-услуг.

MPEG-CMAF основан на использовании контейнера fMP4 (ISOBMFF) и может применяться как в рамках MPEG-DASH, так и c HLS-протоколом c использованием общего шифрования. Действительно, режим шифрования CBC теперь поддерживают Apple, Microsoft, Google и Adobe, что позволяет абонентским устройствам, поддерживающим разные системы DRM, принимать и открывать один и тот же зашифрованный видеофрагмент. Сохранилась необходимость составлять в отдельном манифест-файле для MPEG DASH и плейлисте для HLS, но зашифрованные медиасегменты при использовании CMAF одинаковы для обоих форматов, что значительно упрощает распространение контента и снижает нагрузку на сети.

Другим важным преимуществом MPEG-CMAF является появление возможности организации низкой задержки LLC (Low Latency Chunk — чанки с низкой задержкой). MPEG-CMAF LLC предоставляет возможность доставки сегмента небольшими частями (чанками), длительностью, например, по 200 мс, до формирования полного двухсекундного или шестисекундного сегмента. В режиме CMAF LLC передача данных ускоряется по всей цепочке, в том числе в декодере, который может начать декодирование, не дожидаясь получения всего сегмента. MPEG CMAF LLC — очень эффективный инструмент, который при использовании кодера с низкой задержкой и плеера с поддержкой DASH (так как iOS 11 поддерживает CMAF, но не LLC) может обеспечить суммарную задержку в тракте в пределах трех секунд или меньше. Конечно, проигрыватель HLS также может декодировать данный поток, но при этом будет вносить дополнительную задержку по сравнению с плеером MPEG DASH CMAF LLC (см. рисунки 3 и 4).

Чтобы в полной мере использовать преимущества CMAF LLC, необходимо обеспечить поддержку CMAF и передачи HTTP-чанков во всех звеньях цепи доставки, включая пакетизатор, вещающий сервер, CDN и плеер. Судя по тестам Harmonic и обсуждениям с партнерами, можно говорить о широкой поддержке CMAF LLC со стороны отраслевых игроков, включая операторов CDN и разработчиков плееров. Тем не менее отметим, что проигрыватели, которые поддерживают CMAF, но без LLC, по-прежнему могут декодировать видео только после приема полного медиасегмента.

A Basic Breakdown: How Does HLS Work?

We’ve covered the matter-of-fact definition of HLS, but before we move on to an equally technical overview of how this protocol works, we’re going to take a chance to go back to the basics.

As we’ve mentioned, HLS is an important protocol for live streaming. The live streaming process that is compatible with the greatest number of devices and browsers looks something a little bit like this:

  1. Capturing devices (cameras, microphones, etc.) capture the content.
  2. The content is sent from the capturing device to a live encoder. 
  3. The encoder transmits the content to the video hosting platform via RTMP.
  4. The video hosting platform uses HLS to transmit the content to an HTML5 video player.

This process requires two main software solutions: a live video encoder and a powerful video hosting platform. If you choose to stream with HLS, you’ll want to make sure that both software offers the protocols and features we mentioned.

HTML5 video players powered by HLS are great for reaching the largest audience since this duo is practically universal. Dacast is a feature-rich live video streaming solution that includes HLS streaming and a customizable, white-label HTML5 video player.

Want to see the HLS streaming protocol in action? Sign up for your free trial of Dacast to try out HLS and other powerful streaming features.

Архитектура

HTTP Live Streaming использует стандартный веб-сервер для распространения аудиовизуальных материалов по запросу, при этом требует специальное ПО для того, чтобы обеспечивать передачу контента в режиме реального времени.

Серверная часть
Кодирует и оборачивает входящее медиа в подходящий для доставки формат. Далее материал готовится к распределению путём сегментирования. Медиа сегментируется на фрагменты (чанки, chunks) и индексный файл (плейлист).
  • Кодировка: видео кодируется в формате H.264 и аудио в MP3, HE-AAC или AC-3. Всё это вкладывается в транспортный поток MPEG-2 для последующей доставки.
  • Сегментирование: контент в MPEG-2 TS разделяется на фрагменты одинаковой длины, записанные в файлы .ts. Также создаётся индексный файл, содержащий ссылки на фрагменты или другие индексные файлы — он сохраняется как файл .m3u8
Распределение
Работая как стандартный веб-сервер, сервер принимает запросы от клиентов и доставляет всё необходимое для воспроизведения.
Клиент
Запрашивает и скачивает все файлы, собирая их воедино так, чтобы предоставить пользователю непрерывный поток видео. Клиентское ПО скачивает первый индексный файл через URL и далее несколько доступных файлов медиа. ПО для проигрывания собирает всё в последовательность для воспроизведения.

Существует два режима работы HLS — «по запросу» и живой трансляции. В режиме «по запросу» плей-лист содержит ссылки на все фрагменты от первого до последнего. В режиме живой трансляции плей-лист содержит только ссылки на последние несколько фрагментов, кроме того при последующих обращениях к плей-листу, фрагменты будут меняться, отражая текущее состояние трансляции.

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

На конференции WWDC 2016 Apple анонсировала включение адресации через byte-range для фрагментированных MP4 файлов (fMP4), что позволяет проигрывать контент через HLS не прибегая к мультиплексированию в транспортном потоке MPEG-2. Эксперты отрасли оценили это как большой шаг к совместимости между HLS и MPEG-DASH.

На конференции WWDC 2019 была анонсирована технология Low Latency HLS — развитие спецификации HLS, позволяющее вести передачу медиа-данных с низкой задержкой. Нововведения включают в себя partial segments (частничные сегменты), дельту плей-листов, возврат сегментов через HTTP/2 и другие изменения.

B2B-стриминг

Стриминговые технологии применяются не только для доставки видео конечным пользователям, но и для профессиональной передачи. Если речь идет о доставке в точки ретрансляции, то это часто решается с помощью CDN, иногда даже на базе традиционного HLS. По информации от Cisco, некоторые операторы используют HLS для доставки видео к сегментам администрируемых сетей IPTV, заменяя ими прежние транспортные решения. Логика такого подхода заключается в том, что HLS-формат все равно требуется для доставки на гаджеты, и чтобы не дублировать транспортные потоки и не поддерживать две системы доставки, операторы оставляют только стриминг. Помимо доставки в точки ретрансляции, существуют задачи передачи живого контента с места события до студии и межстудийная передача или раздача корпоративного видео. Кроме того, некоторых могут не устраивать условия или технические возможности доступных CDN. Другими словами, транспортные системы, не интегрированные с CDN, тоже имеют право на жизнь.

Самое известное транспортное решение для B2B-сектора — Nimbra Appliance шведской компании Netinsight. О нем известно только, что оно позиционируется как замена выделенной линии, не уступающее по надежности, скорости и безопасности передачи, и включает собственные кодеры и декодеры.

Еще одно интересное решение — QARVA MultiPipe, оно разработано грузинской компанией QARVA. Оно позволяет передавать видео по кусочкам с разных серверов и собирать их воедино на клиентском устройстве. По всей видимости, это торрент-технология, хотя разработчики не используют этот термин, вероятно, из-за стойких ассоциаций с пиратством. В то же время торрент-технология совершенно не обязательно предполагает пиратское использование. Аналогичное решение в свое время предложила компания Ocotoshape, позже купленная крупнейшей CDN-сетью Akamai. Решение QARVA MultiPipe как раз позволяет обойтись без услуг CDN. Кроме того, видео делится на очень маленькие фрагменты, что позволяет избежать задержек при начале просмотра или переключении на другой канал. Опыты подтвердили, что эта технология позволяет без задержек передавать по открытому Интернету даже 4К-каналы. Разработчик позиционирует это решение как B2C, и его можно так использовать в сети со специализированными приставками. Однако для стриминга на стандартные гаджеты его можно использовать как замену CDN.

Отдельно можно рассматривать задачу переброски потока из одной точки в другую. Для ее решения предлагается протокол SRT (Secure Reliable Transport), разработанный компанией Haivision. Эта компания специализируется в основном на разработке кодеров, транскодеров и декодеров, в которые и были интегрированы первые версии SRT. Этот алгоритм имеет встроенный механизм восстановления потерянных пакетов, постоянно мониторит состояние канала и адаптирует к нему передаваемый поток, а также защищает видео AES-шифрованием. По сути, он делает то же, что и другие протоколы для передачи видео через открытый Интернет с непредсказуемым качеством каналов. Статус индустриального стандарта SRT получил благодаря тому, что весной 2017 года был основан SRT-альянс, а сам протокол был выложен в открытый доступ. Вначале в состав альянса входило всего две компании — Haivision и Wowsa Media Solutions. Однако потребность в открытом решении такого рода была настолько велика, что за следующий год альянс набрал более 100 участников, и их число продолжает расти. Среди них такие известные нам компании, как Harmonic, Appear TV, WISI и Sencore. На выставке IBC 2019 на стендах большинства этих компаний можно было видеть кодеры с поддержкой SRT. Более того, есть уже десятки внедрений этого протокола в действующих проектах.

MPEG-DASH

В отличие от остальных HTTP-технологий MPEG-DASH — общеиндустриальный стандарт, ратифицированный ISO/IEC MPEG. В его разработке принимали участие многие крупные компании, в том числе Adobe и Microsoft, имеющие собственные HTTP-решения. 

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

Внедрение DASH CMAF LLC на головной станции

Задержка в цепочке DASH CMAF LLC может сильно различаться в зависимости от метода реализации (на аппаратной или облачной платформе) и стабильности пропускной способности сети. Если OTT-платформа развернута на аппаратной платформе, то ABR-кодер обычно получает тот же сигнал, что и вещательный кодер. Поскольку качество видео и скорость битрейта являются общими задачами для операторов вещания и OTT-услуг, то кодеры в обоих случаях дают схожую задержку. Остальная часть цепочки DASH CMAF LLC (пакетизатор, сервер вещания, CDN и плеер) вносит незначительный вклад в общую задержку, особенно при использовании сетей доступа с хорошей пропускной способностью (например, проводные сети). В этом случае при использовании двухсекундных сегментов и фрагментов CMAF длительностью 100 мс средняя совокупная задержка видео от вещания до его отображения на абонентском устройстве составляла около 5,5 секунд, то есть примерно столько же, сколько и в вещательной сети (см. рисунок 5).

Пути снижения задержки

Она из самых больных проблем HTTP-стриминга — большие задержки от момента съемки до появления контента на экране. В системе Adobe RTMP/Flash при достаточных транспортных ресурсах задержка составляет 2-3 секунды, что даже меньше стандартных 5—10 сек для вещательного канала. В системах на базе HTTP задержка составляет от 20 до 60 секунд, а иногда и больше. Причина такой задержки — последовательная обработка сегментов каждым элементом цепочки. А элементов достаточно много: система предварительной обработки видео, кодер, пакетизатор, сервер-источник, один или несколько кэширующих серверов CDN, граничный сервер СDN — сеть доступа, буфер клиентского устройства. Каждый элемент вносит задержку, равную времени обработки одного сегмента и результаты суммируются. Какие-то потоки могут быть сохранены на кэширующих серверах, тогда фактическая задержка окажется меньше, но так как задержка может меняться, например, при переходе от одного профиля видео к другому, то система все равно работает с максимальной задержкой. Эта проблема особенно заметна в HLS-стриминге, где стандартный размер сегмента составляет 10 секунд. Причем плееры в устройствах Apple начинают проигрывание после того, как в их буфере накопится три сегмента, то есть 30 секунд видео. Эта мера связана в основном с неустойчивым состоянием интернет-каналов, а большая длина одного сегмента — еще и со стремлением снизить долю заголовка в общем объеме.

С развитием CDN и общим увеличением пропускной способности каналов такой запас стал избыточным, а появление стандарта CMAF c эффективным контейнером позволило сократить размер сегмента. На самом деле CMAF не ограничивается определением контейнера, но также описывает порядок пакетизации, в том числе объединения и синхронизации разные версий потока. Среди прочего в нем предусмотрена возможность выделения маленьких подсегментов (чанков) в рамках одного сегмента. Это обстоятельство используется при реализации режима передачи с низкой задержкой, позволяющего, по оценкам специалистов, снизить ее до 3 секунд.

Снижению задержки будет также способствовать массовый переход на стандарт HTTP 2.0, принятый в 2015 году. Он разрабатывался в том числе и с учетом задач медиастриминга, и по сравнению с нынешней версией HTTP 1.1 в нем много полезных для стриминга усовершенствований. Он, в частности, позволяет приоритизировать запросы, более гибко разбивать ответы на фрагменты и даже отправлять с сервера данные, которые еще не были запрошены клиентом. К тому же заголовки сообщений в этом протоколе отправляются в компрессированном виде и занимают меньше места.

Оптимизация потоковой передачи ABR с применением механизмов HLS и DASH

Сегодня подавляющее большинство OTT-проектов реализовано на базе адаптивной потоковой HTTP-передачи с использованием HLS или DASH. Поскольку плеерам необходимо буферизовать определенное количество сегментов, прежде чем они смогут начать декодировать видео (три в случае HLS), существует прямая зависимость между размером сегмента и суммарной задержкой. Одним из наиболее простых подходов к снижению суммарной задержки является простое сокращение длительности сегмента. Основное преимущество такого подхода в том, что он не требует никакого изменения компонентов экосистемы. Тем не менее эта опция имеет некоторые важные ограничения:

• Согласованность экосистемы. Cокращение длительности сегмента в технологии DASH и особенно в HLS возможно с определенными оговорками. Для пакетов формата HLS компания Apple изначально установила минимальную длительность сегмента в 10 секунд, которая затем была сокращена до шести секунд. И хотя опуститься ниже этого порога технически возможно, это потребует нестандартной реализации плеера. Кроме того, это означает, что вся экосистема (пакетизатор, сервер-источник, CDN, клиент, проигрыватель) должны согласовать возможность совместной работы в таком режиме.

• Рост трафика. При стандартной реализации каждый раз, когда плеер запрашивает сегмент, в сеть отправляется HTTP-запрос. Чем короче продолжительность сегмента, тем больше HTTP-запросов будет циркулировать в сети. Сильное снижение длительности сегмента приведет к тому, что сеть доставки будет загружена большим количеством HTTP-запросов на всем пути от сервера-источника до пограничных кеширующих CDN серверов.

• Качество видео. Как показано на рисунке 7, уменьшение длительности сегмента с 10 до 2 секунд не влияет на качество видео. Тем не менее снижение ниже двухсекундного порога приведет к использованию кодером более короткой последовательности кадров, что, в свою очередь, немедленно повлечет за собой снижение качества видео. А снижения длительности сегмента двухсекундного порога, к сожалению, недостаточно для обеспечения задержки, сопоставимой с вещательной.

Таким образом, задержку в стандартных системах ABR-стриминга на базе HLS и DASH снизить можно, но до определенного уровня. Переход в режим с действительно низкой задержкой приводит к риску появления несогласованностей в экосистеме, дополнительным затратам на настройку и снижению качества восприятия услуги (QoE).

Влияние качества сети доступа на задержку в плеере

Приведенные результаты были получены в условиях распространения видео по качественным сетям доступа, как правило, по управляемым сетям, с хорошим Wi-Fi-покрытием. В таких случаях сетевой буфер DASH CMAF LLC плеера может быть уменьшен до минимума без риска его опустошения из-за перегрузки сети.

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

Тесты, проводившиеся в сетях LTE, подтвердили важность увеличения глубины сетевого буфера на 1-2 секунду для обеспечения непрерывности обработки и воспроизведения видео (см. таблицу 2).. Таблица 2

Результаты испытаний

Таблица 2. Результаты испытаний

DASH CMAF LLC доставка

Кодирование ОТТ-потока на головной станции

Кодирование ОТТ-потока в облаке

Управляемая проводная сеть

5,5 сек

7,0 сек

Сеть LTE

7,5 сек

9,5 сек

Таким образом, качество сети доступа является основным фактором, определяющим задержку, а следовательно, и качество восприятия услуги (QoE). С этой точки зрения возможность адаптироваться к изменяющимся условиям сети нужнее, чем доработка клиентской части.

How HLS Works

HLS Container Format

Unlike most HTTP-based protocols, which use the MPEG-4 Part 14 (MP4) container format, HLS initially specified the use of MPEG-2 Transport Stream (TS) containers. This changed in 2016, when Apple announced support for the fragmented MP4 (fMP4) format. Today, fMP4 is the preferred format for all HTTP-based streaming (including MPEG-DASH and Microsoft Smooth). These video files typically contain  encoded video and  encoded audio.

HLS Segmented Delivery

As described above, video streams delivered via HLS are broken up into segments of data (also called chunks or packets) at the media server rather than being delivered as a continuous flow of information. Segmented delivery allows the player to shift between different renditions depending on available resources, while also driving down latency.

HLS Encoding Requirements

Apple provides the below encoding targets as an example of typical sets of bit rate variants when streaming with HLS.

16:9 Aspect Ratio H.264/AVC Framerate
416 x 234 145 ≤30 fps
640 x 360 365 ≤30 fps
768 x 432 730 ≤30 fps
768 x 432 1,100 ≤30 fps
960 x 540 2,000 same as source
1280 x 720 3,000 same as source
1280 x 720 4,500 same as source
1920 x 1080 6,000 same as source
1920 x 1080 7,800 same as source

HLS Encoding Targets

.M3U8 Manifest File

HLS video segments are indexed into a media playlist so that the video player understands how to organize the data. A master .m3u8 playlist file must also be created — think of this as the index of indexes — to instruct the player on how to jump between the variant-specific playlists. This is also referred to as the manifest file. Anyone delivering the stream can then distribute the content by embedding the .m3u8 reference URL in a web page or creating an application that downloads the file.


Segment Size and Latency

Up until 2016, Apple recommended using ten-second segments for HLS. The specification also required three segments to be loaded before playback could begin. By sticking with the ten-second recommendation, broadcasters would start out with 30 seconds of latency based on segment size alone. Apple eventually decreased the default segment size to six seconds, but that still meant that a ‘live’ stream might lag almost 20 seconds behind.

A popular way to decrease the lag has been to reduce the size of segments, called ‘tuning’ HLS for low latency. Shorter chunks enable faster download times, thereby speeding things up. But that’s not the only route to speedy streaming with HLS. In 2019, Apple announced the specs for an extension called Apple Low-Latency HLS. And more recently, this extension has been incorporated into the overarching HLS standard as a feature set.

Резюме файла HLS

Расширение файла HLS имеет два тип (-ов) файла (-ов) и связано с два различными программными обеспечениями, но главным образом с Electronic Arts SimCity 4, разработанным Electronic Arts. Часто они представлены в формате SimCity 4 Hitlist. Большинство файлов HLS относятся к Game Files, однако они также могут относится к Video Files.

Просматривать файлы HLS можно с помощью операционных систем Windows, Mac и iOS. Они обычно находятся на настольных компьютерах (и ряде мобильных устройств) и позволяют просматривать и иногда редактировать эти файлы. Рейтинг популярности данных файлов составляет «Низкий» и они обычно не используются.

Поддержка на сервере

Nimble Streamer — бесплатный программный медиа-сервер с полной поддержкой SLDP. Он берёт на вход любой протокол и выдаёт SLDP на выход. Создаётся поток SLDP с H.264/H.265/VP8/VP9 видео и AAC/MP3 аудио, и любой плеер с поддержкой протокола может к нему подключиться.

Amazon CloudFront полностью поддерживает доставку WebSockets, таким образом SLDP можно доставлять через CloudFront.Статья Настройка CloudFront для доставки SLDP даст больше подробностей.

Синхронизация проигрывания

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

Это бывает важно в различных случаях:

  • Один экран с несколькими личными аудио-устройствами.
  • Приложение «второго экрана».
  • Несколько экранов с одним источником звука.
  • Камеры наблюдения, отображаемые на одной странице.

Читайте эту статью

Можете попробовать демо-страницу HTML5 с двуми плеерами SLDP, которые показывают видео синхронно.На видео ниже показан плеер в HTML5 браузере, на устройствах Android и iOS, играющие один и тот же синхронизированный поток:

Комплексное сравнение различных решений

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

Таблица 3, сравнение потоковых технологий с низкой задержкой

Ключевые показатели

ABR (HLS/DASH)

ABR (HLS/DASH) c CMAF LLC*

WebRTC

Основная область применения

OTT-вещание

OTT-вещание

Обмен данными в режиме близком к реальному времени

Суммарная задержка

От 20 до 40 сек (обычная). Ниже 10 секунд (с ограничением по качеству видео)

5-9 сек (результаты тестов)

Может быть ниже 3 сек

Основные преимущества

Низкая стоимость доставки **

  Встроенная поддержка:
  • Линейные и нелинейные рабочие процессы
  • Монетизация контента (DAI)
  • Стандартные DRM системы с общим шифрованием
  • Вещательные кодеки (в том числе и HEVC) и UHD-разрешение
 

Ограничения

Ухудшение качества сжатого видео при выборе режима кодирования с низкой задержкой (короткие сегменты и GOP)

Проблемы интеграции компонентов экосистемы (сервера- источника, CDN, плеера).

Масштабируемость Ограниченная поддержка кодеков Собственная DRM-система, нет поддержки монетизации контента (DAI)

Этап внедрения

Широкое внедрение, (без оптимизации по задержке)

Готова к внедрению

Внедрена

Время задержки — это важно

Низкое время задержки — критичный вопрос для живого вещания. Многие сценарии требуют минимальной задержки — менее секунды — между съёмкой и отображением события на экране.

  • Чаты: общение всегда подразумевает немеденную реакцию.
  • Игровые трансляции требуют реального масштаба времени.
  • Ставки и торги: когда на кону большие деньги, вам точно не захочется узнать всё последним.
  • Безопасность и системы слежения требуют живой картинки для немеленной реакции.
  • В приложениях «второго экрана» зритель не хочет видеть картинку на десятки секунд позже телевизионной.

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


Софтвелум представляет SLDP — протокол доставки «последней мили» до пользовательских устройств, который решает эти задачи.

HTML5 Video Streaming with HLS

As mentioned above, the HLS protocol has become the go-to approach for streaming content with HTML5 video players. If you’re not familiar with HTML5 video streaming, it’s one of three main approaches to video streaming today.

With HTML5, the content-hosting website uses native HTTP to stream the media directly to viewers. Content tags (e.g., <video> tag) are included as part of the HTML code. 

As a result, the <video> tag creates a native HTML5 video player within your browser. These tags provide direction to the HTTP protocol (HLS), as to what to do with this content. HTTP displays the text, and an audio player plays audio content.

Like HLS, HTML5 is customizable for broadcasters and free for viewers. You can check out our related post on optimizing HTML5 video players with HLS to learn more.

We’ve also written extensively about the transition from Flash-based video (usually delivered via RTMP) to HTML5 video (usually delivered using HLS). Check out our “Flash is Dead” blog post for more on that subject, including why it’s important to use an HTML5 video player.

If you’re streaming over the Dacast, you’re already using a fully-compatible HTML5 video player. Content delivered via Dacast defaults to HTML5 delivery. However, it will use Flash as a backup method if HTML5 is not supported on a given device or browser. This means that even older devices will have no problem playing your content over your Dacast account.

Of course, some broadcasters may prefer to use a custom video player. Luckily, it’s quite simple to embed your HLS stream within any video player. For example, if you’re using JW Player, simply insert the M3U8 reference URL into the code for your video player. Here’s a visual example:

Another note about using HLS and an HTML5 video player with Dacast is that Dacast uses the THEOplayer. THEOplayer is a universal video player that can be embedded in websites, mobile apps, and pretty much any platform that you can think of.

As we’ve mentioned before, compatibility is key when choosing video players and protocols since you want to be able to reach the greatest number of people.

WebRTC

WebRTC — это протокол с открытым исходным кодом, изначально разработанный для взаимодействия между браузерами в одноранговых сетях. С точки зрения показателей задержки протоколы WebRTC и Web-socket актуальны в первую очередь для приложений со сверхнизкой задержкой. Типичные приложения, для которых предназначен WebRTC, — задачи близкие к вещанию в реальном времени (например, приложения для интерактивных социальных сетей, видеоконференции и т. д.). Следует признать, что с точки зрения задержки данная технология может работать даже лучше, чем это необходимо для соответствия параметрам задержки в вещательных сетях. Однако к ОТТ-платформам предъявляются и другие требования.

Конкурентоспособная система OTT-услуг должна удовлетворять значительно большему количеству требований, чем просто доставка живого контента с минимальной задержкой. Современные OTT-платформы должны обеспечивать защиту контента, масштабируемость услуг, поддерживать нелинейные сервисы и т. д. Технология WebRTC как таковая таких возможностей не дает. В момент начала сеанса WebRTC требует выделенных серверов, имеющихся не во всех CDN, поэтому масштабируемость технологии вызывает сомнения. Более того, для WebRTC требуется другая версия клиента, поэтому понадобится реинжиниринг всей базы HLS и DASH клиентов.

Внедрение DASH CMAF LLC при облачной реализации OTT

Поскольку все больше операторов рассматривают применение облачной инфраструктуры для развертывания OTT-сервисов, в Harmonic провели тестирование с использованием видео SaaS от Harmonic. Производительность кодера Harmonic, включая задержку, была одинаковой, независимо от того, работал он в составе локального или облачного решения (см. рисунок 6).

Основная трудность облачной реализации заключается в том, что сигнал из аппаратной должен быть доставлен до облачного сервиса транскодирования. Обычно для преобразования студийного сигнала в IP-поток, который может быть отправлен в облако, требуется кодер для межстудийного обмена. Такие кодеры обеспечивают видеопоток хорошего качества с задержкой в несколько сотен миллисекунд. Затем поток IP отправляется в облако через управляемую сеть с хорошим QoS или через открытый Интернет.

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

Таблица 1. Влияние режима помехозащищенности на задержку

Качество сети

Помехозащищенность в канале доставки в облако

Суммарная задержка в канале доставки в облако

Отличное

Не активирована

О,8 сек

Удовлетворительное

Работает в обычном режиме

1,4 сек

Плохое

Работает в усиленном режиме

2,5 сек

В ходе тестов компания Harmonic обнаружила, что все процессы, связанные с загрузкой потока в облако, в большинстве регионов добавляли дополнительные 1,4 секунды задержки. В результате общая задержка HD-потока с момента его выхода из аппаратной до начала воспроизведения плеером при использовании облачных систем компрессии и доставки составляла приблизительно семь секунд.


С этим читают