Based on an MPD including information as documented in Table 11-1 and available at time NOW on the server, a synchronized DASH client derives the information of the list of Segments for each Representation in each Period. This clause only describes the information that is expressed by the values in the MPD. The generation of the information on the server and the usage of the information in the client is provided in clause 11.2.3 and 11.2.4 respectively.

The following definitions are relevant and aligned with ISO/IEC 23009-1 [43]:

• available Segment is a Segment that is accessible at its assigned HTTP-URL. This means that a request with an HTTP GET to the URL of the Segment results in a reply of the Segment and 2xx status code.
• valid Segment URL is an HTTP-URL that is promised to reference a Segment during its Segment availability period.
• NOW is a time that is expressing the time on the content server as wallclock time. All information in the MPD related to wallclock is expressed as a reference to the time NOW.

For a dynamic service without MPD updates, the following information shall be present and not present in the MPD (also please refer to Table 11-1):

• The MPD@type shall be set to "dynamic".
• The MPD@mediaPresentationDuration shall be present, or the Period@duration of the last Period shall be present.
• The MPD@minimumUpdatePeriod shall not be present.

Each Period is documented by a Period element in the MPD. An MPD may contain one or more Periods. In order to document the use of multiple Periods, the sequence of Period elements is expressed by an index i with i increasing by 1 for each new Period element.

• Each regular Period i in the MPD is assigned a
  • Period start time PSwc[i] in wall-clock time,
  • Period end time PEwc[i], in wall-clock time.

The Period start time PSwc[i] for a regular Period i is determined according to clause 5.3.2.1 of ISO/IEC 23009-1 [43]:

• If the attribute @start is present in the Period, then PSwc[i] is the sum of AST and the value of this attribute.
• If the @start attribute is absent, but the previous Period element contains a @duration attribute then the start time of the Period is the sum of the start time of the previous Period PSwc[i] and the value of the attribute @duration of the previous Period. Note that if both are present, then the @start of the new Period takes precedence over the information derived from the @duration attribute.

The Period end time PEwc[i] for a regular Period i is determined as follows:

• If the Period is the last one in the MPD, the time PEwc[i] is obtained as
  • the sum of AST and Media Presentation Duration MPDur, with MPDur the value of MPD@mediaPresentationDuration if present, or the sum of PSwc[i] of the last Period and the value of Period@duration of the last Period.
• Else
  • the time PEwc[i] is obtained as the Period start time of the next Period, i.e. PEwc[i] = PSwc[i+1].

Based on such an MPD at a specific time NOW, a list of Segments contained in a Representation in a Period i with Period start time PSwc[i] and Period end time PEwc[i] can be computed. Let:

• NS=1,
• ato is the value of the @availabilityTimeOffset attribute, if present. Otherwise, it is zero.
• ts the value of the @timescale attribute
• t[s] is 0,
• the d[s] is the value of @duration attribute
• r[s] is the ceiling of (PEwc[i] − PSwc[i] − t[s]/ts) × ts/d[s])

Each Media Segment at position k=1,2, ... for each Representation has assigned an earliest media presentation time EPT[k,r,i] and an accurate segment duration SDUR[k,r,j], all measured in media presentation time. The earliest presentation time may be estimated from the MPD using the segment availability start time minus the segment duration announced in the MPD. The earliest presentation time may be accurately determined from the Segment itself.

For each Period i with Period start time PSwc[i] and Period end time PEwc[i] and each Representation r in the Period the following information can be computed:

• the presentation time offset described in the MPD, o[i,r]
• the availability time offset of this Representation, ato[r]
• the number of the first segment described in the MPD, k1[i,r]
• the number of the last segment described in the MPD, k2[i,r]
• segment availability start time of the initialization segment SAST[0,i,r]
• segment availability end time of the initialization segment SAET[0,i,r]
• segment availability start time of each media segment SAST[k,i,r], k=k1, ..., k2
• segment availability end time of each media segment SAET[k,i,r], k=k1, ..., k2
• adjusted segment availability start time ASAST[0,i,r], k=0, k1, ..., k2
• segment duration of each media segment SD[k,i,r], k=k1, ..., k2
• the URL of each of the segments, URL[k,i,r]

In addition,

• the latest available Period i[NOW] and the latest segment available at the server k[NOW] can be computed. This segment is also referred to as live edge segment.
• the earliest available Period i × [NOW] and the earliest segment available at the server k × [NOW] can be computed.

Based on the above information, for each Representation r in a Period i, the segment availability start time SAST[k,i,r], the segment availability end time of each segment SAET[k,i,r], the segment duration of each segment SD[k,i,r], and the URL of each of the segments, URL[k,i,r] within one Period i be derived as follows using the URL Template function URLTemplate(ReplacementString, Address):

