7 3GPP Dynamic Adaptive Streaming over HTTP

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

7.1 System Description

The 3GPP Dynamic Adaptive Streaming over HTTP (3GP-DASH) specified in this specification provides streaming services over HTTP. 3GP-DASH is a set of profiles of ISO/IEC 23009-1 [43], also known as MPEG-DASH, with some extensions. For this it specifies XML and binary formats that enable delivering content from standard HTTP servers to an HTTP-Streaming client and enables caching content by standard HTTP caches.

The specification for 3GP-DASH primarily defines two formats:

1) 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. For 3GP-DASH, the resource identifiers are exclusively HTTP-URLs possibly combined with a byte range.

2) The Segment formats specify the formats of the entity body of the HTTP response to an HTTP GET request or an HTTP partial GET request with the indicated byte range through HTTP/1.1 as defined in RFC 2616 [9] to a resource identified in the MPD. Segments typically contain efficiently coded media data and metadata according to or aligned with common media formats.

The MPD provides sufficient information for a client to provide a streaming service to the user by accessing the Segments through the protocol specified in the scheme of the defined resources, in the context of this specification exclusively HTTP/1.1. Such a client is referred to as a 3GP-DASH client in the remainder of the present document. However, this specification does not provide a normative definition for such a client. An informative client model to illustrate the formats defined in this specification is provided in section 7.2. An informative example client behaviour description is provided in Annex A of ISO/IEC 23009-1 [43].

Figure 7-1 shows an architecture in which the formats defined in this specification are typically used. Boxes with solid lines indicate devices that are mentioned in this specification as they host or process the formats defined in this specification whereas dashed boxes are conceptual or transparent. This specification deals with the definition of formats that are accessible on the interface to the 3GP-DASH client, indicated by the solid lines. Any other formats or interfaces are not in scope of this specification. In the considered deployment scenario, it is assumed that the 3GP-DASH client has access to an MPD. The MPD provides sufficient information for the 3GP-DASH client to provide a streaming service to the user by requesting Segments from an HTTP server and demultiplexing, decoding and rendering the included media streams.

Figure 7-1: System Architecture for 3GP-DASH

The normative aspects of 3GP-DASH formats are defined by

– the profiles defined in clause 7.3.

– the DASH Media Presentation as defined in clause 8.

– the usage of the 3GPP file format for DASH as defined in clause 9.

The clauses mentioned above may refer to normative aspects in clause 10 on Quality-of-Experience, normative Annexes B and H as well as ISO/IEC 23009-1 [43].

7.2 3GP-DASH Client Model

The design of the formats defined in this specification is based on the informative client model as shown in Figure 7-2. The figure illustrates the logical components of a conceptual 3GP-DASH client model. In this figure the 3GP-DASH Access Engine receives the Media Presentation Description (MPD), constructs and issues requests and receives Segments or parts of Segments. In the context of this standard, the output of the DASH Access Engine consists of media in container formats according to the ISO/IEC 14496-12 ISO Base Media File Format [11] and specifically the 3GP file format [4]. In addition, timing information is provided that maps the internal timing of the media to the time line of the Media Presentation.

Figure 7-2: 3GP-DASH client Model

7.3 3GP-DASH Profiles

7.3.1 General

Profiles of 3GP-DASH are defined so as to enable interoperability and the signaling of the use of features etc. A profile refers to a set of specific restrictions. Those restrictions might be on features of the MPD as defined in clause 8 of this specification, Segment formats as for example defined in clause 9 of this specification, usage of the network, codec(s) used, content protection formats, or on quantitative measures such as bit-rates, segment lengths, screen size, and so on. Profiles defined in this specification define restrictions on features of this specification, but may additionally impose restrictions on other aspects of media delivery.

NOTE A profile can also be understood as permission for 3GP-DASH clients that only implement the features required by the profile to process the Media Presentation. However, as 3GP-DASH client operation is not specified normatively, it is also unspecified how a 3GP-DASH client conforms to a particular profile. Hence, profiles merely specify restrictions on MPD and Segments rather than DASH client behaviour.

For details on the use of profiles, refer to ISO/IEC 23009-1 [43], section 8.1.

