idnits 2.17.1 draft-ietf-payload-rtp-vc2hq-05.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 -- The document date (April 11, 2018) is 2206 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'VC2' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Payload Working Group J. Weaver 3 Internet-Draft BBC 4 Intended status: Standards Track April 11, 2018 5 Expires: October 13, 2018 7 RTP Payload Format for VC-2 HQ Profile Video 8 draft-ietf-payload-rtp-vc2hq-05 10 Abstract 12 This memo describes an RTP Payload format for the High Quality (HQ) 13 profile of SMPTE Standard ST 2042-1 known as VC-2. This document 14 describes the transport of HQ Profile VC-2 in RTP packets and has 15 applications for low-complexity, high-bandwidth streaming of both 16 lossless and lossy compressed video. 18 The HQ profile of VC-2 is intended for low latency video compression 19 (with latency potentially on the order of lines of video) at high 20 data rates (with compression ratios on the order of 2:1 or 4:1). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 13, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 58 3. Media Format Description . . . . . . . . . . . . . . . . . . 3 59 4. Payload format . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 9 61 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . 10 62 4.3. The Choice of Parse Codes (Informative) . . . . . . . . . 12 63 4.4. Stream Constraints . . . . . . . . . . . . . . . . . . . 12 64 4.5. Payload Data . . . . . . . . . . . . . . . . . . . . . . 13 65 4.5.1. Reassembling the Data . . . . . . . . . . . . . . . . 14 66 5. Congestion Control Considerations . . . . . . . . . . . . . . 16 67 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 16 68 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 16 69 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 18 70 6.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 18 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 73 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 19 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 76 10.2. Informative References . . . . . . . . . . . . . . . . . 20 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 79 1. Introduction 81 This memo specifies an RTP payload format for the video coding 82 standard SMPTE ST 2042-1:2017 [VC2] also known as VC-2 84 The VC-2 codec is a wavelet-based codec intended primarily for 85 professional video use with high bit-rates and only low levels of 86 compression. It has been designed to be low-complexity, and 87 potentially have a very low latency through both encoder and decoder: 88 with some choices of parameters this latency may be as low as a few 89 lines of video. 91 The low level of complexity in the VC-2 codec allows for this low 92 latency operation but also means that it lacks many of the more 93 powerful compression techniques used in other codecs. As such it is 94 suitable for low compression ratios that produce coded data rates 95 around half to a quarter of that of uncompressed video, at a similar 96 visual quality. 98 The primary use for VC-2 is likely to be in professional video 99 production environments. 101 2. Conventions, Definitions and Acronyms 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 3. Media Format Description 111 The VC-2 specification defines a VC-2 stream as being composed of one 112 or more Sequences. Each Sequence is independently decodable, 113 containing all of the needed parameters and metadata for configuring 114 the decoder. 116 Each Sequence consists of a series of 13-octet Parse Info headers and 117 variable length Data Units. The Sequence begins and ends with a 118 Parse Info header and each Data Unit is preceded by a Parse Info 119 Header. Data Units come in a variety of types, the most important 120 being the Sequence Header, which contains configuration data needed 121 by the decoder, and several types of Coded Picture, which contain the 122 coded data for the pictures themselves. Each picture represents a 123 frame in a progressively scanned video Sequence or a field in an 124 interlaced video Sequence. 126 The first Data Unit in a Sequence as produced by an encoder is always 127 a Sequence Header, but Sequences can be joined in the middle, so this 128 should not be assumed. 130 The High Quality (HQ) profile for VC-2 restricts the types of Parse 131 Info Headers which may appear in the Sequence to only: 133 o Sequence Headers, 135 o High Quality Pictures, 137 o High Quality Fragments, 139 o Auxiliary Data, 141 o Padding Data, and 143 o End of Sequence. 145 At time of writing there is currently no definition for the use of 146 Auxiliary Data in VC-2, and Padding Data is required to be ignored by 147 all receivers. 149 Each High Quality Picture data unit contains a set of parameters for 150 the picture followed by a series of coded Slices, each representing a 151 rectangular region of the transformed picture. Slices within a 152 picture may vary in coded length, but all represent the same shape 153 and size of rectangle in the picture. 155 Each High Quality Fragment data unit contains either a set of 156 parameters for a picture or it contains a series of coded Slices. 157 Fragments carry the same data as pictures, but broken up into smaller 158 units to facilitate transmission via packet-based protocols such as 159 RTP. 161 This payload format only makes use of fragments, not pictures. 163 4. Payload format 165 This specification only covers the transport of Sequence Headers, 166 High Quality Fragments, Auxiliary Data, and (optionally) End of 167 Sequence Headers and Padding Data. 169 High Quality Pictures can be transported by converting them into an 170 equivalent set of High Quality Fragments. The size of fragments 171 should be chosen so as to fit within the MTU of the network in use. 173 For this reason this document defines six types of RTP packets in a 174 VC-2 media stream: one which carries the VC-2 Sequence Header 175 (Figure 1), one which carries the Picture Fragment containing the 176 VC-2 Transform Parameters for a Picture (Figure 2), one which carries 177 a Picture Fragment containing VC-2 Coded Slices (Figure 3) for a 178 picture, one which signals the end of a VC-2 Sequence (Figure 4), one 179 which carries the contents of an auxiliary data unit (Figure 5), and 180 one which indicates the presence of a padding data unit (Figure 6). 182 These six packet-types can be distinguished by the fact that they use 183 different codes in the "PC (Parse Code)" field, except for the two 184 types of picture fragment which both use the same value in PC but 185 have different values in the "No. of slices" field. 187 The choices of PC codes is explained in more detail in a following 188 informative section (Section 4.3). 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | V |P|X| CC |M| PT | Sequence Number | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Timestamp | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | SSRC | 198 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 199 | contributing source (CSRC) identifiers | 200 | .... | 201 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 202 | Optional Extension Header | 203 | .... | 204 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 205 | Extended Sequence Number | Reserved | PC = 0x00 | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 207 . . 208 . Variable Length Coded Sequence Header . 209 . . 210 +---------------------------------------------------------------+ 212 Figure 1: RTP Payload Format For Sequence Header 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | V |P|X| CC |M| PT | Sequence Number | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Timestamp | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | SSRC | 222 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 223 | contributing source (CSRC) identifiers | 224 | .... | 225 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 226 | Optional Extension Header | 227 | .... | 228 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 229 | Extended Sequence Number | Reserved |I|F| PC = 0xEC | 230 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 231 | Picture Number | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 233 | Slice Prefix Bytes | Slice Size Scaler | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 235 | Fragment Length | No. of Slices = 0 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 237 . . 238 . Variable Length Coded Transform Parameters . 239 . . 240 +---------------------------------------------------------------+ 242 Figure 2: RTP Payload Format For Transform Parameters Fragment 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | V |P|X| CC |M| PT | Sequence Number | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Timestamp | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | SSRC | 252 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 253 | contributing source (CSRC) identifiers | 254 | .... | 255 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 256 | Optional Extension Header | 257 | .... | 258 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 259 | Extended Sequence Number | Reserved |I|F| PC = 0xEC | 260 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 261 | Picture Number | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 263 | Slice Prefix Bytes | Slice Size Scaler | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 265 | Fragment Length | No. of Slices | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 267 | Slice Offset X | Slice Offset Y | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 269 . . 270 . Coded Slices . 271 . . 272 +---------------------------------------------------------------+ 274 Figure 3: RTP Payload Format For Fragment Containing Slices 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | V |P|X| CC |M| PT | Sequence Number | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Timestamp | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | SSRC | 284 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 285 | contributing source (CSRC) identifiers | 286 | .... | 287 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 288 | Optional Extension Header | 289 | .... | 290 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 291 | Extended Sequence Number | Reserved | PC = 0x10 | 292 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 294 Figure 4: RTP Payload Format For End of Sequence 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | V |P|X| CC |M| PT | Sequence Number | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Timestamp | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | SSRC | 304 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 305 | contributing source (CSRC) identifiers | 306 | .... | 307 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 308 | Optional Extension Header | 309 | .... | 310 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 311 | Extended Sequence Number |B|E| Reserved | PC = 0x20 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Data Length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 . . 316 . Uncoded Payload Data . 317 . . 318 +---------------------------------------------------------------+ 320 Figure 5: RTP Payload Format For Auxiliary Data 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | V |P|X| CC |M| PT | Sequence Number | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Timestamp | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | SSRC | 330 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 331 | contributing source (CSRC) identifiers | 332 | .... | 333 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 334 | Optional Extension Header | 335 | .... | 336 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 337 | Extended Sequence Number |B|E| Reserved | PC = 0x30 | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Data Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 . . 342 . Optional Payload Data . 343 . . 344 +---------------------------------------------------------------+ 346 Figure 6: RTP Payload Format For Padding Data 348 4.1. RTP Header Usage 350 The fields of the RTP header have the following additional notes on 351 their useage: 353 Marker Bit (M): 1 bit The marker bit MUST be set on any packet which 354 contains the final slice in a coded picture and MUST NOT be set 355 otherwise. 357 Payload Type (PT): 7 bits A dynamically allocated payload type field 358 that designates the payload as VC-2 coded video. 360 Sequence Number: 16 bits Because the data rate of VC-2 coded streams 361 can often be very high, in the order of gigabits rather than 362 megabits per second, the standard 16-bit RTP sequence number 363 can cycle very quickly. For this reason the sequence number is 364 extneded to 32-bits, and this field MUST hold the low-order 365 16-bits of this value. 367 Timestamp: 32 bits If the packet contains transform parameters or 368 coded slice data for a coded picture then the timestamp 369 corresponds to the sampling instant of the coded picture. A 370 90kHz clock SHOULD be used. A single RTP packet MUST NOT 371 contain coded data for more than one coded picture, so there is 372 no ambiguity here. 374 A Sequence Header packet SHOULD have the same timestamp as the 375 next picture which will follow it in the stream. An End of 376 Sequence packet SHOULD have the same timestamp as the previous 377 picture which appeared in the stream. 379 The remaining RTP header fields are used as specified in RTP 380 [RFC3550]. 382 4.2. Payload Header 384 The fields of the extended headers are defined as follows: 386 Extended Sequence Number: 16 bits MUST Contain the high-order 387 16-bits of the 32-bit packet sequence number, a number which 388 increments with each packet. This is needed since the high 389 data rates of VC2 Sequences mean that it is highly likely that 390 the 16-bit sequence number will roll-over too frequently to be 391 of use for stream synchronisation. 393 B: 1 bit MUST be set to 1 if the packet contains the first byte of 394 an Auxiliary Data or Padded Data Unit. 396 E: 1 bit MUST be set to 1 if the packet contains the final byte of 397 an Auxiliary Data or Padded Data Unit. 399 I: 1 bit MUST be set to 1 if the packet contains coded picture 400 paramaters or slice data from a field in an interlaced frame, 401 and to 0 if the packet contains data from any part of a 402 progressive frame. 404 F: 1 bit MUST be set to 1 if the packet contains coded picture 405 paramaters or slice data from the second field of an interlaced 406 frame, and to 0 if the packet contains data from the first 407 field of an interlaced frame or any part of a progressive 408 frame. 410 Parse Code (PC): 8 bits Contains a Parse Code which MUST be the 411 value indicated for the type of data in the packet. 413 Data Length: 32 bits For an auxiliary data unit this contains the 414 number of bytes of data contained in the uncoded payload 415 section of this packet. For a Padding Data Unit this field may 416 have any value and simply indicates the size of the recommended 417 padding. 419 Picture Number: 32 bits MUST contain the Picture Number for the 420 coded picture this packet contains data for, as described in 421 Section 12.1 of the VC-2 specification [VC2]. 423 The sender MUST send at least one transform parameters packet 424 for each coded picture and MAY include more than one as long as 425 they contain identical data. The sender MUST NOT send a packet 426 from a new picture until all the coded data from the current 427 picture has been sent. 429 If the receiver does not receive a transform parameters packet 430 for a picture then it MAY assume that the parameters are 431 unchanged since the last picture, or MAY discard the picture. 433 Slice Prefix Bytes: 16 bits MUST contain the Slice Prefix Bytes 434 value for the coded picture this packet contains data for, as 435 described in Section 12.3.4 of the VC-2 specification [VC2]. 437 In the VC-2 specification this value is not restricted to 16 438 bits, but the constraints on streams specified in this document 439 (Section 4.4) do require this. 441 Slice Size Scaler: 16 bits MUST contain the Slice Size Scaler value 442 for the coded picture this packet contains data for, as 443 described in Section 12.3.4 of the VC-2 specification [VC2]. 445 In the VC-2 specification this value is not restricted to 16 446 bits, but the constraints on streams specified in this document 447 (Section 4.4) do require this. 449 Fragment Length: 16 bits MUST contain the number of bytes of data 450 contained in the coded payload section of this packet. 452 No. of Slices: 16 bits MUST contain the number of coded slices 453 contained in this packet, which MUST be 0 for a packet 454 containing transform parameters. In a packet containing coded 455 slices this number MUST be the number of whole slices contained 456 in the packet, and the packet MUST NOT contain any partial 457 slices. 459 Slice Offset X: 16 bits MUST contain the X coordinate of the first 460 slice in this packet, in slices, starting from the top left 461 corner of the picture. 463 Slice Offset Y: 16 bits MUST contain the Y coordinate of the first 464 slice in this packet, in slices, starting from the top left 465 corner of the picture. 467 4.3. The Choice of Parse Codes (Informative) 469 The "PC" field in the packets is used to carry the Parse Code which 470 identifies the type of content in the packet. This code matches the 471 value of the Parse Code used to identify each data unit in a VC-2 472 stream, as defined in the VC-2 specification, and each packet 473 contains the entire data unit. 475 The table below lists all of the parse codes currently allowed in a 476 VC-2 Sequence. The final column indicates whether the code in 477 question can be present in a stream transmitted using this 478 specification. 480 +----------+-----------+---------------------+---------------+ 481 | PC (hex) | Binary | Description | Valid | 482 +----------+-----------+---------------------+---------------+ 483 | 0x00 | 0000 0000 | Sequence Header | Yes | 484 | 0x10 | 0001 0000 | End of Sequence | Yes | 485 | 0x20 | 0010 0000 | Auxiliary Data | Yes | 486 | 0x30 | 0011 0000 | Padding Data | Yes | 487 +----------+-----------+---------------------+---------------+ 488 | 0xC8 | 1100 1000 | LD Picture | No | 489 | 0xE8 | 1110 1000 | HQ Picture | No | 490 | 0xEC | 1110 1100 | HQ Picture Fragment | Yes | 491 +----------+-----------+---------------------+---------------+ 493 Figure 7: Parse Codes and Meanings 495 4.4. Stream Constraints 497 There are some constraints which a Sequence needs to conform to in 498 order to be transmissible with this specification. 500 o The sequence MUST NOT contain Parse Info Headers with a Parse Code 501 which is not 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20 502 (Auxiliary Data), 0x30 (Padding Data) and 0xEC (High Quality 503 Picture Fragment). Some other streams MAY be convertible to meet 504 this restriction (see below). 506 o Every High Quality Picture Fragment MUST be no longer than 65535 507 bytes. This can usually be ensured by splitting large fragments 508 into several smaller fragments, except in the case where an 509 individual slice is too large, in which case see the notes below 510 on conversion. 512 o Informative note: this requirement ensures that every Hight 513 Quality Picture Fragment will always contain no more than 65535 514 slices. 516 o Every High Quality Picture Fragment SHOULD be small enough that 517 the RTP packet carrying it will fit within the network MTU size. 518 This can usually be ensured by splitting large fragments into 519 several smaller fragments, except in the case where an individual 520 slice is too large, in which case see the notes below on 521 conversion. 523 o Every High Quality Picture Fragment MUST be encoded using values 524 for Slice Prefix Bytes and Slice Size Scaler no greater than 525 65535. 527 If a Sequence intended for tranmission does not conform to these 528 restrictions then it MAY be possible to simply convert it into a form 529 that does by splitting pictures and/or large fragments into suitably 530 sized fragments. This can be done provided that the following 531 (weaker) constraints are met: 533 o The sequence does not contain Parse Info Headers with a Parse Code 534 which is not 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20 535 (Auxiliary Data), 0x30 (Padding Data), 0xE8 (High Quality 536 Picture), and 0xEC (High Quality Picture Fragment). 538 o Every High Quality Picture or High Quality Picture Fragment 539 contains no slices which are individually longer than 65535 bytes. 540 Note: When this is the case the values of Slice Prefix Bytes and 541 Slice Size Scaler will necessarily also be smaller than 65535. 543 o Every High Quality Picture or High Quality Picture Fragment 544 contains no slices which are individually so large that an RTP 545 packet carrying a Fragment containing that single slice will fit 546 within the network MTU size. 548 Sending a Stream which does not meet these requirements via this 549 mechanism is not possible unless the stream is re-encoded by a VC-2 550 Encoder so as to meet them. 552 When encoding VC-2 video intended to be transported via RTP a VC-2 553 profile and level which ensures these requirements are met SHOULD be 554 used. 556 4.5. Payload Data 558 For the Sequence Header packet type (PC = 0x00) the payload data MUST 559 be the coded Sequence Header exactly as it appears in the VC-2 560 Sequence. 562 For the Transform Parameters packet type (PC = 0xEC and No. Slices = 563 0) the payload data MUST be the variable length coded transform 564 parameters. This MUST NOT include the fragment header (since all 565 data in the picture header is already included in the packet header). 567 For the Auxiliary Data packet type (PC = 0x20) the payload data MUST 568 be a portion of the auxiliary data bytes contained in the Auxiliary 569 data unit being being transmitted. The B flag MUST be set on the 570 packet which contains the first byte, the E flag MUST be set on the 571 packet which contains the last byte, the bytes MUST be included in 572 order, and the packets MUST have contiguous sequence numbers. 574 For the Padding Data packet type (PC = 0x30) the payload data is 575 OPTIONAL, and if present MUST be a series of 0x00 values. 577 For the Picture Fragment packet type (PC = 0xEC and No. Slices > 0) 578 the payload data MUST be a specified number of coded slices in the 579 same order that they appear in the VC-2 stream. Which slices appear 580 in the packet is identified using the Slice Offset X and Slice Offset 581 Y fields in the payload header. 583 For the End of Sequence packet type (PC = 0x10) there is no payload 584 data. 586 4.5.1. Reassembling the Data 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | 0x42 | 0x42 | 0x43 | 0x44 | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Parse Code | Next Parse Offset 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Prev Parse Offset 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | 598 +-+-+-+-+-+-+-+-+ 600 Figure 8: VC-2 Parse Info Header 602 To reassemble the data in the RTP packets into a valid VC-2 Sequence 603 the receiver SHOULD: 605 o Take the data from each packet with a Parse Code of 0x00 and 606 prepend a valid VC-2 Parse Info Header (Figure 8) with the same 607 parse code to it. The resulting Sequence Header Parse Info Header 608 and data unit MUST be included in the output stream before any 609 coded pictures which followed it in the RTP stream unless an 610 identical Sequence Header has already been included, and MAY be 611 repeated at any point that results in a valid VC-2 stream. 613 o Take the data from each packet with a Parse Code of 0xEC and No. 614 of Slices set to 0 (which together indicates that this packet 615 contains the transform parameters for a coded picture) and prepend 616 a valid VC-2 Parse Info Header (Figure 8) followed by the picture 617 number, fragment data length, and slice count (0) to it with the 618 same parse code. 620 o Take the data from each packet with a Parse Code of 0xEC and No. 621 of Slices not set to 0 (which together indicates that this packet 622 contains coded slices) and prepend a valid VC-2 Parse Info Header 623 (Figure 8) followed by the picture number, fragment data length, 624 slice count, x offset and y offset taken from the packet header to 625 it with the same parse code. 627 o A receiver MAY combine all fragment data units (with parse code 628 0xEC) and the same picture number into a single picture data unit 629 with parse code 0xE8. If the stream is required to comply with 630 major versions 1 or 2 of the VC-2 Spec then this MUST be done. 632 o Take the data from each packet with a Parse Code of 0x20 and the B 633 bit set and prepend a valid VC-2 Parse Info Header (Figure 8) with 634 the parse code 0x20 and then take each subsequent packet with 635 parse code 0x20 without the B bit set and append their payload to 636 the growing data unit. When all packets for a particular data 637 unit have been received it SHOULD be included in the output 638 stream. The final packet for a data unit will have the E bit set. 640 o Once a data unit has been assembled, whether a Sequence Header, 641 Coded Picture Fragment, Coded Picture, or Auxiliary Data Unit, the 642 next parse offset and previous parse offset values in its Parse 643 Info Header should be filled with the offset between the start of 644 the header and the start of the next or previous. 646 o An End of Sequence Parse Info Header MAY be inserted when a packet 647 with parse code set to 0x10 is encountered, or at any other time 648 that is allowed in a valid VC-2 stream. After an End of Sequence 649 Parse Info Header is included in the output stream either the 650 stream must end or it MUST be followed by a Sequence Header 651 indicating the start of a new Sequence. 653 o A Padding Data Parse Info Header MAY be inserted when a packet 654 with parse code set to 0x30 and the B bit set is encountered, or 655 at any other time that is allowed in a valid VC-2 stream. The 656 length of this padding data MAY have any value, and its contents 657 MUST be set to a series of zero bytes. 659 5. Congestion Control Considerations 661 Congestion control for RTP SHALL be used in accordance with RFC 3550 662 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 663 [RFC3551]. An additional requirement if best-effort service is being 664 used is: users of this payload format MUST monitor packet loss to 665 ensure that the packet loss rate is within acceptable parameters. 666 Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines 667 criteria for when one is required to stop sending RTP Packet Streams, 668 and applications implementing this standard MUST comply with it. RFC 669 8085 [RFC8085] provides additional information on the best practices 670 for applying congestion control to UDP streams. 672 In particular it should be noted that the expected data rate for RTP 673 sessions which use this profile is likely to be in the range of 674 gigabits per second. If used on a closed network which has been 675 correctly provisioned for the expected data rates this might not pose 676 a problem, but there is always the risk of data getting out onto the 677 open internet. 679 6. Payload Format Parameters 681 This RTP payload format is identified using the video/vc2 media type 682 which is registered in accordance with RFC 4855 [RFC4855] and using 683 the template of RFC 6838 [RFC6838]. 685 6.1. Media Type Definition 687 Type name: 689 video 691 Subtype name: 693 vc2 695 Required parameters: 697 rate: The RTP timestamp clock rate. Applications using this 698 payload format SHOULD use a value of 90000. 700 profile: The VC-2 profile in use, the only currently allowed value 701 is "HQ". 703 Optional parameters: 705 version: the VC-2 specification version in use. The only 706 currently allowed value is "3" since all Sequences transported 707 using this mechanism will contain HQ Picture Fragment data units, 708 which the VC-2 specification [VC2] defines as requiring version 3. 710 level: The VC-2 level in use. Any integer may be used. 712 Encoding considerations: 714 This media type is framed and binary, see section 4.8 in RFC6838 715 [RFC6838]. 717 Security considerations: 719 Please see security consideration in RFCXXXX 721 Interoperability considerations: N/A 723 Published specification: 725 "VC-2 Video Compression", SMPTE Standard ST 2042-1 [VC2] 727 Applications that use this media type: 729 Video Communication. 731 Additional information: N/A 733 Person & email address to contact for further information: 735 james.barrett@bbc.co.uk 737 Intended usage: 739 COMMON 741 Restrictions on usage: 743 This media type depends on RTP framing, and hence is only defined 744 for transfer via RTP [RFC3550]. Transport within other framing 745 protocols is not defined at this time. 747 Author: 749 Change controller: 751 IETF Payload working group delegated from the IESG. 753 Provisional registration? (standards tree only): 755 No 757 (Any other information that the author deems interesting may be added 758 below this line.) 760 6.2. Mapping to SDP 762 The mapping of the above defined payload format media type and its 763 parameters SHALL be done according to Section 3 of RFC 4855 764 [RFC4855]. 766 o The type name ("video") goes in SDP "m=" as the media name. 768 o The subtype name ("vc2") goes in SDP "a=rtpmap" as the encoding 769 name, followed by a slash ("/") and the rate parameter. 771 o The required parameter profile and the optional parameters version 772 and level, when present, are included in the "a=fmtp" attribute 773 line of SDP as a semicolon-separated list of parameter=value 774 pairs. 776 Version and level SHALL be specified in decimal when present. 778 For example, a sample SDP mapping for VC-2 could be as follows: 780 m=video 30000 RTP/AVP 112 781 a=rtpmap:112 vc2/90000 782 a=fmtp:112 profile=HQ;version=3;level=0 784 In this example, a dynamic payload type 112 is used for vc-2 data. 785 The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" line 786 after the subtype. In the "a=fmtp:" line, profile HQ, version 3, and 787 level 0 (unknown or non-standard level) are specified. 789 6.3. Offer/Answer Considerations 791 All parameters are declarative. 793 7. IANA Considerations 795 This memo requests that IANA registers video/vc2 as specified in 796 Section 6.1. The media type is also requested to be added to the 797 IANA registry for "RTP Payload Format MIME types" 798 (http://www.iana.org/assignments/rtp-parameters). 800 8. Security Considerations 802 RTP packets using the payload format defined in this specification 803 are subject to the security considerations discussed in the RTP 804 specification [RFC3550] , and in any applicable RTP profile such as 805 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ 806 SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: 807 Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] 808 discusses, it is not an RTP payload format's responsibility to 809 discuss or mandate what solutions are used to meet the basic security 810 goals like confidentiality, integrity and source authenticity for RTP 811 in general. This responsibility lays on anyone using RTP in an 812 application. They can find guidance on available security mechanisms 813 and important considerations in Options for Securing RTP Sessions 814 [RFC7201]. Applications SHOULD use one or more appropriate strong 815 security mechanisms. The rest of this security consideration section 816 discusses the security impacting properties of the payload format 817 itself. 819 This RTP payload format and its media decoder do not exhibit any 820 significant non-uniformity in the receiver-side computational 821 complexity for packet processing, and thus are unlikely to pose a 822 denial-of-service threat due to the receipt of pathological data. 823 Nor does the RTP payload format contain any active content. 825 To avoid buffer overruns when processing these packets the receiver 826 MUST consider both the reported fragment length and the actual 827 received size of a packet containing slice data. 829 In some cases the transmitter may need to decode variable length 830 coded headers in order to extract some data from the VC-2 bitstream 831 before assembling packets. This process is potentially subject to 832 buffer overruns if not implemented carefully. 834 9. RFC Editor Considerations 836 Note to RFC Editor: This section may be removed after carrying out 837 all the instructions of this section. 839 RFCXXXX is to be replaced by the RFC number this specification 840 receives when published. 842 10. References 843 10.1. Normative References 845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 846 Requirement Levels", BCP 14, RFC 2119, 847 DOI 10.17487/RFC2119, March 1997, 848 . 850 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 851 Jacobson, "RTP: A Transport Protocol for Real-Time 852 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 853 July 2003, . 855 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 856 Video Conferences with Minimal Control", STD 65, RFC 3551, 857 DOI 10.17487/RFC3551, July 2003, 858 . 860 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 861 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 862 . 864 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 865 Specifications and Registration Procedures", BCP 13, 866 RFC 6838, DOI 10.17487/RFC6838, January 2013, 867 . 869 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 870 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 871 DOI 10.17487/RFC8083, March 2017, 872 . 874 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 875 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 876 March 2017, . 878 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 879 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 880 May 2017, . 882 [VC2] SMPTE, "VC-2 Video Compression", SMPTE Standard ST 2042-1, 883 2017, . 885 10.2. Informative References 887 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 888 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 889 RFC 3711, DOI 10.17487/RFC3711, March 2004, 890 . 892 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 893 "Extended RTP Profile for Real-time Transport Control 894 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 895 DOI 10.17487/RFC4585, July 2006, 896 . 898 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 899 Real-time Transport Control Protocol (RTCP)-Based Feedback 900 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 901 2008, . 903 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 904 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 905 . 907 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 908 Framework: Why RTP Does Not Mandate a Single Media 909 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 910 2014, . 912 Author's Address 914 James P. Weaver 915 BBC 917 Email: james.barrett@bbc.co.uk