{"id":1158,"date":"2026-06-24T09:43:56","date_gmt":"2026-06-24T02:43:56","guid":{"rendered":"https:\/\/liveapi.com\/blog\/mpeg-dash\/"},"modified":"2026-06-24T09:44:20","modified_gmt":"2026-06-24T02:44:20","slug":"mpeg-dash","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/mpeg-dash\/","title":{"rendered":"What Is MPEG-DASH? How Dynamic Adaptive Streaming over HTTP Works"},"content":{"rendered":"Reading Time: <\/span> 11<\/span> minutes<\/span><\/span>

When you watch a movie on Netflix or a clip on YouTube, the video quality shifts up and down as your connection changes \u2014 and most of the time, you never notice the switch. A large part of that smooth playback comes from MPEG-DASH, an open streaming standard that powers adaptive video delivery for some of the biggest platforms on the internet.<\/p>\n

MPEG-DASH gives developers a vendor-neutral way to deliver video over plain HTTP, with no proprietary servers or codecs locking you in. If you’re building a video product and weighing your protocol options, understanding how DASH works \u2014 and where it fits next to HLS \u2014 will save you weeks of trial and error.<\/p>\n

This guide breaks down what MPEG-DASH is, how the MPD manifest and segments fit together, how DASH compares to HLS, what low-latency DASH changes, and how to add adaptive streaming to your own app.<\/p>\n

What Is MPEG-DASH?<\/h2>\n

MPEG-DASH is an adaptive bitrate streaming protocol that delivers video over standard HTTP by splitting content into short segments encoded at multiple quality levels, letting the player pick the best version for current network conditions. The name stands for Dynamic Adaptive Streaming over HTTP<\/strong>.<\/p>\n

It was developed by the Moving Picture Experts Group (MPEG) and published as an international standard, ISO\/IEC 23009-1<\/a>, in April 2012, with later revisions in 2019 and 2022. Unlike HLS, which Apple created and controls, MPEG-DASH is an open standard backed by more than 50 companies, including Microsoft, Netflix, Google, Samsung, and Adobe.<\/p>\n

The core idea is simple. Instead of streaming one fixed-quality file, a DASH server prepares several renditions of the same video \u2014 for example 480p, 720p, and 1080p \u2014 and chops each into small chunks. The player then requests whichever chunk matches the viewer’s bandwidth at that moment, switching between renditions on the fly. This is the foundation of adaptive bitrate streaming<\/a>, and it’s why a stream can drop from HD to SD during a network dip without stopping to buffer.<\/p>\n

Because DASH rides on ordinary HTTP, it works with the same web servers and content delivery networks that already serve websites. There are no specialized streaming servers to maintain, which keeps delivery costs low.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Property<\/th>\nMPEG-DASH detail<\/th>\n<\/tr>\n<\/thead>\n
Full name<\/td>\nDynamic Adaptive Streaming over HTTP<\/td>\n<\/tr>\n
Standard<\/td>\nISO\/IEC 23009-1 (2012, revised 2022)<\/td>\n<\/tr>\n
Developed by<\/td>\nMoving Picture Experts Group (MPEG)<\/td>\n<\/tr>\n
Transport<\/td>\nHTTP (TCP or QUIC, depending on HTTP version)<\/td>\n<\/tr>\n
Manifest format<\/td>\nXML (.mpd file)<\/td>\n<\/tr>\n
Segment containers<\/td>\nFragmented MP4 (fMP4), MPEG-TS<\/td>\n<\/tr>\n
Codec support<\/td>\nCodec-agnostic (H.264, H.265, VP9, AV1, and more)<\/td>\n<\/tr>\n
Typical latency<\/td>\n6\u201330 seconds standard; 3\u20135 seconds with LL-DASH<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

MPEG-DASH vs HLS: Key Terminology<\/h2>\n

Before going deeper, it helps to clear up where DASH sits next to HLS, since the two protocols solve the same problem in similar ways. Both are HTTP-based adaptive bitrate protocols. Both split video into segments and use a manifest to describe them. The differences come down to who controls the standard and which devices support it natively.<\/p>\n

The biggest practical gap is Apple. HLS plays natively on iOS, Safari, and Apple TV, while DASH does not \u2014 Apple devices need a JavaScript player or a workaround to handle DASH. That single fact shapes most protocol decisions, since iPhone and iPad traffic is too large to ignore.<\/p>\n

On the other side, DASH is codec-agnostic. You can pair it with VP9<\/a>, AV1<\/a>, H.264, or H.265 without the protocol caring, whereas traditional HLS was tied to H.264 and H.265. DASH also uses an XML manifest, while HLS uses the text-based .m3u8 playlist<\/a>.<\/p>\n

For a full side-by-side breakdown including latency, packaging, and DRM, see our dedicated comparison of HLS vs DASH<\/a>. The short version: most production setups today serve both, packaging once and delivering HLS to Apple devices and DASH everywhere else.<\/p>\n

How Does MPEG-DASH Work?<\/h2>\n

MPEG-DASH works by preparing multiple encoded versions of a video, segmenting each one, describing them all in a manifest, and letting the player request segments adaptively based on real-time network conditions. Here’s the full process step by step.<\/p>\n

Step 1: Encoding into multiple renditions<\/h3>\n

The source video is transcoded into several renditions at different resolutions and bitrates. A typical ladder might include 1080p at 5 Mbps, 720p at 2.5 Mbps, 480p at 1 Mbps, and 360p at 600 kbps. Each rendition targets a different network speed and device class. This transcoding<\/a> step is what makes adaptive switching possible \u2014 without multiple quality levels, there’s nothing to adapt between.<\/p>\n

Step 2: Segmentation into chunks<\/h3>\n

Each rendition is split into short segments, usually 2 to 10 seconds long, with 2 to 4 seconds being common for live streaming. Segments are stored as fragmented MP4<\/a> files or, in older setups, MPEG-TS files. Short segments make the player more responsive to bandwidth changes, while longer segments improve compression efficiency.<\/p>\n

Step 3: Generating the MPD manifest<\/h3>\n

A Media Presentation Description (MPD) file is created. This XML document is the map of the entire stream \u2014 it lists every rendition, the segment URLs, durations, codecs, resolutions, and bitrates. The player downloads the MPD first and uses it to plan every request that follows.<\/p>\n

Step 4: Adaptive playback<\/h3>\n

The DASH player reads the MPD, then begins requesting segments over HTTP. As it downloads, it continuously measures available bandwidth and buffer fullness. If the connection is strong, it requests higher-quality segments; if bandwidth drops, it switches to a lower rendition for the next segment. This decision loop runs for the entire playback session, which is why DASH playback feels continuous even on unstable connections.<\/p>\n

Because every request is a normal HTTP GET, the segments can be cached and served by any CDN built for video<\/a>, bringing content physically closer to viewers and cutting load times.<\/p>\n

Inside the MPD: Periods, Adaptation Sets, and Representations<\/h2>\n

The MPD manifest follows a four-level hierarchy that’s worth understanding if you’ll ever debug a DASH stream. Each level nests inside the one above it.<\/p>\n