11 Live Services

26.2473GPPProgressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)Release 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

11.1 Overview Dynamic and Live Media Presentations

DASH Media Presentations with MPD@type set to "dynamic" enable that media is made available over time and its availability may also be removed over time. This has two major effects, namely

1) The content creator can announce a DASH Media Presentation for which not all content is yet available, but only gets available over time.

2) Clients are forced into a timed schedule for the playout, such that they follow the schedule as desired by the content author.

Dynamic services may be used for different types of services:

1) Dynamic Distribution of Available Content: Services, for which content is made available as dynamic content, but the content is entirely generated prior to distribution. In this case the details of the Media Presentation, especially the Segments (duration, URLs) are known and can be announced in a single MPD without MPD updates.

2) MPD-controlled Live Service: Services for which the content is typically generated on the fly, and the MPD needs to be updated occasionally to reflect changes in the service offerings, e.g. announcing a new Period with new media or providing the end of the Media Presentation. The DASH client operates solely on information in the MPD.

Dynamic and Live services are typically controlled by different client transactions and server-side signaling.

For initial access to the service and joining the service, an MPD is required. MPDs may be accessed at join time or may have been provided earlier, for example along with an Electronic Service Guide. The initial MPD or join MPD is accessed and processed by the client and the client is synchronized with the server can analyze the MPD and extract suitable information in order to initiate the service. This includes, but is not limited to:

– identifying the currently active Periods in the service and the Period that expresses the live edge (for more details see below)

– selecting the suitable media components by selecting one or multiple Adaptation Sets. Within each Adaptation Set selecting an appropriate Representation and identifying the live edge segment in each Representations. The client then issues requests for the Segments.

The MPD may be updated on the server based on certain rules and clients consuming the service are expected to update MPDs based on certain triggers.

This clause provides requirements and recommendations for different functions, namely

– for the dynamic segment download in clause 11.2.

– for services with MPD updates in clause 11.3

– for offering live generated services in on-demand mode in clause 11.4

– for client-server timing synchronization in clause 11.5.

– for robust service offerings and corresponding clients in clause 11.6.

11.2 Dynamic Segment Download

11.2.1 Background and Assumptions

The dynamic segment download function is a key component of live services, In addition, the dynamic segment download function may also be used for scheduling playout of on-demand content by the content author. In this subsection, it is assumed that the client has access to a single instance of an MPD and all information of the entire Media Presentation is contained in the MPD.

The timing model of dynamic services, especially the generation of Segment availabilities is a relevant component of a live services. This forms the basis for live services and explains the key concepts and rules for Segment availabilities.

11.2.2 MPD Information and Timing Model

11.2.2.1 MPD Information

If the Media Presentation is of type dynamic, then Segments have different Segment availability times, i.e. the earliest time for which the service provider permits the DASH client to issue a request to the Segment and guarantees, under regular operation modes, that the client gets a 200 OK response for the Segment. The Segment availability times for each Representation can be computed based on the information in an MPD.

For a dynamic service the MPD should at least contain information as available in Table 11-1. Information included there may be used to compute a list of announced Segments, Segment Availability Times and URLs.

Assume that an MPD is available to the DASH client at a specific wall-clock time NOW. It is assumed that the client and the DASH server providing the Segments are synchronized to wall-clock, either through external means or through a specific client-server synchronization. Details on synchronization are provided in clause 11.6.

Assuming synchronization, the information in the MPD can then be used by the client at time NOW to derive the availability (or non-availability) of Segments on the server.

Table 11-1 — Information related to Segment Information and Availability Times for a dynamic service

MPD Information	Status	Comment
MPD@type	mandatory, set to "dynamic"	the type of the Media Presentation is dynamic, i.e. Segments get available over time.
MPD@availabilityStartTime	mandatory	the start time is the anchor for the MPD in wall-clock time. The value is denoted as AST in the following.
MPD@mediaPresentationDuration	mandatory (for the considered use cases)	provides the duration of the Media Presentation.
MPD@suggestedPresentationDelay	optional, but recommended	suggested presentation delay as delta to segment availability start time. The value is denoted as SPD. Details on the setting and usage of the parameter is provided in the following.
MPD@minBufferTime	mandatory	minimum buffer time, used in conjunction with the @bandwidth attribute of each Representation. The value is denoted as MBT. Details on the setting and usage of the parameter is provided in the following.
MPD@timeShiftBufferDepth	optional, but recommended	time shift buffer depth of the media presentation. The value is denoted as TSB. Details on the setting and usage of the parameter is provided in the following.
Period@start	Mandatory for the first Period in the MPD	the start time of the Period relative to the MPD availability start time.
Representation@availabilityTimeOffset	Optional default	The offset in availability time for this Representation. It may also be available on a Base URL or default NOTE: the value of "INF" implies availability of all segments starts at MPD@availabilityStartTime
SegmentTemplate@media	mandatory	The template for the Media Segment assigned to a Representation.
SegmentTemplate@startNumber	optional default	number of the first segment in the Period assigned to a Representation
SegmentTemplate@timescale	optional default	timescale for this Representation.
SegmentTemplate@duration	mandatory	the duration of each Segment in units of a time.

