MPEG-DASH: Dynamic Adaptive Streaming Over HTTP Explained

Have you ever wondered how a video stream switches to different qualities depending on your network conditions? Answer is Adaptive Bitrate Streaming. But how does this techincally work?

In concise way, Adaptive bitrate streaming technology works through the video player which identifies network/buffer conditions and decides which quality segment to request next. The server/CDN usually does not “push” a quality change. It simply serves whatever segment URL the player asks for.

But who created those different quality video segment URLs and how do the player get to know about those URLs. This is where MPEG-DASH and HLS comes in. As these video streaming protocols or formats are the one that defines how these quality specific URL list which the player refers to in case of switching the playback.

In this blog, we will be talking more about MPEG-DASH or Dynamic Adaptive Streaming over HTTP, and also how it compares to HLS, another streaming protocol.

What is MPEG-DASH?

MPEG-DASH is a streaming protocol. DASH stands for “Dynamic Adaptive Streaming over HTTP.” Because it is based on HTTP, any origin server can be set up to serve MPEG-DASH streams. Both DASH and HLS are streaming specifications/protocols that define how video should be packaged, described, requested, and played. They are not like a software that make something but just definitions on how to create those things.

For example, we earlier discussed how MPEG-DASH and HLS are used to create URL listing file. So, MPEG-DASH tells us how we create Media Presentation Description or an MPD file and HLS tells us how we create m3u8 file.

MPD file is an XML manifest file that contains information about how the media URLs are mapped out. This tells the player where to find the video chunks and what quality levels are available. The MPD describes the full streaming structure: periods, adaptation sets, representations, and segment URLs. AWS’s DASH documentation describes the MPD as the primary DASH manifest containing periods, adaptation sets, representations, and segments.

MPEG-DASH Technical Structure

Think of DASH like the following which has 5 important things, MPD, Period, AdaptationSet, Representation and Segments.

MPD
└── Period
├── AdaptationSet: video
│ ├── Representation: 360p, 800 kbps
│ ├── Representation: 720p, 2500 kbps
│ └── Representation: 1080p, 5000 kbps
│
├── AdaptationSet: audio
│ ├── Representation: English audio, 128 kbps
│ └── Representation: Hindi audio, 128 kbps
│
└── AdaptationSet: subtitles
└── Representation: English subtitles

1. MPD

The MPD, or Media Presentation Description, is the DASH manifest file. Usually it has this extension, .mpd

The player first requests this:

GET /video/manifest.mpd

The MPD tells the player:

Available video qualities:
- 360p at 800 kbps
- 720p at 2500 kbps
- 1080p at 5000 kbps

Available audio tracks:
- English
- Hindi

Segment pattern:
- /video/360/segment-1.m4s
- /video/720/segment-1.m4s
- /video/1080/segment-1.m4s

DASH-IF’s timing model explains that the MPD tells the DASH client when it can download and present media segments, and that it provides the information needed for the client to switch between different bitrate representations as network conditions change.

2. Period

A Period is a time section inside the video.

For a normal movie, there may be only one period:

Period 1 = full movie

But for ad insertion, there may be multiple periods:

Period 1 = main content
Period 2 = ad
Period 3 = main content continues

Example XML:

<Period start="PT0S">
...
</Period>

3. AdaptationSet

An AdaptationSet groups interchangeable tracks of the same media type.

For example:

Video AdaptationSet:
- 360p
- 720p
- 1080p

Audio AdaptationSet:
- English audio
- Hindi audio

Subtitle AdaptationSet:
- English subtitles

For ABR, the most important one is usually the video AdaptationSet, because it contains multiple quality levels.

Example:

<AdaptationSet mimeType="video/mp4" codecs="avc1.640028">
...
</AdaptationSet>

4. Representation

A Representation is one actual version of the video.

Example:

Representation 1 = 360p, 800 kbps
Representation 2 = 720p, 2500 kbps
Representation 3 = 1080p, 5000 kbps

In HLS, you may casually call these “variants.” In DASH, the usual term is Representation.

Example:

<Representation id="360p" bandwidth="800000" width="640" height="360" />
<Representation id="720p" bandwidth="2500000" width="1280" height="720" />
<Representation id="1080p" bandwidth="5000000" width="1920" height="1080" />

