0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Что такое MPEG DASH вещание

Что такое MPEG DASH вещание?

На сегодняшний день тема MPEG DASH вещания является наиболее актуальной в сфере передачи видеоданных. В этой статье мы рассмотрим, что представляет собой MPEG DASH вещание и какое влияние в будущем оно может оказать на технологии видеовещания.

MPEG DASH (Dynamic Adaptive Streaming over http — Динамическое Адаптивное Потоковое HTTP-вещание) — это проект стандарта ISO (ISO/IEC 23009-1). Планируется, что окончательно стандарт MPEG DASH будет разработан к концу этого года. Как следует из названия, DASH — это стандарт для адаптивного потокового HTTP-вещания. Ожидается, что в будущем он заменит существующие технологии вещания, такие как Microsoft Smooth Streaming, Adobe Dynamic Streaming и Apple HTTP Live Streaming (HLS). Единый стандарт станет полезным для контент-производителей, которым будет достаточно создавать файлы одного типа, которые без каких-либо трудностей будут проигрываться на всех DASH-совместимых устройствах.

Группа разработчиков DASH-стандарта нашла поддержку среди крупнейших мировых компаний, таких как Apple, Adobe, Microsoft, Netflix, Qualcomm и многих других. Более того, Microsoft заявила, что она внедрит DASH-стандарт, как только он будет утвержден. И хотя от Adobe и Apple пока еще не было подобных заявлений, поддержка со стороны этих двух компаний окажет положительное влияние на будущее этого стандарта на рынке вещания.

Тем не менее, MPEG DASH-стандарт имеет серьезные проблемы с HTML5-кодеком. Ведь за основу в DASH-стандарте будут взяты H.264 или WebM кодеки, которые не являются универсальными и не поддерживаются всеми HTML5 браузерами. Это значит, что DASH-пользователям придется осуществлять мультипотоковую передачу, задействовав несколько кодеков, что увеличит затраты на кодирование и хранение информации. Также вырастут и административные расходы.

И наконец, остается неясным вопрос, будет ли DASH-стандарт платным или абсолютно бесплатным? Ответ на этот вопрос может повлиять на большинство потенциальных пользователей стандарта. Например, Mozilla заявила, что она вряд ли будет применять DASH-стандарт, если тот не будет бесплатным. А учитывая тот факт, что на начало этого года браузеру Firefox принадлежало около 22% рынка, то будущее платного DASH-стандарта на рынке HTML5 выглядит весьма туманным.

Статьи

Компании и провайдеры сетей доставки контента (CDN) готовятся к будущему, где потоковое вещание получит ещё более широкое распространение. Поэтому потребность в более эффективных протоколах такого вещания становится как никогда актуальной. Встречайте будущее живых трансляций – SRT, HLS и MPEG DASH. Давайте посмотрим, что представляет собой каждый из этих протоколов прямой трансляции, их преимущества и применение. А чтобы помочь вам выбрать тот, который подходит именно вам, в конце этой статьи приведено краткое сравнение.

Secure Reliable Transport (SRT)

SRT – восходящая звезда потоковой передачи. Протокол обеспечивает высокое качество видео и аудио с низкой задержкой по ненадёжному общедоступному Интернету. Фактически вы можете контролировать величину задержки и устранять такие проблемы, как дрожание из-за потери пакетов в плохих сетях. SRT также упрощает обход файерволов без помощи IT-специалиста, а также экономичен при развёртывании в существующей сетевой инфраструктуре. Кроме того, SRT предлагает безопасную потоковую передачу с 256-битным шифрованием AES.

SRT – это потоковый протокол с открытым исходным кодом, который набирает популярность благодаря «Альянсу SRT», объединяющему усилия многих лидеров отрасли и разработчиков с целью его продвижения и внедрения. Epiphan Video является сертифицированным членом «Альянса SRT» наряду с YouTube, Akamai, Wowza и другими. SRT включает в себя популярное программное обеспечение, в которое уже встроены OBS Studio, gstreamer и VLC.

Это фактически «технология замены спутника» – низкая стоимость и способность SRT доставлять высококачественный контент через Интернет в режиме, близком к реальному времени, дают вещателям жизнеспособную альтернативу дорогостоящей спутниковой технологии.

Преимущества
  • Высококачественные видео и аудио с низкой задержкой надёжно доставляются даже через ненадёжный Интернет.
  • SRT легко пересекает межсетевые экраны (файерволы) между источником и получателем.
  • Контроль задержки, чтобы приспособиться к изменяющимся условиям сети.
  • Прямая трансляция защищена с помощью 256-битного шифрования AES.