11.2.2.2 Segment Information Derivation

11.2.2.2.1 Introduction

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 section 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.

11.2.2.2.2 Definitions

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

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.

11.2.2.2.2 Definitions

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

– 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 wall-clock time. All information in the MPD related to wall-clock is expressed as a reference to the time NOW.

11.2.2.2.3 MPD Information

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.

Furthermore, it is recommended to provide values for MPD@timeShiftBufferDepth and MPD@suggestedPresentationDelay.

11.2.2.2.4 Period Information

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.

NOTE: An MPD update may extend the Period end time of the last regular Period. For details refer to section 11.3.

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

– 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].

11.2.2.2.5 Representation Information

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

– N_S=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 ceil of (PEwc[i] – PSwc[i] – t[s]/ts)*ts/d[s])

11.2.2.2.6 Media Time Information of Segment

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.

11.2.2.2.7 Segment List Parameters

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, … N_S [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].

11.2.2.2.8 URL Generation with Segment Template

The function URL Template function URLTemplate(ReplacementString, Address) generates a URL. For details refer to ISO/IEC 23009-1, section 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, section 5.6.

11.2.3 Service Offering Requirements and Guidelines

11.2.3.1 General Service Offering Requirements

For dynamic service offerings, the MPD shall conform to the MPD in clause 8 and shall at least contain the mandatory information as documented in Table 11-1.

If such an MPD is accessible at time NOW at the location MPD.Location, then

– all Segments for all Representations in all Periods as announced in an MPD shall be available latest at the announced segment availability start time SAST[k,i,r] at all URL[k,i,r] as derived in section 11.2.2.2;

– all Segments for all Representations in all Periods as announced in an MPD shall at least be available until the announced segment availability end time SAET[k,i,r] at all URL[k,i,r] as derived in section 11.2.2.2;

– for all Media Segments for all Representations in all Periods as announced in an MPD the Segment in this Period is available prior to the sum of Period start, earliest presentation time and segment duration, i.e. SAST[k,i,r] <= PSwc[i] + SD[k,r,i] + EPT[k,r,i];

– if a Media Segments with segment number k is delivered over a constant bitrate channel with bitrate equal to value of the @bandwidth attribute then each presentation time PT is available at the client latest at time with a delay of at most PT + MBT.

11.2.3.2 Dynamic Service Offering Guidelines

11.2.3.2.1 Introduction

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:

Table 11-2 – Basic Service Offering

MPD Information	Value
MPD@type	dynamic
MPD@availabilityStartTime	START
MPD@mediaPresentationDuration	PDURATION
MPD@suggestedPresentationDelay	SPD
MPD@minBufferTime	MBT
MPD@timeShiftBufferDepth	TSB
MPD.BaseURL	"http://example.com/"
Period@start	PSTART
Representation@bandwidth	BW
SegmentTemplate@media	"$RepresentationID$/$Number$"
SegmentTemplate@startNumber	1
SegmentTemplate@duration	SDURATION

Note that the setting of capitalized parameters is discussed in clause 11.2.3.2.2.

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]

11.2.3.2.2 Basic Parameter Settings

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.

11.2.3.3 Content Offering with Periods

11.2.3.3.1 General

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.

Table 6 Multi-Period Service Offering

MPD Information		Value
MPD@type		dynamic
MPD@availabilityStartTime		START
MPD@mediaPresentationDuration		PDURATION
MPD@suggestedPresentationDelay		SPD
MPD@minBufferTime		MBT
MPD@timeShiftBufferDepth		TSB
MPD.BaseURL		"http://example.com/"
Period@start		PSTART
	SegmentTemplate@media	"1/$RepresentationID$/$Number$"
	SegmentTemplate@startNumber	1
	SegmentTemplate@duration	SDURATION1
