Glossary entry · Manifest format

DASH MPD (MPEG-DASH Manifest)

The XML manifest behind MPEG-DASH adaptive streaming. An MPD file describes everything a player needs to know about a presentation: timeline, qualities, audio tracks, subtitles, and DRM.

Definition

An MPD file is an XML document defined by the ISO/IEC 23009-1 standard, also known as MPEG-DASH (Dynamic Adaptive Streaming over HTTP). The file is typically served with the .mpd extension and the application/dash+xml MIME type. The MPD does not contain media bytes. It describes how a player should request media segments from a regular HTTP server.

MPEG-DASH was developed as an open standard alternative to HLS. The protocol was published in 2012 and has since become the dominant streaming protocol on non-Apple platforms. YouTube, Netflix, Amazon Prime Video, and most premium streaming services serve DASH content to web and Android clients while serving HLS to iOS clients.

Structure: Period, AdaptationSet, Representation, Segment

An MPD uses a strict four-level hierarchy. Each level expresses a specific concern.

Period: a contiguous segment of the presentation's timeline. Most VOD content has a single Period; ad-stitched and live content can have many.
AdaptationSet: a group of media that are functionally interchangeable. One AdaptationSet per video, one per audio language, one per subtitle track.
Representation: an encoded version of the content with specific bandwidth, resolution, and codec parameters. The player switches between Representations inside an AdaptationSet for adaptive bitrate.
Segment: the actual media chunk. Defined either through a SegmentTemplate (URLs follow a pattern) or a SegmentList (URLs are enumerated). Segments are usually fragmented MP4 (.m4s) files.

A skeletal MPD looks like this:

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" type="static"
     mediaPresentationDuration="PT10M">
  <Period>
    <AdaptationSet mimeType="video/mp4" codecs="avc1.640028">
      <Representation id="1080p" bandwidth="4500000"
                      width="1920" height="1080">
        <SegmentTemplate media="1080p/seg-$Number$.m4s"
                         initialization="1080p/init.mp4"
                         startNumber="1" duration="6" timescale="1"/>
      </Representation>
    </AdaptationSet>
    <AdaptationSet mimeType="audio/mp4" codecs="mp4a.40.2" lang="en">
      <Representation id="audio-en" bandwidth="128000">
        <SegmentTemplate media="audio-en/seg-$Number$.m4s"
                         initialization="audio-en/init.mp4"
                         startNumber="1" duration="6" timescale="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

The video and audio AdaptationSets are independent. The player picks one Representation in each and downloads them in parallel, which is why DASH content has separate video and audio segment files. HLS historically muxed audio into the same TS segment but moves toward separate streams in modern fMP4 deployments.

DASH vs HLS

The two protocols solve the same problem. The differences are mostly historical and tactical.

Manifest format: DASH uses XML (.mpd). HLS uses plain text (.m3u8). XML is more expressive; plain text is easier to debug by eye.
Segment container: DASH essentially always uses fragmented MP4 (.m4s). HLS used MPEG-TS (.ts) historically and now supports fMP4 too.
Native browser support: HLS plays natively in Safari. DASH does not play natively anywhere; it requires a JavaScript player.
DRM ecosystem: DASH uses Common Encryption (CENC) with Widevine and PlayReady. HLS uses FairPlay on Apple platforms.
Live latency: both protocols support low-latency variants (LL-DASH and LL-HLS), with sub-second latency possible.

If you maintain a streaming service today, the realistic answer is to publish both formats from a shared set of fMP4 segments using CMAF. Apple platforms get HLS playlists; everyone else gets a DASH MPD. The same encoded segments are reused.

DRM and DASH (Widevine, PlayReady)

DASH is the de facto streaming format for DRM-protected content on the open web because the major web browsers ship Widevine. The MPD references DRM through one or more ContentProtection elements inside each AdaptationSet:

<ContentProtection
  schemeIdUri="urn:mpeg:dash:mp4protection:2011"
  value="cenc"
  cenc:default_KID="abcdef01-2345-6789-abcd-ef0123456789"/>
<ContentProtection
  schemeIdUri="urn:uuid:edef8ba9-79d6-4ace-a3c8-27dcd51d21ed">
  <cenc:pssh>...base64 PSSH box...</cenc:pssh>
</ContentProtection>

The schemeIdUri identifies the DRM system. Widevine, PlayReady, and FairPlay each have their own UUID. The actual encryption is Common Encryption (CENC), which means the segments themselves are encrypted bytes regardless of which DRM ecosystem will deliver the key. Consumer tools cannot bypass Widevine or PlayReady. The key exchange happens in a hardware-backed secure environment on the device.

If a DASH stream is not protected by a recognized DRM, the segments are usually plain fMP4 and a tool that can speak DASH (like yt-dlp, N_m3u8DL-RE, or Vidora) can download and remux them into a single MP4. Our deep-dive DASH MPD downloader guide covers the exact workflows for both video and audio.

Common manifest patterns

You will run into three families of DASH manifests in the wild.

Static VOD with SegmentTemplate: the manifest defines a pattern like seg-$Number$.m4s, the player iterates from 1 to N. This is the most common case for short videos.
Static VOD with SegmentTimeline: the manifest lists exact durations of every segment. Used when segments are not perfectly uniform.
Dynamic live: the manifest has type="dynamic" and refreshes every few seconds. The player must reload the MPD periodically to discover new segments.

Knowing which pattern you face matters when scripting a downloader: a static MPD can be fully resolved in one pass, while a dynamic MPD needs a polling loop until the live event ends. Our DASH MPD analyzer shows you which pattern a given manifest uses without leaving the browser.