idnits 2.17.1 draft-ietf-payload-rtp-mvc-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1050 has weird spacing: '... (the medi...' -- The document date (June 25, 2012) is 4323 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4648' is mentioned on line 889, but not defined == Missing Reference: 'I-D.draft-ietf-avt-svc' is mentioned on line 1262, but not defined == Missing Reference: 'RFC3984' is mentioned on line 1259, but not defined ** Obsolete undefined reference: RFC 3984 (Obsoleted by RFC 6184) == Unused Reference: 'RFC3548' is defined on line 1121, but no explicit reference was found in the text == Unused Reference: 'DVB-H' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'IGMP' is defined on line 1142, but no explicit reference was found in the text == Unused Reference: 'McCanne' is defined on line 1146, but no explicit reference was found in the text == Unused Reference: 'MBMS' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'MPEG2' is defined on line 1154, but no explicit reference was found in the text == Unused Reference: 'RFC3450' is defined on line 1156, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MPEG4-10' ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3450 (Obsoleted by RFC 5775) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio/Video Transport Payloads WG Y.-K. Wang 2 Internet Draft Qualcomm Inc. 3 Intended status: Standards track T. Schierl 4 Expires: December 2012 Fraunhofer HHI 5 R. Skupin 6 Fraunhofer HHI 7 P. Yue 8 Huawei Technologies 9 June 25, 2012 11 RTP Payload Format for MVC Video 12 draft-ietf-payload-rtp-mvc-02.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on December 25, 2012. 31 Copyright Notice 33 Copyright (c) 2012 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with 41 respect to this document. Code Components extracted from this 42 document must include Simplified BSD License text as described in 43 Section 4.e of the Trust Legal Provisions and are provided without 44 warranty as described in the Simplified BSD License. 46 Abstract 48 This memo describes an RTP payload format for Multiview Video Coding 49 (MVC), the multiview extension of the ITU-T Recommendation H.264 50 video codec that is technically identical to ISO/IEC International 51 Standard 14496-10. The RTP payload format allows for packetization 52 of one or more Network Abstraction Layer (NAL) units, produced by 53 the video encoder, in each RTP payload. The payload format can be 54 applied in RTP based 3D video transmissions such as such as 3D video 55 streaming, free-viewpoint video, and 3DTV. 57 Table of Contents 59 1. Introduction...................................................3 60 1.1. The MVC Codec.............................................4 61 1.1.1. Overview.............................................4 62 1.1.2. Parameter Set Concept................................4 63 1.1.3. Network Abstraction Layer Unit Header................5 64 1.2. Overview of the Payload Format............................7 65 1.2.1. Design Principles....................................8 66 1.2.2. Transmission Modes and Packetization Modes...........8 67 2. Conventions....................................................8 68 3. Definitions and Abbreviations..................................9 69 3.1. Definitions...............................................9 70 3.1.1. Definitions per MVC specification....................9 71 3.1.2. Definitions Specific to this memo...................10 72 3.1. Abbreviations............................................11 73 4. MVC RTP Payload Format........................................11 74 4.1. RTP Header Usage.........................................11 75 4.2. Common Structure of the RTP Payload Format...............11 76 4.3. NAL Unit Header Usage....................................11 77 4.4. Packetization Modes......................................12 78 4.4.1. Packetization Modes for single-session transmission.12 79 4.4.2. Packetization Modes for multi-session transmission..13 80 4.5. Aggregation Packets......................................13 81 4.6. Fragmentation Units (FUs)................................13 82 4.7. Payload Content Scalability Information (PACSI) NAL Unit for 83 MVC...........................................................13 84 4.8. Non-Interleaved Multi-Time Aggregation Packets (NI-MTAPs)17 85 4.9. Cross-Session DON (CS-DON) for multi-session transmission17 86 5. Packetization Rules...........................................17 87 6. De-Packetization Process (Informative)........................19 88 7. Payload Format Parameters.....................................19 89 7.1. Media Type Registration..................................19 90 7.2. SDP Parameters...........................................24 91 7.2.1. Mapping of Payload Type Parameters to SDP...........24 92 7.2.2. Usage with the SDP Offer/Answer Model...............24 93 7.2.3. Usage with multi-session transmission...............24 94 7.2.4. Usage in Declarative Session Descriptions...........24 95 7.3. Examples.................................................24 96 7.4. Parameter Set Considerations.............................24 97 8. Security Considerations.......................................24 98 9. Congestion Control............................................25 99 10. IANA Considerations..........................................25 100 11. Acknowledgments..............................................25 101 12. References...................................................25 102 12.1. Normative References....................................25 103 12.2. Informative References..................................26 104 Author's Addresses...............................................26 105 13. Open issues..................................................27 106 14. Changes Log..................................................28 108 1. Introduction 110 This memo specifies an RTP [RFC3550] payload format for the 111 multiview extension of the H.264/AVC video coding standard, also 112 known as Multiview Video Coding (MVC). MVC is specified in Annex H 113 of ITU-T Rec. H.264 [H.264] | ISO/IEC 14496 Part 10 [MPEG4-10]. 115 MVC covers a wide range of 3D video applications, including 3D video 116 streaming, free-viewpoint video as well as 3DTV. 118 This memo follows a backward compatible enhancement philosophy, by 119 keeping as close an alignment to the H.264/AVC payload format 120 [RFC6184] as possible. It documents the enhancements relevant from 121 an RTP transport viewpoint, and defines signaling support for MVC, 122 including a new media subtype name. 124 Due to the similarity between MVC and Scalable Video Coding (SVC), 125 as defined in Annex G of H.264 [H.264], in system and transport 126 aspects, this memo reuses the design principles as well as many 127 features of the SVC RTP payload draft [RFC6190]. 129 [Ed.Note(TS):Need text on session multiplexing and on the relation 130 of this draft to [RFC6190] here.] 132 1.1. The MVC Codec 134 1.1.1. Overview 136 MVC provides multi-view video bitstreams. An MVC bitstream contains 137 a base view conforming to at least one of the profiles of H.264/AVC 138 defined in Annex A of [H.264], and one or more non-base views. To 139 enable high compression efficiency, coding of a non-base view can 140 utilize other views for inter-view prediction, thus its decoding 141 relies on the presence of the views it depends on. Each coded view 142 itself may be temporally scalable. Besides temporal scalability, 143 MVC also supports view scalability, wherein a subset of the encoded 144 views can be extracted, decoded and displayed, whenever it is 145 desired by the application. 147 The concept of video coding layer (VCL) and network abstraction 148 layer (NAL) is inherited from H.264/AVC. The VCL contains the 149 signal processing functionality of the codec; mechanisms such as 150 transform, quantization, motion-compensated prediction, loop 151 filtering and inter-view prediction. The NAL encapsulates each 152 slice generated by the VCL into one or more NAL units. Please 153 consult RFC 6184 for a more in-depth discussion of the NAL unit 154 concept. MVC specifies the decoding order of NAL units. 156 In MVC, one access unit contains all NAL units pertaining to one 157 output time instance for all the views. Within one access unit, the 158 coded representation of each view, also named as view component, 159 consists of one or more slices. 161 The concept of temporal scalability is not newly introduced by SVC 162 or MVC, as profiles defined in Annex A of [H.264] already support 163 it. In [H.264], sub-sequences have been introduced in order to 164 allow optional use of temporal layers. SVC extended this approach 165 by advertising the temporal scalability information within the NAL 166 unit header or prefix NAL units, both were inherited to MVC. 168 1.1.2. Parameter Set Concept 170 The parameter set concept was first specified in [H.264]. Please 171 refer to section 1.2 of [RFC6184] for more details. SVC introduced 172 some new parameter set mechanisms. MVC has inherited the parameter 173 set concept from [H.264]. 175 In particular, a different type of sequence parameter set (SPS), 176 which is referred to as subset SPS, using a different NAL unit type 177 than "the old SPS" specified in [H.264] is used for non-base views, 178 while the base view still uses "the old SPS". Slices from different 179 views would be able to use either 1) the same sequence or picture 180 parameter set, or 2) different sequence or picture parameter sets. 182 The inter-view dependency and the decoding order of all the encoded 183 views are indicated in a new syntax structure, the SPS MVC 184 extension, included in each subset SPS. 186 1.1.3. Network Abstraction Layer Unit Header 188 An MVC NAL unit of type 20 or 14 consists of a header of four octets 189 and the payload byte string. MVC NAL units of type 20 are coded 190 slices of non-base views. A special type of an MVC NAL unit is the 191 prefix NAL unit (type 14) that includes descriptive information of 192 the associated H.264/AVC VCL NAL unit (type 1 or 5) that immediately 193 follows the prefix NAL unit. 195 MVC extends the one-byte H.264/AVC NAL unit header by three 196 additional octets. The header indicates the type of the NAL unit, 197 information regarding the relative importance of the NAL unit for 198 the decoding process, the view identification information, the 199 temporal layer identification information, and other fields as 200 discussed below. 202 The syntax and semantics of the NAL unit header are formally 203 specified in [H.264], but the essential properties of the NAL unit 204 header are summarized below. 206 The first byte of the NAL unit header has the following format (the 207 bit fields are the same as defined for the one-byte H.264/AVC NAL 208 unit header, while the semantics of some fields have changed 209 slightly, in a backward compatible way): 211 +---------------+ 212 |0|1|2|3|4|5|6|7| 213 +-+-+-+-+-+-+-+-+ 214 |F|NRI| Type | 215 +---------------+ 217 F: 1 bit 219 forbidden_zero_bit. H.264/AVC declares a value of 1 as a syntax 220 violation. 222 NRI: 2 bits 224 nal_ref_idc. A value of 00 indicates that the content of the NAL 225 unit is not used to reconstruct reference pictures for future 226 prediction. Such NAL units can be discarded without risking the 227 integrity of the reference pictures in the same view. A value 228 higher than 00 indicates that the decoding of the NAL unit is 229 required to maintain the integrity of reference pictures in the same 230 view, or that the NAL unit contains parameter sets. 232 Type: 5 bits 234 nal_unit_type. This component specifies the NAL unit type. 236 In H.264/AVC, NAL unit types 14 and 20 are reserved for future 237 extensions. MVC uses these two NAL unit types. NAL unit type 14 is 238 used for prefix NAL unit, and NAL unit type 20 is used for coded 239 slice of non-base view. NAL unit types 14 and 20 indicate the 240 presence of three additional octets in the NAL unit header, as shown 241 below. 243 +---------------+---------------+---------------+ 244 |0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7|0|1|2|3|4|5|6|7| 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |S|I| PRID | VID | TID |A|V|O| 247 +---------------+---------------+---------------+ 249 S: 1 bit 251 svc_extention_flag. MUST be equal to 0 in MVC context. In the 252 context of Scalable Video Coding (SVC), the flag must be equal to 1. 254 I: 1 bit 256 non_idr_flag. This component specifies whether the access unit the 257 NAL unit belongs to is an IDR access unit (when equal to 0) or not 258 (when equal to 1), as specified in [H.264]. 260 PRID: 6 bits 262 priority_id. This flag specifies a priority identifier for the NAL 263 unit. A lower value of PRID indicates a higher priority. 265 VID: 10 bits 267 view_id. This component specifies the view identifier of the view 268 the NAL unit belongs to. 270 TID: 3 bits 271 temporal_id. This component specifies the temporal layer (or frame 272 rate) hierarchy. Informally put, a temporal layer consisting of 273 view component with a less temporal_id corresponds to a lower frame 274 rate. A given temporal layer typically depends on the lower 275 temporal layers (i.e. the temporal layers with less temporal_id 276 values) but never depends on any higher temporal layer (i.e. a 277 temporal layer with a greater temporal_id value). 279 A: 1 bit 281 anchor_pic_flag. This component specifies whether the access unit 282 the NAL unit belongs to is an anchor access unit (when equal to 1) 283 or not (when equal to 0), as specified in [H.264]. 285 V: 1 bit 287 inter_view_flag. This component specifies whether the view 288 component is used for inter-view prediction (when equal to 1) or not 289 (when equal to 0). 291 O: 1 bit 293 reserved_one_bit. Reserved bit for future extension. R shall be 294 equal to 1. Receivers SHOULD ignore the value of 295 reserved_zero_one_bit. This memo reuses the same additional NAL 296 unit types introduced in RFC 6190, which are presented in section 297 4.2. In addition, this memo introduces one more NAL unit type, 30, 298 as specified in section 4.7. These NAL unit types are marked as 299 unspecified in [H.264] and intentionally reserved for use in systems 300 specifications like this memo. Moreover, this specification extends 301 the semantics of F, NRI, PRID, TID, A, and I as described in section 302 4.3. 304 1.2. Overview of the Payload Format 306 This payload specification can only be used to carry the "naked" NAL 307 unit stream over RTP, and not the byte stream format according to 308 Annex B of [H.264]. Likely, the applications of this specification 309 will be in the IP based multimedia communications fields including 310 3D video streaming over IP, free-viewpoint video over IP, and 3DTV 311 over IP. 313 This specification allows, in a given RTP packet stream, to 314 encapsulate NAL units belonging to 315 o the base view only, detailed specification in [RFC6184], or 317 o one or more non-base views, or 319 o the base view and one or non-base views 321 [Ed.Note(YkW): To be extended to allow separate carriage of 322 different temporal layers in different RTP packet streams as in 323 [RFC6190].] 325 1.2.1. Design Principles 327 The following design principles have been observed: 329 o Backward compatibility with [RFC6184] wherever possible. 331 o As the MVC base view is H.264/AVC compatible, the base view or 332 any H.264/AVC compatible subset of it, when transmitted in its 333 own RTP packet stream, MUST be encapsulated using [RFC6184]. 334 Requiring this has the desirable side effect that the 335 transmitted data can be received by [RFC6184] receivers and 336 decoded by H.264/AVC decoders. 338 o Media-Aware Network Elements (MANEs) as defined in [RFC6184] 339 are signaling aware and rely on signaling information. MANEs 340 have state. 342 o MANEs can aggregate multiple RTP streams, possibly from 343 multiple RTP sessions. 345 o MANEs can perform media-aware stream thinning. By using the 346 payload header information identifying Layers within an RTP 347 session, MANEs are able to remove packets from the incoming RTP 348 packet stream. This implies rewriting the RTP headers of the 349 outgoing packet stream and rewriting of RTCP Receiver Reports. 351 1.2.2. Transmission Modes and Packetization Modes 353 Please see section 1.2.2 of [RFC6190]. 355 2. Conventions 357 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 358 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 359 document are to be interpreted as described in BCP 14, RFC 2119 360 [RFC2119]. 362 This specification uses the notion of setting and clearing a bit 363 when bit fields are handled. Setting a bit is the same as assigning 364 that bit the value of 1 (On). Clearing a bit is the same as 365 assigning that bit the value of 0 (Off). 367 3. Definitions and Abbreviations 369 3.1. Definitions 371 3.1.1. Definitions per the MVC Specification 373 This document uses the definitions of [H.264]. The following terms, 374 defined in [H.264], are summed up for convenience: 376 access unit: A set of NAL units always containing exactly one 377 primary coded picture with one or more view components. In addition 378 to the primary coded picture, an access unit may also contain one or 379 more redundant coded pictures, one auxiliary coded picture, or other 380 NAL units not containing slices or slice data partitions of a coded 381 picture. The decoding of an access unit always results in one 382 decoded picture. All slices or slice data partitions in an access 383 unit have the same value of picture order count. 385 anchor access unit: An access unit in which the primary coded picture 386 is an anchor picture. 388 anchor picture: A coded picture in which all slices may reference 389 only slices within the same access unit, i.e., inter-view prediction 390 may be used, but no inter prediction is used, and all following coded 391 pictures in output order do not use inter prediction from any picture 392 prior to the coded picture in decoding order. The value of 393 anchor_pic_flag is equal to 1 for all the prefix NAL units (when 394 present) and all the slice extension NAL units that are contained in 395 an anchor picture. 397 base view: A bitstream subset that contains all the NAL units with 398 the nal_unit_type syntax element equal to 1, 5 or 14 of the bitstream 399 and does not contain any NAL unit with the nal_unit_type syntax 400 element equal to 15, or 20 and conforms to one or more of the 401 profiles specified in Annex A of [H.264]. 403 prefix NAL unit: A NAL unit with nal_unit_type equal to 14 that 404 immediately precedes a NAL unit with nal_unit_type equal to 1, 5, 405 or 12. The NAL unit that succeeds the prefix NAL unit is also 406 referred to as the associated NAL unit. The prefix NAL unit 407 contains data associated with the associated NAL unit, which are 408 considered to be part of the associated NAL unit. 410 target output view: A view that is targeted for output. 412 view component: An access unit subset containing only NAL units that 413 share to the same view identifier. 415 3.1.2. Definitions Specific to this Memo 417 MVC NAL unit: A NAL unit of NAL unit type 14 or 20 as specified in 418 Annex H of [H.264]. An MVC NAL unit has a four-byte NAL unit header. 420 operation point: An operation point of an MVC bitstream represents 421 a certain level of temporal and view scalability. An operation 422 point contains only those NAL units required for a valid bitstream 423 to represent a certain subset of views at a certain temporal level. 424 An operation point is described by the view_id values of the subset 425 of views, and the highest temporal_id. 427 multi-session transmission: The transmission mode in which the MVC 428 bitstream is transmitted over multiple RTP sessions, with each 429 stream having the same SSRC. These multiple RTP streams can be 430 associated using the RTCP CNAME, or explicit signalling of the SSRC 431 used. Dependency between RTP sessions MUST be signaled according to 432 [RFC5583] and this memo. 434 single-session transmission: The transmission mode in which the MVC 435 bitstream is transmitted over a single RTP session, with a single 436 SSRC and separate timestamp and sequence number spaces. 438 cross-session decoding order number (CS-DON): A derived variable 439 indicating NAL unit decoding order number over all NAL units within 440 all the session-multiplexed RTP sessions that carry the same MVC 441 bitstream. 443 [Ed.Note(TS):Need more definitions here.] 445 3.1. Abbreviations 447 In addition to the abbreviations defined in [RFC6184], the following 448 ones are defined. 450 MVC: Multiview Video Coding 451 CS-DON: Cross-Session Decoding Order Number 452 MST: multi-session transmission 453 PACSI: Payload Content Scalability Information 454 SST: single-session transmission 456 4. MVC RTP Payload Format 458 4.1. RTP Header Usage 460 Please see section 5.1 of [RFC6184]. 462 4.2. Common Structure of the RTP Payload Format 464 Please see section 5.2 of [RFC6184]. 466 4.3. NAL Unit Header Usage 468 The structure and semantics of the NAL unit header were introduced 469 in section 1.1.3. This section specifies the semantics of F, NRI, 470 PRID, TID, A and I according to this specification. 472 Note that, in the context of this section, "protecting a NAL unit" 473 means any RTP or network transport mechanism that could improve the 474 probability of success delivery of the packet conveying the NAL 475 unit, including applying a QoS-enabled network, forward error 476 correction (FEC), retransmissions, and advanced scheduling behavior, 477 whenever possible. 479 The semantics of F specified in section 5.3 of [RFC6184] also 480 applies herein. 482 For NRI, for a bitstream conforming to one of the profiles defined 483 in Annex A of [H.264] and transported using [RFC6184], the semantics 484 specified in section 5.3 of [RFC6184] are applicable, i.e., NRI also 485 indicates the relative importance of NAL units. In MVC context, in 486 addition to the semantics specified in Annex H of [H.264] are 487 applicable, NRI also indicate the relative importance of NAL units 488 within a view. MANEs MAY use this information to protect more 489 important NAL units better than less important NAL units. 490 [Ed.Note(YkW): "MVC context" to be clearly specified.] 491 For PRID, the semantics specified in Annex H of [H.264] applies. 492 Note that MANEs implementing unequal error protection MAY use this 493 information to protect NAL units with smaller PRID values better 494 than those with larger PRID values, for example by including only 495 the more important NAL units in a forward error correction (FEC) 496 protection mechanism. The importance for the decoding process 497 decreases as the PRID value increases. 499 For TID, in addition to the semantics specified in Annex H of 500 [H.264], according to this memo, values of TID indicate the relative 501 importance. A lower value of TID indicates a higher importance for 502 NAL units within a view. MANEs MAY use this information to protect 503 more important NAL units better than less important NAL units. 505 For A, in addition to the semantics specified in Annex H of [H.264], 506 according to this memo, MANEs MAY use this information to protect 507 NAL units with A equal to 1 better than NAL units with A equal to 0. 508 MANEs MAY also utilize information of NAL units with A equal to 1 to 509 decide when to forward more packets for an RTP packet stream. For 510 example, when it is sensed that view switching has happened such 511 that the operation point has changed, MANEs MAY start to forward NAL 512 units for a new target view only after forwarding a NAL unit with A 513 equal to 1 for the new target view. 515 For I, in addition to the semantics specified in Annex H of [H.264], 516 according to this memo, MANEs MAY use this information to protect 517 NAL units with I equal to 1 better than NAL units with I equal to 0. 518 MANEs MAY also utilize information of NAL units with I equal to 1 to 519 decide when to forward more packets for an RTP packet stream. For 520 example, when it is sensed that view switching has happened such 521 that the operation point has changed, MANEs MAY start to forward NAL 522 units for a new target view only after forwarding a NAL unit with I 523 equal to 1 for the new target view. 525 4.4. Packetization Modes 527 [Ed.Note(TS): Need to add text from [RFC6190] to this section with 528 respect to MVC.] 530 4.4.1. Packetization Modes for Single-Session Transmission 532 This section will address the issues of section 4.5.1 and 5.1 of 533 [RFC6190]. 535 4.4.2. Packetization Modes for Multi-Session Transmission 537 This section will address the issues of section 4.5.2 and 5.2 of 538 [RFC6190]. 540 4.5. Aggregation Packets 542 This section will address the issues of section 4.7 of [RFC6190]. 544 4.6. Fragmentation Units (FUs) 546 This section will address the issues of section 4.8 of [RFC6190]. 548 4.7. Payload Content Scalability Information (PACSI) NAL Unit for MVC 550 A new NAL unit type is specified in this memo, and referred to as 551 payload content scalability information (PACSI) NAL unit. The PACSI 552 NAL unit, if present, MUST be the first NAL unit in an aggregation 553 packet, and it MUST NOT be present in other types of packets. The 554 PACSI NAL unit indicates view and temporal scalability information 555 and other characteristics that are common for all the remaining NAL 556 units in the payload of the aggregation packet. Furthermore, a PACSI 557 NAL unit MAY include a DONC field and contain zero or more SEI NAL 558 units. PACSI NAL unit makes it easier for MANEs to decide whether 559 to forward/process/discard the aggregation packet containing the 560 PACSI NAL unit. Senders MAY create PACSI NAL units and receivers 561 MAY ignore them, or use them as hints to enable efficient 562 aggregation packet processing. Note that the NAL unit type for the 563 PACSI NAL unit is selected among those values that are unspecified 564 in [H.264] and [RFC6184]. 566 When the first aggregation unit of an aggregation packet contains a 567 PACSI NAL unit, there MUST be at least one additional aggregation 568 unit present in the same packet. The RTP header and payload header 569 fields of the aggregation packet are set according to the remaining 570 NAL units in the aggregation packet. 572 When a PACSI NAL unit is included in a multi-time aggregation packet 573 (MTAP), the decoding order number (DON) for the PACSI NAL unit MUST 574 be set to indicate that the PACSI NAL unit has an identical DON to 575 the first NAL unit in decoding order among the remaining NAL units 576 in the aggregation packet. 578 The structure of a PACSI NAL unit is as follows. The first four 579 octets are exactly the same as the four-byte MVC NAL unit header as 580 discussed in section 4.3. They are followed by two always present 581 octet, two optional octets, and zero or more SEI NAL units, each SEI 582 NAL unit preceded by a 16-bit unsigned size field (in network byte 583 order) that indicates the size of the following NAL unit in bytes 584 (excluding these two octets, but including the NAL unit type octet 585 of the SEI NAL unit). Figure 1 illustrates the PACSI NAL unit 586 structure and an example of a PACSI NAL unit containing two SEI NAL 587 units. 589 The bits P, C, S, and E are specified only if the bit X is equal to 590 1. The T bit MUST NOT be equal to 1 if the aggregation packet 591 containing the PACSI NAL unit is not an STAP-A packet. The T bit 592 MAY be equal to 1 if the aggregation packet containing the PACSI NAL 593 unit is an STAP-A packet. The field DONC MUST NOT be present if the 594 T bit is equal to 0, and MUST be present if the T bit is equal to 1. 596 0 1 2 3 597 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |F|NRI| Type |S| PRID | TID |A| VID |I|V|R| 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 |X|T|RR |P|C|S|E| RRR | DONC (optional) | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | NAL unit size 1 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SEI NAL unit 1 | 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | NAL unit size 2 | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SEI NAL unit 2 | 609 | | 610 | +-+-+-+-+-+-+-+-+ 611 | | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Figure 1. PACSI NAL unit structure 616 The values of the fields in PACSI NAL unit MUST be set as follows. 617 The term "target NAL units" are used in the semantics of some 618 fields. The target NAL units are such NAL units contained in the 619 aggregation packet, but not included in the PACSI NAL unit, that are 620 within the access unit to which the first NAL unit following the 621 PACSI NAL unit in the aggregation packet belongs. 623 o The F bit MUST be set to 1 if the F bit in at least one of the 624 remaining NAL units in the aggregation packet is equal to 1. 625 Otherwise, the F bit MUST be set to 0. 627 o The NRI field MUST be set to the highest value of NRI field among 628 all the remaining NAL units in the aggregation packet. 630 o The Type field MUST be set to 30. 632 o The S bit MUST be set to 1. 634 o The PRID field MUST be set to the lowest value of the PRID values 635 of all the remaining NAL units in the aggregation packet. 637 o The TID field MUST be set to the lowest value of the TID values of 638 all the remaining NAL units with the lowest value of VID in the 639 aggregation packet. 641 o The A bit MUST be set to 1 if the A bit of at least one of the 642 remaining NAL units in the aggregation packet is equal to 1. 643 Otherwise, the A bit MUST be set to 0. 645 o The VID field MUST be set to the lowest value of the VID values of 646 all the remaining NAL units in the aggregation packet. 648 o The I bit MUST be set to 1 if the I bit of at least one of the 649 remaining NAL units in the aggregation packet is equal to 1. 650 Otherwise, the I bit MUST be set to 0. 652 o The V bit MUST be set to 1 if the V bit of at least one of the 653 remaining NAL units in the aggregation packet is equal to 1. 654 Otherwise, the A bit MUST be set to 0. 656 o The R bit MUST be set to 0. Receivers SHOULD ignore the value of 657 R. 659 o If the X bit is equal to 1, the bits P, C, S, and E are specified 660 as below. Otherwise, the bits P, C, S, and E are unspecified, and 661 receivers MUST ignore these bits. The X bit SHOULD be identical for 662 all the PACSI NAL units involved in all the RTP sessions conveying 663 an MVC bitstream. 665 o The RR field MUST be set to '00' (in binary form). Receivers 666 SHOULD ignore the value of RR. 668 o If the T bit is equal to 1, the OPTIONAL field DONC MUST be 669 present and specified as below. Otherwise, the field DONC MUST NOT 670 be present. 672 o The P bit MUST be set to 1 if all the remaining NAL units in the 673 aggregation packet are with redundant_pic_cnt higher than 0, i.e. 675 the slices are redundant slices. Otherwise, the P bit MUST be set 676 to 0. 678 Informative note: The P bit indicates whether the packet can be 679 discarded because it contains only redundant slice NAL units. 680 Without this bit, the corresponding information can be concluded 681 from the syntax element redundant_pic_cnt, which is buried in the 682 variable-length coded slice header. 684 o The C bit MUST be set to 1 if the target NAL units belong to an 685 access unit for which the view components are intra coded. 686 Otherwise, the C bit MUST be set to 0. The C bit SHOULD be 687 identical for all the PACSI NAL units for which the target NAL units 688 belong to the same access unit. 690 Informative note: The C bit indicates whether the packet contains 691 intra slices which may be the only packets to be forwarded for a 692 fast forward playback, e.g. when the network condition is 693 extremely bad. 695 o The S bit MUST be set to 1, if the first VCL NAL unit, in 696 transmission order, of the view component containing the first NAL 697 unit following the PACSI NAL unit in the aggregation packet is 698 present in the aggregation packet. Otherwise, the S bit MUST be set 699 to 0. 701 o The E bit MUST be set to 1, if the last VCL NAL unit, in 702 transmission order, of the view component containing the first NAL 703 unit following the PACSI NAL unit in the aggregation packet is 704 present in the aggregation packet. Otherwise, the E field MUST be 705 set to 0. 707 Informative note: The S or E bit indicates whether the first or 708 last slice, in transmission order, of a view component is in the 709 packet, to enable a MANE to detect slice loss and take proper 710 action such as requesting a retransmission as soon as possible, 711 as well as to allow an efficient playout buffer handling 712 similarly as the M bit in the RTP header. The M bit in the RTP 713 header still indicates the end of an access unit, not the end of 714 a view component. 716 o The RRR field MUST be set to '00000000'(in binary form). 717 Receivers SHOULD ignore the value of RRR. 719 o When present, the field DONC indicates the CL-DON value for the 720 first NAL unit in the STAP-A in transmission order. 722 SEI NAL units included in the PACSI NAL unit, if any, MUST contain a 723 subset of the SEI messages associated with the access unit of the 724 first NAL unit following the PACSI NAL unit within the aggregation 725 packet. 727 Informative note: Senders may repeat such SEI NAL units in the 728 PACSI NAL unit the presence of which in more than one packet is 729 essential for packet loss robustness. Receivers may use the 730 repeated SEI messages in place of missing SEI messages. 732 An SEI message SHOULD NOT be included in a PACSI NAL unit and 733 included in one of the remaining NAL units contained in the same 734 aggregation packet. 736 4.8. Non-Interleaved Multi-Time Aggregation Packets (NI-MTAPs) 738 This section will address the issues of section 4.7.1 of [RFC6190]. 740 4.9. Cross-Session DON (CS-DON) for Multi-Session Transmission 742 This section will address the issues of section 4.11 of [RFC6190]. 744 5. Packetization Rules 746 [Ed.Note(TS): We need to adjust this section with respect to 747 [RFC6190].] 749 Section 6 of [RFC6184] applies. The following rules apply in 750 addition. 752 All receivers MUST support the single NAL unit packetization mode to 753 provide backward compatibility to endpoints supporting only the 754 single NAL unit mode of RFC 3984. However, the single NAL unit 755 packetization mode SHOULD NOT be used whenever possible, because 756 encapsulating NAL units of small sizes, e.g. small NAL units 757 containing parameter sets, SEI messages or prefix NAL units, in 758 their own packets is typically less efficient because of the 759 relatively big overhead. 761 All receivers MUST support the non-interleaved packetization mode. 763 Informative note: The non-interleaved mode allows an application 764 to encapsulate a single NAL unit in a single RTP packet. 765 Historically, the single NAL unit mode has been included into 766 [RFC6184] only for compatibility with ITU-T Rec. H.241 Annex A 767 [H.241]. There is no point in carrying this historic ballast 768 towards a new application space such as the one provided with 769 MVC. More technically speaking, the implementation complexity 770 increase for providing the additional mechanisms of the non- 771 interleaved mode (namely STAP-A and FU-A) is minor, and the 772 benefits are great, that STAP-A implementation is required. 774 A NAL unit of small size SHOULD be encapsulated in an aggregation 775 packet together with one or more other NAL units. For example, non- 776 VCL NAL units such as access unit delimiter, parameter set, or SEI 777 NAL unit are typically small. 779 A prefix NAL unit SHOULD be aggregated to the same packet as the 780 associated NAL unit following the prefix NAL unit in decoding order. 782 When the first aggregation unit of an aggregation packet contains a 783 PACSI NAL unit, there MUST be at least one additional aggregation 784 unit present in the same packet. 786 When an MVC bitstream is transported in more than one RTP session, 787 the following applies. 789 o Interleaved mode SHOULD be used for all the RTP sessions. 791 o An RTP session that does not use interleaved mode SHOULD be 792 constrained as follows. 794 - Non-interleaved mode MUST be used. 796 - STAP-A MUST be used, and any other type of packets MUST NOT be 797 used. 799 - Each STAP-A MUST contain a PACSI NAL unit and the DONC field 800 MUST be present in the PACSI NAL unit. 802 Informative note: The motivation for these constraints is to 803 allow the use of non-interleaved mode for the session conveying 804 the H.264/AVC compatible view, such that RFC 3984 receivers 805 without interleaved mode implementation can subscribe to the base 806 view session. 808 Non-VCL NAL units SHOULD be conveyed in the same session as the 809 associated VCL NAL units. To meet this, SEI messages that are 810 contained in scalable nesting SEI message and are applicable to more 811 than one session SHOULD be separated and contained into multiple 812 scalable nesting SEI messages. The DON values MUST indicate the 813 cross-layer decoding order number values as if all these SEI 814 messages were in separate scalable nesting SEI messages and 815 contained in the beginning of the corresponding access units as 816 specified in [H.264]. 818 6. De-Packetization Process (Informative) 820 For a single RTP session, the de-packetization process specified in 821 section 7 of [RFC6184] applies. 823 For receiving more than one of multiple RTP sessions conveying a 824 scalable bitstream, an example of a suitable implementation of the 825 de-packetization process is to be specified similarly as what will 826 be finally included in [RFC6190]. 828 7. Payload Format Parameters 830 This section specifies the parameters that MAY be used to select 831 optional features of the payload format and certain features of the 832 bitstream. The parameters are specified here as part of the media 833 type registration for the MVC codec. A mapping of the parameters 834 into the Session Description Protocol (SDP) [RFC4566] is also 835 provided for applications that use SDP. Equivalent parameters could 836 be defined elsewhere for use with control protocols that do not use 837 SDP. 839 7.1. Media Type Registration 841 The media subtype for the MVC codec is allocated from the IETF tree. 843 The receiver MUST ignore any unspecified parameter. 845 Informative note: Requiring ignoring unspecified parameter allows 846 for backward compatibility of future extensions. For example, if 847 a future specification that is backward compatible to this 848 specification specifies some new parameters, then a receiver 849 according to this specification is capable of receiving data per 850 the new payload but ignoring those parameters newly specified in 851 the new payload specification. This sentence is also present in 852 RFC 3984. 854 Media Type name: video 856 Media subtype name: H264-MVC 858 The media subtype "H264" MUST be used for RTP streams using RFC 859 3984, i.e. not using any of the new features introduced by this 860 specification compared to RFC 3984. For RTP streams using any of 861 the new features introduced by this specification compared to RFC 862 3984, the media subtype "H264-MVC" SHOULD be used, and the media 863 subtype "H264" MAY be used. Use of the media subtype "H264" for RTP 864 streams using the new features allows for RFC 3984 receivers to 865 negotiate and receive H.264/AVC or MVC streams packetized according 866 to this specification, but to ignore media parameters and NAL unit 867 types it does not recognize. 869 Required parameters: none 871 OPTIONAL parameters: 873 In the following definitions of parameters, "the stream" or "the 874 NAL unit stream" refers to all NAL units conveyed in the current 875 RTP session in SST, and all NAL units conveyed in the current RTP 876 session and all NAL units conveyed in other RTP sessions that the 877 current RTP session depends on in MST. 879 profile-level-id: 881 sprop-view-scalability-info: 883 This parameter MAY be used to convey the NAL unit containing 884 the view scalability information SEI message as specified in 885 Annex H of [H.264]. This parameter MAY be used to signal the 886 contained target temporal level and target output views of an 887 MVC bitstream. The parameter MUST NOT be used to indicate 888 codec capability in any capability exchange procedure. The 889 value of the parameter is the base64 [RFC4648] representation 890 of the NAL unit containing the view scalability information 891 SEI message. If present, the NAL unit MUST contain only one 892 SEI message that is a view scalability information SEI message. 894 This parameter MAY be used in an offering or declarative SDP 895 message to indicate what temporal level and output views 896 (operation points) can be provided. A receiver MAY indicate 897 its choice of one operation point using the optional media 898 type parameter sprop-view-operation-point-id. 900 sprop-view-operation-point-id: 902 This parameter MAY be used to signal a receiver's choice of 903 the offers or declared operation points using sprop-view- 904 scalability-info or sprop-view-operation-point-info. The 905 value of sprop-view-operation-point-id is a base16 906 representation of the operation_point_id[i] syntax element in 907 the view scalability information SEI message as specified in 908 Annex H of [H.264] or operation-point-ID contained in sprop- 909 view-operation-point-info. 911 sprop-view-operation-point-info 913 This parameter MAY be used to describe the operation points of 914 an RTP session. The value of this parameter consists of a 915 comma-separated list of view-operation-point-description 916 vector. The values given by the view-operation-point- 917 description vectors are the same as, or are derived from, the 918 values that would be given for an operation point in the view 919 scalability information SEI message as specified in Annex H of 920 [H.264], where the term operation point in the view 921 scalability information SEI message refers to those NAL units 922 required for a valid bitstream to represent a certain subset 923 of views at a certain temporal level. An operation point is 924 described by the view_id values of the subset of views, and 925 the highest temporal_id. 927 Each view-operation-point-description vector has variable 928 number (depends on the number of view-IDs) of elements, 929 provided as a comma-separated list of values as defined below. 930 The first value of the view-operation-point-description vector 931 is preceded by a '<', and the last value of the view- 932 operation-point-description vector is followed by a '>'. If 933 the sprop-view-operation-point-info is followed by exactly one 934 view-operation-point-description vector, this describes the 935 highest operation point contained in the RTP session. If 936 there are two or more view-operation-point-description 937 vectors, the first describes the lowest and the last describes 938 the highest operation point contained in the RTP session. 940 The values given by the operation-point-description vector are 941 as follows, in the order listed: 943 - operation-point-ID: This value specifies the identifier of 944 the operation point, which is identical to the 945 operation_opint_id that would be indicated (for the same 946 values of a list of views and the highst temporal_id) in 947 the view scalability information SEI message. This field 948 MAY be empty, indicating that the value is unspecified. 949 When there are multiple view-operation-point-description 950 vectors with operation-point-ID, the values of operation- 951 point-ID do not need to be consecutive. 953 - temporal-ID: This value specifies the maximum value of 954 temporal_id of the NAL units in the represntaiton of the 955 current operation point. 957 - num-target-output-views-minus1: This value plus 1 specifies 958 the number of target output views for the current operation 959 point. 961 - view-ID: each of this parameter specifies the identifier of 962 a target output view for the current operation point. The 963 number of this parameter depends on num-target-output- 964 views-minus1. 966 - profile-level-ID: This value specifies the profile-level- 967 idc of the operation point in the base16 format. The 968 default sub-profile or default level indicated by the 969 parameter profile-level-ID in the sprop-view-operation- 970 point-info vector SHALL be equal to or lower than the 971 default sub-profile or default level indicated by profile- 972 level-id, which may be either present or the default value 973 is taken. This field MAY be empty, indicating that the 974 value is unspecified. 976 - avg_bitrate: This value specifies the average bit rate of 977 the representation of the current operation point. This 978 parameter is given as an integer in kbits per second over 979 the entire stream. Note that this parameter is provided in 980 the view scalability information SEI message in bits per 981 second and calculated over a variable time window. This 982 field MAY be empty, indicating that the value is 983 unspecified. 985 - max_bitrate: This value specifies the maximum bitrate of 986 the operation point. This parameter is given as an integer 987 in kbits per second and describes the maximum bitrate per 988 each one-second window. Note that this parameter is 989 provided in the view scalability information SEI message in 990 bits per second and is calculated over a variable time 991 window. This field MAY be empty, indicating that the value 992 is unspecified. 994 - avg_frm_rate: This value specifies the average frame rate 995 of the operation point. This value is given as an integer 996 in frames per 256 seconds. The field MAY be empty, 997 indicating that the value is unspecified. 999 Similarly to sprop-view-scalability-info, this parameter 1000 MAY be used in an offering or declarative SDP message to 1001 indicate what temporal level and output views (operation 1002 points) can be provided. A receiver MAY indicate its 1003 choice of the highest layer it wants to send and/or receive 1004 using the optional media type parameter sprop-view- 1005 operation-point-id. 1007 [Editors' note: more parameters to be added] 1009 Encoding considerations: 1011 This type is only defined for transfer via RTP (RFC 3550). 1013 Security considerations: 1015 See section 10 of RFC XXXX. 1017 Public specification: 1019 Please refer to RFC XXXX and its section 14. 1021 Additional information: none 1023 File extensions: none 1025 Macintosh file type code: none 1027 Object identifier or OID: none 1029 Person & email address to contact for further information: 1031 Intended usage: COMMON 1033 Author: NN 1035 Change controller: 1037 IETF Audio/Video Transport working group delegated from the 1038 IESG. 1040 7.2. SDP Parameters 1042 7.2.1. Mapping of Payload Type Parameters to SDP 1044 The media type video/H264-MVC string is mapped to fields in the 1045 Session Description Protocol (SDP) as follows: 1047 The media name in the "m=" line of SDP MUST be video. 1049 The encoding name in the "a=rtpmap" line of SDP MUST be H264-MVC 1050 (the media subtype). 1052 The clock rate in the "a=rtpmap" line MUST be 90000. 1054 The OPTIONAL parameters, when present, MUST be included in the 1055 "a=fmtp" line of SDP. These parameters are expressed as a media 1056 type string, in the form of a semicolon separated list of 1057 parameter=value pairs. 1059 7.2.2. Usage with the SDP Offer/Answer Model 1061 TBD. 1063 7.2.3. Usage with Multi-Session Transmission 1065 If multi-session transmission is used, the rules on signaling media 1066 decoding dependency in SDP as defined in 1067 [RFC5583] apply. 1069 7.2.4. Usage in Declarative Session Descriptions 1071 TBD. 1073 7.3. Examples 1075 TBD. 1077 7.4. Parameter Set Considerations 1079 Please see section 10 of [RFC6184]. 1081 8. Security Considerations 1083 Please see section 11 of [RFC6184]. 1085 9. Congestion Control 1087 TBD. 1089 10. IANA Considerations 1091 Request for media type registration to be added. 1093 11. Acknowledgments 1095 The work of Thomas Schierl has been supported by the European 1096 Commission under contract number FP7-ICT-248036, project COAST. 1098 This document was prepared using 2-Word-v2.0.template.dot. 1100 12. References 1102 12.1. Normative References 1104 [H.264] ITU-T Recommendation H.264, "Advanced video coding for 1105 generic audiovisual services", January 2012. 1107 [RFC6190] Wenger, S., Wang, Y. -K., Schierl, T. and A. 1108 Eleftheriadis, "RTP payload format for SVC video", RFC 1109 6190, May 2011. 1111 [RFC5583] Schierl, T., and Wenger, S., "Signaling media decoding 1112 dependency in the Session Description Protocol (SDP)", RFC 1113 5583, July 2009. 1115 [MPEG4-10] 1116 ISO/IEC International Standard 14496-10:2012. 1118 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1119 Requirement Levels", BCP 14, RFC 2119, March 1997. 1121 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1122 Encodings", RFC 3548, July 2003. 1124 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, 1125 V., "RTP: A Transport Protocol for Real-Time 1126 Applications", STD 64, RFC 3550, July 2003. 1128 [RFC6184] Wang, Y.-K., Kristensen, T., Jesup, R., "RTP Payload 1129 Format for H.264 Video", RFC 6184, May 2011. 1131 [RFC4566] Handley, M., Jacobson, V., and Perkins, C., "SDP: Session 1132 Description Protocol", RFC 4566, July 2006. 1134 12.2. Informative References 1136 [DVB-H] DVB - Digital Video Broadcasting (DVB); DVB-H 1137 Implementation Guidelines, ETSI TR 102 377, 2005. 1139 [H.241] ITU-T Rec. H.241, "Extended video procedures and control 1140 signals for H.300-series terminals", May 2006. 1142 [IGMP] Cain, B., Deering S., Kovenlas, I., Fenner, B., and 1143 Thyagarajan, A., "Internet Group Management Protocol, 1144 Version 3", RFC 3376, October 2002. 1146 [McCanne] McCanne, S., Jacobson, V., and Vetterli, M., "Receiver- 1147 driven layered multicast", in Proc. of ACM SIGCOMM'96, 1148 pages 117--130, Stanford, CA, August 1996. 1150 [MBMS] 3GPP - Technical Specification Group Services and System 1151 Aspects; Multimedia Broadcast/Multicast Service (MBMS); 1152 Protocols and codecs (Release 6), December 2005. 1154 [MPEG2] ISO/IEC International Standard 13818-2:1993. 1156 [RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and 1157 Crowcroft, J., "Asynchronous layered coding (ALC) protocol 1158 instantiation", RFC 3450, December 2002. 1160 Author's Addresses 1162 Ye-Kui Wang 1163 Qualcomm Incorporated 1164 5775 Morehouse Drive 1165 San Diego, CA 92121 1166 USA 1167 Phone: +1-858-651-8345 1168 EMail: yekuiw@qualcomm.com 1170 Thomas Schierl 1171 Fraunhofer HHI 1172 Einsteinufer 37 1173 D-10587 Berlin 1174 Germany 1175 Phone: +49-30-31002-227 1176 EMail: ts@thomas-schierl.de 1177 Robert Skupin 1178 Fraunhofer HHI 1179 Einsteinufer 37 1180 D-10587 Berlin 1181 Germany 1182 Phone: +49-30-314-21700 1183 EMail: robert.skupin@hhi.fraunhofer.de 1185 Peiyu Yue 1186 Huawei Technologies 1187 Huawei Base 1188 101 Software Avenue, Yuhua District 1189 Nanjing, Jiangsu 210012 1190 China 1192 Phone: +86-25-56620258 1193 Email: yuepeiyu@huawei.com 1195 13. Open Issues 1197 - The use of CL-DON for session reordering allows also for 1198 interleaved transmission with non-interleaved packetization mode. 1199 There should be a clear separation between both tools. This issue 1200 should be handled the same way as for the SVC payload draft. 1202 - Since SVC session multiplexing (multi source transmission(MST)) is 1203 cleared, it would be great to just reference the MST sections in 1204 [RFC6190]. Since the text in sections 6 and 7 of [RFC6190] is 1205 currently very SVC specific, the authors would have to try to 1206 rewrite these sections in a more generic way. If this is not 1207 possible, we need to copy text from [RFC6190] with respect to MVC. 1209 - The structure of this document should be aligned with recently 1210 finished RFC6190. 1212 - This document is not intended to be a delta document in respect to 1213 RFC6190. 1215 - The PASCI definition in this document differs from the definition 1216 in RFC6190 1218 14. Changes Log 1220 Initial version 00 1222 10 November 2007: YkW 1223 Initial version 1225 12 November 2007: TS 1226 - Added definition of "Session multiplexing" 1227 - Added the reference of [I-D.draft-ietf-mmusic-decoding- 1228 dependency], and its reference in section 9.2.3 1230 12 November 2007: YkW 1231 - Added the reference of [I-D.draft-ietf-avt-svc] and its 1232 reference in section 1. 1233 - Added in sections 3.1 and 3.2 paragraphs regarding inter- 1234 view prediction 1236 From draft-wang-avt-rtp-mvc-00 to draft-wang-avt-rtp-mvc-01 1238 18 February 2008: YkW 1239 - Alignment to the latest MVC draft in JVT-Z209 and version 07 1240 of [I-D.draft-ietf-avt-svc]. 1242 25 February 2008: TS 1244 - Minor modifications and updates throughout the document 1246 - Added open issue on clear separation between "decoding order 1247 recovery" and "interleaving" 1249 From draft-wang-avt-rtp-mvc-01 to draft-wang-avt-rtp-mvc-02 1251 09 July 2008: TS 1253 - Minor modifications and updates throughout the document 1255 - Added open issue 1257 - NAL unit header alignment with MVC spec 1259 - Section 6. References corresponding sections in [RFC3984] and [I- 1260 D.draft-ietf-avt-svc]. 1262 - TBD: Section 7, we may align [I-D.draft-ietf-avt-svc] in a way 1263 that SVC is not mentioned in this paragraphs, so that we can 1264 reference them from this document. 1266 21 August 2008: 1268 - Minor modifications, editing and adding notes throughout the 1269 document. 1271 - Updated references 1273 From draft-wang-avt-rtp-mvc-02 to draft-wang-avt-rtp-mvc-03 1275 04 February 2009: YkW 1277 - Updated author's address. 1279 04 February 2009: YkW 1281 - Updated the boiler template. 1283 From draft-wang-avt-rtp-mvc-03 to draft-wang-avt-rtp-mvc-04 1285 22 October 2009: YkW 1287 - Updated author's address and the boiler template (added the last 1288 sentence in Copyright Notice). 1290 From draft-wang-avt-rtp-mvc-04 to draft-wang-avt-rtp-mvc-05 1292 22 April 2010: YkW 1294 - To keep the draft alive, no change other than version number etc. 1296 From draft-wang-avt-rtp-mvc-05 to draft-ietf-avt-rtp-mvc-00 1298 28 April 2010: YkW 1300 - No change other than version number etc. 1302 From draft-ietf-avt-rtp-mvc-00 to draft-ietf-avt-rtp-mvc-01 1304 8/9 October 2010: 1306 - YkW: Updated the NAL unit header syntax and semantics in section 1307 3.3 per the latest MVC specification. 1309 - TS: Minor edits 1311 From draft-ietf-avt-rtp-mvc-01 to draft-ietf-payload-rtp-mvc-00 1313 14 March 2011: YkW 1315 - Minor changes such as updates of some references the work group 1316 name from AVT to AVT Payload, etc. 1318 From draft-ietf-payload-rtp-mvc-00 to draft-ietf-payload-rtp-mvc-01 1320 1 September 2011: RS 1322 - Added some definitions 1324 - Started structural alignment with RFC 6190 1326 - Reference updates: (RFC3984 -> RFC6184), (I-D.draft-ietf-avt-rtp- 1327 svc -> RFC6190) 1329 From draft-ietf-payload-rtp-mvc-01 to draft-ietf-payload-rtp-mvc-02 1331 - Added definitions of some media type parameters (PY) 1333 - Minor changes throughout the document, including updating of some 1334 definitions and references (YkW)