Period@start		PSTART2
	Representation@availabilityTimeOffset	ATO2
	SegmentTemplate@media	"2/$RepresentationID$/$Number$"
	SegmentTemplate@startNumber	1
	SegmentTemplate@duration	SDURATION2
Period@start		PSTART3
	SegmentTemplate@media	"1/$RepresentationID$/$Number$"
	SegmentTemplate@startNumber	STARTNUMBER2
	SegmentTemplate@duration	SDURATION1
	SegmentTemplate@presentationTimeOffset	PTO

Based on the details in section 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.

11.2.3.4 Joining Recommendation

By default, an MPD with MPD@type="dynamic" suggests that the client would want to join the stream at the live edge, therefore to download the latest available segment (or close to, depending on the buffering model), and then start playing from that segment onwards.

However there are circumstances where a dynamic MPD might be used with content intended for playback from the start, or from another position. For example, when a content provider offers ‘start again’ functionality for a live program, the intention is to make the content available as an on-demand program, but not all the segments will be available immediately.

This may be signalled to the DASH client by including an MPD Anchor, with either

– the t parameter, or

– both the period and t parameter, in the MPD URL provided to the DASH client, or

The format and behaviour of MPD Anchors is defined in section C.4 of ISO/IEC 23009-1.

For example to start from the beginning of the MPD the following would be added to the end of the MPD URL provided to the DASH client:

– #t=0

Or to start from somewhere other than the start, in this case 50 minutes from the beginning of the period with Period ID "program_part_2":

– #period=program_part_2&t=50:00

Where an MPD Anchor is used it should refer to a time for which segments are currently available in the MPD.

11.2.4 Client Operation, Recommendations and Guidelines (informative)

11.2.4.1 Basic Operation

A DASH client is guided by the information provided in the MPD. A simple client model is shown in Figure 11-1.

Figure 11-1 Simple Client Model

Assume that the client has access to an MPD and the MPD contains the parameters in Table 11-1 and Table 11-3, i.e. it consumes a dynamic service with fixed media presentation duration, but possibly multiple Periods

The following example client behaviour may provide a continuous streaming experience to the user:

1) The client parses the MPD, selects a collection of Adaptation Sets suitable for its environment based on information provided in each of the AdaptationSet elements.

2) Within each Adaptation Set it selects one Representation, typically based on the value of the @bandwidth attribute, but also taking into account client decoding and rendering capabilities.

The client creates a list of accessible Segments at least for each selected Representation taking into account the information in the MPD as documented in Table 11-1 and Table 11-3 and the current time JOIN in the client and in particular the segment closest to the live edge referred to the live edge segment. For details refer to section 11.2.4.2.
For this it needs to take into account the latest Period i[NOW]. The latest Period and the latest segment are obtained as follows with i* the index of the last Period.:

– if NOW <= PSwc[1]

– no segment is yet available

– else if NOW > PSwc[i*]

– the last one and the latest segment is available is k2[i*]

– else if NOW > PSwc[i*] + TSB

– no segment is available any more

– else if PSwc[1] < NOW <= PEwc[i*]

– i’ the such that PSwc[i’] < NOW <= PEwc[i’]

– k[NOW] = MIN(floor ((NOW – PEwc[i‘] – PSwc[i‘])/SDURATION[i’]), k2)

Note again that if k[NOW] is 0, then only the Initialization Segment is available. If the Period is not the first one, then the last available Media Segment is the last Media Segment of the previous Period.

3) The client downloads the initialization segment of the selected Representations and then accesses the content by requesting entire Segments or byte ranges of Segments. Typically at any time the client downloads the next segment at the larger of the two: (i) completion of download of current segment or (ii) the Segment Availability Start Time of the next segment. Note that if the @availabilityTimeOffset is present, then the segments may be downloaded earlier, namely at the adjusted segment availability start time. Based on the buffer fullness and other criteria, rate adaptation is considered. Typically the first media segment that is downloaded is the live edge segment, but other decisions may be taken in order to minimize start-up latency. For details on initial buffering, refer to section 11.2.4.4.

4) According to Figure 11-1 media is fed into buffer and at some point in time, the decoding and rendering of the media is kicked off. The downloading and presentation is done for the selected Representation of each selected Adaptation. The synchronization is done using the presentation time in the Period. For synchronized playout, the exact presentation times in the media is expected to be used.