Как работает SRT

Между источником SRT (кодер) и получателем SRT (декодер) устанавливается выделенная линия связи для управления и восстановления пакетов. Получателем может быть сервер, CDN или другое устройство SRT. SRT использует свой собственный метод восстановления после потери пакетов, используя UDP-пакеты по сети, которые можно настроить для адаптации к изменяющимся условиям сети. Когда сетевые условия плохие, можно добавить больше буферизации пакетов для улучшения качества видео. По мере улучшения условий в сети величина задержки может быть уменьшена для потоковой передачи практически в реальном времени.

SRT обеспечивает прохождение через любые файерволы между источником и получателем. Для этого протокол имеет три режима: рандеву и вызов/слушатель.

Режим рандеву является самым простым и обычно не требует участия IT-специалистов для настройки прохождения файрволов между источником и получателем SRT. Если вы не можете пройти через сетевой экран, то следует использовать режим вызов/слушатель. Однако для настройки пересылки трафика потребуется определённое участие IT-специалистов, чтобы трафик, полученный на общедоступный IP-адрес и порт устройства-получателя SRT, переадресовывался на устройство в локальной сети.

Применение SRT

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

HTTP Live Streaming (HLS)

HLS – это адаптивный протокол потоковой передачи на основе HTTP, который отправляет видео- и аудиоконтент по сети в небольшие сегменты потокового мультимедиа на основе TCP, которые повторно собираются в месте назначения. Стоимость развёртывания HLS является низкой, поскольку она использует существующую сетевую технологию на основе TCP, что является привлекательным для CDN, желающих заменить старые (и дорогие) RTMP-серверы. Но поскольку HLS использует TCP, то он работает по принципу «качество важней задержки», поэтому время задержки может быть высоким (например, в секундах, а не в миллисекундах).

HLS был первоначально разработан Apple Inc. в качестве протокола для потоковой передачи мультимедиа на устройства Apple. С тех пор Apple разработала HLS (push), который является потоковым протоколом открытого стандарта, доступным для всех устройств. В настоящее время HLS поддерживает видео, кодированное с использованием кодеков H.264 или HEVC.

Преимущество HLS заключается в том, что он предназначен для адаптации к различным условиям сети. Разные версии потока отправляются с разными разрешениями и битрейтами. Зрители могут выбрать то качество потока, что они хотят. HLS также поддерживает несколько звуковых дорожек, что означает, что ваш поток может иметь несколько языковых дорожек, из которых пользователи могут выбирать нужную. Другие преимущества включают поддержку скрытых титров, метаданных, управления цифровыми правами (DRM) и даже встроенных рекламных объявлений (в не слишком отдалённом будущем).

Поддерживается безопасная потоковая передача по HTTP, а также алгоритмы хеширования MD5 и SHA для аутентификации имени пользователя и пароля.

Преимущества
  • Высококачественное видео (до 4K) и аудио надёжно доставляются по некачественным сетям, где низкая задержка не является обязательным требованием.
  • Легко проходит через фаейрволы.
  • Адаптируется к различным условиям сети и отправляет несколько видеопотоков с различными разрешениями и битрейтами.
  • Поддержка нескольких звуковых дорожек для таких вещей, как многоязычные потоки.
  • Поддерживает метаданные и другие расширенные функции.
  • Экономичен в развёртывании и легко масштабируется с использованием традиционных сетевых серверов и технологий.
  • Безопасный прямой эфир с использованием HTTP и алгоритмов аутентификации MD5 и SHA.

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

Подход очень похож на передачу файлов. Сегменты потокового мультимедиа через порт HTTP 80 (или порт 443 для HTTPS), который обычно уже открыт для сетевого трафика. Таким образом, контент может легко проходить через файерволы практически без участия IT-специалистов.

HLS использует контейнер транспортного потока MPEG2-TS с полуконфигурируемой продолжительностью сегмента, а также с настраиваемым размером списка воспроизведения для повторной сборки принятых сегментов на центральном сервере. Также поддерживается фрагментированный MP4.

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

Применение HLS

