media presentation description

Structure of a MPEG-DASH MPD

In this article, we look at the structure of an MPEG-DASH MPD (Media Presentation Description) file that is required for ABR streaming using MPEG-DASH. Learn about the XML file structure, MIME-Type, Presentations, Period, Adaptation Sets, Representations, Segments, and more.

MPEG-DASH is one of the most popular video-streaming protocols and is widely used to deliver media either via Video on Demand (VOD) or Live Streaming and to various end-user devices, including smartphones, tablets, SmartTVs, gaming consoles, and more.

Fundamental to the MPEG-DASH protocol is the manifest or MPD (Media Presentation Description) that is created when the media is packaged and prepared for transmission via DASH.

In this edition of the guide to MPEG-DASH, we dig into the DASH Media Presentation Description (MPD), as defined in ISO/IEC 23009-1. The goal is to give you a better understanding of the different parts of a DASH MPD, what they’re used for, and how they work.

Interested in MPEG-DASH and video streaming? You’ll be interested in these articles for sure!

What is MPEG-DASH – a deep dive into the basics.
Structure of a MPEG-DASH MPD file – a deep dive
How to package using Bento4 mp4dash
How to package using GPAC mp4box
How to package using Shaka packager
List of free MPEG-DASH MPDs for testing
List of MPEG-DASH MPD players available online

So, let’s get started!

Table of Contents

What is the advantage of DASH in video streaming?

MPEG DASH is a platform and browser-agnostic video streaming protocol. There are plenty of freely-available online players , and more and more browsers include native DASH support, eliminating the need for external players or plugins. So long as the webserver reports the DASH manifest MIME type correctly, the user doesn’t need to ask how to play the MPD or find a player; When the browser downloads the MPD, the video loads and plays automatically.

What is a DASH Manifest?

You will recall that a browser or DASH player uses the MPD file, commonly known as a DASH Manifest, to determine which resources to request from an HTTP server and when to request them. To quote the specification:

The Media Presentation Description (MPD) is a document that contains metadata required by a DASH Client to construct appropriate HTTP-URLs to access Segments and to provide the streaming service to the user.

DASH MPD Format

DASH MPD files are XML documents. XML schemas like MPD can be quite complex, and it is the packager’s responsibility to create a valid MPD. The ISO specification is a technical document written by and for developers. This article aims to give an overview of the MPD structure so you can have a better understanding of the packager input parameters.

DASH MPD Encoding

DASH MPD files use UTF-8 encoding. Remember that the first 128 UTF-8 symbols are identical to traditional 7-bit ASCII, so an ASCII document is automatically a UTF-8 document. For characters 129 and above, it is the packager’s responsibility to do the encoding correctly.

DASH MPD MIME Type

Browsers use the MIME type/subtype reported in the HTTP content-type header to figure out how to process a file, similar to how a computer uses the file extension to select a suitable application. You must configure your webserver to deliver DASH MPD files with the IANA-registered content-type application/dash+xml. There are no required parameters.

What are the parts of an MPD?

As the name says, an MPD contains a Media Presentation with a clear, consistent hierarchical organization. From top to bottom, the individual elements of the MPD hierarchy are:

The Media Presentation contains a sequence of one or more Periods.
A Period contains one or more Adaptation Sets.
An Adaptation Set contains one or more Representations.
A Representation contains one or more Segments.
Segments carry the actual media data and associated metadata.

Each element consists of a set of attributes. Individual attributes are either Mandatory, Conditionally Mandatory, Optional, or Optional with Default Values.

An excellent description of an MPD’s structure can be found in the popular and definitive guide published by Iraj Sodogar in IEEE Multimedia titled The MPEG-DASH Standard for Multimedia Streaming Over the Internet “. It clearly depicts the hierarchical structure used in a DASH MPD.

In the next few sections, we’ll tackle each of these parts of an MPD separately and understand how they are used and how they work with each other.

Media Presentation

The Media Presentation contains information about all of the different media types in the content. The most common media types are video, audio, and closed captioning data. At the top level, the MPD contains information including the MPD Profile, minimum buffer time, presentation duration, and maximum segment duration, and title.

Example of the top level of an MPD

DASH lets you divide a video into multiple Periods. By default, playback continues seamlessly from one Period to the next, providing an easy way to add seek points for individual chapters. SCTE35 tags between Periods can trigger the player to perform dynamic ad insertion.

Example of MPD with 3 Periods

Adaptation sets.

An Adaptation Set catalogs the different representations of the media. Within each Adaptation Set, the player will only select one Representation for a particular Segment, but the Representation can change from one Segment to the next.

Video Adaptation Sets typically contain multiple Representations, one for each resolution/bitrate, allowing the media player to select the best available quality without buffering. If the video is available in more than one codec, each codec will be in a different AdaptationSet.

If the audio is available in both stereo and multi-channel surround, these will be in separate adaptation sets to prevent the player from switching back and forth during playback. Each language will have its own Adaptation Set.

For each Adaptation Set, the player will select one of the available Representations at a time, but the selection can change from one segment to the next.

After downloading the MPD, the player selects the Adaptation Sets to play based on a combination of device capabilities and user preferences. Consider an MPD that contains video, audio, and closed captioning. Video is available in AVC and HEVC (two Adaptation Sets). Audio is available in either stereo or 6-channel audio in English, French, and Spanish (six Adaptation Sets). Closed captioning is available in English, French, Portuguese, and Spanish (four Adaptation Sets). The player might select:

HEVC video (because the player supports it).
English language stereo audio (because the player only has two audio channels and the user has selected English as their default language).
No closed captioning (because the user has turned off captioning).