5) Once presentation has started, the playout process is continuous. The playout process expects media to be present in the buffer continuously. If the MPD@suggestedPresentationDelay is present, then this value may be used as the presentation delay PD. If the MPD@suggestedPresentationDelay is not present, but the client is expected to consume the service at the live edge, then a suitable presentation delay should be selected, typically between the value of @minBufferTime and the value of @timeShiftBufferDepth. It is recommended that the client starts rendering the first sample of the downloaded media segment k with earliest presentation time EPT(k) at PSwc[i] + (EPT(k) – o[r,i]) + PD. For details on selecting and minimizing end-to-end latency as well as the start-up latency, see section 11.2.4.4.

6) The client may request Media Segments of the selected Representations by using the generated Segment list during the availability time window.

7) Once the presentation has started, the client continues consuming the media content by continuously requesting Media Segments or parts of Media Segments and playing content that according to the media presentation timeline. The client may switch Representations taking into updated information from its environment, e.g. change of observed throughput. In a straight-forward implementation, with any request for a Media Segment starting with a stream access point, the client may switch to a different Representation. If switching at a stream access point, the client is expected to switch seamlessly at such a stream access point.

8) With the wall-clock time NOW advancing, the client consumes the available Segments. As NOW advances the client possibly expands the list of available Segments for each Representation in the Period according to the procedures specified in 11.2.4.2.

9) Once the client is consuming media contained in the Segments towards the end of the announced media in the Representation, then either the Media Presentation is terminated, a new Period is started (see subsection or the MPD needs to be refetched. Once the client is consuming media contained in the Segments towards the end of the announced media in the Representation, and the Representation is contained not in the last Period, then the DASH clients generally needs to reselect the Adaptation Sets and a Representation in same manner as described in bullet 1) and 2). Also steps 3), 4), 5) and 6) need to be carried out at the transition of a Period. Generally, audio/video switching across period boundaries may not be seamless. According to ISO/IEC 23009-1, section 7.2.1, at the start of a new Period, the playout procedure of the media content components may need to be adjusted at the end of the preceding Period to match the PeriodStart time of the new Period as there may be small overlaps or gaps with the Representation at the end of the preceding Period. Overlaps (respectively gaps) may result from Media Segments with actual presentation duration of the media stream longer (respectively shorter) than indicated by the Period duration. Also in the beginning of a Period, if the earliest presentation time of any access unit of a Representation is not equal to the presentation time offset signalled in the @presentationTimeOffset, then the playout procedures need to be adjusted accordingly.

The client should play the content continuously across Periods, but there may be implications in terms of implementation to provide fully continuous and seamless playout. It may be the case that at Period boundaries, the presentation engine needs to be reinitialized, for example due to changes in formats, codecs or other properties. This may result in a re-initialization delay. Such a re-initialization delay should be minimized. If the Media Presentation is of type dynamic, the addition of the re-initialisation delay to the playout may result in drift between the encoder and the presentation engine. Therefore, the playout should be adjusted at the end of each Period to provide a continuous presentation without adding drift between the time documented in the MPD and the actual playout, i.e. the difference between the actual playout time and the Period start time should remain constant.

If the client presents media components of a certain Adaptation Set in one Period, and if the following Period has assigned an identical Asset Identifier, then the client should identify an associated Period and, in the absence of other information, continue playing the content in the associated Adaptation Set.

If furthermore the Adaptation Sets are period-continuous, i.e. the presentation times are continuous and this is signalled in the MPD, then the client is expected to seamlessly play the content across the Period boundary. Most suitably the client may continue playing the Representation in the Adaptation Set with the same @id, but there is no guarantee that this Representation is available. In this case the client is expected to seamlessly switch to any other Representation in the Adaptation Set.

For details on MPD updates and refetching, please refer to section 11.3.

11.2.4.2 Joining, Initial Buffering and Playout Recommendations

11.2.4.2.1 General

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".

11.2.4.2.2 Joining at the live edge

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 tradeoff 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.

11.2.5 Considerations on live edge)

A DASH client should avoid being too aggressive in requesting segments exactly at the computed segment availability start time, especially if it is uncertain to be fully synchronized with the server. If the DASH client observes issues, such as 404 responses, it should back up slightly in the requests.

In addition, for a content authoring to avoid too aggressive requests and possible 404 responses, the content author may schedule the segment availability start time in the MPD with a small safety delay compared to the actual publish time. This also provides the content author a certain amount of flexibility in the publishing of Segments. However, note that such safety margins may lead to slightly increased end-to-end latencies, so it is a balance to be taken into account.

11.3 Live Services with MPD Updates

11.3.1 Background and Assumptions

If many cases, the service provider cannot predict that an MPD that is once offered, may be used for the entire Media Presentations. Examples for such MPD changes are:-The duration of the Media Presentation is unknown