7.3.2 3GPP Adaptive HTTP Streaming (Release-9 AHS)

Release-9 Adaptive HTTP Streaming as defined in TS 26.234 [3] Release-9, clause 12 is not a profile of this specification. Rel-9 AHS uses a different namespace "urn:3GPP:ns:PSS:AdaptiveHTTPStreamingMPD:2009" and a different MIME type signalling "application/3gpp-ahs+xml" for the MPD. However, a Media Presentation may be defined such that segments complying with the segment formats in TS 26.234 [3] Release-9, clause 12, also comply with segment formats for this specification.

7.3.3 3GP-DASH Release-10 Profile

7.3.3.1 Introduction

The 3GP-DASH Release-10 profile is identified by the URN "urn:3GPP:PSS:profile:DASH10".

This profile includes all features defined in the Release-10 version of this specification in clauses 7.3.6 (media codecs), 7.3.7 (content protection), 8 (Media Presentation Description), 9 (File Format) and 10 (QoE).The @mimeType attribute of each Representation shall be provided according to RFC4337. Additional parameters may be added according to RFC6381 [26].

7.3.4 3GP-DASH Release 11 multiview stereoscopic 3D video profile

The 3GP-DASH Release 11 multiview stereoscopic 3D video profile is identified by the URN "urn:3GPP:PSS:profile:DASH11:MS3D".

The @mimeType attribute of each Representation shall be provided according to RFC4337. Additional parameters may be added according to RFC6381 [26].

This profile includes all features defined in clauses 7.3.7, 8, 9 and 10.

Clients that support 3GP-DASH Release 11 multiview stereoscopic 3D video profile shall support multiview stereoscopic 3D video as specified in clause 7.4 of TS 26.234 [3]. For any other particular continuous media type, the corresponding media decoders are specified in TS 26.234 [3], clause 7.2 for speech, 7.3 for audio, 7.4 for video, 7.9 for timed text and 7.11 for timed graphics. Additionally, the following contraints apply for multiview stereoscopic 3D video bitstreams, if present in a media presentation:

The DASH multiple views scheme as defined in 5.8.5.6 of ISO/IEC 23009-1 [43] shall be used in the MPD.

One of the following shall be true:

– The base view of the stereoscopic multiview bitstream shall be a complementary representation and the non-base view of the bitstream shall be a dependent representation. The @dependencyId attribute as specified in 5.3.5.2 of ISO/IEC 23009-1 [43] shall be used to indicate the complementary and dependent representations.

– The base view and the non-base view of the stereoscopic multiview bitstream shall reside in the same representation. The SubRepresentation element shall be used for the representation, and the base view and the non-base view shall form separate sub-representations. The @level and @dependencyLevel attributes within the SubRepresentation element shall be used. The Level Assignment box shall be used. For each leaf segment index, that is, each Segment Index box that indexes only subsegments but not other Segment index boxes, there shall be exactly one Subsegment Index box.

7.3.5 3GP-DASH Release 11 frame-packed stereoscopic 3D video profile

The 3GP-DASH Release 11 frame-packed stereoscopic 3D video profile is identified by the URN "urn:3GPP:PSS:profile:DASH11:FPS3D".

The @mimeType attribute of each Representation shall be provided according to RFC4337. Additional parameters may be added according to RFC6381 [26].

This profile includes all features defined in clauses 7.3.7, 8, 9 and 10.

Clients that support 3GP-DASH Release 11 frame-packed stereoscopic 3D video profile shall support frame-packed stereoscopic 3D video as specified in clause 7.4 of TS 26.234 [3]. For any other particular continuous media type, the corresponding media decoders are specified in TS 26.234 [3], clause 7.2 for speech, 7.3 for audio, 7.4 for video, 7.9 for timed text and 7.11 for timed graphics. Additionally, the following contraints apply for frame-packed stereoscopic 3D video bitstreams, if present in a media presentation:

The FramePacking element as defined in clause 8.4.3.2 shall be used in the MPD.

7.3.6 Media Codecs