HLS по-прежнему является стандартом для потоковой передачи на мобильные устройства и планшеты. Вы также можете использовать HLS для потоковой передачи на CDN, который не поддерживает RTMP, когда низкая задержка не является обязательным требованием. Важно отметить, что RTMP уже считается устаревшим во всё более увеличивающемся количестве CDN. HLS также хорошо подходит для безопасной потоковой передачи корпоративного обучения и трансляций через локальные сети (LAN), когда низкая задержка не является обязательным требованием, а условия сети плохие (при условии, что сеть поддерживает HLS).

MPEG-DASH (Dynamic Adaptive Streaming over HTTP)

MPEG-DASH – это открытый стандарт адаптивного протокола потоковой передачи на основе HTTP, который отправляет видео и аудиоконтент по сети в виде небольших сегментов потокового мультимедиа на основе TCP, которые повторно собираются в месте назначения. Международная организация по стандартизации (ISO) и команда MPEG и MPEG-DASH спроектировали кодирование и разрешение независимо от других, что означает, что MPEG-DASH может передавать потоковое видео (и аудио) любого формата (H.264, H.265 и т. д.) и поддерживает разрешения до 4K. В остальном, MPEG-DASH функционирует почти так же, как и HLS.

Стоимость развёртывания MPEG-DASH низкая, поскольку в нём используется существующая сетевая технология на основе TCP, что является привлекательным для CDN. Но поскольку HLS использует TCP, то он работает по принципу «качество важней задержки», поэтому время задержки может быть высоким

MPEG-DASH также предназначен для адаптации к различным условиям сети. Разные версии потока отправляются с разными разрешениями и битрейтами. Зрители могут выбрать качество потока, который они хотят. Также поддерживаются несколько звуковых дорожек, а также расширенные функции, такие как скрытые титры, метаданные и управление цифровыми правами (DRM). Инфраструктура предназначена для будущих разработок, например, встроенной рекламу.

Поддерживается безопасная потоковая передача по HTTP, а также алгоритмы хеширования MD5 и SHA для аутентификации имени пользователя и пароля.

Преимущества
  • Высококачественное видео (до 4K) и аудио надёжно доставляются по некачественным сетям, где низкая задержка не является главным требованием.
  • Легко проходит через файерволы.
  • Адаптируется к различным условиям сети и отправляет несколько видеопотоков с различными разрешениями и битрейтами.
  • Поддерживает различные видео и аудио кодеки.
  • Поддерживает нескольких звуковых дорожек, например, для многоязычных потоков.
  • Поддерживает метаданные и другие расширенные функции.
  • Экономичен в развёртывании и легко масштабируется с использованием традиционных сетевых серверов и технологий.
  • Безопасный прямой эфир с использованием HTTP и алгоритмов аутентификации MD5 и SHA.

Как работает MPEG-DASH и его применение

MPEG-DASH работает так же, как HLS – отправляет короткие средние сегменты по HTTP (порт 80) или HTTPS (порт 443) для облегчения обхода файервола. Он использует контейнер транспортного потока MPEG2-TS с половиной настраиваемой длительности сегмента, а также настраиваемый размер списка воспроизведения для повторной сборки принятых сегментов на центральном сервере. Также поддерживается фрагментированный MP4.

Высокая задержка MPEG-DASH обусловлена ​​главным образом потерей сетевых пакетов и методом восстановления, используемым во всех сетях на основе TCP. И хотя MPEG-DASH предлагает некоторый контроль над размером сегмента мультимедиа, возможность уменьшить задержку ограничена – особенно, если сервер требует загрузки среднего сегмента определённого размера.

MPEG-DASH лучше всего подходит для потоковой передачи на CDN, которые не поддерживают RTMP, в случаях, когда низкая задержка не является обязательным требованием. MPEG-DASH также хорошо подходит для безопасной потоковой передачи корпоративного обучения и трансляций через локальные сети (LAN), когда низкая задержка не является обязательным требованием, а условия сети плохие

Какой потоковый протокол подходит вам?

Хотя RTMP, безусловно, всё ещё является самым популярным потоковым протоколом, такие протоколы, как SRT, HLS и MPEG-DASH, бросают ему вызов. Так что они умеют такого, чего не умеет RTMP?

  • Транслировать несколько звуковых каналов для одного канала видео, что позволяет транслировать многоязычный контент.
  • Включать в себя метаданные и другие типы встроенного контента.
  • Поддерживать управления цифровыми правами (DRM).
  • Отправлять несколько версий потока с различными разрешениями и битрейтами, чтобы зрители могли выбрать качество, соответствующее их условиям сети или размеру экрана.