5. Segments

Each Representation is split into small segment files.

Example:

360p:
segment-1.m4s
segment-2.m4s
segment-3.m4s

720p:
segment-1.m4s
segment-2.m4s
segment-3.m4s

1080p:
segment-1.m4s
segment-2.m4s
segment-3.m4s

The important point is that these segments are time-aligned.

So:

360p/segment-10.m4s = 00:36 to 00:40
720p/segment-10.m4s = 00:36 to 00:40
1080p/segment-10.m4s = 00:36 to 00:40

That is how the player can switch from 720p segment 10 to 1080p segment 11 without breaking playback.

What is DASH Streaming?

DASH stand for Dynamic Adaptive Streaming over HTTP, as the name suggests it’s it has the “Dynamic” bit rate and is “adaptive” to Network performance, that is it changes the bit rate according to network to keep the video playing. Higher the video bitrate higher the video quality.

It’s a modern way of delivering videos over the internet. Instead of sending one big video file, DASH breaks the video into smaller chunks and sends them piece by piece. This helps the video play smoothly, even if your internet speed goes up and down while watching.

One of the biggest advantages of DASH is adaptive quality. It can automatically switch the video quality based on your current internet speed. If your connection is fast, you get high-definition video. If it slows down, DASH lowers the quality temporarily—so the video keeps playing without buffering. This makes it great for streaming on mobile networks, Wi-Fi, or any setup where internet speed isn’t always stable.

The video is encoded into multiple quality levels—say, 1080p, 720p, 480p, and so on. When a viewer starts watching, DASH begins streaming the version that suits their network speed. As the network conditions change, it switches to a higher or lower quality, all without interrupting the stream. The player keeps checking every few seconds to decide the best version to show.

DASH is used by many big platforms and companies that want reliable and flexible video delivery. It works across web browsers, smart TVs, and mobile apps. However, unlike HLS (Apple’s format), DASH doesn’t work natively on Safari or iOS without additional tweaks.

How DASH Streaming Works Technically?

Step 1: Encoding

The original video is encoded into multiple bitrates:

source.mp4

360p - 800 kbps
720p - 2500 kbps
1080p - 5000 kbps

These become DASH Representations.

Step 2: Packager creates segments and MPD

The DASH packager creates:

manifest.mpd
init-stream0.m4s
chunk-stream0-00001.m4s
chunk-stream0-00002.m4s
chunk-stream0-00003.m4s

In many modern DASH workflows, the segments are fragmented MP4 files:

init.mp4 / init.m4s
segment-1.m4s
segment-2.m4s
segment-3.m4s

The initialization segment contains metadata needed to initialize the decoder. The media segments contain the actual audio/video samples.

Step 3: Player downloads the MPD

The playback starts like this:

GET /video/manifest.mpd

The DASH player parses the XML and learns:

Video AdaptationSet:
- 360p, bandwidth 800000
- 720p, bandwidth 2500000
- 1080p, bandwidth 5000000

Audio AdaptationSet:
- audio, bandwidth 128000

Segment template:
media="video/$RepresentationID$/segment-$Number$.m4s"

Step 4: Player selects initial Representation

The player chooses a safe starting quality.

For example, Chosen video Representation: 1080p and audio Representation: English audio

It may choose this based on startup strategy, previous bandwidth estimate, device type, player settings, or screen size.

Step 5: Player requests init segment

Before media segments, DASH often needs an init segment:

GET /video/1080p/init.mp4

This tells the browser/player how to decode the upcoming media segments.

Step 6: Player requests first media segment

Then the player requests the first segment:

GET /video/1080p/segment-1.m4s

The CDN simply returns that file. The CDN is not usually deciding that the network is fast and send 1080p.

Instead, the player decides: I want 1080p segment 1. Then the CDN serves it.

Step 7: Player measures download speed and buffer

After downloading a segment, the player checks:

Segment duration: 4 seconds
Segment size: 1 MB
Download time: 1 second
Estimated throughput: around 8 Mbps
Current buffer: 12 seconds

Now the ABR algorithm decides whether to stay, go up, or go down.