For 3GP-DASH clients supporting a particular continuous media type, media decoders are specified in TS 26.234 [3], clause 7.2 for speech, 7.3 for audio, 7.4 for video, 7.9 for timed text and 7.11 for timed graphics.

NOTE: If 3GP-DASH formatted content is delivered outside the scope of this specification, additional constraints may apply on which media codecs can be used. For example, TS26.346 [42] defines further restrictions when delivered over MBMS.

7.3.7 Content Protection

3GP-DASH clients content protection may support OMA DRM 2.0 [15] or OMA DRM 2.1 [16]. Other content protection schemes may be supported. The ContentProtection element in the MPD should be used to convey content protection information.

When using OMA DRM V2.0 or OMA DRM V2.1 scheme for content protection, the non-streamable Packetized DRM Content Format (PDCF) shall be used. An OMA-DRM encrypted Representation shall include the brand "opf2". OMA-DRM [15] [16] defines the procedures for acquiring the Rights Object from the Rights Issuer to decrypt PDCF protected content. The scheme is identified by a ContentProtection@schemeIdUri set to "urn:mpeg:dash:mp4protection" and the ContentProtection@value shall include the version number; it starts with "odkm", which is the scheme_type contained in the Scheme Type Box of the PDCF file, followed by a ":" and the scheme_version from the Scheme Type Box of the PDCF file, encoded as up to 8 hexadecimal digits, where the leading ‘0’s may be omitted. For example, for OMA DRM2.0 the value could be "odkm:200".

7.3.8 Partial File Handling

3GP-DASH clients should support partial-file-accept requests and partial file responses as defined in clause 5.3.2. If 3GP-DASH clients support partial file handling they shall use partial-file-accept requests as defined in TS26.346 [42], clause 7.9.2.1.

Without excluding other response options, as a response to a partial-file-accept request using a regular HTTP GET request a 3GP-DASH client may typically receive one of the following responses:

1) 200 OK with Content-Type set to the Media Type of the requested object

2) 200 OK with the Content-Type set to application/3gpp-partial and the message format according to the definition in clause 7.9.2.2 of TS26.346 [42].

3) 416 Requested Range Not Satisfiable with the additional information according to the definition in clause 7.9.2.2 of TS26.346 [42].

4) 404 Not Found

If the 3GP-DASH server supports the handling of partial files, then it should implement the HTTP response format as defined in TS 26.346 [42], clause 7.9.2.2. Consequently, a 3GP-DASH client may receive a response indicating 404 Not Found along with the Content-Type header set to ‘application/3gpp-partial’ as indication of partial file availability at the server.

Case 1 is the regular response.

Guidelines for handling request responses according to case 4 from above are provided in Annex A.7.

Guidelines for handling request responses 2 and 3 from above are provided in Annex A.9.

7.3.9 3GP-DASH Enhanced Interoperability Point

The 3GP-DASH Enhanced interoperability point (IOP) is identified by the URN "urn:3GPP:PSS:iop:DASH-enhanced".

This interoperability point includes all features defined in the Release-13 version of this specification in clauses 7.3.6 (media codecs), 7.3.7 (content protection), 8 (Media Presentation Description), 9 (File Format), 10 (QoE), 11 (simple live) and 12 (ad insertion).

A DASH client conforms to the IOP by supporting at least the following features:

– All DASH-related features as defined in clause.8 of this document.

– The file format related aspects defined in clause 9 of this document.

– The QoE related aspects defined in clause 10 of this document.

– The requirements and guidelines in clause 11 for simple live operation.

– The requirements and guidelines in clause 12 for server-based ad insertion.

– The following additional requirements:

– Segment formats are based on ISO BMFF with fragmented movie files, i.e. (Sub)Segments are encoded as movie fragments containing a track fragment as defined in ISO/IEC 14496-12, plus the following constraints to make each movie fragment independently decodable:

– Default parameters and flags shall be stored in movie fragments (‘tfhd’ or ‘trun’ box) and not track headers (‘trex’ box)

– The ‘moof’ boxes shall not use external data references, the flag ‘default-base-is-moof’ shall also be set (aka movie-fragment relative addressing) and data-offset shall be used, i.e. base-data-offset-present shall not be used (follows ISO/IEC 23009-1).

