DASH — What It Is, Protocol and Principles of Dynamic Streaming

What Is DASH?

MPEG-DASH (Dynamic Adaptive Streaming over HTTP) is an international standard ISO/IEC 23009-1, published in 2012 as a response to the fragmentation of proprietary adaptive streaming solutions. Unlike HLS (Apple’s proprietary protocol) and Smooth Streaming (Microsoft), DASH was developed from the start as an open, vendor-independent standard, which ensured its broad industry support.

The main innovation of DASH is the separation of stream description and media content. The stream description is stored in an XML file called MPD (Media Presentation Description), which contains all information about available options: bitrates, resolutions, codecs, subtitles, audio tracks. Media content is stored in separate segments (usually fMP4), which can be loaded independently over HTTP. This architecture allows the server infrastructure to be as simple as possible — any HTTP server can serve DASH content.

Adaptivity in DASH is implemented through multiplexing of content variants. The server prepares several Representations — copies of content with different compression parameters. The client analyzes channel bandwidth and dynamically switches between representations, choosing the optimal balance of quality and playback stability. According to an academic study (IEEE Access, 2024), DASH with the BOLA algorithm shows 22% fewer bitrate switches compared to HLS under unstable connections.

History and Standardization of DASH

MPEG began work on DASH in 2010 after analyzing existing solutions: Apple HLS, Microsoft Smooth Streaming, and Adobe HDS. The first version of the standard (ISO/IEC 23009-1:2012) was released in 2012. The second version (2014) added support for events, improved ad insertion, and Server-Controlled Adaptation. The third version (2019) added support for HDR, 8K, haptic video, and improved integration with MMT (MPEG Media Transport) for 5G networks.

In 2024, MPEG announced DASH Next Generation, which includes support for neural network codecs, cloud rendering, and optimization for Extended Reality (XR) scenarios. A key innovation is Neural Network-Based Video Coding (NNVC), which uses ML models for client-side decoding, potentially reducing bitrate by 30-50% while maintaining quality.

How Does DASH Work?

The DASH stream playback process consists of four sequential stages: fetching the MPD, parsing the stream description, selecting the initial representation, and dynamic switching between representations. Each stage has its own specifics that affect the quality of user experience.

Fetching and Parsing the MPD

The player loads the MPD file from a known URL. The MPD contains an XML structure describing the entire stream: content duration, timeline, available periods (Period), adaptation sets (AdaptationSet), and representations (Representation) with specific encoding parameters. The player parses the MPD and creates an internal model of available media resources.

Example of a basic MPD file for VOD content with two resolutions:

<?xml version="1.0" encoding="utf-8"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
     profiles="urn:mpeg:dash:profile:isoff-live:2011"
     type="static"
     mediaPresentationDuration="PT1H30M">
    <Period duration="PT1H30M">
        <AdaptationSet mimeType="video/mp4">
            <Representation bandwidth="5000000"
                           width="1920" height="1080"
                           codecs="avc1.640028"/>
            <Representation bandwidth="1000000"
                           width="640" height="360"
                           codecs="avc1.64001E"/>
        </AdaptationSet>
    </Period>
</MPD>

Segment Loading and Adaptation

After selecting the initial representation, the player starts loading segments. Each segment contains several seconds of content (usually 2-10 seconds). The player maintains a buffer of several segments ahead, ensuring resilience to short-term network speed drops. The ABR (Adaptive Bitrate) algorithm constantly monitors segment download speed and decides on switching between available bitrates.

Modern ABR algorithms for DASH, such as BOLA (Buffer Occupancy based Lyapunov Algorithm) and Pensieve (based on Reinforcement Learning), consider not only current bandwidth but also buffer size, content type (sports, news, movies), and even device power consumption. BOLA, which is part of dash.js and ExoPlayer, minimizes the number of bitrate switches while maintaining a stable buffer, as confirmed by ACM research (Spiteri et al., 2020).

DASH Structure: MPD, Period, Adaptation Set

The hierarchical structure of a DASH stream is organized into four levels: MPD → Period → AdaptationSet → Representation. Each level adds a layer of detail, allowing the description of complex scenarios — from simple VOD to live broadcasts with ad insertions and multi-angle video.

MPD (Media Presentation Description)

MPD is the root element describing the entire media presentation. MPD attributes define the stream type (static for VOD, dynamic for live), total duration, timeline, profile, and DRM information. The MPD can contain one or more Periods, each representing an independent time segment of the content.

Period, AdaptationSet, and Representation

Period is a time segment of the presentation. For VOD, a single Period is used for the entire content. For live with ad breaks, the Period may change dynamically — the player loads the updated MPD and detects a new Period corresponding to the ad block. Each Period contains one or more AdaptationSets.