– The Media Presentation may be interrupted for advertisements which requires proper splicing of data, for example by adding a Period

– Operational issues require changes, for example the addition of removal of Representations or Adaptation Sets.

– Operational problems in the backend.

– Changes of segment durations, etc.

In this case the MPD typically only can describe a limited time into the future. Once the MPD expires, the service provider expects the client to recheck and get an updated MPD in order to continue the Media Presentation.

The main tool in MPEG-DASH is Media Presentation Description update feature as described in section 5.4 of ISO/IEC 23009-1. The MPD is updated at the server and the client is expected to obtain the new MPD information once the determined Segment List gets to an end.

If the MPD contains the attribute MPD@minimumUpdatePeriod, then the MPD in hand will be updated. The DASH client typically frequently polls the MPD update server whether an MPD update is available or the existing MPD can still be used. The update frequency is controlled by MPD based on the attribute MPD@minimumUpdatePeriod.

11.3.2 Preliminaries

11.3.2.1 MPD Information

As the MPD is typically updated over time on the server, the MPD that is accessed when joining the service as well as the changes of the MPD are referred to as MPD instances in the following. This expresses that for the same service, different MPDs exist depending on the time when the service is consumed.

Assume that an MPD instance is present on the DASH server at a specific wall-clock time NOW. For an MPD-based Live Service Offering, the MPD instance may among others contain information as available in Table 11-5. Information included there may be used to compute a list of announced Segments, Segment Availability Times and URLs.

Table 11-5 – Information related to Live Service Offering with MPD-controlled MPD Updates

MPD Information	Status	Comment
MPD@type	mandatory, set to "dynamic"	the type of the Media Presentation is dynamic, i.e. Segments get available over time.
MPD@availabilityStartTime	mandatory	the start time is the anchor for the MPD in wall-clock time. The value is denoted as AST.
MPD@minimumUpdatePeriod	mandatory	this field is mandatory except for the case where the MPD@mediaPresentationDuration is present. However, such an MPD falls then in an instance as documented in section 11.2.
Period@start	mandatory	the start time of the Period relative to the MPD availability start time. The value is denoted as PS.
SegmentTemplate@media	mandatory	the template for the Media Segment
SegmentTemplate@startNumber	optional default	the number of the first segment in the Period. The value is denoted as SSN.
SegmentTemplate@duration	mandatory	the duration of each Segment in units of a time. The value divided by the value of @timescale is denoted as MD[k] with k=1, 2, … The segment timeline may contain some gaps.

11.3.2.2 Segment Information Derivation

Based on an MPD instance including information as documented in Table 11-5 and available at time NOW on the server, a DASH client may derive the information of the list of Segments for each Representation in each Period.

If the Period is the last one in the MPD and the MPD@minimumUpdatePeriod is present, then the time PEwc[i] is obtained as the sum of NOW and the value of MPD@minimumUpdatePeriod. Note that with the MPD present on the server and NOW progressing, the Period end time is extended. This issue is the only change compared to the segment information generation in section 11.2.2.2.

If the MPD@minimumUpdatePeriod is set to 0, then the MPD documents all available segments on the server.

11.3.3 Service Offering Requirements and Guidelines

11.3.3.1 General

The same service requirements as in section 11.2.2.1 hold for any time NOW the MPD is present on the server with the interpretation that the Period end time PEwc[i] of the last Period is obtained as the sum of NOW and the value of MPD@minimumUpdatePeriod.

In order to offer a simple live service with unknown presentation end time, but only a single Period and the following details are known in advance,

– start at wall-clock time START,

– location of the segments for each Representation at " http://example.com/$RepresentationID$/$Number$",

a service provider may offer an MPD with values according to Table 11-6.

Table 11-6 – Basic Service Offering with MPD Updates

MPD Information	Value
MPD@type	dynamic
MPD@availabilityStartTime	START
MPD@publishTime	PUBTIME1
MPD@minimumUpdatePeriod	MUP
MPD.BaseURL	"http://example.com/"
Period@start	PSTART
SegmentTemplate@media	"$RepresentationID$/$Number$"
SegmentTemplate@startNumber	1
SegmentTemplate@duration	SDURATION

Based on the details in section 11.2.2.2 and 11.4.2.2, the Segment Information can be derived at each time NOW by determining the end time of the Period PEwc[1] = NOW + MUP.

The service provider may leave the MPD unchanged on the server. If this is the case the Media Presentation may be terminated with an updated MPD that

– adds the attribute MPD@mediaPresentationDuration with value PDURATION

– removes the attribute MPD@minimumUpdatePeriod

– changes the MPD@publishTime attribute to PUBTIME2

The MPD must be published latest at the end of the Media Presentation minus the value of MUP, i.e. PUBTIME2 <= START + PSTART + PDURATION – MUP.

The minimum update period may also be changed during an ongoing Media Presentation. Note that as with any other change to the MPD, this will only be effective with a delay in media time of the value of the previous MUP.

The principles in this document also holds for multi-period content, for which an MPD update may add a new Period. In the same way as for signalling the end of the Media Presentation, the publish time of the updated MPD with the new period needs to be done latest at the start of the new Period minus the value of the MPD@minimumUpdatePeriod attribute of the previous MPD.

11.3.3.2 Setting the Minimum Update Period Value

Setting the value of the minimum update period primarily affects two main service provider aspects: A short minimum update period results in the ability to change and announce new content in the MPD on shorter notice. However, by offering the MPD with a small minimum update period, the client requests an update of the MPD more frequently, potentially resulting in increased uplink and downlink traffic.

A special value for the minimum update period is 0. In this case, the end time of the period is the current time NOW. This implies that all segments that are announced in the MPD are actually available at any point in time. This also allows changing the service provider to offer changes in the MPD that are instantaneous on the media timeline, as the client, prior for asking for a new segment, has to revalidate the MPD.

11.3.3.3 Permitted Updates in an MPD

The permitted updates are provided in section 5.4 of ISO/IEC 23009-1.

In addition, updates in the MPD only extend the timeline. This means that information provided in a previous version of the MPD shall not be invalidated in an updated MPD.

In order to make the MPD joining friendly and to remove data that is available in the past, any segments that have fallen out of the time shift buffer may no longer be announced in the MPD. In this case, the Period start may be moved by changing one or both, MPD@availabilityStartTime and Period@start. However, this requires that the @startNumber and @presentationTimeOffset need to be updated such that the Segment Information is correct.

If Representations and Adaptations Sets are added or removed or the location of the Segments is changed, it is recommended to update the MPD and provide Adaptation Sets in a period-continuous manner.

11.3.3.4 Last Segment Message

If the @segmentProfiles contains the ‘lmsg’ brand for a certain Representation, then the ‘lmsg’ brand for signaling the last segment shall be applied for any content with MPD@minimumUpdatePeriod present and the MPD@type="dynamic".

DASH clients operating based on such an MPD and consuming the service at the live edge typi-cally need to request a new MPD prior to downloading a new segment. However, in order to minimise MPD requests and resulting traffic load, the client may use one or more of the follow-ing optimisations:

– If the client fetches the MPD using HTTP, the client should use conditional GET methods to reduce unnecessary network usage in the downlink.

– If the @segmentProfiles contains the ‘lmsg’ brand clients may also rely on the ‘lmsg’ message and request a new MPD only in case a segment is received with an ‘lmsg’ brand. Otherwise the client may use template constructions to continue deter-mining the URL and the segment availability start time of segments.

If the attribute MPD@minimumUpdatePeriod is set to a value greater than 0 then all Segments with availability start time less than the sum of the request time and the value of the MPD@minimumUpdatePeriod will eventually get available at the advertised position at their computed segment availability start time. Note that by providing a MPD@minimumUpdatePeriod is set to a value greater than 0, DASH servers reduce the polling frequency of clients, but at the same time cannot expect that clients will request an updated MPD to be informed on changes in the segment URL constructions, e.g. at the start of a new Period.

11.3.4 MPD-based Live Client Operation based on MPD

In an extension to the description in section 11.2.4, the client now has access to an MPD and the MPD contains the MPD@minimumUpdatePeriod, for example following the parameters in Table 11-5. The start time of each Period is computed as period start time PSwc[i] and the MPD-URL does not include any fragment parameters.

The client fetches an MPD with parameters in Table 11-5 at time FetchTime, at its initial location if no MPD.Location element is present, or at a location specified in any present MPD.Location element. FetchTime is defined as the time at which the server processes the request for the MPD from the client. The client typically should not use the time at which it actually successfully received the MPD, but is expected to take into account delay due to MPD delivery and processing. The fetch is considered successful either if the client obtains an updated MPD or the client verifies that the MPD has not been updated since the previous fetching.

If the client fetches the MPD using HTTP, the client is expected to use conditional GET methods as specified in RFC 2616 to reduce unnecessary network usage in the downlink.