Example of two video adaptation sets and one audio adaptation set

Representations.

Within an Adaptation Set, a Representation describes one of the versions of the content. The most common use of multiple Representations is to describe the various video bitrates available for Adaptive Bitrate (ABR) streaming. Each Representation always includes the average bandwidth of the Representation.

Example of four video Representations

Segments contain the information required to construct the actual URLs used to download the content. The MPD can either provide a list of the segment URLs or a template that the player uses to build the URLs dynamically.

Example of a Segment list

Example of a segment template, how are urls described in an mpd.

Given the vast amount of content available from streaming providers, the URLs can get rather long, sometimes more than 100 characters. Video is often available in 6-10 bitrates to support good quality over a range of network conditions. Individual segments are usually 2-10 seconds long, allowing the player to respond rapidly to changing network conditions.

For our hypothetical video with 12 adaptation sets, a 2-hour movie could require 40,000 segments. A list of those URLs would be over 4MB, and the player needs to download the complete MPD before it can start playing the video. Our hypothetical user would use less than 9% of those URLs. There has to be a better way, and sure enough, there is.

The Base URL

While the actual URLs might be over 100 characters each, most of those characters will be the same for all URLs. This is where the Base URL comes in. Each MPD has an optional @BaseURL attribute. The Base URL is used as the prefix for all of the Segment URLs and contains the protocol, domain name, and most of the server’s directory structure for the video. It is stored at the MPD level and shared by all Representations, Adaptation Sets, and Periods. Additional Base URLs can be added at the Period, Adaptation Set, and Representation levels, further increasing the storage efficiency.

If the content is available from multiple sources, a separate BaseURL can be included for each source.

Example of nested Base URLs

In this example, the video segment files would be available at both http://cdn1.example.com/video/<segmentfilename> and http://cdn2.example.com/video/<segmentfilename> .

Segment Lists

The simplest way to store the URLs, at least from a human readability perspective, is to list them all in each Representation. If each Representation has its own directory on the server and you use Base URLs, this is nothing more than the Segment file names. For shorter content with a small number of Adaptation Sets, this is a common practice.

Segment Templates

For longer content, with hundreds or thousands of segments per Representation, listing all of the file names still takes a lot of space. To further reduce the MPD size, DASH allows Segments to be stored using a SegmentTemplate. URL templates consist of ordinary characters combined with one or more Identifiers. Identifiers are marked (‘escaped’ in programmer-speak) with a “$” character at the beginning and end. The player uses the template to construct the URL when it is ready to request the Segment.

The packager can insert Segment Templates at the Period level or lower, using the defined Identifiers shown in the table below.

	Substitution parameter
	An escape sequence, i.e., “$$” is replaced with a single “$”.
	The player substitutes this identifier with the value of the attribute Representation@id of the containing Representation.
	The player substitutes this identifier with the number of the corresponding Segment.
	The player substitutes this identifier with the value of Representation@bandwidth attribute value.
	The player substitutes this identifier with the value of the SegmentTimeline@t attribute for the Segment. You can use either or , but not both at the same time.

You can suffix any identifier, within the enclosing ‘$’ characters, with an additional format tag following this prototype:

The width parameter is an unsigned integer that provides the minimum number of characters to print. If the value to print is shorter than this, it will pad the result with zeros. The value isn’t truncated if the number is larger than the tag format.

Segment Templates let you stream live content without the need to periodically update the MPD with new Segments as they become available.
Segment Templates require careful, consistent construction of the individual file names, but your packager takes care of this for you.

How can MPDs be updated dynamically?

DASH supports both static and dynamic MPDs. Dynamic MPDs are typically used for live streaming, adding new segments or periods as content becomes available, and dropping older segments and periods when the content is no longer available.

What are MPD Profiles?

DASH Profiles tell the player which of the many DASH features the MPD contains, mainly for compatibility reasons. Your packager will take care of this for you, so you don’t need to worry about it. The most commonly used profiles are:

urn:mpeg:dash:profile:full:2011
urn:mpeg:dash:profile:isoff-on-demand:2011
urn:mpeg:dash:profile:isoff-live:2011

How does DASH support DRM?

DASH uses the ContentProtection element to identify the content protection used. The contents of this element are unique to each DRM provider. If you are using DRM, you will need to work with your DRM provider to make sure that your packager is properly integrated with their system.

Example of Content Protection in an MPD

That’s it folks for this introduction to MPEG-DASH MPDs. I hope you understood the different components that make up an MPD and its structure. In future articles of this series, we’ll learn about packaging videos into MPEG-DASH format using popular packagers such as Bento4, Shaka, mp4box, etc.

Do check out this article on OTTVerse.com for a list of freely available DASH MPDs covering a variety of streaming use cases.

Until next time, happy streaming!

Ron Garrison

Ron has lead streaming optimization Product Management teams at companies including Ortiva Wireless, Allot Communications, and MediaMelon.

3 thoughts on “Structure of a MPEG-DASH MPD”

Thanks a lot for the information. This article gives an idea how MPD works on streaming. While you have given almost all details, few missed points are segment-timeline, time scale, min buffer time. I think these are also fit into this article. Hope this helps to anyone who vistis the page in future. Thank you

Thanks for the suggestions, Mahesh. We’ll consider that as an addition or in another post of this series. Thank you 🙂

Thanks a lot for the information. This article gives a lot of information. I have a qestion, I have DASH streaming in 4 .ts profile, each of them hes own ENG lang audio How meny audio will streaming? Is each video profile will play it’s own ENG lang audio? Or only one ENG lang audio will streaming? Thank you Regards Rony vana