– Withing each Adaptation Set the following applies

– Fragmented movie files are used for encapsulation of media data

– (Sub)Segments are aligned to enable seamless switching

– The following additional restrictions are applied.

– IDR-like SAPs (i.e., SAPs type 2 or below) at the start of each (Sub)Segment for simple switching.

– Segments should have almost equal duration.

– only non-multiplexed Representations should be used, i.e. each Representation only contains a single media component.

– Addressing schemes are restricted to

– templates with number-based addressing

– Subsegments with Segment Index. In this case either the @indexRange attribute shall be present or the RepresentationIndex element shall be present. Only a single sidx box shall be present.

– For DRM purposes, suitable DRM may be used together with common encryption as defined in ISO/IEC 23001-7 [47]. If used, only the AES-128 CTR mode shall be used. No specific requirements on a specific DRM system are added.

Content shall only be authored claiming conformance to this IOP if such a client can properly play the content. In addition, the content shall follow the mandatory aspects and should take into account the recommendations and guidelines for content authoring documented in clauses 7.3.6 (media codecs), 7.3.7 (content protection), 8 (Media Presentation Description), 9 (File Format), 10 (QoE), 11 (simple live) and 12 (ad insertion).

The @mimeType attribute of each Representation shall be provided according to RFC4337. Additional parameters may be added according to RFC6381 [26].

7.3.10 DASH in TeleVision (TV) over 3GPP Services

If used for TeleVision (TV) over 3GPP Services, 3GP-DASH clients shall support the DASH features defined in clause 5 of TS 26.116 [58].

7.3.11 5G Media Streaming DASH Interoperability Point

If DASH [43] is used in 5G Media Streaming as defined in TS 26.501 [64] and TS 26.512 [66], then the 5GMSd AS takes the role of a DASH Server and the Media Player in the 5GMSd Client takes the role of a DASH Client. A detailed definition of the Media Player is provided in TS 26.512 [66] separating the DASH Access Client and a CMAF-based playback platform.

This clause defines a 5G Media Streaming DASH Interoperability Point for the DASH Access Client, in particular the processing requirements for the MPD and Segment formats. An interoperability point following the requirements in this clause is identified by the URN "urn:3GPP:5GMS:iop:DASH". This profile is targeted to support the playback of segmented media content according to CMAF as defined in ISO/IEC 23000-19 [66].

The requirements for playback of codecs and formats for a 5GMSd Client are documented in TS 26.511 [12].

The Media Presentation shall conform to a DASH profile for CMAF Content as defined in ISO/IEC 23009-1 [43] with the following additional restrictions and extensions:

– Exactly one of the following Segment and Subsegment Information Modes shall be used within one Subset of one Period:

– The SegmentTemplate element with @media containing a $Number$ template and @duration is present.

– The SegmentTemplate element with @media containing a $Number$ template and SegmentTimeline is present.

– The SegmentTemplate element with @media containing a $Time$ template and SegmentTimeline is present.

– The SegmentBase element with the Segment Index signalling is present.

The following extensions may apply for the 5G Media Streaming DASH Interoperability Point:

– The DASH Media Presentation may conform to DASH-IF low latency Media Presentation with the @profiles parameter set to ‘http://www.dashif.org/guidelines/low-latency-live-v5’ as defined in DASH-IF IOP Low-Latency Modes [68].

– The DASH Media Presentation may contain one or several ServiceDescription elements.

– The DASH Media Presentation may contain one or several Subset elements. If the value of the @id of the Subset is identical to the value of the @id of the ServiceDescription element, then this Subset defines a restriction of Adaptation Sets being available for playback in case this Service Description is selected.

The DASH Access Client shall support playback and handling of Media Presentations conforming to the 5G Media Streaming DASH Interoperability Point as defined in this clause. Specifically, this includes support for:

– The playback of CMAF Content and the DASH profiles for CMAF Content as defined in ISO/IEC 23009-1 [43] with the restrictions of Segment and Subsegment Information modes as documented above.

– The requirements of a Low-Latency client as defined in DASH-IF IOP Low-Latency Modes [68].