Understanding and configuring a Dynamic MPD (MPEG-DASH)

This page explains the most relevant attributes in dynamic MPD. Quite some of these attributes are unique to Live streaming scenarios and won't be present in a static MPD. None of them have to be configured (Origin will take care of this automatically), but some can be.


In general, we recommend against manually configuring any of the below options, and to rely on the default logic of Origin instead.


MPD@type is set to 'dynamic', meaning that this is an MPD for a Live stream and that new segments will become available over time.


By default the DASH 'ISO Media Live profile' is used (so the @profile is urn:mpeg:dash:profile:isoff-live:2011). For certain devices that require the DVB-DASH MPD profile, you may want to use --mpd.profile to specify this profile.


MPD@availabilityStartTime indicates the zero point on the MPD timeline of a dynamic MPD. It defaults to Unix epoch. The benefit of this becomes evident when Rec.: Add Origin and encoder redundancy is required: when both encoders are setup to use UTC timing they can start independent of each other, as the Unix epoch is always the same. Please see: Req.: Use of UTC timestamps.

Offsetting availabilityStartTime

Adding for instance 10 seconds will offset the player's Live edge with that amount. An example:



MPD@publishTime specifies the wall-clock time when the MPD was generated and served by Origin.


MPD@minimumUpdatePeriod defaults to two seconds (aligned with the recommended GOP/segment size sent by the encoder). This specifies the smallest period between potential changes to the MPD, so matching the segment length is the correct default. However, if needed it can be changed with --mpd.minimum_update_period.


Once an MPD changes from dynamic to static MPD@minimumUpdatePeriod is removed. Absence of the MPD@minimumUpdatePeriod attribute indicates an infinite validity period (the MPD will not be updated anymore). A value of '0' indicates that the MPD has no validity after the moment it was retrieved. In such a situation, the client will have to acquire a new MPD whenever it wants to retrieve new media segments.


MPD@timeShiftBufferDepth is signals the length of the DVR window (i.e., how much a client can scrub back, to start playback at an earlier point in the stream). This length is specified with the --dvr_window_length.


MPD@maxSegmentDuration is set to twice the segment length, so four seconds in default scenarios.


MPD@minimumBufferTime prescribes how much buffer a client should keep under ideal network conditions. This value can be changed with --mpd.min_buffer_time. It is set to 10 seconds by default.


MPD@suggestedPresentationDelay by default is not present in the MPD (except when you use --mpd.profile to specify the DVB-DASH MPD profile). It is a suggested delay of the presentation compared to the Live edge. This option may be used to mitigate problems caused by a player that requests segments that do not exist yet (getting 404 errors in return). A reasonable value may be 2 to 4 times the segment duration, but not smaller than 4 seconds in order for the client to maintain some buffering. The delay can be defined with --mpd.suggested_presentation_delay.


@presentationTimeOffset is a key component in establishing the relationship between the MPD timeline and the actual media timeline, also referred to as the sample timeline. Origin uses it in scenarios when a virtual subclip is requested from a Live archive, if that subclip has an end time in the past.

As the all of the content for the subclip will be available in the Live archive in such a case (assuming the start time is not to far in the past and still part of the archive), this will result in a VOD clip being served, of which the media timeline starts at zero.

In such scenarios the presentation time offset is calculated automatically to represent the time between the start of Unix epoch and the start of the media, so that the media can be addressed using the original timestamps used for the livestream.

Configuring presentation time offset

Under certain circumstances, it may be useful to set this value manually. For example, an encoder may use a different clock than the DASH specified UTC clock, causing time shifts in the player. This can be mitigated with a @presentationTimeOffset in all SegmentTemplates for the livestream, which can be specified with --mpd.presentation_time_offset.