idnits 2.17.1 draft-ietf-payload-rtp-vc2hq-03.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 (August 9, 2017) is 2451 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 August 9, 2017 5 Expires: February 10, 2018 7 RTP Payload Format for VC-2 HQ Profile Video 8 draft-ietf-payload-rtp-vc2hq-03 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 http://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 February 10, 2018. 39 Copyright Notice 41 Copyright (c) 2017 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 (http://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. Payload Data . . . . . . . . . . . . . . . . . . . . . . 12 64 4.4.1. Reassembling the Data . . . . . . . . . . . . . . . . 13 65 5. Congestion Control Considerations . . . . . . . . . . . . . . 14 66 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 15 67 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 15 68 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 16 69 6.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 16 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 17 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 75 10.2. Informative References . . . . . . . . . . . . . . . . . 18 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 This memo specifies an RTP payload format for the video coding 81 standard SMPTE ST 2042-1:2017 [VC2] also known as VC-2 83 The VC-2 codec is a wavelet-based codec intended primarily for 84 professional video use with high bit-rates and only low levels of 85 compression. It has been designed to be low-complexity, and 86 potentially have a very low latency through both encoder and decoder: 87 with some choices of parameters this latency may be as low as a few 88 lines of video. 90 The low level of complexity in the VC-2 codec allows for this low 91 latency operation but also means that it lacks many of the more 92 powerful compression techniques used in other codecs. As such it is 93 suitable for low compression ratios that produce coded data rates 94 around half to a quarter of that of uncompressed video, at a similar 95 visual quality. 97 The primary use for VC-2 is likely to be in professional video 98 production environments. 100 2. Conventions, Definitions and Acronyms 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 3. Media Format Description 108 The VC-2 specification defines a VC-2 stream as being composed of one 109 or more sequences. Each sequence is independently decodable, 110 containing all of the needed parameters and metadata for configuring 111 the decoder. 113 Each Sequence consists of a series of 13-octet Parse Info headers and 114 variable length Data Units. The Sequence begins and ends with a 115 Parse Info header and each Data Unit is preceded by a Parse Info 116 Header. Data Units come in a variety of types, the most important 117 being the Sequence Header, which contains configuration data needed 118 by the decoder, and several types of Coded Picture, which contain the 119 coded data for the pictures themselves. Each picture represents a 120 frame in a progressively scanned video sequence or a field in an 121 interlaced video sequence. 123 The first Data Unit in a Sequence as produced by an encoder is always 124 a Sequence Header, but sequences can be joined in the middle, so this 125 should not be assumed. 127 The High Quality (HQ) profile for VC-2 restricts the types of parse 128 info headers which may appear in the Sequence to only: 130 o Sequence Headers, 132 o High Quality Pictures, 134 o High Quality Fragments, 136 o Auxiliary Data, 138 o Padding Data, and 140 o End of Sequence. 142 At time of writing there is currently no definition for the use of 143 Auxiliary Data in VC-2, and Padding Data is required to be ignored by 144 all receivers. 146 Each High Quality Picture data unit contains a set of parameters for 147 the picture followed by a series of coded Slices, each representing a 148 rectangular region of the transformed picture. Slices within a 149 picture may vary in coded length, but all represent the same shape 150 and size of rectangle in the picture. 152 Each High Quality Fragment data unit contains either a set of 153 parameters for a picture or a series of coded Slices. Fragments 154 carry the same data as pictures, but broken up into smaller units to 155 facilitate transmission via packet-based protocols such as RTP. 157 4. Payload format 159 This specification only covers the transport of Sequence Headers, 160 High Quality Fragments, Auxiliary Data, and (optionally) End of 161 Sequence headers and Padding Data. 163 High Quality Pictures can be transported by converting them into an 164 equivalent set of High Quality Fragments. The size of fragments 165 should be chosen so as to fit within the MTU of the network in use. 167 For this reason this document defines six types of RTP packets in a 168 VC-2 media stream: one which carries the VC-2 Sequence Header 169 (Figure 1), one which carries the Picture Fragment containing the 170 VC-2 Transform Parameters for a Picture (Figure 2), one which carries 171 a Picture Fragment containing VC-2 Coded Slices (Figure 3) for a 172 picture, one which signals the end of a VC-2 Sequence (Figure 4), one 173 which carries the contents of an auxiliary data unit (Figure 5), and 174 one which indicates the presence of a padding data unit (Figure 6). 176 These six packet-types can be distinguished by the fact that they use 177 different codes in the "PC (Parse Code)" field, except for the two 178 types of picture fragment which both use the same value in PC but 179 have different values in the "No. of slices" field. 181 The choices of PC codes is explained in more detail in a following 182 informative section (Section 4.3). 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | V |P|X| CC |M| PT | Sequence Number | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Time Stamp | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | SSRC | 192 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 193 | contributing source (CSRC) identifiers | 194 | .... | 195 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 196 | Optional Extension Header | 197 | .... | 198 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 199 | Extended Sequence Number | Reserved | PC = 0x00 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 201 . . 202 . Variable Length Coded Sequence Header . 203 . . 204 +---------------------------------------------------------------+ 206 Figure 1: RTP Payload Format For Sequence Header 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | V |P|X| CC |M| PT | Sequence Number | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Time Stamp | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | SSRC | 216 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 217 | contributing source (CSRC) identifiers | 218 | .... | 219 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 220 | Optional Extension Header | 221 | .... | 222 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 223 | Extended Sequence Number | Reserved |I|F| PC = 0xEC | 224 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 225 | Picture Number | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 227 | Slice Prefix Bytes | Slice Size Scaler | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 229 | Fragment Length | No. of Slices = 0 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 231 . . 232 . Variable Length Coded Transform Parameters . 233 . . 234 +---------------------------------------------------------------+ 236 Figure 2: RTP Payload Format For Transform Parameters 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | V |P|X| CC |M| PT | Sequence Number | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Time Stamp | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | SSRC | 246 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 247 | contributing source (CSRC) identifiers | 248 | .... | 249 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 250 | Optional Extension Header | 251 | .... | 252 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 253 | Extended Sequence Number | Reserved |I|F| PC = 0xEC | 254 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 255 | Picture Number | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 257 | Slice Prefix Bytes | Slice Size Scaler | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 259 | Fragment Length | No. of Slices | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 261 | Slice Offset X | Slice Offset Y | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 263 . . 264 . Coded Slices . 265 . . 266 +---------------------------------------------------------------+ 268 Figure 3: RTP Payload Format For Slices 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | V |P|X| CC |M| PT | Sequence Number | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Time Stamp | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | SSRC | 278 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 279 | contributing source (CSRC) identifiers | 280 | .... | 281 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 282 | Optional Extension Header | 283 | .... | 284 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 285 | Extended Sequence Number | Reserved | PC = 0x10 | 286 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 288 Figure 4: RTP Payload Format For End of Sequence 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | V |P|X| CC |M| PT | Sequence Number | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Time Stamp | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | SSRC | 298 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 299 | contributing source (CSRC) identifiers | 300 | .... | 301 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 302 | Optional Extension Header | 303 | .... | 304 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 305 | Extended Sequence Number |B|E| Reserved | PC = 0x20 | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Data Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 . . 310 . Uncoded Payload Data . 311 . . 312 +---------------------------------------------------------------+ 314 Figure 5: RTP Payload Format For Auxiliary Data 316 0 1 2 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | V |P|X| CC |M| PT | Sequence Number | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Time Stamp | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | SSRC | 324 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 325 | contributing source (CSRC) identifiers | 326 | .... | 327 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 328 | Optional Extension Header | 329 | .... | 330 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 331 | Extended Sequence Number |B|E| Reserved | PC = 0x30 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Data Length | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 . . 336 . Optional Payload Data . 337 . . 338 +---------------------------------------------------------------+ 340 Figure 6: RTP Payload Format For Padding Data 342 4.1. RTP Header Usage 344 The fields of the RTP header have the following additional notes on 345 their useage: 347 Marker Bit (M): 1 bit The marker bit MUST be set on any packet which 348 contains the final slice in a coded picture and MUST NOT be set 349 otherwise. 351 Payload Type (PT): 7 bits A dynamically allocated payload type field 352 that designates the payload as VC-2 coded video. 354 Sequence Number: 16 bits Because the data rate of VC-2 coded streams 355 can often be very high, in the order of gigabits rather than 356 megabits per second, the standard 16-bit RTP sequence number 357 can cycle very quickly. For this reason the sequence number is 358 extneded to 32-bits, and this field MUST holds the low-order 359 16-bits of this value. 361 Timestamp: 32 bits If the packet contains transform parameters or 362 coded slice data for a coded picture then the timestamp 363 corresponds to the sampling instant of the coded picture. A 364 90kHz clock SHOULD be used. A single RTP packet MUST NOT 365 contain coded data for more than one coded picture, so there is 366 no ambiguity here. 368 A sequence header packet SHOULD have the same timestamp as the 369 next picture which will follow it in the stream. An End of 370 Sequence packet SHOULD have the same timestamp as the previous 371 picture which appeared in the stream. 373 The remaining RTP header fields are used as specified in RTP 374 [RFC3550]. 376 4.2. Payload Header 378 The fields of the extended headers are defined as follows: 380 Extended Sequence Number: 16 bits MUST Contain the high-order 381 16-bits of the 32-bit packet sequence number, a number which 382 increments with each packet. This is needed since the high 383 data rates of VC2 sequences mean that it is highly likely that 384 the 16-bit sequence number will roll-over too frequently to be 385 of use for stream synchronisation. 387 B: 1 bit MUST be set to 1 if the packet contains the first byte of 388 an Auxiliary Data or Padded Data Unit. 390 E: 1 bit MUST be set to 1 if the packet contains the final byte of 391 an Auxiliary Data or Padded Data Unit. 393 I: 1 bit SHOULD be set to 1 if the packet contains coded picture 394 paramaters or slice data from a field in an interlaced frame, 395 and to 0 if the packet contains data from any part of a 396 progressive frame. 398 F: 1 bit SHOULD be set to 1 if the packet contains coded picture 399 paramaters or slice data from the second field of an interlaced 400 frame, and to 0 if the packet contains data from the first 401 field of an interlaced frame or any part of a progressive 402 frame. 404 Parse Code (PC): 8 bits Contains a Parse Code which MUST be the 405 value indicated for the type of data in the packet. 407 Data Length: 32 bits For an auxiliary data unit this contains the 408 number of bytes of data contained in the uncoded payload 409 section of this packet. For a Padding Data Unit this field may 410 have any value and simply indicates the size of the recommended 411 padding. 413 Picture Number: 32 bits MUST contain the Picture Number for the 414 coded picture this packet contains data for, as described in 415 Section 12.1 of the VC-2 specification [VC2]. 417 The sender MUST send at least one transform parameters packet 418 for each coded picture and MAY include more than one as long as 419 they contain identical data. The sender MUST NOT send a packet 420 from a new picture until all the coded data from the current 421 picture has been sendt. 423 If the receiver does not receive a transform parameters packet 424 for a picture then it MAY assume that the parameters are 425 unchanged since the last picture, or MAY discard the picture. 427 Slice Prefix Bytes: 16 bits MUST contain the Slice Prefix Bytes 428 value for the coded picture this packet contains data for, as 429 described in Section 12.3.4 of the VC-2 specification [VC2]. 431 In the VC-2 specification this value is not restricted to 16 432 bits, but in practice this is unlikely to ever be too large. 434 Slice Size Scaler: 16 bits MUST contain the Slice Size Scaler value 435 for the coded picture this packet contains data for, as 436 described in Section 12.3.4 of the VC-2 specification [VC2]. 438 In the VC-2 specification this value is not restricted to 16 439 bits, but in practice this is unlikely to ever be too large. 441 Fragment Length: 16 bits Contains the number of bytes of data 442 contained in the coded payload section of this packet. 444 No. of Slices: 16 bits Contains the number of coded slices contained 445 in this packet, which MUST be 0 for a packet containing 446 transform parameters. In a packet containing coded slices this 447 number MUST be the number of whole slices contained in the 448 packet, and the packet MUST NOT contain any partial slices. 450 Slice Offset X: 16 bits Indicates the X coordinate of the first 451 slice in this packet, in slices, starting from the top left 452 corner of the picture. 454 Slice Offset Y: 16 bits Indicates the Y coordinate of the first 455 slice in this packet, in slices, starting from the top left 456 corner of the picture. 458 4.3. The Choice of Parse Codes (Informative) 460 The "PC" field in the packets is used to carry the Parse Code which 461 identifies the type of content in the packet. This code matches the 462 value of the Parse Code used to identify each data unit in a VC-2 463 stream, as defined in the VC-2 specification, and each packet 464 contains the entire data unit. 466 If an incoming stream to be transmitted contains High Quality Picture 467 Data Units (Parse Code 0xE8) then these MUST be converted into High 468 Quality Picture Fragments (Parse Code 0xEC) before the data is placed 469 in the RTP packets. 471 +----------+-----------+---------------------+---------------+ 472 | PC (hex) | Binary | Description | Origin | 473 +----------+-----------+---------------------+---------------+ 474 | 0x00 | 0000 0000 | Sequence Header | VC-2 Spec | 475 | 0x10 | 0001 0000 | End of Sequence | VC-2 Spec | 476 +----------+-----------+---------------------+---------------+ 477 | 0xEC | 1110 1100 | HQ Picture Fragment | VC-2 Spec | 478 +----------+-----------+---------------------+---------------+ 480 Figure 7: Parse Codes and Meanings 482 4.4. Payload Data 484 For the Sequence Header packet type (PC = 0x00) the payload data MUST 485 be the coded sequence header exactly as it appears in the VC-2 486 Sequence. 488 For the Transform Parameters packet type (PC = 0xEC and No. Slices = 489 0) the payload data MUST be the variable length coded transform 490 parameters. This MUST NOT include the fragment header (since all 491 data in the picture header is already included in the packet header). 493 For the Auxiliary Data packet type (PC = 0x20) the payload data MUST 494 be a portion of the auxiliary data bytes contained in the Auxiliary 495 data unit being being transmitted. The B flag MUST be set on the 496 packet which contains the first byte, the E flag MUST be set on the 497 packet which contains the last byte, the bytes MUST be included in 498 order, and the packets MUST have contiguous sequence numbers. 500 For the Padding Data packet type (PC = 0x30) the payload data is 501 OPTIONAL, and if present MUST be a series of 0x00 values. 503 For the Picture Fragment packet type (PC = 0xEC and No. Slices > 0) 504 the payload data MUST be a specified number of coded slices in the 505 same order that they appear in the VC-2 stream. Which slices appear 506 in the packet is identified using the Slice Offset X and Slice Offset 507 Y fields in the payload header. 509 For the End of Sequence packet type (PC = 0x10) there is no payload 510 data. 512 4.4.1. Reassembling the Data 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | 0x42 | 0x42 | 0x43 | 0x44 | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Parse Code | Next Parse Offset 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Prev Parse Offset 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | 524 +-+-+-+-+-+-+-+-+ 526 Figure 8: VC-2 Parse Info Header 528 To reassemble the data in the RTP packets into a valid VC-2 sequence 529 the receiver SHOULD: 531 o Take the data from each packet with a Parse Code of 0x00 and 532 prepend a valid VC-2 Parse Info header (Figure 8) with the same 533 parse code to it. The resulting sequence header parse info header 534 and data unit MUST be included in the output stream before any 535 coded pictures which followed it in the RTP stream unless an 536 identical sequence header has already been included, and MAY be 537 repeated at any point that results in a valid VC-2 stream. 539 o Take the data from each packet with a Parse Code of 0xEC and No. 540 of Slices set to 0 (which together indicates that this packet 541 contains the transform parameters for a coded picture) and prepend 542 a valid VC-2 Parse Info header (Figure 8) followed by the picture 543 number, fragment data length, and slice count (0) to it with the 544 same parse code. 546 o Take the data from each packet with a Parse Code of 0xEC and No. 547 of Slices not set to 0 (which together indicates that this packet 548 contains coded slices) and prepend a valid VC-2 Parse Info header 549 (Figure 8) followed by the picture number, fragment data length, 550 slice count, x offset and y offset taken from the packet header to 551 it with the same parse code. 553 o A receiver MAY combine all fragment data units (with parse code 554 0xEC) and the same picture number into a single picture data unit 555 with parse code 0xE8. If the stream is required to comply with 556 major version 2 of the VC-2 Spec then this MUST be done. 558 o Take the data from each packet with a Parse Code of 0x20 and the B 559 bit set and prepend a valid VC-2 Parse Info header (Figure 8) with 560 the parse code 0x20 and then take each subsequent packet with 561 parse code 0x20 without the B bit set and append their payload to 562 the growing data unit. When all packets for a particular data 563 unit have been received it SHOULD be included in the output 564 stream. The final packet for a data unit will have the E bit set. 566 o Once a data unit has been assembled, whether a Sequence Header, 567 Coded Picture Fragment, Coded Picture, or Auxiliary Data Unit, the 568 next parse offset and previous parse offset values in its parse 569 info header should be filled with the offset between the start of 570 the header and the start of the next or previous. 572 o An End of Sequence parse info header MAY be inserted when a packet 573 with parse code set to 0x10 is encountered, or at any other time 574 that is allowed in a valid VC-2 stream. After an End of Sequence 575 parse info header is included in the output stream either the 576 stream must end or it MUST be followed by a Sequence Header 577 indicating the start of a new sequence. 579 o A Padding Data parse info header MAY be inserted when a packet 580 with parse code set to 0x30 and the B bit set is encountered, or 581 at any other time that is allowed in a valid VC-2 stream. The 582 length of this padding data MAY have any value, and its contents 583 MUST be set to a series of zero bytes. 585 5. Congestion Control Considerations 587 Congestion control for RTP SHALL be used in accordance with RFC 3550 588 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 589 [RFC3551]. An additional requirement if best-effort service is being 590 used is: users of this payload format MUST monitor packet loss to 591 ensure that the packet loss rate is within acceptable parameters. 592 Circuit Breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is an update 593 to RTP [RFC3550] that defines criteria for when one is required to 594 stop sending RTP Packet Streams. The circuit breakers is to be 595 implemented and followed. 597 6. Payload Format Parameters 599 This RTP payload format is identified using the video/vc2 media type 600 which is registered in accordance with RFC 4855 [RFC4855] and using 601 the template of RFC 6838 [RFC6838]. 603 6.1. Media Type Definition 605 Type name: 607 video 609 Subtype name: 611 vc2 613 Required parameters: 615 rate: The RTP timestamp clock rate. Applications using this 616 payload format SHOULD use a value of 90000. 618 profile: The VC-2 profile in use, the only currently allowed value 619 is "HQ". 621 Optional parameters: N/A 623 Encoding considerations: 625 This media type is framed and binary, see section 4.8 in RFC6838 626 [RFC6838]. 628 Security considerations: 630 Please see security consideration in RFCXXXX 632 Interoperability considerations: N/A 634 Published specification: 636 "VC-2 Video Compression", SMPTE Standard ST 2042-1 [VC2] 638 Applications that use this media type: 640 Video Communication. 642 Additional information: N/A 644 Person & email address to contact for further information: 646 james.barrett@bbc.co.uk 648 Intended usage: 650 COMMON 652 Restrictions on usage: 654 This media type depends on RTP framing, and hence is only defined 655 for transfer via RTP [RFC3550]. Transport within other framing 656 protocols is not defined at this time. 658 Author: 660 Change controller: 662 IETF Payload working group delegated from the IESG. 664 Provisional registration? (standards tree only): 666 No 668 (Any other information that the author deems interesting may be added 669 below this line.) 671 6.2. Mapping to SDP 673 The mapping of the above defined payload format media type and its 674 parameters SHALL be done according to Section 3 of RFC 4855 675 [RFC4855]. 677 6.2.1. Offer/Answer Considerations 679 All parameters are declarative. 681 7. IANA Considerations 683 This memo requests that IANA registers video/vc2 as specified in 684 Section 6.1. The media type is also requested to be added to the 685 IANA registry for "RTP Payload Format MIME types" 686 (http://www.iana.org/assignments/rtp-parameters). 688 8. Security Considerations 690 RTP packets using the payload format defined in this specification 691 are subject to the security considerations discussed in the RTP 692 specification [RFC3550] , and in any applicable RTP profile such as 693 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ 694 SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: 695 Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] 696 discusses, it is not an RTP payload format's responsibility to 697 discuss or mandate what solutions are used to meet the basic security 698 goals like confidentiality, integrity and source authenticity for RTP 699 in general. This responsibility lays on anyone using RTP in an 700 application. They can find guidance on available security mechanisms 701 and important considerations in Options for Securing RTP Sessions 702 [RFC7201]. Applications SHOULD use one or more appropriate strong 703 security mechanisms. The rest of this security consideration section 704 discusses the security impacting properties of the payload format 705 itself. 707 This RTP payload format and its media decoder do not exhibit any 708 significant non-uniformity in the receiver-side computational 709 complexity for packet processing, and thus are unlikely to pose a 710 denial-of-service threat due to the receipt of pathological data. 711 Nor does the RTP payload format contain any active content. 713 9. RFC Editor Considerations 715 Note to RFC Editor: This section may be removed after carrying out 716 all the instructions of this section. 718 RFCXXXX is to be replaced by the RFC number this specification 719 receives when published. 721 10. References 723 10.1. Normative References 725 [I-D.ietf-avtcore-rtp-circuit-breakers] 726 Perkins, C. and V. Singh, "Multimedia Congestion Control: 727 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 728 avtcore-rtp-circuit-breakers-18 (work in progress), August 729 2016. 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, 734 . 736 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 737 Jacobson, "RTP: A Transport Protocol for Real-Time 738 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 739 July 2003, . 741 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 742 Video Conferences with Minimal Control", STD 65, RFC 3551, 743 DOI 10.17487/RFC3551, July 2003, 744 . 746 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 747 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 748 . 750 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 751 Specifications and Registration Procedures", BCP 13, 752 RFC 6838, DOI 10.17487/RFC6838, January 2013, 753 . 755 [VC2] SMPTE, "VC-2 Video Compression", SMPTE Standard ST 2042-1, 756 2017, . 758 10.2. Informative References 760 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 761 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 762 RFC 3711, DOI 10.17487/RFC3711, March 2004, 763 . 765 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 766 "Extended RTP Profile for Real-time Transport Control 767 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 768 DOI 10.17487/RFC4585, July 2006, 769 . 771 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 772 Real-time Transport Control Protocol (RTCP)-Based Feedback 773 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 774 2008, . 776 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 777 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 778 . 780 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 781 Framework: Why RTP Does Not Mandate a Single Media 782 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 783 2014, . 785 Author's Address 787 James P. Weaver 788 BBC 790 Email: james.barrett@bbc.co.uk