In an extension of bullet 3 in section 11.2.4.1

– the client creates a list of accessible Segments at least for each selected Representation taking into account the information in the MPD as documented in Table 11-5 and the current time NOW by using the Period end time of the last Period as FetchTime + MUP.

In an extension of bullet 9 in section 11.2.4.1,

– the client consumes media in last announced Period. Once the client is consuming media contained in the Segments towards the end of the announced Period, i.e. requesting segments with segment availability start time close to the validity time of the MPD defined as FetchTime + MUP, them, then the DASH client needs to fetch an MPD at its initial location if no MPD.Location element is present, or at a location specified in any present MPD.Location element.

– If the client fetches the updated MPD using HTTP, the client is expected to use conditional GET methods to reduce unnecessary network usage in the downlink.

– The client parses the MPD and generates a new segment list based on the new FetchTime and MUP of the updated MPD. The client searches for the currently consumed Adaptation Sets and Representations and continues the process of downloading segments based on the updated Segment List.

11.4 Provisioning of Live Content in On-Demand Mode

11.4.1 Scenario

A common scenario for DASH distribution results that a live generated service is also made available for On-Demand offering after the live program is completed. The typical scenario is as follows:

– The Segments as generated for the live service are also used for the On-Demand case. This avoids reformatting and also permits to reuse the Segments that are already cached.

– The MPD is modified to reflect that the content is available as On-Demand now.

– Problems that results from live delivery may be solved, e.g. variable segment durations, or issues of segment unavailability.

– The content may be augmented with ads.

– The content may be trimmed from a longer, e.g. 24/7 stream, at the beginning and/or end.

11.4.2 Content Offering Requirements and Recommendations

In order to provide live content as On-Demand in the above scenario, the following is recommended:

– The same Segments as generated for the live distribution are reused also for static distribution.

– Typically, the Segments also will have the same URL in order to exploit caching advantages.

– An MPD should be generated latest at the end of the live session, but also may be created during an ongoing live session to document a certain window of the program that is offered for On-Demand.

– A new MPD is generated that should contain the following information

– The MPD@type is set to static.

– The MPD@availabilityStartTime may be set to any time in the past, for example the time of the original "live" MPD may reused.

– The attributes @timeShiftBufferDepth and @minimumUpdatePeriod are not present (in contrast to the live MPD) and a @mediaPresentationDuration attribute is added.

– The window offered by the MPD is expressed by appropriately setting the Period@start value (including the presentation time offset and the start number) and the @mediaPresentationDuration attribute. The wall-clock time should be maintained by offsetting the Period@start without changing the MPD@availabilityStartTime.

– Content may be offered in the same Period structure as for live or in a different one.

– If Periods are continuous, it is preferable to remove the Period structure.

– If new Periods are added for Ad Insertion, the Periods preferably be added in a way that they are at Segment boundaries.

– The same templating mode as used in the live service should also be used for static distribution.

11.4.3 Client Behavior

For a DASH client, there is basically no difference on whether the content was generated from a live service or the content is provided as On-Demand. However, there are some aspects that may be "left-overs" from a live service distribution that a DASH client is expected to be aware of:

– The Representations may show gaps in the media offering by using early terminated Periods. Such gaps are expected to be recognized and properly handled.

11.5 Availability Time Synchronization between Client and Server

11.5.1 Background

According to ISO/IEC 23009-1, in order to properly access MPDs and Segments that are available on origin servers or get available over time, DASH servers and clients should synchronize their clocks to a globally accurate time standard.

Specifically Segment Availability Times are expected to be wall-clock accurately announced in the MPD and the client needs to have access to the same time base as the MPD generation in order to enable a proper service. In order to ensure this, this section provides server and client requirements to ensure proper operation of a live service.

11.5.2 Service Provider Requirements and Guidelines

If the Media Presentation is dynamic or if the MPD@availabilityStartTime is present then the service shall provide a Media Presentation as follows:

– The segment availability times announced in the MPD should be generated from a device that is synchronized to a globally accurate timing source, preferably using NTP.

– The MPD should contain at least one UTCTiming element with @schemeIdURI set to one of the following:

– urn:mpeg:dash:utc:ntp:2014

– urn:mpeg:dash:utc:http-head:2014

– urn:mpeg:dash:utc:http-xsdate:2014

– urn:mpeg:dash:utc:http-iso:2014

– urn:mpeg:dash:utc:http-ntp:2014

– If the MPD does not contain any element UTCTiming then the segments shall be available latest at the announced segment availability time using a globally accurate timing source.