• k=0
• SAST[0,i,r] = PSwc[i]
• ASAST[0,i,r] = PSwc[i] - ato
• for s=1, ... NS [i,r]
  • k = k + 1
  • SAST[k,i,r] = PSwc[i] + (t[s,i,r] + d[s,i,r] - o[i,r])/ts
  • ASAST[k,i,r] = SAST[k,i,r] - ato
  • SD[k,i,r] = d[s,i,r]/ts
  • SAET[k,i,r] = SAST[k,i,r] + TSB + d[s,i,r]/ts
  • if SegmentTemplate@media contains $Number$
    • Address=@startNumber
    • URL[k,i,r] = URLTemplate ($Number$, Address)
  • for j = 1, ..., r[s,i,r]
    • k = k + 1
    • SAST[k,i,r] = SAST[k-1,i,r] + d[s,i,r]/ts
    • ASAST[k,i,r] = SAST[k,i,r] - ato
    • SAET[k,i,r] = SAST[k,i,r] + TSB + d[s,i,r] /ts
    • SD[k,i,r] = d[s,i,r] /ts
    • if SegmentTemplate@media contains $Number$
      • Address = Address + 1
      • URL[k,i,r] = URLTemplate ($Number$, Address)
• k2[i,r] = k
• SAET[0,i,r] = SAET[k2[i,r],i,r]

Note that not all segments documented above may necessarily be accessible at time NOW, but only those that are within the segment availability time window. Hence, the number of the first media segment described in the MPD for this Period, k1[i,r], is the smallest k=1, 2, ... for which SAST[k,i,r] >= NOW. The latest available Period i[NOW] is the Period i with the largest PEwc[i] and PEwc[i] is smaller than or equal to NOW. The latest available segment k[NOW] available for a Representation of Period i[NOW] (also the live edge segment) is the segment with the largest k=0,1,2,... such that SAST[k,i,r] is smaller than or equal to NOW. Note that this contains the Initialization Segment with k=0 as not necessarily any media segment may yet be available for Period i[NOW]. In this case, last media segment k2[i[NOW]-1,r], i.e., the last media segment of the previous Period is the latest accessible media Segment. However, if the @availabilityTimeOffset is present, then the segments for this Representation are available earlier than the nominal segment availability start time, namely at ASAST[k,i,r].

The function URL Template function URLTemplate(ReplacementString, Address) generates a URL. For details refer to ISO/IEC 23009-1 [43], clause 5.3.9.4. Once the Segment is generated, processing of the Base URLs that apply on this segment level is done as defined in ISO/IEC 23009-1 [43], clause 5.6.

In order to offer a simple dynamic service for which the following details are known in advance,

• start at wall-clock time START,
• exact duration of media presentation PDURATION,
• location of the segments for each Representation at " http://example.com/$RepresentationID$/$Number$",

a service provide may offer an MPD as follows:

Based on the details in clause 11.2.2.2, the Segment Information is derived as:

• k1 = 1
• k2 = ceil(PDURATION/SDURATION)
• for k = 1, ..., k2
  • SAST[k] = START + PSTART + k*SDURATION
  • SAET[k] = SAST[k] + TSB + SDURATION
  • SD[k] = SDURATION
  • URL[k] = http://example.com/$RepresentationID$/k
• The segment availability times of the Initialization Segment are as follows:
  • SAST[0] = START + PSTART
  • SAET[0] = SAET[k2]

In the following recommendations are provided for the

• Time Shift Buffer Depth (TSB):
  • If the content should be consumed at the live edge, then the time shift buffer depth should be set short. However, the TSB should not be smaller than the recommended value of 4*SDURATION and 6 seconds in media time in order for the client to do some prebuffering in more difficult network conditions.
  • If no restrictions on the accessibility of the content are provided, then the TSB may be set to a large value that even exceeds PDURATION.
• Suggested Presentation Delay (SPD)
  • If synchronized play-out with other devices adhering to the same rule is desired and/or the service provider wants to define the typical live edge of the program, then this value should be provided. The service provider should set the value taking into account at least the following:
    • the desired end-to-end latency
    • the typical required buffering in the client, for example based on the network condition
    • the segment duration SDURATION
    • the time shift buffer depth TSB
  • A reasonable value may be 2 to 4 times of the segment duration SDURATION, but the time should not be smaller than 4 seconds in order for the client to maintain some buffering.
• Segment Duration (SDURATION)
  • The segment duration typically influences the end-to-end latency, but also the switching and random access granularity as in DASH-264/AVC each segment starts with a stream access point which can also be used as s switch point. The service provider should set the value taking into account at least the following:
    • the desired end-to-end latency
    • the desired compression efficiency
    • the start-up latency
    • the desired switching granularity
    • the desired amount of HTTP requests per second
    • the variability of the expected network conditions
  • Reasonable values for segment durations are between 1 second and 10 seconds.