Step 8: Player switches Representation for the next segment

Suppose the stream starts at 1080p. Network don’t look good and the stream starts buffering.

The player switches:

GET /video/720p/segment-3.m4s
GET /video/720p/segment-4.m4s

Network again start looking good.

The player switches up again:

GET /video/1080p/segment-5.m4s

Then network drops.

The player switches down:

GET /video/480p/segment-6.m4s
GET /video/360p/segment-7.m4s

That is MPEG-DASH ABR in action. The switch happens because the player changes which Representation’s segment URL it requests next.

MPEG-DASH VOD vs Live

DASH VOD

For video-on-demand, the MPD is usually:

<MPD type="static">

Meaning the full video is already available.

The player can seek anywhere because the full segment timeline is known.

Example:

User jumps to 08:00
Player calculates segment number
Requests that segment

DASH Live

For live streaming, the MPD is usually:

<MPD type="dynamic">

In live DASH, new segments keep becoming available as the event continues. DASH-IF explains that in a dynamic presentation, the MPD timeline maps to wall-clock time, media segments become available and expire over time, and the MPD may change during playback.

For live, the flow is:

• Player downloads MPD
• Finds live edge
• Requests latest available segment
• Downloads next segments as they appear
• Refreshes MPD if needed

Example:

At 10:00:00 → segment 100 available
At 10:00:04 → segment 101 available
At 10:00:08 → segment 102 available

The player stays a little behind the live edge to avoid buffering.

MPEG-DASH and DRM

DASH is also strong in DRM workflows because the MPD can include ContentProtection elements.

Example:

<ContentProtection
schemeIdUri="urn:mpeg:dash:mp4protection:2011"
value="cenc" />

The MPD can signal DRM/encryption information so the client can determine whether it can play protected content. DASH-IF says the ContentProtection element’s schemeIdUri identifies the protection scheme and can include DRM system, encryption algorithm, or key-distribution information.

This is one reason DASH is commonly used with:

• Widevine
• PlayReady
• Common Encryption
• Encrypted Media Extensions

MPEG-DASH vs HLS: Pros and Cons

Pros of MPEG-DASH

• Flexible manifest format: DASH uses an MPD manifest, which gives detailed information about video representations, bitrates, audio tracks, subtitles, segments, and DRM signaling.
• Strong multi-DRM support: DASH is commonly used with Widevine, PlayReady, and Common Encryption, making it suitable for premium protected video across browsers, Android, smart TVs, and OTT platforms.
• Broad codec flexibility: DASH is codec-agnostic, so it can work with codecs such as H.264, H.265/HEVC, VP9, and AV1, depending on device and browser support.
• Good for advanced workflows: DASH is useful for complex streaming setups involving multi-audio, subtitles, ad insertion, live streaming, and DRM.

Cons of MPEG-DASH

• Limited native Apple support: Apple platforms are built primarily around HLS. DASH-only delivery can create playback issues on Safari, iOS, iPadOS, and tvOS unless additional libraries or separate HLS outputs are used.
• More complex implementation: DASH gives more control, but that also means more packaging, player, DRM, and compatibility decisions.
• Requires JavaScript players in browsers: DASH usually needs players like dash.js or Shaka Player for browser playback.

Pros of HLS

• Wide device support: HLS is natively supported on Apple devices, including Safari, iOS, iPadOS, tvOS, and AVPlayer-based apps. It is also supported on Android through ExoPlayer/Media3 and can be played in other browsers using libraries like hls.js.
• Easy to scale: HLS works over standard HTTP, so it can be delivered through regular web servers and CDNs without specialized streaming servers.
• Mature ecosystem: Most encoders, CDNs, video players, analytics tools, and DRM vendors support HLS, making it easier to implement and troubleshoot.

Cons of HLS

• Historically higher latency: Traditional HLS had higher latency, although Low-Latency HLS has reduced this gap.
• Apple-focused DRM workflow: HLS is commonly used with FairPlay DRM on Apple devices. For broader multi-DRM workflows involving Widevine and PlayReady, DASH or CMAF-based workflows are often preferred.
• Codec flexibility depends on device support: HLS can support modern codecs, but practical playback depends heavily on Apple, browser, and hardware support.