HLS и MPEG-DASH обеспечивают гораздо более простую и дешёвую масштабируемость, чем RTMP. Так как RTMP и обычно требует, чтобы порты были открыты вручную для прохождения через файерволы.

Если задержка или плохие условия сети не являются проблемой, то HLS или MPEG-DASH превосходит SRT. Протоколы адаптивной потоковой передачи на основе HTTP обеспечивают наилучшее возможное качество видео для зрителей с различными условиями сети и более просты в настройке, чем SRT.

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

Заверните!

Многие CDN, такие, например, как Akamai, уже объявили о прекращении поддержки RTMP, как устаревшего и дорогого для развёртывания. С ростом популярности новых протоколов SRT, HLS и MPEG-DASH, RTMP вскоре уйдёт в прошлое. Вот почему мы в Epiphan Video, добавили поддержку SRT, HLS и MPEG-DASH в наше семейство систем видеопроизводства «все-в-одном» Pearl.

Теперь вы можете быть уверены, что Pearl Nano и Pearl Mini готовы к будущему потокового вещания. Семейство кодеров Pearl является одним из немногих устройств в своём ценовом диапазоне, которые сертифицированы для потоковой передачи HLS и MPEG-DASH на Akamai.

Low Latency DASH (LL-DASH)

Apple’s HLS and MPEG-DASH are two of the most popular HTTP Adaptive Streaming (HAS) protocols that have become the de facto industry standards. In this blog we will talk about MPEG-DASH, more specifically its low latency variant (LL-DASH), explain how it works and things to consider when it comes to its implementation. You can also check out our previous blog posts to learn more about HLS and Low Latency HLS (LL-HLS).

Dynamic Adaptive Streaming over HTTP

Dynamic Adaptive Streaming over HTTP (DASH) was first released in 2010 from MPEG (Moving Picture Experts Group). This streaming protocol is codec agnostic, meaning it is compatible with almost all video codecs such as H.264, H.265/HEVC, VP9 and AV1, as well as most audio codecs. Low Latency DASH (LL-DASH) was first introduced in 2017 by means of interoperability profiles and extensions of the specification. It can be supported following the same approach as MPEG-DASH where support can be implemented in a “bring your own” media player approach on most common browsers and platforms. This includes notable platforms such as Android devices as well as smart TVs. Where most platforms don’t support LL-DASH natively, players for these platforms are available.

With MPEG-DASH being compatible with the Common Media Application Format (CMAF), most people wrongly assume this also allows for low latency. This is however not the case: CMAF itself does not reduce latency, but does provide some tools to make it possible such as splitting up media segments in smaller chunks. The main driver behind CMAF was efficiency, not low latency.

MPEG-DASH works by splitting video into smaller files, called segments which can be sent efficiently over the network and over Content Delivery Networks (CDNs). Latency is caused by the segments themselves (travelling through the video ecosystem), the encoder, the CDN or network, or from the player buffer. While reducing the size of the segments might slightly reduce the glass to glass latency, the smaller segments could cause the quality or the bandwidth of the stream to suffer, and it also causes more requests from the CDN (slowing down the stream).

How Does LL-DASH Work?

Although sometimes LL-DASH is referred to in the industry as CMAF-CTE (Chunked Transfer Encoding), this is not entirely accurate as CMAF-CTE is only a method used in LL-DASH. This method essentially cuts the segments into smaller, non-overlapping chunks (often containing a handful of frames), which are all independent of one another. This means the origin doesn’t have to wait until the segment is completely finished before the first chunks can be sent to the player.

The Manifest can indicate when a segment will become available on the server. By observing when segments become available, a client can quickly and accurately request a segment as soon as it becomes available, reducing delays. This does require an accurate synchronization between the clocks of the client and server. For this, MPEG-DASH allows you to configure a time server.

DASH vs. LL-DASH

Usually when live streaming, the media is sent in segments that are each a few seconds long. These segments shouldn’t be shorter than 2 to 4 seconds or there could be a risk of poor performance/playback quality. With LL-DASH, if the player requests a segment which is not completed, chunks will be delivered as soon as they are available using Chunked Transfer Encoding. As media can be delivered to the client as soon as it is generated on the server side, overhead is reduced, allowing to reduce the client’s buffer and, as a result, latency. A client’s buffer should contain around 3-4 chunks to guarantee smooth playback, potentially reducing the latency to something of this order of magnitude. In practice, it is also important to take manifest handling, time synchronization and buffering for network issues into account. With LL-DASH, we can reduce the latency to a couple seconds instead of the multiple 10’s of seconds that we had before.