• Minimum Buffer Time (MBT) and bandwidth (BW)
  • the value of the minimum buffer time does not provide any instructions to the client on how long to buffer the media. The value describes how much buffer a client should have under ideal network conditions. As such, MBT is not describing the burstiness or jitter in the network, it is describing the burstiness or jitter in the content encoding. Together with the BW value, it is a property of the content. Using the "leaky bucket" model, it is the size of the bucket that makes BW true, given the way the content is encoded.
  • The minimum buffer time provides information that for each Stream Access Point (and in the case of DASH-IF therefore each start of the Media Segment), the property of the stream: If the Representation (starting at any segment) is delivered over a constant bitrate channel with bitrate equal to value of the BW attribute then each presentation time PT is available at the client latest at time with a delay of at most PT + MBT.
  • In the absence of any other guidance, the MBT should be set to the maximum GOP size (coded video sequence) of the content, which quite often is identical to the maximum segment duration. The MBT may be set to a smaller value than maximum segment duration, but should not be set to a higher value.

For content offered within a Period, and especially when offered in multiple Periods, then the content provider should offer the content such that actual media presentation time is as close as possible to the actual Period duration. It is recommended that the Period duration is the maximum of the presentation duration of all Representations contained in the Period. A typical multi-Period offering is shown in Table 11-4. This may for example represent a service offering where main content provided in Period 1 and Period 3 are interrupted by an inserted Period 2.

Based on the details in clause 11.2.2.2, the Segment Information is derived as:

• Period 1
  • PSwc[1] = START + PSTART
  • PEwc[1] = START + PSTART2
  • k1 = 1
  • k2 = ceil((PSTART2-PSTART1)/SDURATION)
  • for k = 1, ..., k2
    • SAST[k] = PSwc[1] + k*SDURATION
    • SAET[k] = SAST[k] + TSB + SDURATION
    • SD[k] = SDURATION
    • URL[k] = http://example.com/1/$RepresentationID$/k
  • SAST[0] = PSwc[1]
  • SAET[0] = SAET[k2]
• Period 2
  • PSwc[2] = START + PSTART2
  • PEwc[2] = START + PSTART3
  • k1 = 1
  • k2 = ceil((PSTART3-PSTART2)/SDURATION2)
  • for k = 1, ..., k2
    • SAST[k] = PSwc[2] + k*SDURATION2
    • ASAST[k] = SAST[k] - ATO2
    • SAET[k] = SAST[k] + TSB + SDURATION2
    • SD[k] = SDURATION2
    • URL[k] = http://example.com/2/$RepresentationID$/k
  • SAST[0] = PSwc[2]
  • SAET[0] = SAET[k2]
• Period 3
  • PSwc[3] = START + PSTART3
  • PEwc[3] = START + PDURATION
  • k1 = 1
  • k2 = ceil((PSTART3-PDURATION)/SDURATION1)
  • for k = 1, ..., k2
    • SAST[k] = PSwc[3] + k × SDURATION1
    • SAET[k] = SAST[k] + TSB + SDURATION1
    • SD[k] = SDURATION1
    • URL[k] = http://example.com/1/$RepresentationID$/(k+STARTNUMBER2-1)
  • SAST[0] = PSwc[3]
  • SAET[0] = SAET[k2]

Note that the number k describes position in the Period. The actual number used in the segment template increased by the one less than the actual start number.

A DASH client is expected to start playout from:

• The time indicated by the MPD Anchor, if one is present
• The live edge, if there is no MPD Anchor and MPD@type="dynamic".

For joining at the live edge there are basically two high-level strategies:

• Every client participating in the service commits to the same presentation delay (PD) relative to the announced segment availability start time at start-up and in continuous presentation, possible using one suggested by the Content Provider and then attempts to minimise start-up latency and maintain the buffer. The content provider may have provided the MPD@suggestedPresentationDelay (SPD) or may have provided this value by other means outside the DASH formats. The content author should be aware that the client may ignore the presence of MPD@suggestedPresentationDelay and may choose its own suitable playout scheduling.
• The client individually picks the presentation delay (PD) in order to maximize stable quality and does this dependent on its access, user preferences and other considerations.

In both cases the client needs to decide, which segment to download first and when to schedule the playout of the segment based on the committed PD. A DASH client would download an available segment and typically render the earliest presentation time EPT(k) of the segment at PSwc[i] + (EPT(k) − o[r,i]) + PD. As PD may be quite large, for example in order to provision for downloading in varying bitrate conditions, and if a segment is downloaded that was just made available it may result in larger start up delay. Therefore, a couple of strategies may be considered as a trade-off of for start-up delay, presentation delay and sufficient buffer at the beginning of the service, when joining at the live edge:

1. The client downloads the next available segment and schedules playout with delay PD. This maximizes the initial buffer prior to playout, but typically results in undesired long start-up delay.
2. The client downloads the latest available segment and schedules playout with delay PD. This provides large initial buffer prior to playout, but typically results in undesired long start-up delay.
3. The client downloads the earliest available segment that can be downloaded to schedules playout with delay PD. This provides a smaller initial prior to playout, but results in reasonable start-up delay. The buffer may be filled gradually by downloading later segments faster than their media playout rate, i.e. by initially choosing Representations that have lower bitrate than the access bandwidth.