How Streaming over HTTP came into Existence?

Did you know streaming over HTTP wasn’t even a thing until iPhone 3GS came into existence? Up until then, video streaming happened over RTMP and required the Adobe Flash plugin for playback. Steve Jobs was determined to kill Adobe Flash. He vouched for open web standards to take charge of video streaming on web browsers and mobile devices. The industry-backed him and hailed him a savior. Nobody wanted to rest the faith of the entire video streaming industry on the shoulders of one corporate.

The death of Adobe Flash

To begin with, there were too many problems with Flash. It was proprietary. While the Adobe Flash plugin was compatible with most web browsers of that time, creating Flash content required web developers to buy costly software licenses from Adobe. Flash plugin was a security nightmare even when it was updated fifteen times a month. Setting up a dedicated server for RTMP streaming was another hassle and wasn’t exactly cheap.

Firewalls would disallow traffic over port essential to receive content from RTMP servers. Firewalls weren’t the problem for content over HTTP since port 80 is always set to allow.

Further, Adobe Flash was too resource-heavy for battery-operated devices. It was simply impractical to bring Flash to mobile devices when web standards were constantly evolving. There is a reason death of flash is often regarded as the rebirth of the web we know today.

The need for an open streaming standard

Adobe killed Flash a few years later, leaving a huge vacuum in the industry. Apple was quick to tap on the opportunity with its proprietary HTTP-based adaptive bitrate streaming protocol, HLS streaming(or HTTP Live Streaming).

While HLS addressed every problem associated with Adobe RTMP, it didn’t one. HLS was proprietary just like Adobe’s offering. This initialized the development of MPEG.

DASH was the perfect candidate in the post-Flash world. It was an open streaming method not controlled by a corporation. It allowed video playback on browsers supported by open web standards powered by HTML5. MPEG-DASH did not require users to install any plugin and streaming provider deploys a dedicated RSTM server and would run on existing protocols: HTTP and TCP. The firewall wasn’t a problem either for HTTP servers.

The birth of the first open streaming method: MPEG DASH

Apparently, some competitors weren’t fine with the situation Apple was putting them into. One of them was Google. Together, they laid the plan for an alternative to HLS, an industry standard that is not controlled in any way by a single corporate but a consortium of independent stakeholders.More than 50 companies became involved — Microsoft, Netflix, Google, Ericsson, Samsung, and Adobe included — and the effort was coordinated by MPEG with other industry organizations such as 3GPP, DECE, OIPF, and W3C. MPEG published the Dynamic Adaptive Streaming over HTTP (DASH) standardin April 2012as MPEG-DASHandreviseditin 2019 as MPEG-DASH ISO/IEC 23009-1:2019.

List of Other MPEG DASH Player without secure video playback?

Dash.js

Dash.js is an open-source HTML5 Video player based on MPEG_DASH and built by the own dash industry forum to demonstrate a production-ready framework for Dash Playback.

It is based on the Media Source Extension API by w3c and provides a simple user interface with tons of information to debug the video stream for error.

Sample code for using Dash.js :

<!doctype html>
<html>
  <head>
    <title>Dash.js Rocks</title>
    <style>
      video {
        width: 640px;
        height: 360px;
      }
    </style>
  </head>
  <body>
    <div>
      <video data-dashjs-player autoplay src="https://dash.akamaized.net/envivio/EnvivioDash3/manifest.mpd" controls>
      </video>
    </div>
    <script src="yourPathToDash/dash.all.min.js"></script>
  </body>
</html>

Exoplayer:

Exoplayer video player on application level for android, it is alternative to Android’s MediaPlayer API for providing better features and customization, it has feature like persistent caching and custom rendered.

Android’s MediaPlayer API is fixed to the android version of the device, whereas Exoplayer can be updated via playstore application update

We’ve also written a blog on how to stream videos on iOS using AVPlayer, do check it out to know more about video streaming in iOS.

How to build the MPEG DASH player?

Dash player functionality is to fetch the manifest file, parse it and play all segments one by one.

MPEG Dash player can be processed in 7 steps:

1. Get the video element reference
2. Create media source
3. Create ObjectURL from the media source and add to source of video
4. Set the mime type for media source via addSourceBuffer
5. Fetch the manifest file and parse and store all required data in variable
6. Initialize the video with first segment
7. Use event `timeupdate` to continuously update the source with all other segments

// Create media source
const videoEl = document.getElementById("my-video");
const mediaSource = new MediaSource();
const sourceUrl = URL.createObjectURL(mediaSource);
videoEl.src = sourceUrl;
let videoSource;
let segCheck;
let currentSegmentIndex = 0;
let lastTime;

// get mainfest file
const xmlData = await fetch("MANIFEST_URL_FROM_SERVER")
 .then((r) => r.text())
 .then((xml) => parser.parseFromString(xml, "text/xml", 0));

// extract data from manifest file
const file = xmlData.querySelectorAll("BaseURL")[0].textContent.toString();
const rep = xmlData.querySelectorAll("Representation");
const type = rep[0].getAttribute("mimeType");
const codecs = rep[0].getAttribute("codecs");
const width = rep[0].getAttribute("width");
const height = rep[0].getAttribute("height");
const bandwidth = rep[0].getAttribute("bandwidth");
const ini = xmlData.querySelectorAll("Initialization");
const initialization = ini[0].getAttribute("range");
const segments = xmlData.querySelectorAll("SegmentURL");
const segList = xmlData.querySelectorAll("SegmentList");
let segDuration = segList[0].getAttribute("duration");

// wait for media source to ready
mediaSource.addEventListener(
 "sourceopen",
 function (e) {
  try {
   videoSource = mediaSource.addSourceBuffer("video/mp4");
   initVideo(initialization, file);
  } catch (e) {
   log("Exception calling addSourceBuffer for video", e);
   return;
  }
 },
 false
);

// init the video with first segment
async function initVideo(range, url) {
 const segmentVideoBuffer = await fetch(url, {
  header: `Range: "bytes=${range}"`,
 });
 B.appendBuffer(new Uint8Array(segmentVideoBuffer));
 videoEl.addEventListener("timeupdate", playSegment);
}

// play all segment one by one if necessary
function playSegment() {
 if (index < segments.length && videoEl.currentTime - lastTime >= segCheck) {
  const range = segments[index].getAttribute("mediaRange").toString();
  segCheck = (timeToDownload(range) * 0.8).toFixed(3);
  const segmentVideoBuffer = await fetch(url, {
   header: `Range: "bytes=${range}"`,
  });
  videoSource.appendBuffer(new Uint8Array(segmentVideoBuffer));
  segCheck = (timeToDownload(range) * 0.8).toFixed(3);
  lastTime = videoElement.currentTime;
 }
}

// Helper
function timeToDownload(range) {
 const [start, end] = range.split("-");
 return ((end - start) * 8) / bandwidth;
}

FAQs

How Streaming Platforms Utilise HLS & DASH?

In our research, we found sufficient evidence to claim that every major streaming platform support DASH in addition to HLS, including Amazon Prime Video, Netflix, Disney Plus and Hulu. Game streaming service Amazon Twitch is an exception as it relies majorly on HLS for live game streaming. Netflix CEO even claimed that MPEG-DASH loweredtheirnetwork costs.

Is MPEG Dash playback secure for Videos?

Dash playback is not secure by default, it’s just a technology for adaptive media playback, it does not contain any encryption standards to secure your video, what secure the video is the DRM services.

Does Netflix use MPEG-DASH?

Yes. Netflix has used MPEG-DASH as part of its HTML5 streaming workflow, especially with fragmented MP4 and Common Encryption for adaptive, DRM-protected playback.

Is MPEG still used today?

Yes. MPEG standards are still widely used today in video compression, MP4 packaging, streaming, audio, DRM workflows, and adaptive bitrate delivery.

Is MPEG-DASH open source?

MPEG-DASH is an open streaming standard, not open-source software. But open-source MPEG-DASH players and tools, such as dash.js and Shaka Player, are available.

What browser supports MPEG-DASH?

MPEG-DASH can play in modern browsers such as Chrome, Edge, Firefox, and Safari when used with a JavaScript player like dash.js or Shaka Player, provided the browser supports Media Source Extensions and the required codec/DRM combination.