AdaptationSet is a group of interchangeable representations of one media type: video, audio, subtitles. Within an AdaptationSet, all representations differ only in bitrate and/or resolution but encode the same content. An important property: the player can switch between representations within the same AdaptationSet at segment boundaries without playback interruption.

Representation is a specific encoding variant with a defined bitrate, resolution, and codec. For each Representation, the MPD specifies a URL template for loading segments. DASH uses a flexible segment addressing system — through URL templates with segment number and time substitution ($Number$, $Time$), allowing the server to dynamically generate file names without listing each segment in the MPD.

Segmentation and Packaging

Segments in DASH can be of two types: Segment type (contain only media data) and Subsegment type (part of a segment for finer-grained access). For encoding DASH content, tools such as FFmpeg or batch encoders are used. Example of creating a DASH stream from an input file:

import subprocess

subprocess.run([
    "ffmpeg",
    "-i", "input.mp4",
    "-filter_complex",
    "[0:v]split=2[v1][v2];[v1]scale=1920:1080[v1out];[v2]scale=640:360[v2out]",
    "-map", "[v1out]", "-b:v:0", "5000k",
    "-map", "[v2out]", "-b:v:1", "1000k",
    "-map", "0:a",
    "-f", "dash",
    "-seg_duration", "4",
    "-use_template", "1",
    "-use_timeline", "1",
    "dash/stream.mpd"
])

DASH vs HLS: Protocol Comparison

The choice between DASH and HLS is one of the key decisions when designing a video streaming system. Both protocols solve the same problem (adaptive HTTP video delivery) but have fundamental differences in architecture, codec support, and ecosystem. Let’s examine them by key parameters.

Key advantage of DASH — codec independence. While HLS originally limited codecs to those supported by Apple (H.264, HEVC, and recently AV1), DASH can use any codec supported by the player: VP9/VP8 (critical for YouTube and Chrome), AV1 (for efficiency), H.264/HEVC (for compatibility). This makes DASH the preferred choice for cross-platform services requiring a unified stream for all devices.

Disadvantage of DASH on iOS — lack of native support in Safari and AVPlayer. iOS developers need to use third-party HLS-compatible players or libraries like libdash with integration via VTDecoder. In practice, this means that for iOS-first projects, HLS remains the de facto standard, while for Android and web platforms, DASH is a more flexible and powerful solution.

Using DASH in Mobile Development

Integration of DASH into mobile applications depends on the platform. On Android, DASH is supported directly through ExoPlayer with the extension module. On iOS, third-party libraries such as libdash with integration via AVFoundation or MPEGDASHPlayer are required. Let’s look at practical implementation for both platforms.

DASH on Android via ExoPlayer

ExoPlayer from Google provides built-in DASH support through the `exoplayer-dash` module. Connecting a DASH stream is no different from other formats — simply pass the MPD file URI in a MediaItem. ExoPlayer automatically detects the content format and launches the appropriate renderer, supporting all standard ABR algorithms.

val player = ExoPlayer.Builder(this).build()

val dashMediaItem = MediaItem
    .Builder()
    .setUri("https://example.com/dash/stream.mpd")
    .setMimeType("application/dash+xml")
    .build()

player.setMediaItem(dashMediaItem)
player.prepare()
player.playWhenReady = true

DASH with DRM on Both Platforms

Common Encryption (CENC) is one of DASH’s key features, allowing a single media stream to be used with different DRM systems. The MPD file contains ContentProtection XML elements with DRM system identifiers (Widevine, PlayReady, FairPlay). The client selects the appropriate DRM system based on its platform and requests a license from the license server.

val drmLicenseUri = Uri.parse("https://license.example.com/wv")
val drmSessionManager = DefaultDrmSessionManager
    .Builder()
    .setUuidAndExoMediaDrmProvider(
        C.WIDEVINE_UUID,
        FrameworkMediaDrm.DEFAULT_PROVIDER
    )
    .build(drmLicenseUri, null)

val mediaItem = MediaItem
    .Builder()
    .setUri("https://example.com/encrypted/stream.mpd")
    .setDrmConfiguration(
        MediaItem.DrmConfiguration.Builder(C.WIDEVINE_UUID)
            .setLicenseUri("https://license.example.com/wv")
            .build()
    )
    .build()

Optimizing DASH for Mobile Devices

Mobile applications require special DASH configuration due to limitations in bandwidth and power consumption. Key recommendations include: setting a minimum buffer of 2-3 segments for resilience to short-term speed drops, using segments 2-4 seconds long for faster response to network changes, and pre-loading the next segment when switching quality.

To save traffic on mobile networks, Bitmovin (2024) recommends using Content Steering — a mechanism similar to HLS’s analogous feature, allowing dynamic client direction to the optimal CDN node. DASH Content Steering is described in the ISO/IEC 23009-1:2022 specification and is supported in dash.js 4.5+ and ExoPlayer 2.18+.