Protecting your low latency content with DRM for LL-DASH

Certain Digital Rights Management (DRM) Systems are native to specific browsers, which can present limitations to which streaming protocol can be used:

Microsoft Playready: Native on IE, Edge

Google’s Widevine: Native on Chrome, Firefox

Adobe Primetime: Native on Firefox

Clearkey: an encryption solution and free alternative to commercial DRM solutions for DASH content, but it does not offer the same level of protection as PlayReady, Widevine.

DRM can have an important impact on latency because the player must first inspect the content and acquire a license for it, and once the player notices the encryption is there, it will start to request the license that is needed to start the stream. In low latency situations, buffers are smaller, and making these requests could cause a few hundreds of milliseconds or even seconds delay. This delay may not seem like much, but it’s important to keep in mind, especially when it comes to start-up time and key rotation (i.e. with SSAI when a period ends and a new one starts). The player must have this license request before playback can start, so the request must happen quickly.

In DASH you can put DRM initialisation information (called the PSSH) in the manifest or in the initialisation segment. By placing this information in the manifest, a client can start negotiating for a license before any media segments have to be loaded. In a low latency case, it is recommended to provide the PSSH information in the manifest in order to avoid any unneeded delays for the license request.

Widevine and PlayReady both support MPEG-DASH, so with that in mind, it is possible to encrypt and package your content once and decrypt using either DRM system. It is possible to do the same with HLS, and add all DRMs (including Fairplay) in one stream.

Monetizing your low latency content with SSAI for LL-DASH

With MPEG-DASH, SSAI can be implemented using Periods. Periods are some of the basic building blocks, indicating a coherent piece of content being played, such as a section of main content, or an advertisement. A manifest contains one or more periods, which in turn contain Adaptation Sets (about the same as a Track) containing Representations (which are the different qualities). When inserting an advertisement, a period can be added in the manifest to break up the main content. In LL-DASH, this same mechanism can be used.

There are some important limitations to multi period support:

Not all players support this.

Decoders (especially on older devices or platforms such as smart TV) don’t like the reconfiguration required when changing periods. This often results in black frames or delays between playback of different periods.

Enabling or disabling DRM on a decoder can be especially tricky.

To identify a future period, a client has to update the manifest. With low latency, this means the player needs to refresh the manifest at a quick interval. Depending on when the ad has to be inserted, it can mean a segment ends early and that the client cannot anticipate a next segment becoming available at a certain location, but instead needs to discover it from an up to date manifest. This results in frequent refreshes of the manifest, causing overhead. All of this makes doing SSAI with Low Latency DASH far from trivial, and should be evaluated carefully.

Improving accessibility with subtitles and captions at low latency with LL-DASH

DASH is most often used with WebVTT or TTML. These require start and end times to be specified for every cue. Cues often appear on the screen for a few seconds, allowing a viewer to read the text. When the latency is supposed to be only a few seconds, knowing the end time of a cue can be a challenge. When a player is close to the live edge, the end time can be unknown, but this is not supported in the WebVTT or TTML formats. For Low Latency, a creative solution is to be found to ensure proper rendering of subtitles.

  1. Give subtitles a fixed duration: It’s simple, but doesn’t always give the desired result. For example when a commentator in a sports match is speaking rapidly during an on-screen action.
  2. Repeat subtitles: For example give subtitles an end-time of 1s and extend it if needed. This is also quite simple, but a client has to be aware subtitles are being repeated. If subtitles are badly aligned in start and end time, cues could appear on screen twice (however briefly), or could disappear for a short amount of time, creating a blinking effect.

Based on our experience the 2nd approach is the most flexible. To avoid blinking, a client can extend the cue further when no information about the cue is known after the end of the current segment. Also, it can detect duplicate text and render it on screen only once.

Test Your LL-DASH Stream

LL-DASH is supported widely across the video ecosystem in terms of compatibility and flexibility with different video codecs. DRM, SSAI and subtitles are features that are crucial for a wide range of services and impact content protection, content monetisation and accessibility. You can see LL-DASH in action on our test page, where you can use a stream provided by our friends at Akamai, or insert your own LL-DASH stream to test.

These solutions can be optimised together with our THEO Universal Player Solution to reduce latency and accelerate viewer experience. THEO has also implemented an Adaptive Bitrate algorithm optimized for Low-Latency DASH. If you have questions or would like personalised advice for your specific use case, contact our experts.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector