Guidelines for Implementation: DASH-AVC/264 Interoperability Points
August 15, 2013
DASH Industry Forum
Version 2.0
Note: This document is no specification.
1 Scope
2 The scope of the interoperability points defined in this document is to provide basic support for 3 high-quality video distribution over the top. Both live and on-demand services are supported. Ex- 4 tensions for improved audio-visual experience are defined. 5 6 7 8 9 10
DASH-AVC/264 V2.0
1 Disclaimer
2 This is a document made available by DASH-IF. The technology embodied in this docu- 3 ment may involve the use of intellectual property rights, including patents and patent ap- 4 plications owned or controlled by any of the authors or developers of this document. No 5 patent license, either implied or express, is granted to you by this document. DASH-IF has 6 made no search or investigation for such rights and DASH-IF disclaims any duty to do so. 7 The rights and obligations which apply to DASH-IF documents, as such rights and obliga- 8 tions are set forth and defined in the DASH-IF Bylaws and IPR Policy including, but not 9 limited to, patent and other intellectual property license rights and obligations. A copy of 10 the DASH-IF Bylaws and IPR Policy can be obtained at http://dashif.org/. 11 The material contained herein is provided on an "AS IS" basis and to the maximum extent 12 permitted by applicable law, this material is provided AS IS, and the authors and develop- 13 ers of this material and DASH-IF hereby disclaim all other warranties and conditions, either 14 express, implied or statutory, including, but not limited to, any (if any) implied warranties, 15 duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or 16 completeness of responses, of workmanlike effort, and of lack of negligence.
17 In addition, this document may include references to documents and/or technologies controlled 18 by third parties. Those third party documents and technologies may be subject to third party rules 19 and licensing terms. No intellectual property license, either implied or express, to any third party 20 material is granted to you by this document or DASH-IF. DASH-IF makes no any warranty what- 21 soever for such third party material.
DASH-AVC/264 V2.0 2
1 Contents
2 GUIDELINES FOR IMPLEMENTATION: DASH-AVC/264 INTEROPERABILITY POINTS ...... I 3 1. INTRODUCTION ...... 7 4 2. DEFINITION AND USAGE OF INTEROPERABILITY POINTS ...... 8 5 2.1. PROFILE DEFINITION IN ISO/IEC 23009-1 ...... 8 6 2.2. USAGE OF PROFILES ...... 9 7 2.3. INTEROPERABILITY POINTS AND EXTENSIONS ...... 10 8 3. DASH-RELATED ASPECTS ...... 10 9 3.1. SCOPE ...... 10 10 3.2. DASH FEATURES ...... 10 11 3.2.1. Introduction ...... 10 12 3.2.2. Media Presentation Description constraints ...... 12 13 3.2.3. Segment format constraints ...... 14 14 3.2.4. Presence of Attributes and Elements ...... 14 15 3.2.5. Dimension Constraints ...... 15 16 3.2.6. Generic Metadata ...... 15 17 3.3. CLIENT IMPLEMENTATION GUIDELINES ...... 15 18 3.4. TRANSPORT-RELATED ISSUES ...... 17 19 3.4.1. General ...... 17 20 3.4.2. Synchronization Considerations ...... 17 21 3.5. CONSIDERATIONS FOR LIVE SERVICES ...... 17 22 4. MEDIA CODING TECHNOLOGIES ...... 18 23 4.1. INTRODUCTION ...... 18 24 4.2. VIDEO ...... 18 25 4.2.1. General ...... 18 26 4.2.2. DASH-specific aspects for H.264/AVC video ...... 19 27 4.2.3. Video Metadata ...... 20 28 4.3. AUDIO ...... 20 29 4.3.1. General ...... 20 30 4.3.2. DASH-specific aspects for HE-AACv2 audio ...... 21 31 4.3.3. Audio Metadata ...... 22 32 4.4. AUXILIARY COMPONENTS ...... 22 33 4.4.1. Introduction ...... 22 34 4.4.2. Basic Subtitles and Closed Captioning ...... 22 35 4.4.3. DASH-specific aspects of Auxiliary components ...... 22 36 5. DRM-RELATED ASPECTS ...... 23 37 5.1. INTRODUCTION ...... 23 38 5.2. BASE TECHNOLOGIES ...... 24 39 5.3. WORKFLOW OVERVIEW ...... 24 40 5.4. INTEGRATION AND MAPPING TO DASH ...... 26 41 5.4.1. MP4 Structure Overview ...... 26 42 5.4.2. Box Hierarchy ...... 26
DASH-AVC/264 V2.0 3
1 5.5. DRM ASPECTS FOR DASH-AVC/264...... 27 2 5.5.1. General ...... 27 3 5.5.2. pssh and tenc Parameters in Movie or Movie Fragment Box ...... 27 4 5.5.3. Use of Content Protection Descriptor ...... 27 5 5.6. KEY ROTATION ...... 28 6 5.6.1. Introduction ...... 28 7 5.6.2. Encryption of Different Representations ...... 29 8 5.7. ADDITIONAL CONTENT PROTECTION REQUIREMENTS ...... 29 9 5.8. SIGNALING ...... 29 10 5.9. COMMON ENCRYPTION TEST DRM ...... 30 11 5.9.1. Introduction ...... 30 12 5.9.2. Test of Common Encryption ...... 30 13 5.9.3. ContentProtection descriptor ...... 30 14 5.9.4. Test Scenarios ...... 31 15 6. INTEROPERABILITY POINT DASH-AVC/264 ...... 33 16 6.1. INTRODUCTION ...... 33 17 6.2. SUPPORTERS ...... 33 18 6.3. DEFINITION ...... 33 19 7. INTEROPERABILITY POINT DASH-AVC/264 SD ...... 34 20 7.1. INTRODUCTION ...... 34 21 7.2. SUPPORTERS ...... 34 22 7.3. DEFINITION ...... 34 23 8. INTEROPERABILITY POINT DASH-AVC/264 HD ...... 34 24 8.1. INTRODUCTION ...... 34 25 8.2. SUPPORTERS ...... 34 26 8.3. DEFINITION ...... 35 27 9. MULTI-CHANNEL AUDIO EXTENSION ...... 35 28 9.1. SCOPE ...... 35 29 9.2. TECHNOLOGIES ...... 35 30 9.2.1. Dolby Multichannel Technologies ...... 35 31 9.2.2. DTS-HD ...... 36 32 9.2.3. MPEG Surround ...... 36 33 9.2.4. MPEG-4 High Efficiency AAC Profile v2, level 6 ...... 37 34 9.3. CLIENT IMPLEMENTATION GUIDELINES ...... 38 35 9.4. EXTENSIONS ...... 38 36 9.4.1. General ...... 38 37 9.4.2. Dolby Extensions ...... 39 38 9.4.3. DTS-HD Interoperability Points ...... 40 39 9.4.4. MPEG Surround Interoperability Points ...... 41 40 9.4.5. MPEG HE-AAC Multichannel Interoperability Points ...... 41 41 10. REFERENCES ...... 42 42 11. ANNEX A: EXAMPLES FOR PROFILE SIGNALLING ...... 44 43 11.1. EXAMPLE 1 ...... 44 44 11.2. EXAMPLE 2 ...... 44
DASH-AVC/264 V2.0 4
1 12. DOCUMENT HISTORY ...... 45 2
3 List of Figures
4 Figure 1 DASH aspects of a DASH-AVC/264 v1 client compared to a client supporting the union 5 of DASH ISO BMFF live and on-demand profile...... 16 6 Figure 2 Workflow with pssh information in the Initialization Segment...... 25
7 List of Tables
8 Table 1 Interoperability Points and Extensions defined in this document...... 7 9 Table 2 H.264 (AVC) Codecs parameter according to RFC6381 [8] ...... 19 10 Table 3 HE-AACv2 Codecs parameter according to RFC6381 [8]...... 21 11 Table 4 Subtitle Codecs parameter according to RFC6381 [8] ...... 23 12 Table 5 Boxes relevant for DRM systems ...... 26 13 Table 6 Dolby Technologies: Codec Parameters and ISO BMFF encapsulation ...... 36 14 Table 7: DTS Codec Parameters and ISO BMFF encapsulation ...... 36 15 Table 8 Codecs parameter according to RFC6381 [8] and ISO BMFF encapsulation for MPEG 16 Surround codec ...... 37 17 Table 9 Codecs parameter according to RFC6381 [8] and ISO BMFF encapsulation ...... 38
18
19 Acronyms, abbreviations and definitions
20 For acronyms, abbreviations and definitions refer to ISO/IEC 23009-1 [1]. 21 In addition, the following abbreviations and acronyms are used in this document: 22 AAC Advanced Audio Coding 23 AVC Advanced Video Coding 24 DRM Digital Rights Management 25 DTV Digital Television 26 FCC Federal Communications Commission 27 GOP Group-of-Pictures 28 HD High-Definition
DASH-AVC/264 V2.0 5
1 HDMI High-Definition Multimedia Interface 2 KID common Key IDentifier 3 IDR Instantaneous Decoder Refresh 4 PCM Pulse Code Modulation 5 PPS Picture Parameter Set 6 PS Parametric Stereo 7 SBR Spectral Band Replication 8 SD Standard Definition 9 SMPTE Society of Motion Picture and Television Engineers 10 SPS Sequence Parameter Set 11 TT Timed Text 12 TTML Timed Text Markup Language
DASH-AVC/264 V2.0 6
1
2 1. Introduction 3 The scope of the initial DASH-AVC/264 interoperability point is the basic support high-quality 4 video distribution over the top. Both live and on-demand services are supported. It is expected that 5 the client supports at least 6 presentation of progressive high-definition video up to 720p (based on H.264/AVC [5][6] 7 Progressive High Profile), 8 presentation of stereo audio (based on HE-AAC v2 Profile [9]), 9 support of basic subtitles (based on ISO/IEC 14496-30 [20]), 10 basic support for encryption/DRM (based on ISO/IEC 23001-7 [21]). 11 In addition, it is recognized that certain clients may only be capable to operate with H.264/AVC 12 Main Profile. Therefore content authors may provide and signal a specific subset of DASH- 13 AVC/264 by providing a dedicated interoperability identifier referring to a standard definition 14 presentation. This interoperability point is defined as DASH-AVC/264 SD. 15 In addition, one extension for HD video (up to 1080p) and several multichannel audio extensions 16 are defined. 17 Test cases and test vectors for DASH-AVC/264 Interoperability Points are defined in [23]. The 18 conformance and reference software for DASH-AVC/264 Interoperability Points is defined in [24] 19 (based on the MPEG conformance software [2]).This version of the document defines the follow- 20 ing Interoperability Points. The version in which each Interoperability Point was added is also 21 provided in Table 1. 22 Table 1 Interoperability Points and Extensions defined in this document
Interoperability Point or Identifier Version Section Extension
DASH-AVC/264 http://dashif.org/guidelines/dash264 1.0 6.3
DASH-AVC/264 SD http://dashif.org/guidelines/dash264#sd 1.0 7.3
DASH-AVC/264 HD http://dashif.org/guidelines/dash264#hd 2.0 8.3
DASH-IF multichannel http://dashif.org/guidelines/dashif#ec-3 2.0 9.4.2.3 audio extension with En- hanced AC-3
DASH-IF multichannel http://dashif.org/guidelines/dashif#mlpa 2.0 9.4.2.3 extension with Dolby TrueHD
DASH-AVC/264 V2.0 7
DASH-IF multichannel http://dashif.org/guidelines/dashif#dtsc 2.0 9.4.3.3 audio extension with DTS Digital Surround
DASH-IF multichannel http://dashif.org/guidelines/dashif#dtsh 2.0 9.4.3.3 audio extension with DTS-HD High Resolu- tion and DTS-HD Mas- ter Audio
DASH-IF multichannel http://dashif.org/guidelines/dashif#dtse 2.0 9.4.3.3 audio extension with DTS Express
DASH-IF multichannel http://dashif.org/guidelines/dashif#dtsl 2.0 9.4.3.3 extension with DTS-HD Lossless (no core)
DASH-IF multichannel http://dashif.org/guidelines/dashif#mps 2.0 9.4.4.3 audio extension with MPEG Surround
DASH-IF multichannel http://dashif.org/guide- 2.0 9.4.5.3 audio extension with lines/dashif#heaac-mc51 HE-AACv2 level 4
DASH-IF multichannel http://dashif.org/guide- 2.0 9.4.5.3 audio extension with lines/dashif#heaac-mc71 HE-AACv2 level 6
1 2 Beyond these initial IOPs and extensions, it is expected that additional IOPs and extensions will 3 be defined in future versions of this document.
4 2. Definition and Usage of Interoperability Points 5 2.1. Profile Definition in ISO/IEC 23009-1 6 MPEG DASH defines formats for MPDs and segments. In addition MPEG provides the ability to 7 further restrict the applied formats by the definition of Profiles as defined on section 8 of ISO/IEC 8 23009-1 [1]. Profiles of DASH are defined to enable interoperability and the signaling of the use 9 of features. 10 Such a profile can also be understood as permission for DASH clients that implement the features 11 required by the profile to process the Media Presentation (MPD document and Segments). 12 Furthermore, ISO/IEC 23009-1 permits external organizations or individuals to define restrictions, 13 permissions and extensions by using this profile mechanism. It is recommended that such external 14 definitions be not referred to as profiles, but as Interoperability Points. Such an interoperability 15 point may be signalled in the @profiles parameter once a URI is defined. The owner of the
DASH-AVC/264 V2.0 8
1 URI is responsible to provide sufficient semantics on the restrictions and permission of this in- 2 teroperability point. 3 This document makes use of this feature and provides a set of Interoperability Points. Therefore, 4 based on the interoperability point definition, this document may be understood in two ways: 5 a collection of content conforming points, i.e. as long as the content conforms to the re- 6 strictions as specified by the IOP, clients implementing the features can consume the con- 7 tent. 8 a client capability points that enable content and service providers for flexible service pro- 9 visioning to clients conforming to these client capabilities. 10 2.2. Usage of Profiles 11 A Media Presentation may conform to one or multiple profiles/interoperability points and con- 12 forms to each of the profiles indicated in the MPD@profiles attribute is specified as follows: 13 When ProfA is included in the MPD@profiles attribute, the MPD is modified into a profile- 14 specific MPD for profile conformance checking using the following ordered steps: 15 1. The MPD@profiles attribute of the profile-specific MPD contains only ProfA. 16 2. An AdaptationSet element for which @profiles does not or is not inferred to in- 17 clude ProfA is removed from the profile-specific MPD. 18 3. A Representation element for which @profiles does not or is not inferred to include 19 ProfA is removed from the profile-specific MPD. 20 4. All elements or attributes that are either (i) in this Part of ISO/IEC 23009 and explicitly 21 excluded by ProfA, or (ii) in an extension namespace and not explicitly included by 22 ProfA, are removed from the profile-specific MPD. 23 5. All elements and attributes that “may be ignored” according to the specification of ProfA 24 are removed from the profile-specific MPD. 25 An MPD is conforming to profile ProfA when it satisfies the following: 26 1. ProfA is included in the MPD@profiles attribute. 27 2. The profile-specific MPD for ProfA conforms to ISO/IEC 23009-1 28 3. The profile-specific MPD for ProfA conforms to the restrictions specified for ProfA. 29 A Media Presentation is conforming to profile ProfA when it satisfies the following: 30 1. The MPD of the Media Presentation is conforming to profile ProfA as specified above. 31 2. There is at least one Representation in each Period in the profile-specific MPD for ProfA. 32 3. The Segments of the Representations of the profile-specific MPD for ProfA conform to 33 the restrictions specified for ProfA.
DASH-AVC/264 V2.0 9
1 2.3. Interoperability Points and Extensions 2 This document defines Interoperability Points and Extensions. Both concepts make use of the pro- 3 file functionality of ISO/IEC 23009-1. 4 Interoperability Points provide a basic collection of tools and features to ensure that content/service 5 providers and client vendors can rely to support a sufficiently good audio-visual experience. Ex- 6 tensions enable content/service providers and client vendors to enhance the audio-visual experi- 7 ence provided by an Interoperability Point in a conforming manner. 8 The only difference between Interoperability Points and Extensions is that Interoperability Points 9 define a full audio-visual experience and Extensions enhance the audio-visual experience in typi- 10 cally only one dimension. 11 Examples for the usage of the @profiles signaling are provided in Annex A of this document.
12 3. DASH-Related Aspects 13 3.1. Scope 14 DASH-AVC/264 is uses ISO base media file format based encapsulation and has significant com- 15 monality with a superset of the ISO BMFF On-Demand and the ISO BMFF Live profile as defined 16 in ISO/IEC 23009-1 [1], sections 8.3 and 8.4, respectively. DASH-AVC/264 is intended to provide 17 basic support for on-demand and live content. The primary constraints imposed by this profile are 18 the requirement that each Representation is provided in one of the following two ways 19 as a single Segment, where Subsegments are aligned across Representations within an Ad- 20 aptation Set. This permits scalable and efficient use of HTTP servers and simplifies seam- 21 less switching. This is mainly for on-demand use cases. 22 as a sequence of Segments where each Segment is addressable by a template-generated 23 URL. Content generated in this way is mainly suitable for dynamic and live services. 24 In both cases (Sub)Segments must begin with Stream Access Points (SAPs) of type 1 or 2, i.e. 25 regular IDR frames in case of video. In addition, (Sub)Segments are constrained so that for switch- 26 ing video Representations within one Adaptation Set the boundaries are aligned without gaps or 27 overlaps in the media data. Furthermore, switching is possible by a DASH client that downloads, 28 decodes and presents the media stream of the come-from Representation and then switches to the 29 go-to Representation by downloading, decoding and presenting the new media stream. No overlap 30 in downloading, decoding and presentation is required for seamless switching of Representations 31 in one Adaptation Set. 32 3.2. DASH features 33 3.2.1. Introduction 34 This section introduces the detailed constraints of the MPD and the DASH segments in a descrip- 35 tive way referring to ISO/IEC 23009-1 [1]. The DASH-based restrictions have significant com- 36 monality with the ISO BMFF Live and On-Demand profiles from the MPEG-DASH specification.
DASH-AVC/264 V2.0 10
1 Specifically: 2 • Segment formats are based on ISO BMFF with fragmented movie files, i.e. (Sub)Segments 3 are encoded as movie fragments containing a track fragment as defined in ISO/IEC 14496- 4 12 [4], plus the following constraints to make each movie fragment independently de- 5 codable: 6 Default parameters and flags are stored in movie fragments (‘tfhd’ or ‘trun’ box) 7 and not track headers (‘trex’ box) 8 The ‘moof’ boxes shall use movie-fragment relative addressing for media data that 9 does not use external data references, and the flag ‘default-base-is-moof’ shall 10 also be set and data-offset shall be used, i.e. base-data-offset-present 11 shall not be used (follows ISO/IEC 23009-1 [1]). 12 • Alignment with ISO BMFF Live & On-Demand Profiles, i.e. within each Adaptation Set 13 the following applies 14 • Fragmented movie files are used for encapsulation of media data 15 • (Sub)Segments are aligned to enable seamless switching 16 Beyond the constraints provided in the ISO BMFF profiles, the following additional restrictions 17 are applied. 18 • IDR-like SAPs (i.e., SAPs type 2 or below) at the start of each (Sub)Segment for simple 19 switching. 20 • Segments have almost equal duration. The maximum tolerance of segment duration is 21 ±50% and the maximum accumulated deviation over multiple segments is ±50% of the 22 signaled segment duration (i.e. the @duration attribute or the S@d in the Seg- 23 mentTimeline). Such fluctuations in actual segment duration may be caused by for ex- 24 ample ad replacement or specific IDR frame placement. Note that the last segment in a 25 representation may be shorter according to ISO/IEC 23009-1 [1]. 26 Note: If accurate seeking to specific time is required and at the same time a fats 27 response is required one may use On-Demand profile for VoD or the Seg- 28 mentTimeline based addressing. Otherwise the offset in segment duration com- 29 pared to the actual media segment duration may result in a less accurate seek posi- 30 tion for the download request, resulting in some increased initial start-up. However, 31 this problem is expected to be specific for only a small subset of applications. 32 • The SegmentTimeline adheres to similar constraints as above and is only used in order 33 to signal occasional shorter Segments (possibly caused by encoder processes) or to signal 34 gaps in the time line. It is not used for providing Segments with significantly varying du- 35 ration. The timing in the segment timeline shall be accurate and no constraints on segment 36 duration deviation are added except the maximum segment duration as specified in the 37 MPD. 38 • only non-multiplexed Representations are supported, i.e. each Representation only con- 39 tains a single media component.
DASH-AVC/264 V2.0 11
1 • Addressing schemes are restricted to 2 o templates with number-based addressing 3 o templates with time-based addressing 4 o subsegments with segment index. In this case either the @indexRange 5 attribute is expected to be present. 6 • the 'lmsg' brand for signaling the last segment is applied for any content with MPD@min- 7 imumUpdatePeriod present and the MPD@type="dynamic". 8 • In case multiple Adaptation Sets with @contentType='video' are offered, exactly 9 one video Adaptation Set is signaled as the main one unless different Adaptation Sets con- 10 tain the same content with different quality or different codecs. In the latter case, all Adap- 11 tation Sets with the same content shall be signaled as the main content. Signalling as main 12 content shall be done by using the Role descriptor with @schemeIdUri=" 13 urn:mpeg:dash:role:2011" and @value="main". 14 • Restrictions on the presence of certain elements and attributes as defined section 3.2.4. 15 It is expected that a DASH-AVC/264 client is able to process content offered under these con- 16 straints. More details on expected client procedures are provided in section 3.3. 17 3.2.2. Media Presentation Description constraints 18 DISCLAIMER: This section serves for the definition of the interoperability point in a similar way, 19 as done for the profile definitions in ISO/IEC 23009-1, but is not intended as a normative specifi- 20 cation. 21 NOTE: The term "ignored" in the following description means, that if an MPD is provided 22 and a client that complies with DASH-AVC/264 removes the element that may be ignored, 23 then the MPD is still complying with the constraints of the MPD as defined in ISO/IEC 24 23001-9, section 5. 25 The Media Presentation Description shall conform to the following constraints: 26 The rules for the MPD and the segments as defined in ISO/IEC 23001-9, section 7.3, 27 shall apply.
28 Representations with value of the @mimeType attribute other than xxx/mp4 with 29 xxx={video, audio, application, text, subtitle} or applica- 30 tion/xml+ttml may be ignored. Additional profile or codec specific parameters 31 may be added to the value of the MIME type attribute. For details refer to specific 32 parameters below.
33 The Subset element may be ignored.
34 The Period.SegmentList element shall not be present.
35 If the AdaptationSet.SegmentList is present in an AdaptationSet element 36 then this AdaptationSet element may be ignored.
DASH-AVC/264 V2.0 12
1 If the Representation.SegmentList is present in a Representation element 2 then this Representation element may be ignored.
3 Elements using the @xlink:href attribute may be ignored from the MPD. The Rep- 4 resentations conforming to this profile are those not accessed through an Adaptation 5 Set that uses an @xlink:href.
6 An AdaptationSet containing ContentComponent element may be ignored, i.e. 7 an Adaptation Set with multiplexed media streams may be ignored. Note that the in- 8 formation present in the ContentComponent element may be added to the Adap- 9 tationSet element.
10 An AdaptationSet element not including the parameters as mandated in sec- 11 tion 3.2.4 for an Adaptation Set may be ignored.
12 A Representation element not including the parameters as mandated in sec- 13 tion 3.2.4 may be ignored.
14 If the MPD@type is equal to "static" and the MPD@profiles attribute includes 15 "urn:mpeg:dash:profile:isoff-on-demand:2011" then
16 AdaptationSet elements with AdaptationSet@subsegmentAlignment not 17 present, or set to 'false' may be ignored.
18 Representation elements with a @subsegmentStartsWithSAP value ab- 19 sent, zero or greater than 2 may be ignored.
20 If the Representation element does not contain a BaseURL element then this 21 Representation element may be ignored.
22 If the MPD@type is equal to "dynamic", then
23 the MPD@profiles attribute shall include the signaling for the 24 "urn:mpeg:dash:profile:isoff-live:2011"
25 if the MPD@profiles attribute includes "urn:mpeg:dash:profile:isoff- 26 live:2011", then
27 AdaptationSet elements with AdaptationSet@segmentAlignment not 28 present, or set to 'false' may be ignored.
29 Representation elements with a @startWithSAP value absent, zero or 30 greater than 2 may be ignored.
31 The attribute MPD@maxSegmentDuration shall be present.
DASH-AVC/264 V2.0 13
1 If a Period contains multiple Adaptation Sets with @contentType="video" then at 2 least one Adaptation Set shall contain a Role element
6 3.2.3. Segment format constraints 7 Representations and Segments referred to by the Representations in the profile-specific 8 MPD for this profile, the following constraints shall be met: 9 Representations shall comply with the formats defined in ISO/IEC 23009-1, section 10 7.3.
11 In Media Segments, all Segment Index ('sidx') and Subsegment Index ('ssix') 12 boxes, if present, shall be placed before any Movie Fragment ('moof') boxes.
13 If the MPD@type is equal to "static" and the MPD@profiles attribute includes 14 "urn:mpeg:dash:profile:isoff-on-demand:2011", then
15 Each Representation shall have one Segment that complies with the Indexed Self- 16 Initializing Media Segment as defined in section 6.3.5.2 in ISO/IEC 23009-1.
17 If the MPD@type is equal to "dynamic" and MPD@minimumUpdatePeriod is pre- 18 sent, then if the Media Segment is the last Media Segment in the Representation, this 19 Media Segment shall carry the 'lmsg' compatibility brand.
20 3.2.4. Presence of Attributes and Elements 21 Elements and attributes are expected to be present for certain Adaptation Sets and Representations 22 to enable suitable initial selection and switching. 23 Specifically the following applies: 24 • For any Adaptation Sets with @contentType="video" the following attributes shall 25 be present 26 o @maxWidth (or @width if all Representations have the same width) 27 o @maxHeight (or @height if all Representations have the same height) 28 o @maxFrameRate (or @frameRate if all Representations have the same 29 frame rate) 30 o @par 31 Note: The attributes @maxWidth and @maxHeight are expected to be used 32 such that they describe the target display size. This means that they may ex- 33 ceed the actual largest size of any coded Representation in one Adaptation Set.
DASH-AVC/264 V2.0 14
1 • For any Representation within an Adaptation Set with @contentType="video" 2 the following attributes shall be present: 3 o @width, if not present in AdaptationSet element 4 o @height, if not present in AdaptationSet element 5 o @frameRate, if not present in AdaptationSet element 6 o @sar 7 • For Adaptation Set or for any Representation within an Adaptation Set with @con- 8 tentType="video" the attribute @scanType shall either not be present or shall 9 be set to "progressive". 10 • For any Adaptation Sets with value of the @contentType="audio" the following at- 11 tributes shall be present 12 o @lang 13 • For any Representation within an Adaptation Set with value of the @con- 14 tentType="audio" the following elements and attributes shall be present: 15 o @audioSamplingRate, if not present in AdaptationSet element 16 o AudioChannelConfiguration, if not present in AdaptationSet ele- 17 ment 18 3.2.5. Dimension Constraints 19 No constraints are defined on MPD size, or on the number of elements. 20 3.2.6. Generic Metadata 21 Generic metadata may be added to MPDs based on DASH. For this purpose, the Essential Property 22 Descriptor and the Supplemental Property Descriptor as defined in ISO/IEC 23009-1 [1], clause 23 5.8.4.7 and 5.8.4.8, may be added. 24 Metadata identifiers for content properties are provided here: http://dashif.org/identifiers. 25 However, it is not expected that DASH-AVC/264 clients supports all metadata at 26 http://dashif.org/identifiers unless explicitly required. 27 3.3. Client Implementation Guidelines 28 As mentioned, the DASH-related aspects of the interoperability point as defined in section 3.2 can 29 also be understood as permission for DASH clients that only implement the features required by 30 the description to process the Media Presentation (MPD document and Segments). However, the 31 detailed DASH-AVC/264 DASH-related client operation is not specified. Therefore, it is also un- 32 specified how a DASH client exactly conforms. This document however provides guidelines on 33 what is expected for conformance to this interoperability point. 34 The DASH-related aspects in DASH-AVC/264 as well as for the ISO BMFF based On-Demand 35 and Live profiles of ISO/IEC 23009-1 are designed such that a client implementation can rely on 36 relatively easy processes to provide an adaptive streaming service, namely:
DASH-AVC/264 V2.0 15
1 selection of the appropriate Adaptation Sets based on descriptors and other attributes 2 initial selection of one Representation within each adaptation set 3 download of (Sub)Segments at the appropriate time 4 synchronization of different media components from different Adaptation Sets 5 seamless switching of representations within one Adaptation Set 6
7 8 Figure 1 DASH aspects of a DASH-AVC/264 v1 client compared to a client support- 9 ing the union of DASH ISO BMFF live and on-demand profile. 10 Figure 1 shows the DASH aspects of a DASH-AVC/264 client compared to a client supporting all 11 features of the DASH ISO BMFF Live and On-Demand profile. The main supported features are: 12 support of HTTP GET and partial GET requests to download Segments and Subsegments 13 three different addressing schemes: number and time-based templating as well as byte 14 range based requests. 15 support of metadata as provided in the MPD and Segment Index 16 download of Media Segments, Initialization Segments and Segment Index 17 ISO BMFF parsing 18 synchronized presentation of media components from different Adaptation Sets 19 switching of video streams at closed GOP boundaries 20 The features of the client are expected to be tested in an interoperability effort to ensure full sup- 21 port. Based on test cases, more detailed client requirements may be added.
DASH-AVC/264 V2.0 16
1 3.4. Transport-Related Issues 2 3.4.1. General 3 It is expected that servers and clients operating in DASH-AVC/264 environments support the nor- 4 mative parts of HTTP/1.1 as defined in RFC2616 [18]. Specifically 5 Clients are expected to support byte range requests, i.e. issue partial GETs to subsegments. 6 Range requests may also be issued by using Annex E of 23009-1 using the syntax of the 7 second example in Annex E.3, 8 BaseURL@byteRange="$base$?$query$&range=$first$-$last$" 9 HTTP Servers serving segments are expected to support suitable responses to byte range 10 requests (partial GETs). HTTP Servers may also support the syntax using Annex E of 11 23009-1 using the syntax of the second example in Annex E.3, 12 BaseURL@byteRange="$base$?$query$&range=$first$-$last$" 13 Clients are expected to follow the reaction to HTTP status and error codes as defined in 14 section A.7 of ISO/IEC 23009-1. 15 3.4.2. Synchronization Considerations 16 In order to properly access MPDs and Segments that are available on DASH servers, DASH serv- 17 ers and clients are expected to synchronize their clocks to a globally accurate time standard. Spe- 18 cifically it is expected that the Segment Availability Times as computed from the MPD according 19 to ISO/IEC 23009-1 [1], section 5.3.9.5 and additional details in ISO/IEC 23009-3 [3], section 6.4 20 are accurately announced in the MPD. 21 Options to obtain timing for a DASH client are for example: 22 Usage of NTP or SNTP as defined in RFC5905 [33]. 23 The Date general-header field in the HTTP header (see RFC2616 [18], section 14.18) rep- 24 resents the date and time at which the message was originated, and may be used as an 25 indication of the actual time. 26 Anticipated inaccuracy of the timing source is expected to be taken into account when requesting 27 segments close to their segment availability time boundaries. 28 3.5. Considerations for Live Services 29 Live services are supported in DASH. MPEG defines two types of Media Presentations: static and 30 dynamic. For static Media Presentations all segments are available at the value of MPD@avail- 31 abilityStartTime. For dynamic Media Presentations, Segments get available over time. If 32 MPD@type="dynamic" then this provides an indication to the client at startup to join at the 33 live edge, i.e. download the latest available segment and start playing from there on. To determin- 34 ing the latest available segment, please refer to the details in ISO/IEC 23009-3 [3], section 6.4. 35 In addition, to communicate unforeseen events such as the addition of a new period in a live service 36 or the end of the Media Presentation, MPEG-DASH supports an MPD update procedure as defined 37 in section 5.4 of ISO/IEC 23009-1 [1]. If the attribute MPD@minimumUpdatePeriod is present
DASH-AVC/264 V2.0 17
1 updates to the MPD are expected and restricted in a sense that at the location where the MPD is 2 available at a certain time, the MPD is also valid for the duration of the value of the MPD@mini- 3 mumUpdatePeriod attribute. 4 If the attribute MPD@minimumUpdatePeriod is set to 0 then all Segments with availability 5 start time less than the request time of the MPD are available at the location advertised in the MPD. 6 DASH clients operating based on such an MPD and consuming the service at the live edge typi- 7 cally need to request a new MPD prior to downloading a new segment. However, in order to min- 8 imise MPD requests and resulting traffic load, the client may use one or more of the following 9 optimisations: 10 If the client fetches the MPD using HTTP, the client should use conditional GET methods 11 as specified in RFC 2616 [18], clause 9.3 to reduce unnecessary network usage in the 12 downlink. 13 Clients may also rely on the 'lmsg' message and request a new MPD only in case a seg- 14 ment is received with an 'lmsg' brand. Otherwise the client may use template construc- 15 tions to continue determining the URL and the segment availability start time of segments. 16 If the server implements other means to provide indication of MPD updates, e.g. in band 17 events, and the client is aware of this, the client may also use this signal to trigger the 18 request of an updated MPD. 19 If the attribute MPD@minimumUpdatePeriod is set to a value greater than 0 then all Segments 20 with availability start time less than the sum of the request time and the value of the MPD@mini- 21 mumUpdatePeriod will eventually get available at the advertised position at their computed 22 segment availability start time. Note that by providing a MPD@minimumUpdatePeriod is set 23 to a value greater than 0, DASH servers reduce the polling frequency of clients, but at the same 24 time cannot expect that clients will request an updated MPD to be informed on changes in the 25 segment URL constructions, e.g. at the start of a new Period.
26 4. Media Coding Technologies 27 4.1. Introduction 28 In addition to DASH-specific constraints, DASH-AVC/264 also adds restrictions on media codecs 29 and other technologies. This section provides an overview on technologies for different media 30 components and how they fit into the DASH-related aspects of DASH-AVC/264. 31 4.2. Video 32 4.2.1. General 33 The codec considered for basic video support up to 1280 x 720p at 30 fps is H.264 (AVC) Pro- 34 gressive High Profile Level 3.1 decoder [6]. This choice is based on the tradeoff between content 35 availability, support in existing devices and compression efficiency.
DASH-AVC/264 V2.0 18
1 Further, it is recognized that certain clients may only be capable to operate with H.264/AVC "Pro- 2 gressive" Main Profile Level 3.0 and therefore content authors may provide and signal a specific 3 subset of DASH-AVC/264. 4 Notes 5 H.264 (AVC) Progressive High Profile Level 3.1 decoder [6] can also decode any content 6 that conforms to 7 o H.264 (AVC) Constrained Baseline Profile up to Level 3.1 8 o H.264 (AVC) "Progressive" Main Profile up to Level 3.1. 9 H.264 (AVC) H.264/AVC "Progressive" Main Profile Level 3.0 decoder [6] can also de- 10 code any content that conforms to H.264 (AVC) Constrained Baseline Profile up to Level 11 3.0. 12 Further, the choice for HD extensions up to 1920 x 1080p and 30 fps is H.264 (AVC) Progressive 13 High Profile Level 4.0 decoder [6]. 14 Other video-related enhancements are expected to be addressed in extensions. 15 4.2.2. DASH-specific aspects for H.264/AVC video 16 For the integration of the above-referred codecs in the context of DASH, the following applies for 17 H.264 (AVC): 18 The encapsulation of H.264/MPEG-4 AVC video data is based on the ISO BMFF as de- 19 fined in ISO/IEC 14496-15 [7]. 20 Clients are expected to support Inband Storage for SPS/PPS based ISO/IEC 14496-15, 21 Amendment 2 [22], i.e. sample entry 'avc3' and 'avc4'. 22 SAP types 1 and 2 correspond to IDR-frames in [6]. 23 The signaling of the different video codec profile and levels for the codecs parameters 24 according to RFC6381 [8] is documented in Table 2. Note that any of the codecs present 25 in Table 2conforms to the profile level combination that is supported in DASH-AVC/264. 26 Table 2 H.264 (AVC) Codecs parameter according to RFC6381 [8]
Profile Level Codec Parameter
H.264 (AVC) Con- 1.1 avc[1..4].42X00B strained Baseline Profile 1.2 avc[1..4].42X00C X=?1????00 1.3 avc[1..4].42X00D
2.0 avc[1..4].42X014
2.1 avc[1..4].42X015
DASH-AVC/264 V2.0 19
2.2 avc[1..4].42X016
3.0 avc[1..4].42X01E
H.264 (AVC) "Progres- 1.1 avc[1..4].4DY00B sive" Main Profile 1.2 avc[1..4].4DY00C Y=??????00 1.3 avc[1..4].4DY00D
2.0 avc[1..4].4DY014
2.1 avc[1..4].4DY015
2.2 avc[1..4].4DY016
3.0 avc[1..4].4DY01E
H.264 (AVC) Progres- 1.1 avc[1..4].64Y00B sive High Profile 1.2 avc[1..4].64Y00C Y=??????00 1.3 avc[1..4].64Y00D
2.0 avc[1..4].64Y014
2.1 avc[1..4].64Y015
2.2 avc[1..4].64Y016
3.0 avc[1..4].64Y01E
3.1 avc[1..4].64Y01F
4.0 avc[1..4].64Y028
1 2 4.2.3. Video Metadata 3 The provisioning of video metadata in the MPD is discussed in section 3.2.4. 4 4.3. Audio 5 4.3.1. General 6 Content offered according to DASH-AVC/264 IOP is expected to contain an audio component in 7 most cases. Therefore, clients consuming DASH-AVC/264-based content are expected to support
DASH-AVC/264 V2.0 20
1 stereo audio. Multichannel audio support and support for additional codecs is defined in extensions 2 in section 9 of this document. 3 The codec for basic stereo audio support is MPEG-4 High Efficiency AAC v2 Profile, level 2 [9]. 4 Notes 5 HE-AACv2 is also standardized as Enhanced aacPlus in 3GPP TS 26.401 [11]. 6 HE-AACv2 Profile decoder [6] can also decode any content that conforms to 7 o MPEG-4 AAC Profile [9] 8 o MPEG-4 HE-AAC Profile [9] 9 Therefore, Broadcasters and service providers encoding DASH-AVC/264 content are free to use 10 any AAC version. It is expected that clients supporting the DASH-AVC/264 interoperability point 11 will be able to play AAC-LC, HE-AAC and HE-AACv2 encoded content. 12 For all HE-AAC and HE-AACv2 bitstreams, explicit backwards compatible signaling shall be 13 used to indicate the use of the SBR and PS coding tools. 14 4.3.2. DASH-specific aspects for HE-AACv2 audio 15 In the context of DASH, the following applies for the High Efficiency AAC v2 Profile 16 The content is expected to be prepared according to the MPEG-DASH Implementation 17 Guidelines [3] to make sure each (Sub)Segment starts with a SAP of type 1. 18 The signaling of MPEG-4 High Efficiency AAC v2 for the codecs parameters is according 19 to IETF RFC6381 [8] and is documented in Table 3. Table 3 also provides information on 20 the ISO BMFF encapsulation. 21 Table 3 HE-AACv2 Codecs parameter according to RFC6381 [8]
Codec Codec Parame- ISO BMFF Encapsulation SAP type ter
MPEG-4 AAC mp4a.40.2 ISO/IEC 14496-14 [10] 1 Profile [9]
MPEG-4 HE- mp4a.40.5 ISO/IEC 14496-14 [10] 1 AAC Profile [9]
MPEG-4 HE- mp4a.40.29 ISO/IEC 14496-14 [10] 1 AAC v2 Pro- file [9]
22 Note: Since both, HE-AAC and HE-AACv2 are based on AAC-LC, for the above-mentioned “Co- 23 dec Parameter” the following is implied: 24 mp4a.40.5 = mp4a.40.2 + mp4a.40.5 25 mp4a.40.29 = mp4a.40.2 + mp4a.40.5 + mp4a.40.29
DASH-AVC/264 V2.0 21
1 4.3.3. Audio Metadata 2 4.3.3.1. General 3 Metadata for audio services is defined in ISO/IEC 23009-1. 4 4.3.3.2. ISO/IEC 23009-1 audio data 5 With respect to the audio metadata, the following elements and attributes from ISO/IEC 23009-1 6 are relevant: 7 the @audioSamplingRate attribute for signaling the sampling rate of the audio media 8 component type in section 5.3.7 of ISO/IEC 23009-1 9 the AudioChannelConfiguration element for signaling audio channel configura- 10 tion of the audio media component type.in section 5.3.7 of ISO/IEC 23009-1. 11 4.4. Auxiliary Components 12 4.4.1. Introduction 13 Beyond regular audio and video support, TV programs typically also require support for auxiliary 14 components such as subtitles and closed captioning. For example, a Federal Communications 15 Commission (FCC) Advisory Committee has recommended that a standard for the closed-caption- 16 ing of online video content developed by the Society of Motion Picture and Television Engineers 17 (SMPTE). DASH-AVC/264 addresses these requirements. 18 4.4.2. Basic Subtitles and Closed Captioning 19 The chosen technology for basic subtitles and closed captioning is W3C TTML [14] and the 20 SMPTE profile on SMPTE Timed Text [15]. Graphics-based subtitles and closed captioning are 21 also supported by SMPTE Timed Text [15]. 22 Support for other technologies such as 23 CEA-708 Digital Television (DTV) Closed Captioning [12] 24 3GPP Timed Text [13] 25 Web VTT [16] 26 are not expected in DASH-AVC/264, but may be required in certain environments. Conversion of 27 CEA-608 and CEA-708 into SMPTE TT may be done according to SPMTE 2052-10 [19]. 28 Note that by the choice of SMPTE TT as the supported format at the client, other formats such as 29 EBU TT [17] are also supported as long as only the subset that is also supported by SMPTE TT is 30 used in the content authoring. 31 4.4.3. DASH-specific aspects of Auxiliary components 32 In the context of DASH, the following applies for text/subtitling: 33 All graphics type samples are SAP type 1.
DASH-AVC/264 V2.0 22
1 The signalling of the different text/subtitling codecs for the codecs parameters is according 2 to RFC6381 [8] is documented in Table 4. Table 4 also provides information on ISO BMFF 3 encapsulation. 4 For live services, encapsulation in ISO BMFF is definitely necessary. However, for On- 5 Demand cases, the full file of subtitles may be provided as XML data only. 6 Table 4 Subtitle Codecs parameter according to RFC6381 [8]
Codec MIME type Codec Parame- ISO BMFF Encapsula- ter tion @codecs
SMPTE Timed application/ttml+xml not pre- n/a Text [15] with- sent out encapsula- tion
SMPTE Timed application/mp4 stpp ISO/IEC 14496-12 [34] Text [15] with ISO/IEC 14496-30 [20] ISO BMFF en- capsulation
7 5. DRM-Related Aspects 8 5.1. Introduction 9 DASH-AVC/264 does not intend to specify a full end-to-end DRM system. However DASH- 10 AVC/264 provides a framework for multiple DRMs to protect DASH content by adding instruc- 11 tions or Protection System Specific, proprietary information in predetermined locations to DASH 12 content that is encrypted with Common Encryption as defined in ISO/IEC 23001-7 [21]. 13 The Common Encryption (‘cenc’) protection scheme specifies encryption parameters that can be 14 applied by a scrambling system and key mapping methods using a common key identifier (KID) 15 to be used by different DRM systems such that the same encrypted version of a file can be com- 16 bined with different DRM systems that can store proprietary secure information for licensing and 17 key retrieval in the Protection System Specific Header box (‘pssh’). The DRM scheme for each 18 pssh box is identified by the SystemID field in that box. 19 The recommendations in this document reduce the encryption parameters and use of the encryption 20 metadata to specific use cases for VOD and live content with key rotation.
DASH-AVC/264 V2.0 23
1 5.2. Base Technologies 2 The base standards to support common encryption in combination with ISO BMFF is ISO/IEC 3 23001-7. In particular 4 Common Encryption with CTR mode as defined in ISO/IEC 23001-7:2011 [21]. 5 Key rotation as defined in ISO/IEC 23001-7 [21]. Note: the latter was added as AMD1 to 6 the 1st edition of ISO/IEC 23001-7:2011 7 XML syntax for expressing default KIDs, as defined in ISO/IEC 23001-7:2013 8 The main DRM elements are: 9 1. The ContentProtection descriptor (see [1] 5.3.7.2-Table 9, 5.8.5.2 and [1] 5.8.4.1) 10 that contains the URI for signaling of the use of Common Encryption as well as the specific 11 DRM being used. 12 2. ‘tenc’ parameters that specify encryption parameters and KID (see [21] 8.2.1). The 13 'tenc' information is in the Initialization Segment (see [21] 8.2.1). The default KID infor- 14 mation may also appear in the MPD (see [21] 11.1). 15 3. ‘pssh’ parameters that are “Protection System Specific” (see [21] 8.1). The pssh infor- 16 mation is in Initialization or Media Segments (See [21] 8.1 and 8.2). It may also be present 17 in the MPD (see [1] 5.8.4.1, [21] 11.2.1) in a scheme-specific way. Information in the MPD 18 increases the MPD size but may allow faster parsing, earlier access and addition of DRMs 19 without content modification. 20 5.3. Workflow Overview 21 Figure 2 below shows a simple workflow with pssh information in the Initialization Segment for 22 informational purpose. 23
DASH-AVC/264 V2.0 24
1 Figure 2 Workflow with pssh information in the Initialization Segment. 2
Encoder Key Key DB Manager
Key Ingest Key + KID AssetID + Key + KID
pssh content
MPD
Content Protection UUID
Decoder DRM Client Lib
Init. Verify if DRM (UUID) Segment is supported pssh [AssetID, KeyID] tenc
Key Request Request Key# Media File KID + pssh content Authenticate user, device, and
Key license. Key
Decrypt, decode and play
DASH-AVC/264 V2.0 25
1 5.4. Integration and Mapping to DASH 2 5.4.1. MP4 Structure Overview 3 Table 5 provides pointers to relevant information in the specifications to understand the standard 4 DRM components and where the relevant information is located. The table is for informational 5 purpose only. 6 Table 5 Boxes relevant for DRM systems
Box Full Name / Usage Info at movie fragment header moof ISO BMFF [4], 8.32 + [1] One ‘moof’ box for each fragment in each stream movie header, container for all the metadata moov ISO BMFF [4] , 8.1 One ‘moov’ box per elementary stream. 1 x for each video stream, + 1 x for the audio stream pssh protection system specific header box [21], 8.1.1 SampleAuxiliaryInformationOffsetsBox saio [21], 5 Contains the offset of the IVs & encryption data. SampleAuxiliaryInformationSizesBox saiz [21], 5 Contains the size of the IVs & encryption data. schi scheme information box [21], 4 CencSampleEncryptionInformation GroupEntry seig [21], 6 Contains tenc information in sample in segments for key rotation. sinf protection scheme information box [21], 4 stsd sample descriptions (codec types, initialization etc.) ISO BMFF [4], 8.16 track encryption box tenc [21], 8.2.1 contains tenc parameters
7 5.4.2. Box Hierarchy 8 The following shows the box hierarchy and composition:
9 In the ‘moov’ box: 10 o one or more ‘pssh’ boxes 11 o in ‘trak::mdia::minf::stbl::stsd’: 12 . the ‘sinf’ box that contains: 13 . the ‘frma’ box 14 . the ‘schm’ box 15 . the ‘schi’ box that contains: 16 . the ‘tenc’ box
DASH-AVC/264 V2.0 26
1 In the ‘moof’ box: 2 o in the ‘traf’ box: 3 . the ‘saiz’ box 4 . the ‘saio’ box 5 . if using key rotation, the ‘sbgp’ box 6 . if using key rotation, the ‘sgpd’ box that contains: 7 . the ‘seig’ box
8 5.5. DRM Aspects for DASH-AVC/264 9 5.5.1. General 10 To enable signaling of a specific DRM scheme in DASH using the Base Technologies as presented 11 in section 5.2 one of the following options as provided in section 5.5.2 can be applied. 12 13 5.5.2. pssh and tenc Parameters in Movie or Movie Fragment Box 14 The pssh and tenc parameters are exclusively provided in the movie or movie fragment box, 15 i.e. in the Initialization Segment (and possibly in the movie fragment box for key rotation) for the 16 live profile or in the movie box for the On-Demand profile: 17 ‘tenc’ parameters are provided by 'tenc' box in the content file that specify encryp- 18 tion parameters and KID as specified in [21], section 8.2.1. 19 ‘pssh’ parameters are provided by pssh box in the content file as specified in [21], sec- 20 tion 8.1. 21 5.5.3. Use of Content Protection Descriptor 22 5.5.3.1. General 23 ContentProtection descriptor shall always appear on the AdaptationSet level. 24 5.5.3.2. Generic ContentProtection Descriptor 25 ContentProtection descriptor with @schemeIdUri value of 26 "urn:mpeg:dash:mp4protection:2011" must be present. 27 Default KID value, as specified by the 'tenc' box, should be carried in the MPD, within the above 28 ContentProtection descriptor above, using the @cenc:default_KID attribute defined 29 in [21], section 11.1. The value of the attribute is the KID value in a UUID notation. 30
31 DASH allows the @cenc:default_KID attribute in every DRM-specific ContentProtec- 32 tion descriptor, but for DASH-AVC/264, the latter should only be included in ContentPro- 33 tection descriptor with the urn:mpeg:dash:mp4protection:2011 @schemeIdUri 34 value, so that it is specified only once and is available in one place for all applications. The ‘tenc’
DASH-AVC/264 V2.0 27
1 box that specifies encryption parameters and KID is also present in the movie box, as specified 2 in [21], section 8.2.1. 3 5.5.3.3. DRM-specific ContentProtection Descriptor 4 A ContentProtection descriptor in MPD specifies a specific DRM scheme. An example is 5 provided below: 6
7 The URI (marked by x) is generated and provided by single DRM provider and uniquely identi- 8 fies this DRM system. 9 The @value attribute describes the DRM system and version in a human readable form 10 5.5.3.4. pssh Parameter in MPD 11 Carrying tenc and pssh parameters in the MPD are useful to allow license evaluation, key iden- 12 tification and retrieval before availability of the initialization segment, which may distribute client 13 requests and is relevant to allow an early decision by the client if this key is already available and 14 to otherwise retrieve it before or during download of the Initialization Segment. 15 Carriage of tenc.default_KID parameter is described in 5.5.3.2 above. 16 pssh parameters can be carried in the MPD within a DRM-specific ContentProtection 17 descriptor and in the DRM-specific syntax and namespace. Examples are provided in 5.9.3 and 18 in [21] sec. 11.2. 19 5.6. Key Rotation 20 5.6.1. Introduction
21 Key rotation is mainly used to allow changes in entitlement for continuous live content. It is used 22 as defined in [21] with the following requirements:
23 In the initialization segment, the movie box ‘moov’ contains ‘tenc’ box and may con- 24 tain a ‘pssh’ box for each DRM to store root license information for authentication and 25 authorization. 26 In addition, each Movie Fragment may contain at most one ‘pssh’ in each ‘moof’ box 27 per SystemID that contains sufficient information to acquire keys for this movie frag- 28 ment, when combined with: 29 o information from ‘pssh’ in ‘moov’ 30 o KID from ‘seig’ box
31 (This will likely result in some redundant pssh boxes but will facilitate processing and 32 trick play, of linear content that is later made available as VOD assets)
DASH-AVC/264 V2.0 28
1 Any KIDs in Movie Fragments override the ‘tenc’ parameter of the ‘default_KID’, 2 as well as the ‘not encrypted’ parameter.
3 5.6.2. Encryption of Different Representations 4 Generally, different Representations of one Adaptation Set are protected by the same license, i.e. 5 encrypted with the same key. That means all Representations have the same value of ‘de- 6 fault_KID’ in their ‘tenc’ boxes in their Initialization Segments. 7 In the case of key rotation, that applies to the root license (one per DRM) and the same value of 8 KID in each leaf license contained in each Media Segment. 9 In cases where HD and SD content are contained in one asset, different license rights may be 10 required for each quality level. It then is often advisable to create individual Adaptation Sets for 11 each quality level, each with a different ContentProtection descriptor in the Adaptation Set. 12 While there may be some Representations that are equivalent in both Adaptation Set and therefore 13 increase the content size, their size typically relatively small and switching between an HD and 14 SD Adaptation Set is difficult to be applied seamlessly because these quality levels typically vary 15 in DRM output controls, use different decryption licenses and keys and use different decoding 16 parameters for e.g. subsampling, entropy coding, aspect ratios and color spaces. 17 The test vectors are limited to a single license (per DRM) per Adaptation Set but this does not 18 explicitly exclude the viability of different licenses within one Adaptation Set. 19 5.7. Additional Content Protection Requirements 20 In addition, content authored claiming conformance to any DASH-264/AVC IOP the following 21 holds: 22 In the case where ‘pssh’ boxes are present in Initialization Segments, each Initialization 23 Segment within one Adaptation Set shall contain an equivalent pssh box for each Sys- 24 temID, i.e. license acquisition for one Representation is sufficient to ensure switching 25 within Adaptation Set. 26 In the case where license acquisition information is present in ContentProtection De- 27 scriptors, they shall only be present on the AdaptationSet element(s). 28 in case of inband key delivery, the pssh box version 2 (as defined in 5.5.3) shall be equiv- 29 alent for all Representations within one Adaptation Set, i.e. license acquisition for one 30 Representation is sufficient to ensure switching within Adaptation Set. 31 32 5.8. Signaling 33 The DRM system is signaled with a URI as described in ISO/IEC 23009-1 [1] 5.8.5.2. The list of 34 enabled DRMs can be found in the DASH identifier repository available here: 35 http://www.dashif.org/identifiers/content-protection.
DASH-AVC/264 V2.0 29
1 5.9. Common Encryption Test DRM 2 5.9.1. Introduction 3 In order to test common encryption without the necessity to do tests for a specific DRM, or all 4 supported DRMs, a common encryption Test-DRM is defined. 5 Specifically the following aspects are defined for the Test-DRM: 6 To test the encryption with common encryption scheme parameters, the key is provided in 7 a separate file. 8 To test the parsing of DRM relevant fields, two different test scenarios are defined to com- 9 municate the encryption parameters in the MPD and in the movie box (see section 5.5.2). 10 The latter case also includes key rotation. 11 In the interest of testing independently of a specific DRM system, the keys are provided directly 12 in lieu of the DRM information that is otherwise used to obtain the keys. 13 The use of an external file allows flexible referencing of the same key from different locations, to 14 e.g. use the same key for audio, video or different Representations. 15 5.9.2. Test of Common Encryption 16 The key file location is the MPD directory or configurable in the player to avoid OS dependent 17 path references. Its file name is the KID in 32 Hex lower case digits with .txt extension. The content 18 is the decryption key in lower case Hex digits e.g.
19 bdff1a347bd8e9f523f5ee6b16273d6e.txt contains: 20 050526bf6d3c386ffe5fc17c93506eca
21 The key file name can be stored in the pssh to verify the creation and parsing of pssh infor- 22 mation. If the pssh information is not present, the file name can also be derived directly with the 23 knowledge of the KID.
24 In the test vectors 3 different test values for @schemeIdUri are defined to represent multi 25 DRMs:
26 00000000-0000-0000-0000-000000000000 27 00000000-0000-0000-0000-000000000001 28 00000000-0000-0000-0000-000000000002
29 The test of common decryption is included in the successful decryption in the above cases. 30 5.9.3. ContentProtection descriptor 31 An extension namespace is defined in order to enable inclusion of pssh parameters in the Con- 32 tentProtection element for the test DRMs above.
DASH-AVC/264 V2.0 30 elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:dashif:iop:drm:2012" >
1 2 An example is provided below: 3
4 5 6 5.9.4. Test Scenarios 7 5.9.4.1. Introduction 8 Different test scenarios are defined which are then mapped to specific test cases in [23]. The first 9 test scenario uses a single key with 10 1. pssh and tenc parameters in the movie box 11 2. pssh and tenc.default_KID parameters in the MPD. 12 Another test scenario implements key rotation with tenc and pssh information in the MPD. 13 Finally, a use case for interleaving of unencrypted content is added.
DASH-AVC/264 V2.0 31
1 5.9.4.2. Test Scenario 1: pssh and tenc Parameters in Movie Box 2 The simulation verifies the signaling of the DRM in the MPD, specifically the pssh and tenc 3 information as it must be exercised to access the keys. 4 The signaling of encryption scheme(s) in MPD: 5
10 The simulation verifies the encoding of the parameters in the MPD as described in 5.5.3. The key 11 file is indicated in the Pssh@data attribute as base64 encoded KID in lower case with .txt ex- 12 tension. For example, for a KID of bdff1a347bd8e9f523f5ee6b16273d6, the key will 13 be in the file bdff1a347bd8e9f523f5ee6b16273d6e.txt.
14 Full Pssh@data with required base64 encoding in this case is:
15
17 A separate key file is used for each key when key rotation is used.
18 5.9.4.4. Test Scenario 3: pssh and KID Parameters in MPD with Key Rotation
19 In this case, the pssh information may contain root license information. For the test scenario, 20 the pssh information does not contain relevant key information but is present as a place holder. 21 The static place holder is the base64 encoding of the string: ”possible root pssh license 22 info”, i.e.:
23
24 A separate key file with different $KeyId$ value is used for each new key.
25 5.9.4.5. Test Scenario 4: pssh and tenc Parameters in MPD with Key Rotation and un- 26 encrypted elements
27 This extends the previous test scenario with segments that are signaled as unencrypted that are 28 combined with encrypted segments.
DASH-AVC/264 V2.0 32
1 6. Interoperability point DASH-AVC/264 2 6.1. Introduction 3 The scope of the DASH-AVC/264 interoperability point is the basic support of high-quality video 4 distribution over the top. Both, live and on-demand services are supported. It is expected that the 5 client supports at least the presentation of 6 high-definition video up to 720p 7 stereo audio 8 basic subtitle support 9 basic support for encryption/DRM 10 The compliance to DASH-AVC/264 may be signaled by an @profiles attribute with the value 11 "http://dashif.org/guidelines/dash264" 12 6.2. Supporters 13 This interoperability point is supported by at least the following DASH-IF members: Akamai, 14 bitmovin, CastLabs, Cisco, Dolby, Digital Primates, DTS, Elemental Technologies, Envivio, Er- 15 icsson, Fraunhofer, Harmonic, Imagine Communications, Intel, InterDigital, Media Excel, Mi- 16 crosoft, Netflix, Path1, Qualcomm Incorporated, RealNetworks, RGB Networks, Sony, Sorenson 17 Media, Thomson Video Networks, Verimatrix. 18 6.3. Definition 19 Content may be authored claiming conformance to this IOP if a client can be properly play the 20 content by supporting at least the following features: 21 All DASH-related features as defined in section 3 of this document. 22 H.264/MPEG AVC Progressive High Profile at level 3.1 as defined in section 4.2. 23 MPEG-4 HE-AAC v2 level 2 profile audio codec as defined in section 4.3. Dynamic Range 24 Control is not expected to be supported. 25 subtitle and closed captioning support using SMPTE-TT as defined in section 4.4.2 26 o For On-Demand single file download is sufficient. 27 o For live services and/or if key rotation is to be supported, the encapsulation into 28 ISO BMFF is necessary. 29 content protection based on common encryption and key rotation as defined in section 5. 30 And specifically, the client supports MPD-based parsing and movie box based parsing of 31 DRM related parameters for common encryption. 32 If content is offered claiming conformance to this IOP, the content author is encouraged to use the 33 HTTP-URL construction as defined in [3], section 5.1.4.
DASH-AVC/264 V2.0 33
1 7. Interoperability Point DASH-AVC/264 SD 2 7.1. Introduction 3 It is recognized that certain clients may only be capable to operate with H.264/AVC Main Profile. 4 Therefore content authors may provide and signal a specific subset of DASH-AVC/264 by provid- 5 ing a specific profile identifier referring to a standard definition presentation. This interoperability 6 point is defined as DASH-AVC/264 SD. 7 The compliance to DASH-AVC/264 SD may be signaled by an @profiles attribute with the 8 value "http://dashif.org/guidelines/dash264#sd" 9 7.2. Supporters 10 This interoperability point is supported by the following DASH IF members: Akamai, bitmovin, 11 CastLabs, Cisco, Dolby, Digital Primates, DTS, Elemental Technologies, Envivio, Ericsson, 12 Fraunhofer, Harmonic, Imagine Communications, Intel, InterDigital, Media Excel, Microsoft, 13 Netflix, Path1, Qualcomm Incorporated, RealNetworks, RGB Networks, Sony, Sorenson Media, 14 Thomson Video Networks, Verimatrix. 15 7.3. Definition 16 A client that attempts to consume content generated conforming to this profile is expected to sup- 17 port the following features: 18 All features as defined in section 6.3, except: 19 o Instead of H.264/MPEG AVC Progressive High Profile at level 3.1, the highest 20 video codec configuration is H.264/MPEG AVC Progressive Main Profile at level 21 3.0 as defined in section 4.2.
22 8. Interoperability Point DASH-AVC/264 HD 23 8.1. Introduction 24 For the support of high-quality video distribution up to 1080p, an additional interoperability point 25 is defined. 26 Compliance to DASH-AVC/264 HD may be signaled by an @profile attribute with the value 27 "http://dashif.org/guidelines/dash264#hd" 28 Note: To signal conformance to both interoperability points, DASH-AVC/264 and DASH- 29 AVC/264 HD, the @profile attribute may contain both interoperability point indicators. 30 8.2. Supporters 31 This interoperability point is supported by the following DASH-IF members: Akamai, bitmovin, 32 CastLabs, Cisco, Dolby, Digital Primates, DTS, Elemental Technologies, Envivio, Ericsson, 33 Fraunhofer, Harmonic, Imagine Communications, Intel, InterDigital, Media Excel, Microsoft,
DASH-AVC/264 V2.0 34
1 Netflix, Path1, Qualcomm, RealNetworks, RGB Networks, Sony, Sorenson Media, Thomson 2 Video Networks, Verimatrix. 3 8.3. Definition 4 A client that attempts to consume content generated conforming to DASH-AVC/264 HD interop- 5 erability point is expected to support the following features: 6 All features as defined in section 6.3. 7 H.264/MPEG AVC Progressive High Profile at level 4.0 as defined in section 4.2.
8 9. Multi-Channel Audio Extension 9 9.1. Scope 10 The Scope of the Multichannel Audio Extension is the support of audio with additional channels 11 and codecs beyond the basic audio support as specified in the DASH-AVC/264 base, which is 12 limited to Stereo HE-AAC. Multichannel audio is widely supported in all distribution channels 13 today, including broadcast, optical disc, and digital delivery of audio, including wide support in 14 adaptive streaming delivery. 15 It is expected that clients may choose which formats (codecs) they support. 16 9.2. Technologies 17 9.2.1. Dolby Multichannel Technologies 18 9.2.1.1. Overview 19 The considered technologies from Dolby for advanced audio support are: 20 Enhanced AC-3 (Dolby Digital Plus) [28] 21 Dolby TrueHD [29] 22 9.2.1.2. DASH-specific issues 23 In the context of DASH, the following applies: 24 The signaling of the different audio codecs for the codecs parameters is documented in [28] 25 and [29], which also provides information on ISO BMFF encapsulation. 26 For E-AC-3 the Audio Channel Configuration shall use the "urn:dolby:dash:au- 27 dio_channel_configuration:2011" as defined at http://dashif.org/identifi- 28 ers/audio-source-data/.
DASH-AVC/264 V2.0 35
1 Table 6 Dolby Technologies: Codec Parameters and ISO BMFF encapsulation
Codec Codec Parameter ISO BMFF Encapsulation SAP type
Enhanced AC-3 [28] ec-3 ETSI TS 102 366 Annex F [28] 1
Dolby TrueHD mlpa Dolby [29] 1
2 9.2.2. DTS-HD 3 9.2.2.1. Overview 4 DTS-HD [30] comprises a number of profiles optimized for specific applications. More infor- 5 mation about DTS-HD and the DTS-HD profiles can be found at www.dts.com. 6 9.2.2.2. DASH-specific issues 7 For all DTS formats SAP is always 1. 8 The signaling of the various DTS-HD profiles is documented in DTS 9302J81100 [27]. DTS 9 9302J81100 [27] also provides information on ISO BMFF encapsulation. 10 Additional information on constraints for seamless switching and signaling DTS audio tracks in 11 the MPD is described in DTS specification 9302K62400 [32]. 12 Table 7: DTS Codec Parameters and ISO BMFF encapsulation
Codec Codec Parameter ISO BMFF Encapsulation SAP type
DT Digital Surround dtsc DTS 9302J81100 [27] 1
DTS-HD High Reso- dtsh lution and DTS-HD Master Audio
DTS Express dtse
DTS-HD Lossless dtsl (no core)
13 14 9.2.3. MPEG Surround 15 9.2.3.1. Overview 16 MPEG Surround, as defined in ISO/IEC 23003-1:2007 [31], is a scheme for coding multichannel 17 signals based on a down-mixed signal of the original multichannel signal, and associated spatial 18 parameters. The down-mix shall be coded with MPEG-4 High Efficiency AAC v2 according to 19 section 5.3.3. 20 MPEG Surround shall comply with level 4 of the Baseline MPEG Surround profile.
DASH-AVC/264 V2.0 36
1 9.2.3.2. DASH-specific issues 2 In the context of DASH, the following applies for audio codecs 3 The signaling of the different audio codecs for the codecs parameters is according to 4 RFC6381 [8] is documented in Table 8. Table 8 also provides information on ISO BMFF 5 encapsulation. 6 The content is expected to be prepared according to the MPEG-DASH Implementation 7 Guidelines [3] to make sure each (sub-)segment starts with a SAP of type 1. 8 Table 8 Codecs parameter according to RFC6381 [8] and ISO BMFF encapsulation 9 for MPEG Surround codec
Codec Codec Parame- ISO BMFF Encapsulation SAP type ter
MPEG Sur- mp4a.40.30 ISO/IEC 14496-14 [8] 1 round [31]
10 Note: Since MPEG Surround is based on a down-mix coded with AAC-LC and HE-AAC, for the 11 above mentioned “Codec Parameters” the following is implied: 12 mp4a.40.30 = AOT 2 + AOT 5 + AOT 30 13 9.2.4. MPEG-4 High Efficiency AAC Profile v2, level 6 14 9.2.4.1. Overview 15 Support for multichannel content is available in the HE-AACv2 Profile, starting with level 4 for 16 5.1 and level 6 for 7.1 [9]Error! Reference source not found.. All MPEG-4 HE-AAC multichan- 17 nel profiles are fully compatible with the DASH-AVC/264 baseline interoperability point for ste- 18 reo audio, i.e. all multichannel decoders can decode DASH-AVC/264 stereo content. 19 9.2.4.2. DASH-specific issues 20 In the context of DASH, the following applies for the High Efficiency AAC v2 Profile 21 The content shall be prepared according to the MPEG-DASH Implementation Guide- 22 lines [3] to make sure each (sub-)segment starts with a SAP of type 1. 23 Signaling of profile levels is not supported in RFC 6381 but the channel configuration shall 24 be signaled by means of the ChannelConfiguration element in the MPD. 25 The signaling of MPEG-4 High Efficiency AAC v2 for the codecs parameters is according 26 to RFC6381 [8] and is documented in Table 9. Table 9 also provides information on the 27 ISO BMFF encapsulation. 28 For all HE-AAC bitstreams, explicit backward-compatible signaling of SBR shall be used. 29 The content should be prepared incorporating loudness and dynamic range information into 30 the bitstream also considering DRC Presentation Mode in ISO/IEC 14496-3 [9], Amd. 4.
DASH-AVC/264 V2.0 37
1 Decoders shall support decoding of loudness and dynamic range related information, i.e. 2 dynamic_range_info() and MPEG4_ancillary_data() in the bitstream. 3 Table 9 Codecs parameter according to RFC6381 [8] and ISO BMFF encapsula- 4 tion
Codec Codec Parame- ISO BMFF Encapsulation SAP type ter
MPEG-4 AAC mp4a.40.2 ISO/IEC 14496-14 [26] 1 Profile [9]
MPEG-4 HE- mp4a.40.5 ISO/IEC 14496-14 [26] 1 AAC Profile [9]
MPEG-4 HE- mp4a.40.29 ISO/IEC 14496-14 [26] 1 AAC v2 Pro- file [9]
5 Note: Since both, HE-AAC and HE-AACv2 are based on AAC-LC, for the above mentioned “Co- 6 dec Parameters” the following is implied: 7 mp4a.40.5 = AOT 2 + AOT 5 8 9.3. Client Implementation Guidelines 9 Independent of the codec, a client that supports one or more codecs of multichannel sound play- 10 back should exhibit the following characteristics: 11 Playback multichannel sound correctly given the client operating environment. As an ex- 12 ample, if the audio track delivers 5.1 multichannel sound, the client might perform one or 13 more of the following: decode the multichannel signal on the device and output either 6ch 14 PCM over HDMI, or pass that multichannel audio with no changes to external AVRs, or if 15 the device is rendering to stereo outputs such as headphones, either correctly downmix that 16 multi-channel audio to 2-channel sound, or select an alternate stereo adaptation set, or other 17 appropriate choices. 18 Adaptively and seamless switch between different bitrates as specified in the adaptation 19 sets according to the playback clients logic. Seamless switching is defined as no percepti- 20 ble interruption in the audio, and no loss of A/V sync. There is no expectation that a client 21 can seamlessly switch between formats. 22 9.4. Extensions 23 9.4.1. General 24 9.4.1.1. Definitions 25 A multichannel audio client at least supports the following features: 26 All DASH-related features as defined in section 3 of this document.
DASH-AVC/264 V2.0 38
1 content protection based on common encryption and key rotation as defined in section 5. 2 And specifically, the client supports MPD-based parsing and movie box based parsing of 3 DRM related parameters for common encryption. 4 The client implementation guidelines in section 9.3. 5 9.4.1.2. Recommendations 6 If content is offered claiming conformance to any extension in this section, the content author is 7 encouraged to use the HTTP-URL construction as defined in [3], section 5.1.4. 8 9.4.2. Dolby Extensions 9 9.4.2.1. Introduction 10 For the support of Dolby advanced audio support, two additional extensions are defined. 11 Compliance to DASH-IF multichannel audio extension with Enhanced AC-3 (Dolby Digital 12 Plus) [28] may be signaled by an @profile attribute with the value 13 "http://dashif.org/guidelines/dashif#ec-3". 14 Compliance to DASH-IF multichannel extension with Dolby TrueHD may be signaled by an 15 @profile attribute with the value "http://dashif.org/guide- 16 lines/dashif#mlpa". 17 9.4.2.2. Supporters 18 These extensions are supported by the following DASH IF members: Dolby, DTS, Fraunhofer, 19 BuyDRM, Sony. 20 9.4.2.3. Definition 21 Content may be authored claiming conformance to DASH-IF multichannel audio extension with 22 Enhanced AC-3 23 if the content is multichannel audio content as defined in section 9.4.1, and 24 if a client can properly play the content by supporting at least the following features 25 all multichannel audio client features as defined in section 9.4.1 26 Enhanced AC-3 (Dolby Digital Plus) [28] and the DASH-specific features defined in 27 section 9.2.1.2 28 Content may be authored claiming conformance to DASH-IF multichannel extension with Dolby 29 TrueHD 30 if the content is multichannel audio content as defined in section 9.4.1, and 31 if a client can be properly play the content by supporting at least the following features 32 all multichannel audio client features as defined in section 9.4.1 33 Dolby TrueHD and the DASH-specific features defined in section 9.2.1.2
DASH-AVC/264 V2.0 39
1 9.4.3. DTS-HD Interoperability Points 2 9.4.3.1. Introduction 3 For the support of DTS advanced audio support, four additional extensions are defined. 4 Compliance to DASH-IF multichannel audio extension with DTS Digital Surround may be sig- 5 naled by a @profile attribute with value "http://dashif.org/guide- 6 lines/dashif#dtsc". 7 Compliance to DASH-IF multichannel audio extension with DTS-HD High Resolution and DTS- 8 HD Master Audio may be signaled by a @profile attribute with value 9 "http://dashif.org/guidelines/dashif#dtsh" 10 Compliance to DASH-IF multichannel audio extension with DTS Express may be signaled by a 11 @profile attribute with value "http://dashif.org/guidelines/dashif#dtse" 12 Compliance to DASH-IF multichannel extension with DTS-HD Lossless (no core) may be signaled 13 by a @profile attribute with value "http://dashif.org/guide- 14 lines/dashif#dtsl" 15 9.4.3.2. Supporters 16 These extensions are supported by the following DASH IF members: Dolby, DTS, Fraunhofer, 17 BuyDRM, Sony. 18 9.4.3.3. Definition 19 Content may be authored claiming conformance to DASH-IF multichannel audio extension with 20 DTS Digital Surround 21 if the content is multichannel audio content as defined in section 9.4.1, and 22 if a client can be properly play the content by supporting at least the following features 23 all multichannel audio client features as defined in section 9.4.1 24 DTS and the DASH-specific features defined in section 9.2.2.2 25 Content may be authored claiming conformance to DASH-IF multichannel audio extension with 26 DTS-HD High Resolution and DTS-HD Master Audio 27 if the content is multichannel audio content as defined in section 9.4.1, and 28 if a client can be properly play the content by supporting at least the following features 29 all multichannel audio client features as defined in section 9.4.1 30 DTS-HD High Resolution and DTS-HD Master Audio and the DASH-specific features 31 defined in section 9.2.2.2 32 Content may be authored claiming conformance to DASH-IF multichannel audio extension with 33 DTS Express 34 if the content is multichannel audio content as defined in section 9.4.1, and 35 if a client can be properly play the content by supporting at least the following features
DASH-AVC/264 V2.0 40
1 all multichannel audio client features as defined in section 9.4.1 2 DTS-HD Express and the DASH-specific features defined in section 9.2.2.2 3 Content may be authored claiming conformance to DASH-IF multichannel extension with DTS- 4 HD Lossless (no core) 5 if the content is multichannel audio content as defined in section 9.4.1, and 6 if a client can be properly play the content by supporting at least the following features 7 all multichannel audio client features as defined in section 9.4.1 8 DTS-HD Lossless (no core) and the DASH-specific features defined in section 9.2.2.2 9 9.4.4. MPEG Surround Interoperability Points 10 9.4.4.1. Introduction 11 For the support of MPEG Surround advanced audio support the following extension is defined. 12 Compliance to DASH-IF multichannel audio extension with MPEG Surround according to 13 ISO/IEC 23003-1:2007 [31] may be signaled by an @profile attribute with the value 14 "http://dashif.org/guidelines/dashif#mps". 15 9.4.4.2. Supporters 16 These extensions are supported by the following DASH IF members: Dolby, DTS, Fraunhofer, 17 BuyDRM, Sony. 18 9.4.4.3. Definition 19 Content may be authored claiming conformance to DASH-IF multichannel audio extension with 20 MPEG Surround 21 if the content is multichannel audio content as defined in section 9.4.1, and 22 if a client can be properly play the content by supporting at least the following features 23 all multichannel audio client features as defined in section 9.4.1 24 ISO/IEC 23003-1:2007 and the DASH-specific features defined in section 9.2.3.2 25 9.4.5. MPEG HE-AAC Multichannel Interoperability Points 26 9.4.5.1. Introduction 27 Compliance to DASH-IF multichannel audio extension with HE-AACv2 level 4 [9] may be signaled 28 by an @profile attribute with the value "http://dashif.org/guide- 29 lines/dashif#heaac-mc51". 30 Compliance to DASH-IF multichannel audio extension with HE-AACv2 level 6 [9] may be signaled 31 by an @profile attribute with the value "http://dashif.org/guide- 32 lines/dashif#heaac-mc71".
DASH-AVC/264 V2.0 41
1 9.4.5.2. Supporters 2 These extensions are supported by the following DASH IF members: Dolby, DTS, Fraunhofer, 3 BuyDRM, Sony. 4 9.4.5.3. Definition 5 Content may be authored claiming conformance to DASH-IF multichannel audio extension with 6 HE-AACv2 level 4 7 if the content is multichannel audio content as defined in section 9.4.1, and 8 if a client can be properly play the content by supporting at least the following features 9 all multichannel audio client features as defined in section 9.4.1 10 HE-AACv2 level 4 [9] and the DASH-specific features defined in section 9.2.4.2 11 Content may be authored claiming conformance to DASH-IF multichannel audio extension with 12 HE-AACv2 level 6 13 if the content is multichannel audio content as defined in section 9.4.1, and 14 if a client can be properly play the content by supporting at least the following features 15 all multichannel audio client features as defined in section 9.4.1 16 HE-AACv2 level 6 [9] and the DASH-specific features defined in section 9.2.4.2
17 10. References 18 [1] ISO/IEC 23009-1:2012 Information technology -- Dynamic adaptive streaming over 19 HTTP (DASH) -- Part 1: Media presentation description and segment formats, Cor.1 20 (available as w13495). 21 [2] ISO/IEC 23009-2:2012 Information technology -- Dynamic adaptive streaming over 22 HTTP (DASH) -- Part 2: Conformance and Reference Software (2nd Study of DIS, avail- 23 able as w13512). 24 [3] ISO/IEC 23009-3:2012 Information technology -- Dynamic adaptive streaming over 25 HTTP (DASH) -- Part 3: Implementation Guidelines (Study of ISO/IEC PDTR, available 26 as w13514). 27 [4] ISO/IEC 14496-12:2012 Information technology -- Coding of audio-visual objects -- Part 28 12: ISO base media file format 29 [5] ISO/IEC 14496-10: Information technology -- Coding of audio-visual objects -- Part 10: 30 Advanced Video Coding 31 [6] ITU-T Recommendation H.264 (01/2012): "Advanced video coding for generic audiovis- 32 ual services" | ISO/IEC 14496-10:2010: "Information technology – Coding of audio-vis- 33 ual objects – Part 10: Advanced Video Coding". 34 [7] ISO/IEC 14496-15:2010 Information technology -- Coding of audio-visual objects -- Part 35 15: Advanced Video Coding (AVC) file format
DASH-AVC/264 V2.0 42
1 [8] IETF RFC 6381, The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types, Au- 2 gust 2011. 3 [9] ISO/IEC 14496-3:2009 - Information technology -- Coding of audio-visual objects -- Part 4 3: Audio with Corrigendum 1:2009, Corrigendum 2:2011, Corrigendum 3:2012, Amend- 5 ment 1:2009, Amendment 2:2010, Amendment 3:2012, and Amendment 4:2014. 6 [10] ISO/IEC 14496-12:2012 Information technology -- Coding of audio-visual objects -- Part 7 14: The MP4 File Format 8 [11] 3GPP (2005-01-04). "ETSI TS 126 401 V6.1.0 (2004-12) - Universal Mobile Telecom- 9 munications System (UMTS); General audio codec audio processing functions; Enhanced 10 aacPlus general audio codec; General description (3GPP TS 26.401 version 6.1.0 Release 11 6)" 12 [12] CEA-708-D: Digital Television (DTV) Closed Captioning, August 2008 13 [13] 3GPP TS 26.245: "Transparent end-to-end Packet switched Streaming Service (PSS); 14 Timed text format" 15 [14] W3C Timed Text Markup Language (TTML) 1.0, November 2010. 16 [15] SMPTE ST 2052: "Timed Text" 17 [16] W3C WebVTT - W3C Web Video Text Tracks, Living Standard — Last Updated 15 18 February 2012 19 [17] EBU Tech 3350, "EBU-TT, Part 1, Subtitling format definition", July 2012, 20 http://tech.ebu.ch/docs/tech/tech3350.pdf?vers=1.0 21 [18] IETF RFC2616, Hypertext Transfer Protocol -- HTTP/1.1, June 1999. 22 [19] Recommended Practice (Conversion from CEA 608 to SMPTE-TT) RP 2052-10-2012 23 https://www.smpte.org/sites/default/files/rp2052-10-2012.pdf 24 [20] ISO/IEC DIS 14496-30:2013, "Timed Text and Other Visual Overlays in ISO Base Media 25 File Format", August 2013. 26 [21] ISO/IEC 23001-7:2013 2nd Edition: "Information technology -- MPEG systems technol- 27 ogies -- Part 7: Common encryption in ISO base media file format files". 28 [22] MPEG M13478: "ISO/IEC 14496-15:2010/FDAM 2 Carriage of HEVC", April 2013. 29 [23] DASH Industry Forum, "Guidelines for Implementation: DASH-AVC/264 Test Cases 30 and Vectors", under development. 31 [24] DASH Industry Forum, "Guidelines for Implementation: DASH-AVC/264 Conformance 32 Software", under development. 33 [25] DASH Identifiers Repository, available here: http://dashif.org/identifiers 34 [26] ISO/IEC 14496-12:2012 Information technology -- Coding of audio-visual objects -- Part 35 14: The MP4 File Format 36 [27] DTS 9302J81100, “Implementation of DTS Audio in Media Files Based on ISO/IEC 37 14496”, http://www.dts.com/professionals/resources/resource-center.aspx
DASH-AVC/264 V2.0 43
1 [28] ETSI TS 102 366 v1.2.1, Digital Audio Compression (AC-3, Enhanced AC-3) Standard 2 (2008-08) 3 [29] MLP (Dolby TrueHD) streams within the ISO Base Media File Format, version 1.0, Sep- 4 tember 2009. 5 [30] ETSI TS 102 114 v1.3.1 (2011-08), “DTS Coherent Acoustics; Core and Extensions with 6 Additional Profiles” 7 [31] ISO/IEC 23003-1:2007 - Information technology -- MPEG audio technologies -- Part 1: 8 MPEG Surround 9 [32] DTS 9302K62400, “Implementation of DTS Audio in Dynamic Adaptive Streaming over 10 HTTP (DASH)”, http://www.dts.com/professionals/resources/resource-center.aspx 11 [33] IETF RFC5905, "Network Time Protocol Version 4: Protocol and Algorithms Specifica- 12 tion," June 2010. 13 [34] ISO/IEC 14496-12:2012 Amd.2 Information technology -- Coding of audio-visual ob- 14 jects -- Part 12: ISO base media file format - Amendment 2: Carriage of timed text and 15 other visual overlays.
16 11. Annex A: Examples for Profile Signalling 17 11.1. Example 1 18 In this case DASH-AVC/264 content is offered, but in addition a non-conforming Adaptation Set 19 is added. 20 Here is an example for an MPD: 21 MPD@profiles="urn:mpeg:dash:profile:isoff-on-demand:2011, 22 http://dashif.org/guidelines/dash264" 23 o AdaptationSet@profiles="urn:mpeg:dash:profile:isoff-on-de- 24 mand:2011, http://dashif.org/guidelines/dash264" 25 o AdaptationSet@profiles ="http://dashif.org/guidelines/dash264" 26 o AdaptationSet@profiles ="urn:mpeg:dash:profile:isoff-on-de- 27 mand:2011" 28 Pruning process for IOP http://dashif.org/guidelines/dash264 results in 29 MPD@profiles ="http://dashif.org/guidelines/dash264" 30 o AdaptationSet@profiles ="http://dashif.org/guidelines/dash264" 31 o AdaptationSet@profiles ="http://dashif.org/guidelines/dash264" 32 It is now required that the pruned MPD conforms to DASH-AVC/264. 33 11.2. Example 2 34 In this case DASH-AVC/264 content is offered, but in addition a non-conforming Adaptation Set 35 is added and one DASH-IF Example Extension Adaptation Set is added with the virtual IOP signal 36 http://dashif.org/guidelines/dashif#extension-example. 37 Here is an example for an MPD:
DASH-AVC/264 V2.0 44
1 MPD@profiles ="urn:mpeg:dash:profile:isoff-on-demand:2011, 2 http://dashif.org/guidelines/dash264, http://dashif.org/guide- 3 lines/dashif#extension-example" 4 o @id = 1, AdaptationSet@profiles ="urn:mpeg:dash:profile:isoff-on- 5 demand:2011, http://dashif.org/guidelines/dash264" 6 o @id = 2, AdaptationSet@profiles ="http://dashif.org/guide- 7 lines/dash264" 8 o @id = 3, AdaptationSet@profiles ="urn:mpeg:dash:profile:isoff-on- 9 demand:2011, http://dashif.org/guidelines/dashif#extension-exam- 10 ple" 11 Pruning process for profile http://dashif.org/guidelines/dash264 results in 12 MPD@profiles="http://dashif.org/guidelines/dash264" 13 o @id = 1, AdaptationSet@profiles="http://dashif.org/guide- 14 lines/dash264" 15 o @id = 2, AdaptationSet@profiles="http://dashif.org/guide- 16 lines/dash264" 17 It is now required that the pruned MPD conforms to DASH-AVC/264. 18 Pruning process for profile http://dashif.org/guidelines/dashif#extension-example re- 19 sults in 20 MPD@profiles="http://dashif.org/guidelines/dash264" 21 o @id = 3, AdaptationSet@profiles="http://dashif.org/guide- 22 lines/dashif# extension-example" 23 It is now required that the pruned MPD conforms to DASH-IF Example Extension Adaptation Set.
24 12. Document History 25 Version 1.00: Initial publication of IOPs. 26 Version 1.01: Change http://dashif.org/metadata to http://dashif.org/identifiers. 27 Version 1.02: Correct application/xml+ttml to application/ttml+xml. 28 Version 1.03: Updated the disclaimer section. 29 Version 2.00: Addition of HD (8) and multichannel extensions (9), and clarifications on relatives 30 ‘moof’ addressing (3.2.1), synchronization considerations (3.4.2), live services considerations 31 (3.5) and audio loudness and dynamic range (9.2.4.2). 32
DASH-AVC/264 V2.0 45