8 DASH – Media Presentation
26.2473GPPProgressive Download and Dynamic Adaptive Streaming over HTTP (3GP-DASH)Release 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS
8.1 Introduction
MPEG had initiated a standardization process to provide specifications to enable scalable and flexible video distribution that addresses fixed and mobile networks. The work had been in close coordination with a parallel effort in 3GPP such that the two standards are aligned for broad industry support across different access networks. 3GPP’s Release-9 specification on Adaptive HTTP Streaming (AHS) [3], section 12 completed in 2010 served as a baseline for MPEG’s DASH [43] (MPEG-DASH) as well as for 3GP DASH specification in this document.
In addition to the format specification, MPEG provides additional supporting material as part of MPEG-DASH, namely:
– ISO/IEC 23009-2: Conformance and Reference software [44]
– ISO/IEC 23009-3: Implementation and Deployment Guidelines [45]
Due to the close coordination in the development, 3GP-DASH can be viewed as a set of profiles of MPEG-DASH, MPEG DASH for the segment format uses the ISO base media file format [7]. In 3GPP, compatibility is achieved with the 3GP file format [5].Dynamic Adaptive Streaming over HTTP (DASH) [43] specifies XML and binary formats that enable delivery of media content from standard HTTP servers to HTTP clients and enable caching of content by standard HTTP caches.
ISO/IEC 23009-1 [43] primarily defines two formats:
The Media Presentation Description (MPD) describes a Media Presentation, i.e. a bounded or unbounded presentation of media content. In particular, it defines formats to announce resource identifiers for Segments and to provide the context for these identified resources within a Media Presentation. These resource identifiers are HTTP-URLs possibly combined with a byte range.
The Segment formats specify the formats of the entity body of the HTTP response to an HTTP GET request or a partial HTTP GET with the indicated byte range using HTTP/1.1 as defined in RFC 2616 to a resource identified in the MPD. Segments typically contain efficiently coded media data and metadata conforming to or at least closely aligned with common media formats.
For more details on DASH System description, please refer to ISO/IEC 23009-1 [43], clause 4.1.
For more details on DASH Client model, please refer to ISO/IEC 23009-1 [43], clause 4.2.
For more details on DASH Data model overview, please refer to ISO/IEC 23009-1 [43], clause 4.3.
For more details on DASH Media Stream and Representation properties, please refer to ISO/IEC 23009-1 [43], clause 4.5.
The format of the Media Presentation Description in 3GP-DASH is defined in clause 8.2.
The format of the Segments in 3GP-DASH is defined in section 9.
Figure 8.1: Void
8.2 Media Presentation Description
8.2.1 General
The Media Presentation Description shall conform to a DASH Media Presentation as defined in ISO/IEC 23009-1 [43], clause 5.2.Updates may also be done using MPD delta files as defined in clause 8.5.2. The MIME type of an MPD delta file is defined in Annex H.2.
8.2.2 Schema and 3GPP Extension
The overview of the XML schema of the MPD is provided in below. Specific types, elements and attributes are introduced in the remainder of this clause. The complete MPD schema is provided in Annex B of this specification. In case of any inconsistencies the schema in Annex B takes precedence over the XML-syntax snippets provided in this clause. For the normative schema refer to the schema in Annex B.
The main schema is provided in Table 8-1 with the namespace "urn:mpeg:dash:schema:mpd:2011". The 3GPP extension namespace is provided in Table 8-2 with namespace "urn:3GPP:ns:DASH:MPD-ext:2011". An extension schema for 3GPP in the context of the specification is referred to as "3gpp-2011.xsd". Elements and attributes in the extension namespace are preceded with "x3gpp:" throughout this document.
The MPD shall be authored such that, after unrecognized XML attributes or elements are removed, the result is a valid XML document formatted according to the XML schema provided in Annex B and that complies with this specification. Namespaces may be used to extend functionalities. Therefore, all extended elements and attributes added to a Representation in particular shall be such that they can be safely ignored by 3GP-DASH clients.
NOTE 1: Based on this if DASH clients remove all XML attributes and elements from the MPD in the DASH namespace (urn:mpeg:dash:schema:mpd:2011) and in other namespaces that are not in the XML schema documented in Annex B, the MPD results in a valid XML document which complies with this specification. The DASH client can use such a resulting MPD for presentation of a conforming Media Presentation.
Example for valid MPDs are provided in Annex D.
Table 8-1: Overview of XML schema of the MPD
|
<?xml version="1.0"?> xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:x3gpp="urn:3GPP:ns:DASH:MPD-ext:2011" <xs:import namespace="http://www.w3.org/1999/xlink" schemaLocation="xlink.xsd"/> <xs:import namespace="urn:3GPP:ns:DASH:MPD-ext:2011" schemaLocation="3gpp-2011.xsd"/> <!– MPD: main element –> … </xs:schema> |
Table 8-2: Overview of XML schema for 3GPP MPD extensions
|
<?xml version="1.0"?> <xs:annotation> … </xs:schema> |
8.2.3 (void)
8.2.4 (void)
8.3 MPD Assembly
3GP-DASH inherits the ability from ISO/IEC 23009-1 [43] to enable to distribute an MPD not as a fully contained document, but to assemble the document by dereferencing certain links by using subset of W3C XLINK [20].
An MPD in 3GP DASH may reference a remote element entities from within a local MPD as defined in ISO/IEC 23009-1 [43], clause 5.5.
8.4 Hierarchical Data Model
8.4.1 General
A Media Presentation is described in the MPD element that is contained in an MPD document formatted as defined in clause 8.2.
A Media Presentation consists of:
– A sequence of one or more Periods described in 8.4.2.
– Each Period contains one or more Adaptation Sets that itself contains one or more Representations as described in clause 8.4.3. Clause 8.4.3 also defines media content components and Sub-Representations.
– Each Representation consists of one or more Segments. Segment Information is introduced in clause 8.4.4. Segments contain media data and/or metadata to access, decode and present the included media content.
Beyond the mandatory elements and attributes in ISO/IEC 23009-1 [43], the MPD element used in 3GP-DASH may contain the following attributes and elements:
– MPD@id
– MPD@type
– MPD@availabilityStartTime
– MPD@availabilityEndTime
– MPD@mediaPresentationDuration
– MPD@minimumUpdatePeriod
– MPD@timeShiftBufferDepth
– MPD@suggestedPresentationDelay
– MPD@maxSegmentDuration
– MPD@maxSubsegmentDuration
– MPD.ProgramInformation
– MPD.UTCTiming
– MPD.BaseURL
– MPD.x3gpp:DeltaSupport
– MPD.Location
– MPD.Metrics
Table 8-5: Void
Table 8-6: Void
8.4.2 Period
8.4.2.1 General
A Media Presentation consists of one or more Periods as defined in ISO/IEC 23009-1 [43], clause 5.3.2. A Period is defined by Period element in the MPD element.
Beyond the mandatory elements and attributes in ISO/IEC 23009-1 [43], the Period element used in 3GP-DASH may contain the following attributes and elements:
– Period@xlink:href
– Period@xlink:actuate
– Period@id
– Period@start
– Period@duration
– Period@bitstreamSwitching
– Period.BaseURL
– Period.SegmentBase
– Period.SegmentList
– Period.SegmentTemplate
– Period.AdaptationSet
– Period.EventStream
– Period.AssetIdentifier
Table 8-7: Void
Table 8-8: Void
8.4.2.2 Content Offering with Multiple Periods
Note: This text was adopted for Amd.3 of ISO/IEC 23009-1 [43], which is not yet published. It is expected that the below text will be replaced with a reference to ISO/IEC 23009-1 once Amd.3 is published.
Content with multiple Periods may be created for different reasons, for example:
– to enable splicing of content, for example for ad insertion,
– to provide a synchronization point to avoid drift in segment numbering,
– to remove or add certain Representations in an Adaptation Set,
– to remove or add certain Adaptation Sets,
– to add or remove content offering on certain CDNs,
– to enable signalling of shorter segments, if produced by the encoder
Periods provide opportunities for resync, for ad insertion, for adding and removing Representations, but if they are not used or only used for minor changes, then continuous playout of the client is expected.
In certain circumstances the Media Presentation author offers content in the next Period that is a continuation of the content in the previous Period, possibly in the immediately following Period or in a later Period. The latter case applies for example after an advertisement Period had been inserted. The content provider may provide period-continuous Adaptation Sets as follows:
– The Adaptation Set identifiers are the same across two Periods.
– The sum of the value of the @presentationTimeOffset and the presentation duration of all Representations in one Adaptation Set are identical to the value of the @presentationTimeOffset of the associated Adaptation Set in the next Period.
– If Representations in both Adaptation Sets have the same value for @id, then they sshould have functionally equivalent Initialization Segments, i.e. the Initialization Segment may be used to continue the play-out the Representation.
From a client perspective, at Period boundary typically no continuity in terms of content offering is ensured. The content may be offered with different codecs, language attributes, different protection and so on. 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 reinitialised, for example due to changes in formats, codecs or other properties. This may result in a re-initialisation delay. Such a re-initialisation delay should be minimized.
If the client presents media components of a certain Adaptation Set in one Period, and if the following Period has an identical Adaptation Set identifier, then the client is suggested to continue playing the content in the associated Adaptation Set.
8.4.3 Adaptation Sets and Representations
8.4.3.1 Overview
Periods are further subdivided as follows:
– Each Period contains one or more groups. Groups consist of Adaptation Sets as described in clause 8.4.3.3.
– In case an Adaptation Set contains multiple media content components, then each media content component is described individually as defined in clause 8.4.3.6.
– Each Adaptation Set contains one or more Representations as described in clause 8.4.3.4.
– A Representation may contain one or more Sub-Representations as described in clause 8.4.3.5.
– Adaptation Sets, Representations and Sub-Representations share common attributes and elements that are described in clause 8.4.3.2.
8.4.3.2 Common Attributes and Elements
The elements AdaptationSet, Representation and SubRepresentation have assigned common attributes and elements.
Beyond the mandatory elements and attributes in ISO/IEC 23009-1 [43], the following common attributes and elements may be used in 3GP-DASH:
– @profiles
– @width
– @height
– @frameRate
– @audioSamplingRate
– @mimeType
– @codecs
– @maximumSAPPeriod
– @startWithSAP
– @maxPlayoutRate
– @codingDependency
– FramePacking
– AudioChannelConfiguration
– ContentProtection
– EssentialProperty
– SupplementalProperty
– InbandEventStream
Table 8-9: Void
Table 8-10: Void
8.4.3.3 Adaptation Set
An Adaptation Set is described by an AdaptationSet element. AdaptationSet elements are contained in a Period element. An Adaptation Set contains alternate Representations, i.e. only one Representation within an Adaptation Set is expected to be presented at a time. All Representations contained in one Adaptation Set represent the same media content components and therefore contain media streams that are considered to be perceptually equivalent.
The Adaptation Set shall conform to the definition in ISO/IEC 23009-1 [43], clause 5.3.3.
Beyond the mandatory elements and attributes in ISO/IEC 23009-1 [43], the AdaptationSet element used in 3GP-DASH may contain the following attributes and elements:
– @xlink:href
– @xlink:actuate
– @id
– @group
– CommonAttributesElements
– @lang
– @contentType
– @minBandwidth
– @maxBandwidth
– @minWidth
– @maxWidth
– @minHeight
– @maxHeight
– @minFrameRate
– @maxFrameRate
– @segmentAlignment
– @bitStreamSwitching
– @subsegmentAlignment
– @subsegmentStartsWithSAP
– Accessibility
– Role
– Rating
– Viewpoint
– ContentComponent
– BaseURL
– SegmentBase
– SegmentList
– SegmentTemplate
– Representation
Table 8-11: Void
Table 8-12: Void
8.4.3.4 Representation
Representations are described by the Representation element. Representation elements are contained in an AdaptationSet element.
A Representation is one of the alternative choices of the complete set or subset of media content components comprising the media content during the defined Period.
A Representation shall conform to the definition in ISO/IEC 23009-1 [43], clause 5.3.4.
Beyond the mandatory elements and attributes in ISO/IEC 23009-1 [43], the Representation element used in 3GP-DASH may contain the following attributes and elements:
– Representation@qualityRanking
– Representation@mediaStreamStructureId
– Representation.CommonAttributesElements
– Representation.BaseURL
– Representation.SubRepresentation
– Representation.SegmentBase
– Representation.SegmentList
– Representation.SegmentTemplate
Table 8-13: Void
Table 8-14: Void
8.4.3.5 Sub-Representation
Sub-Representations are embedded in regular Representations and are described by the SubRepresentation element. SubRepresentation elements are contained in a Representation element.
The SubRepresentation element describes properties of one or several media content components that are embedded in the Representation. It may for example describe the exact properties of an embedded audio component (language, codec, etc.), an embedded sub-title (language) or it may describe some embedded lower quality video layer (e.g. some lower frame rate, etc.).
A Sub-Representation shall conform to the definition in ISO/IEC 23009-1 [43], clause 5.3.5.
Beyond the mandatory elements and attributes in ISO/IEC 23009-1 [43], the SubRepresentation element used in 3GP-DASH may contain the following attributes and elements:
– SubRepresentation@level
– SubRepresentation@dependencyLevel
– SubRepresentation@bandwidth
– SubRepresentation@contentComponent
– CommonAttributesElements
Table 8-15: Void
Table 8-16: Void
8.4.3.6 Content Component
Each Adaptation Set contains one or more media content components. The properties of each media content component are described by a ContentComponent element or may be described directly on the AdaptationSet element if only one media content component is present in the Adaptation Set. ContentComponent elements are contained in an AdaptationSet element.
A Content Component shall conform to the definition in ISO/IEC 23009-1 [43], clause 5.3.6.
Beyond the mandatory elements and attributes in ISO/IEC 23009-1 [43], the ContentComponent element used in 3GP-DASH may contain the following attributes and elements:
– ContentComponent@id
– ContentComponent@lang
– ContentComponent@contentType
– ContentComponent.Accessibility
– ContentComponent.Role
– ContentComponent.Rating
– ContentComponent.Viewpoint
Table 8-17: Void
Table 8-18: Void
8.4.4 Segments and Segment Information
A Segment is the smallest addressable unit described by an MPD and has a defined format. Segment formats are defined in section 9. This clause defines the MPD information for Segments.
Representations are assigned Segment Information through the presence of the elements BaseURL, SegmentBase, SegmentTemplate and/or SegmentList. The Segment Information provides information on the location, availability and properties of all Segments contained in one Representation. Specifically, information on the presence and location of Initialization, Media, Index and Bitstream Switching Segments is provided.
Segment Information shall be provided as defined in ISO/IEC 23009-1 [43], clause 5.3.9 using the elements BaseURL, SegmentBase, SegmentTemplate and/or SegmentList.
– The duration of Segments shall be described by the @duration attribute.
– If the SegmentTemplate is used, then only the following identifiers as defined in ISO/IEC 23009-1 [43], Table 16 may be used: $$, $RepresentationID$, $Number$, and $Bandwidth$. The identifier $Time$ shall not be used.
Table 8-19: Void
Table 8-20: Void
Table 8-21: Void
Table 8-22: Void
Table 8-23: Void
Table 8-24: Void
Table 8-25: Void
Table 8-26: Void
Table 8-27: Void
8.5 MPD Update
8.5.1 General
If the MPD@type is set to ‘dynamic’, the MPD may be updated during the Media Presentation. Updates typically extend the accessible Segment list for each Representation, introduce a new Period, update Segment locations or terminate the Media Presentation.The MPD update functionality in 3GP-DASH shall use the MPD update functionality in ISO/IEC 23009-1 [43], clause 5.4.
8.5.2 Media Presentation Description Delta
If the x3gpp:DeltaSupport element is present in the MPD element, the content provider indicates that MPD delta files, as defined in this clause, are supported on the server. The URI of the MPD delta is provided in x3gpp:DeltaSupport @sourceURL. The x3gpp:DeltaSupport @availabilityDuration element, if present, indicates that the MPD delta file referenced by the URI is available for at least the value of the @availabilityDuration attribute (after this time, the server may redirect the client to the full MPD). If x3gpp:DeltaSupport @availabilityDuration is not present, then no information is conveyed about the availability of the MPD delta. If a client request for an MPD delta file results in an error, the client should request a full MPD.
The semantics of the attributes within the x3gpp:DeltaSupport element are provided in Table 8-28. The XML-syntax of x3gpp:DeltaSupport element is provided in Table 8-29.
Table 8-28: Semantics of x3gpp:DeltaSupport element
|
Element or Attribute Name |
Use |
Description |
||
|
x3gpp:DeltaSupport |
If present, this element indicates that MPD delta files are supported by the server. |
|||
|
@sourceURL |
M |
The source string providing the URL of the MPD delta. The URL may be relative to any BaseURL on MPD level and reference resolution according to clause 8.2.3 shall be applied. |
||
|
@availabilityDuration |
O |
When provided, indicates the duration that the server guarantees the availability of the MPD delta file referenced in @sourceURL after the MPD has been updated. After that the client may be redirected to the full MPD. |
||
|
Legend: For attributes: M=Mandatory, O=Optional, OD=Optional with Default Value, CM=Conditionally Mandatory. For elements: <minOccurs>…<maxOccurs> (N=unbounded) Elements are bold; attributes are non-bold and preceded with an @. |
||||
Table 8-29: XML-Syntax of x3gpp:DeltaSupport element
|
<!–DeltaSupport for the MPD –> |
An MPD delta is a text file that shall include the delta between the MPD that references it and the latest provided MPD. Note that the value of @sourceURL in successive MPDs is necessarily different because it is impossible for the delta between two different MPDs and the most recent MPD to be the same.
The output format consists of one or more structures, each corresponding to a change. The changes are in decreasing line number order. The structure format looks like:
change-command
to-file-line
to-file-line…
.
There are three types of change commands change-command. Each consists of a line number or comma-separated range of lines in the first file and a single character indicating the kind of change to make. All line numbers are the original line numbers in the file. The types of change commands and the instructions are provided in Table 8-30.
Table 8-30: Change commands and the instructions for delta MPD files
|
Change command |
Instruction |
Example |
|
la |
Add text from the second file after line l in the first file. |
‘8a’ means to add the following lines after line 8 of file 1 |
|
rc |
Replace the lines in range r in the first file with the following lines. Like a combined add and delete, but more compact. |
‘5,7c’ means change lines 5–7 of file 1 to read as the text file 2. |
|
rd |
Delete the lines in range r from the first file. |
‘5,7d’ means delete lines 5–7 of file 1. |
|
NOTE: This is the format supported by the GNU diff utilities, see http://www.gnu.org/software/diffutils/manual/#Detailed-ed |
||
Regardless of the presence of a x3gpp:DeltaSupport element, the full MPD shall always be available to clients for regular MPD updates as defined in clause 8.5.1. MPD Delta related procedures are optional at the client.
8.6 Additional Media Presentation Information
8.6.1 Introduction
The MPD, Periods, Adaptation Sets, Representations and Sub-Representations may have assigned descriptors for describing the content or other elements in the MPD. This clause specifies this descriptive information.
8.6.2 Program Information
Descriptive information on the program may be provided for each period within the ProgramInformation element.
Program Information shall conform to the definition in ISO/IEC 23009-1 [43], clause 5.7.
Table 8-31: Void
Table 8-32: Void
8.6.3 Descriptors
The MPD may contain descriptors that are all in the same format as defined in this clause. The elements of type DescriptorType provide a flexible mechanism for DASH content authors to annotate and extend the MPD, Period, AdaptationSet and Representation elements.
Descriptors shall conform to the definition in ISO/IEC 23009-1 [43], clause 5.8.1.
The following descriptors may be used in 3GP-DASH:
– Content Protection as defined in ISO/IEC 23009-1 [43], clause 5.8.4.1
– Role as defined in ISO/IEC 23009-1 [43], clause 5.8.4.3. The DASH Role scheme as defined in ISO/IEC 23009-1 [43], clause 5.8.5.4 may be used.
– Rating as defined in ISO/IEC 23009-1 [43], clause 5.8.4.4
– ViewPoint as defined in ISO/IEC 23009-1 [43], clause 5.8.4.5
– Accessibility as defined in ISO/IEC 23009-1 [43], clause 5.8.4.2
– Audio Channel Configuration as defined in ISO/IEC 23009-1 [43], clause 5.8.4.7
– Frame Packing as defined in ISO/IEC 23009-1 [43], clause 5.8.4.6
– Essential Property as defined in ISO/IEC 23009-1 [43], clause 5.8.4.8
– Supplemental Property as defined in ISO/IEC 23009-1 [43], clause 5.8.4.9
– UTC Timing Descriptor as defined in ISO/IEC 23009-1 [43], clause 5.8.4.10. The DASH UTC Timing Schemes as defined in ISO/IEC 23009-1 [43], clause 5.8.5.10 may be used.
Table 8-33: Void
Table 8-34: Void
8.7 Base URL Processing
The BaseURL element may be used to specify one or more common locations for Segments and other resources. Base URL Processing shall conform to ISO/IEC 23009-1 [43], clause 5.6.
Table 8-35: Void
Table 8-36: Void
8.8 Event Streams
Events may be signalled in the MPD or within a Representation in order to signal aperiodic information to the DASH client or to an application. Events are timed, i.e. each event starts at a specific media presentation time and typically has a duration. Events may include DASH specific signalling or application-specific events. In the latter case, a proper scheme identifier identifies the application such that the DASH client can forward the event to the proper application.
Events of the same type are clustered in Event Streams. This enables a DASH client to subscribe to an Event Stream of interest and ignore Event Streams that are of no relevance or interest.
Two ways of signalling events are provided, namely
– events signalled in the MPD as defined in 5.10.2 of ISO/IEC 23009-1[34]. Event streams for MPD events are signaled by Period.EventStream element.
– events signalled inband in the Representation as defined in 5.10.3 of ISO/IEC 23009-1 [34]. Inband event streams are signaled by the element InbandEventStream for a specific Representation or all Representatons in an Adaptation Set.
This specification does not provide any specific information on how to use Event Streams. It is up to the application that employs DASH formats to instantiate the description elements with appropriate scheme information.
If the DASH client is interested in a specific event stream, it is expected to properly extract each event from an event stream and pass it to the application.