Share this
Low Latency DASH (LL-DASH)
by THEOplayer on September 24, 2020
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
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.
Different options:
- 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.
- 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.
Contact our LL-DASH Experts
Share this
- THEOplayer (45)
- online streaming (40)
- live streaming (35)
- low latency (32)
- video streaming (32)
- HESP (24)
- HLS (21)
- new features (21)
- THEO Technologies (20)
- SDK (19)
- THEOlive (17)
- best video player (17)
- html5 player (16)
- LL-HLS (15)
- cross-platform (15)
- online video (15)
- SmartTV (12)
- delivering content (12)
- MPEG-DASH (11)
- Tizen (11)
- latency (11)
- partnership (11)
- Samsung (10)
- awards (10)
- content monetisation (10)
- innovation (10)
- Big Screen (9)
- CDN (9)
- High Efficiency Streaming Protocol (9)
- fast zapping (9)
- video codec (9)
- SSAI (8)
- Ultra Low Latency (8)
- WebOS (8)
- advertising (8)
- viewers expercience (8)
- "content delivery" (7)
- Adobe flash (7)
- LG (7)
- Online Advertising (7)
- Streaming Media Readers' Choice Awards (7)
- html5 (7)
- low bandwidth (7)
- Apple (6)
- CMAF (6)
- Efficiency (6)
- Events (6)
- drm (6)
- interactive video (6)
- sports streaming (6)
- video content (6)
- viewer experience (6)
- ABR (5)
- Bandwidth Usage (5)
- Deloitte (5)
- HTTP (5)
- ad revenue (5)
- adaptive bitrate (5)
- nomination (5)
- reduce buffering (5)
- release (5)
- roku (5)
- sports betting (5)
- video monetization (5)
- AV1 (4)
- DVR (4)
- Encoding (4)
- THEO Technologies Partner Success Team (4)
- Update (4)
- case study (4)
- client-side ad insertion (4)
- content encryption (4)
- content protection (4)
- fast 50 (4)
- google (4)
- monetization (4)
- nab show (4)
- streaming media west (4)
- support matrix (4)
- AES-128 (3)
- Chrome (3)
- Cost Efficient (3)
- H.265 (3)
- HESP Alliance (3)
- HEVC (3)
- IBC (3)
- IBC trade show (3)
- THEOplayer Partner Success Team (3)
- VMAP (3)
- VOD (3)
- Year Award (3)
- content integration (3)
- customer case (3)
- customise feature (3)
- dynamic ad insertion (3)
- scalable (3)
- server-side ad insertion (3)
- video (3)
- video trends (3)
- webRTC (3)
- "network api" (2)
- Amino Technologies (2)
- Android TV (2)
- CSI Awards (2)
- Encryption (2)
- FireTV (2)
- H.264 (2)
- LHLS (2)
- LL-DASH (2)
- MPEG (2)
- Microsoft Silverlight (2)
- NAB (2)
- OMID (2)
- Press Release (2)
- React Native SDK (2)
- Start-Up Times (2)
- UI (2)
- VAST (2)
- VP9 (2)
- VPAID (2)
- VPAID2.0 (2)
- ad block detection (2)
- ad blocking (2)
- adobe (2)
- ads in HTML5 (2)
- analytics (2)
- android (2)
- captions (2)
- chromecast (2)
- chromecast support (2)
- clipping (2)
- closed captions (2)
- deloitte rising star (2)
- fast500 (2)
- frame accurate clipping (2)
- frame accurate seeking (2)
- metadata (2)
- multiple audio (2)
- playback speed (2)
- plugin-free (2)
- pricing (2)
- seamless transition (2)
- server-side ad replacement (2)
- subtitles (2)
- video publishers (2)
- viewer engagement (2)
- wowza (2)
- "smooth playback" (1)
- 360 Video (1)
- AOM (1)
- API (1)
- BVE (1)
- Best of Show (1)
- CEA-608 (1)
- CEA-708 (1)
- CORS (1)
- DIY (1)
- Edge (1)
- FCC (1)
- HLS stream (1)
- Hudl (1)
- LCEVC (1)
- Microsoft Azure Media Services (1)
- Monoscopic (1)
- NAB Show 2016 (1)
- NPM (1)
- NetOn.Live (1)
- OTT (1)
- Periscope (1)
- React Native (1)
- Real-time (1)
- SGAI (1)
- SIMID (1)
- Scale Up of the Year award (1)
- Seeking (1)
- Stereoscopic (1)
- Swisscom (1)
- TVB Europe (1)
- Tech Startup Day (1)
- Telenet (1)
- Uncategorized (1)
- University of Manitoba (1)
- User Interface (1)
- VR (1)
- VR180 (1)
- Vivaldi support (1)
- Vualto (1)
- adblock detection (1)
- apple tv (1)
- audio (1)
- autoplay (1)
- cloud (1)
- company news (1)
- facebook html5 (1)
- faster ABR (1)
- fmp4 (1)
- hiring (1)
- iGameMedia (1)
- iOS (1)
- iOS SDK (1)
- iPadOS (1)
- id3 (1)
- language localisation (1)
- micro moments (1)
- mobile ad (1)
- nagasoft (1)
- new web browser (1)
- offline playback (1)
- preloading (1)
- program-date-time (1)
- server-guided ad insertion (1)
- stream problems (1)
- streaming media east (1)
- support organization (1)
- thumbnails (1)
- use case (1)
- video clipping (1)
- video recording (1)
- video trends in 2016 (1)
- visibility (1)
- vulnerabilities (1)
- zero-day exploit (1)
- August 2024 (1)
- July 2024 (1)
- January 2024 (1)
- December 2023 (2)
- September 2023 (1)
- July 2023 (2)
- June 2023 (1)
- April 2023 (4)
- March 2023 (2)
- December 2022 (1)
- September 2022 (4)
- July 2022 (2)
- June 2022 (3)
- April 2022 (3)
- March 2022 (1)
- February 2022 (1)
- January 2022 (1)
- November 2021 (1)
- October 2021 (3)
- September 2021 (3)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (8)
- April 2021 (4)
- March 2021 (6)
- February 2021 (10)
- January 2021 (4)
- December 2020 (1)
- November 2020 (1)
- October 2020 (1)
- September 2020 (3)
- August 2020 (1)
- July 2020 (3)
- June 2020 (3)
- May 2020 (1)
- April 2020 (3)
- March 2020 (4)
- February 2020 (1)
- January 2020 (3)
- December 2019 (4)
- November 2019 (4)
- October 2019 (1)
- September 2019 (4)
- August 2019 (2)
- June 2019 (1)
- December 2018 (1)
- November 2018 (3)
- October 2018 (1)
- August 2018 (4)
- July 2018 (2)
- June 2018 (2)
- April 2018 (1)
- March 2018 (3)
- February 2018 (2)
- January 2018 (2)
- December 2017 (1)
- November 2017 (1)
- October 2017 (1)
- September 2017 (2)
- August 2017 (3)
- May 2017 (3)
- April 2017 (1)
- March 2017 (1)
- February 2017 (1)
- December 2016 (1)
- November 2016 (3)
- October 2016 (2)
- September 2016 (4)
- August 2016 (3)
- July 2016 (1)
- May 2016 (2)
- April 2016 (4)
- March 2016 (2)
- February 2016 (4)
- January 2016 (2)
- December 2015 (1)
- November 2015 (2)
- October 2015 (5)
- August 2015 (3)
- July 2015 (1)
- May 2015 (1)
- March 2015 (2)
- January 2015 (2)
- September 2014 (1)
- August 2014 (1)