– If the MPD contains an element UTCTiming then

– the announced timing information in the UTCTiming shall be accessible to the DASH client, and

– the segments shall be available latest at the announced segment availability time in the MPD for any device that uses one of announced time synchronization methods at the same time.

If urn:mpeg:dash:utc:http-head:2014 is used, then the server specified in the @value attribute of the UTCTiming element should be the server hosting the DASH segments such that with each request the Date general-header field in the HTTP header can be used by the client to maintain synchronization.

Note that in practical deployments segment availability may be an issue due to failures, losses, outages and so on. In this case the Server should use methods as defined in section 11.7 to inform DASH clients about potential issues on making segments available.

A leap second is added to UTC every 18 months on average. A service provider should take into account the considerations in RFC 7164 [Y]. The MPD time does not track leap seconds. If these occur during a live service they may advance or retard the media against the real time.

11.5.3 Client Requirements and Guidelines

If the Media Presentation is dynamic or if the MPD@availabilityStartTime is present then client is expected todo the following:

– If the MPD does not contain any element UTCTiming it should acquire an accurate wall-clock time from its system. The anticipated inaccuracy of the timing source should be taken into account when requesting segments close to their segment availability time boundaries.

– If the MPD contains one or several elements UTCTiming then the client is expected toat least use one of the announced timing information in the UTCTiming to synchronize its clock. The client must not request segments prior to the segment availability start time with reference to any of the chosen UTCTiming methods.

– The client may take into account the accuracy of the timing source as well as any transmission delays if it makes segment requests.

– Clients is expected to observe any difference between their time zone and the one identified in the MPD, as MPDs may indicate a time which is not in the same timezone as the client.

– If the client observes that segments are not available at their segment availability start time, the client is expected touse the recovery methods defined in section 11.7.

– Clients is expected to not access the UTCTiming server more frequently than necessary.

11.6 Robust Operation

11.6.1 General Robustness

General Guidelines are provided ISO/IEC 23009-1 DASH spec in A.7 and in Annex A.9 of this specifications. DASH clients and servers should follow those guidelines.

11.6.2 Synchronization Loss of Segmenter

In order to address synchronization loss issues at the segmenter, the following options from the DASH standard should be considered with preference according to the order below:

1) The server is required to always offer a conforming media stream. In case the input stream or encoder is lost, the content author may always add dummy content. This may be done using a separate Period structure and is possible without any modifications of the standard.

2) Early Terminated Periods as included Cor.1 of the second edition of ISO/IEC 23009-1. Early Terminated Periods may be added that contain both Period@start and Period@duration. This expresses that for this Period no media is present at least for the time as expressed by the @duration attribute. Such Periods should only be used if Media Presentation author is experiencing issues in generating media, e.g. due to failures of a live feed. The MPD is updated using the @minimumUpdatePeriod, i.e. the timeline is progressing. This permits server to signal that there is an outage of media generation, but that the service is continuing. It is then up to the client to take appropriate actions.

11.6.3 Encoder Clock Drift

In order to support robust offering even under encoder drift circumstances, the segmenter should avoid being synced to the encoder clock. In order to improve robustness, in the case of an MPD-based offering Periods should be added in a period continuous manner. In the case of MPD and segment-based control, the producer reference box should be added to media streams in order for the media pipeline to be aware of such drifts. In this case the client should parse the segment to obtain this information.

11.6.4 Segment Unavailability

To address signaling of segment unavailability between the client and server and to indicate the reason for this, it is recommended to use regular 404s. In addition, unless a UTC Timing has been defined prior in the MPD, the Date-Header specifying the time of the server should be used. In this case, the DASH client, when receiving a 404, knows that if its time is matching the Date Header, then the loss is due to a segment loss.

11.6.5 Swapping across Redundant Tools

To enable swapping across redundant tools doing hot and warm swaps, the following should be considered

1) the content author is offering the service redundant to the client (for example using multiple BaseURLs) and the client determines the availability of one or the other. This may be possible under certain circumstances

2) Periods may be inserted at a swap instance in order to provide the new information after swap. If possible, the offering may be continuous, but the offering may also be non-continuous from a media time perspective.

3) A completely new MPD is sent that removes all information that was available before any only maintains some time continuity. However, this tool is not fully supported yet in any DASH standard and not even considered.

There is a clear preference for the bullets above in their order 1, 2 and 3 as the service continuity is expected to be smoother with higher up in the bullet list. At the same time, it may be the case that the failure and outages are severe and only the third option may be used.