Understanding and configuring a Dynamic MPD
This page explains the most relevant attributes in dynamic MPD (MPEG_DASH). 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 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: Must Fix: use of UTC timestamps.
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
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 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 maximum segment duration within MPD.
MPD@minimumBufferTime prescribes how many seconds of buffer a client should keep to avoid
stalling when streaming under ideal network conditions with bandwidth matching the @bandwidth
attribute. 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
@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. The @presentationTimeOffset is the media sample time corresponding to the Period@start. 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