idnits 2.17.1 draft-ietf-payload-rtp-vc2hq-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 -- The document date (April 4, 2017) is 2572 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 4, 2017 5 Expires: October 6, 2017 7 RTP Payload Format for VC-2 HQ Profile Video 8 draft-ietf-payload-rtp-vc2hq-02 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 October 6, 2017. 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 . . . . . . . . . . . . . . . . . . . 17 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:2012 [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 Auxiliary Data, 136 o Padding Data, and 138 o End of Sequence. 140 At time of writing there is currently no definition for the use of 141 Auxiliary Data in VC-2, and Padding Data is required to be ignored by 142 all receivers. 144 Each High Quality Picture data unit contains a set of parameters for 145 the picture followed by a series of coded Slices, each representing a 146 rectangular region of the transformed picture. Slices within a 147 picture may vary in coded length, but all represent the same shape 148 and size of rectangle in the picture. 150 4. Payload format 152 This specification only covers the transport of Sequence Headers, 153 High Quality Pictures, Auxiliary Data, and (optionally) End of 154 Sequence headers and Padding Data. 156 Since Sequence Headers and End of Sequence Headers are always small 157 they can easily be encapsulated in a single RTP packet each, but 158 since High Quality Pictures are usually much larger than the MTU of 159 most networks they require fragmentation into multiple packets. 161 For this reason this document defines four types of RTP packets in a 162 VC-2 media stream: one which carries the VC-2 Sequence Header 163 (Figure 1), one which carries the picture fragment containing the 164 VC-2 Transform Parameters for a Picture (Figure 2), one which carries 165 a picture fragment containing VC-2 Coded Slices (Figure 3) for a 166 picture, and one which signals the end of a VC-2 Sequence (Figure 4). 168 These four packet-types can be distinguished by the fact that they 169 use different codes in the "PC (Parse Code)" field, except for the 170 two types of packet fragment which both use the same value in PC but 171 have different values in the "No. of slices" field. 173 The choices of PC codes is explained in more detail in a following 174 informative section (Section 4.3). 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | V |P|X| CC |M| PT | Sequence Number | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Time Stamp | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | SSRC | 184 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 185 | contributing source (CSRC) identifiers | 186 | .... | 187 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 188 | Optional Extension Header | 189 | .... | 190 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 191 | Extended Sequence Number | Reserved | PC = 0x00 | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 193 . . 194 . Variable Length Coded Sequence Header . 195 . . 196 +---------------------------------------------------------------+ 198 Figure 1: RTP Payload Format For Sequence Header 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | V |P|X| CC |M| PT | Sequence Number | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Time Stamp | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | SSRC | 208 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 209 | contributing source (CSRC) identifiers | 210 | .... | 211 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 212 | Optional Extension Header | 213 | .... | 214 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 215 | Extended Sequence Number | Reserved |I|F| PC = 0xEC | 216 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 217 | Picture Number | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 219 | Slice Prefix Bytes | Slice Size Scaler | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 221 | Fragment Length | No. of Slices = 0 | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 223 . . 224 . Variable Length Coded Transform Parameters . 225 . . 226 +---------------------------------------------------------------+ 228 Figure 2: RTP Payload Format For Transform Parameters 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | V |P|X| CC |M| PT | Sequence Number | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Time Stamp | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | SSRC | 238 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 239 | contributing source (CSRC) identifiers | 240 | .... | 241 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 242 | Optional Extension Header | 243 | .... | 244 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 245 | Extended Sequence Number | Reserved |I|F| PC = 0xEC | 246 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 247 | Picture Number | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 249 | Slice Prefix Bytes | Slice Size Scaler | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 251 | Fragment Length | No. of Slices | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 253 | Slice Offset X | Slice Offset Y | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 255 . . 256 . Coded Slices . 257 . . 258 +---------------------------------------------------------------+ 260 Figure 3: RTP Payload Format For Slices 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | V |P|X| CC |M| PT | Sequence Number | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Time Stamp | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | SSRC | 270 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 271 | contributing source (CSRC) identifiers | 272 | .... | 273 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 274 | Optional Extension Header | 275 | .... | 276 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 277 | Extended Sequence Number | Reserved | PC = 0x10 | 278 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 280 Figure 4: RTP Payload Format For End of Sequence 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | V |P|X| CC |M| PT | Sequence Number | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Time Stamp | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | SSRC | 290 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 291 | contributing source (CSRC) identifiers | 292 | .... | 293 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 294 | Optional Extension Header | 295 | .... | 296 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 297 | Extended Sequence Number |B|E| Reserved | PC = 0x20 | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Data Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 . . 302 . Uncoded Payload Data . 303 . . 304 +---------------------------------------------------------------+ 306 Figure 5: RTP Payload Format For Auxiliary Data 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | V |P|X| CC |M| PT | Sequence Number | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Time Stamp | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | SSRC | 316 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 317 | contributing source (CSRC) identifiers | 318 | .... | 319 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 320 | Optional Extension Header | 321 | .... | 322 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 323 | Extended Sequence Number |B|E| Reserved | PC = 0x30 | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Data Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 . . 328 . Optional Payload Data . 329 . . 330 +---------------------------------------------------------------+ 332 Figure 6: RTP Payload Format For Padding Data 334 4.1. RTP Header Usage 336 The fields of the RTP header have the following additional notes on 337 their useage: 339 Marker Bit (M): 1 bit The marker bit MUST be set on any packet which 340 contains the final slice in a coded picture and MUST NOT be set 341 otherwise. 343 Payload Type (PT): 7 bits A dynamically allocated payload type field 344 that designates the payload as VC-2 coded video. 346 Sequence Number: 16 bits Because the data rate of VC-2 coded streams 347 can often be very high, in the order of gigabits rather than 348 megabits per second, the standard 16-bit RTP sequence number 349 can cycle very quickly. For this reason the sequence number is 350 extneded to 32-bits, and this field MUST holds the low-order 351 16-bits of this value. 353 Timestamp: 32 bits If the packet contains transform parameters or 354 coded slice data for a coded picture then the timestamp 355 corresponds to the sampling instant of the coded picture. A 356 90kHz clock SHOULD be used. A single RTP packet MUST NOT 357 contain coded data for more than one coded picture, so there is 358 no ambiguity here. 360 A sequence header packet SHOULD have the same timestamp as the 361 next picture which will follow it in the stream. An End of 362 Sequence packet SHOULD have the same timestamp as the previous 363 picture which appeared in the stream. 365 The remaining RTP header fields are used as specified in RTP 366 [RFC3550]. 368 4.2. Payload Header 370 The fields of the extended headers are defined as follows: 372 Extended Sequence Number: 16 bits MUST Contain the high-order 373 16-bits of the 32-bit packet sequence number, a number which 374 increments with each packet. This is needed since the high 375 data rates of VC2 sequences mean that it is highly likely that 376 the 16-bit sequence number will roll-over too frequently to be 377 of use for stream synchronisation. 379 B: 1 bit MUST be set to 1 if the packet contains the first byte of 380 an Auxiliary Data or Padded Data Unit. 382 E: 1 bit MUST be set to 1 if the packet contains the final byte of 383 an Auxiliary Data or Padded Data Unit. 385 I: 1 bit SHOULD be set to 1 if the packet contains coded picture 386 paramaters or slice data from a field in an interlaced frame, 387 and to 0 if the packet contains data from any part of a 388 progressive frame. 390 F: 1 bit SHOULD be set to 1 if the packet contains coded picture 391 paramaters or slice data from the second field of an interlaced 392 frame, and to 0 if the packet contains data from the first 393 field of an interlaced frame or any part of a progressive 394 frame. 396 Parse Code (PC): 8 bits Contains a Parse Code which MUST be the 397 value indicated for the type of data in the packet. 399 Data Length: 32 bits For an auxiliary data unit this contains the 400 number of bytes of data contained in the uncoded payload 401 section of this packet. For a Padding Data Unit this field may 402 have any value and simply indicates the size of the recommended 403 padding. 405 Picture Number: 32 bits MUST contain the Picture Number for the 406 coded picture this packet contains data for, as described in 407 Section 12.1 of the VC-2 specification [VC2]. 409 The sender MUST send at least one transform parameters packet 410 for each coded picture and MAY include more than one as long as 411 they contain identical data. The sender MUST NOT send a packet 412 from a new picture until all the coded data from the current 413 picture has been sendt. 415 If the receiver does not receive a transform parameters packet 416 for a picture then it MAY assume that the parameters are 417 unchanged since the last picture, or MAY discard the picture. 419 Slice Prefix Bytes: 16 bits MUST contain the Slice Prefix Bytes 420 value for the coded picture this packet contains data for, as 421 described in Section 12.3.4 of the VC-2 specification [VC2]. 423 In the VC-2 specification this value is not restricted to 16 424 bits, but in practice this is unlikely to ever be too large. 426 Slice Size Scaler: 16 bits MUST contain the Slice Size Scaler value 427 for the coded picture this packet contains data for, as 428 described in Section 12.3.4 of the VC-2 specification [VC2]. 430 In the VC-2 specification this value is not restricted to 16 431 bits, but in practice this is unlikely to ever be too large. 433 Fragment Length: 16 bits Contains the number of bytes of data 434 contained in the coded payload section of this packet. 436 No. of Slices: 16 bits Contains the number of coded slices contained 437 in this packet, which MUST be 0 for a packet containing 438 transform parameters. In a packet containing coded slices this 439 number MUST be the number of whole slices contained in the 440 packet, and the packet MUST NOT contain any partial slices. 442 Slice Offset X: 16 bits Indicates the X coordinate of the first 443 slice in this packet, in slices, starting from the top left 444 corner of the picture. 446 Slice Offset Y: 16 bits Indicates the Y coordinate of the first 447 slice in this packet, in slices, starting from the top left 448 corner of the picture. 450 4.3. The Choice of Parse Codes (Informative) 452 The "PC" field in the packets is used to carry the Parse Code which 453 identifies the type of content in the packet. For Sequence Header 454 and End of Sequence packets this code matches the value of the Parse 455 Code used to identify those data units in a VC-2 stream, as defined 456 in the VC-2 specification, and each packet contains the entire such 457 data unit. 459 For coded picture data, however, this is not possible because VC-2 460 coded picture data units are too large to fit conveniently into a 461 packet on most transports. Rather than use the Parse Code for the 462 picture, even though only a fragment of it is present, it was decided 463 to create a new parse code which would indicate a fragment of a 464 picture. 466 In compliance with the VC-2 specification this new choice of Parse 467 Code preserves the meaning of all the bits given meanings in 468 Section 10.4.1.1 of the VC-2 specification, but sets an additional 469 bit, bit 2, which was reserved for future expansion in that 470 specification. In this adaptation approach bit 2 now takes on the 471 meaning of "Picture Fragment". 473 +----------+-----------+---------------------+---------------+ 474 | PC (hex) | Binary | Description | Origin | 475 +----------+-----------+---------------------+---------------+ 476 | 0x00 | 0000 0000 | Sequence Header | VC-2 Spec | 477 | 0x10 | 0001 0000 | End of Sequence | VC-2 Spec | 478 +----------+-----------+---------------------+---------------+ 479 | 0xEC | 1110 1100 | HQ Picture Fragment | This document | 480 +----------+-----------+---------------------+---------------+ 482 Figure 7: Parse Codes and Meanings 484 This choice of Parse Codes and bit meanings matches a revision to the 485 VC-2 specification currently being considered by the SMPTE 487 4.4. Payload Data 489 For the Sequence Header packet type (PC = 0x00) the payload data MUST 490 be the coded sequence header exactly as it appears in the VC-2 491 Sequence. 493 For the Transform Parameters packet type (PC = 0xEC and No. Slices = 494 0) the payload data MUST be the variable length coded transform 495 parameters. This MUST NOT include the picture header (since all data 496 in the picture header is already included in the packet header). 498 For the Auxiliary Data packet type (PC = 0x20) the payload data MUST 499 be a portion of the auxiliary data bytes contained in the Auxiliary 500 data unit being being transmitted. The B flag MUST be set on the 501 packet which contains the first byte, the E flag MUST be set on the 502 packet which contains the last byte, the bytes MUST be included in 503 order, and the packets MUST have contiguous sequence numbers. 505 For the Padding Data packet type (PC = 0x30) the payload data is 506 OPTIONAL, and if present MUST be a series of 0x00 values. 508 For the Picture Fragment packet type (PC = 0xEC and No. Slices > 0) 509 the payload data MUST be a specified number of coded slices in the 510 same order that they appear in the VC-2 stream. Which slices appear 511 in the packet is identified using the Slice Offset X and Slice Offset 512 Y fields in the payload header. 514 For the End of Sequence packet type (PC = 0x10) there is no payload 515 data. 517 4.4.1. Reassembling the Data 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | 0x42 | 0x42 | 0x43 | 0x44 | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Parse Code | Next Parse Offset 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Prev Parse Offset 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | 529 +-+-+-+-+-+-+-+-+ 531 Figure 8: VC-2 Parse Info Header 533 To reassemble the data in the RTP packets into a valid VC-2 sequence 534 the receiver SHOULD: 536 o Take the data from each packet with a Parse Code of 0x00 and 537 prepend a valid VC-2 Parse Info header (Figure 8) with the same 538 parse code to it. The resulting sequence header parse info header 539 and data unit MUST be included in the output stream before any 540 coded pictures which followed it in the RTP stream unless an 541 identical sequence header has already been included, and MAY be 542 repeated at any point that results in a valid VC-2 stream. 544 o Take the data from each packet with a Parse Code of 0xEC and No. 545 of Slices set to 0 (which together indicates that this packet 546 contains the transform parameters for a coded picture) and prepend 547 a valid VC-2 Parse Info header (Figure 8) followed by the picture 548 number to it with the parse code 0xE8, then take the data from 549 each subsequent packet with parse code 0xEC and the same picture 550 number and append it to the end of this data unit. When all the 551 packets for a particular picture have been received (which is 552 indicated by the marker bit) the picture MUST be included in the 553 output stream, although a copy of the most recent Sequence Header 554 MAY be included immediately before it (and MUST be so if not 555 alrerady included in the current sequence). 557 o Take the data from each packet with a Parse Code of 0x20 and the B 558 bit set and prepend a valid VC-2 Parse Info header (Figure 8) with 559 the parse code 0x20 and then take each subsequent packet with 560 parse code 0x20 without the B bit set and append their payload to 561 the growing data unit. When all packets for a particular data 562 unit have been received it SHOULD be included in the output 563 stream. 565 o Once a data unit has been assembled, whether a Sequence Header or 566 a Coded Picture, the next parse offset and previous parse offset 567 values in its parse info header should be filled with the offset 568 between the start of the header and the start of the next or 569 previous. 571 o An End of Sequence parse info header MAY be inserted when a packet 572 with parse code set to 0x10 is encountered, or at any other time 573 that is allowed in a valid VC-2 stream. After an End of Sequence 574 parse info header is included in the output stream either the 575 stream must end or it MUST be followed by a Sequence Header 576 indicating the start of a new sequence. 578 o A Padding Data parse info header MAY be inserted when a packet 579 with parse code set to 0x30 and the B bit set is encountered, or 580 at any other time that is allowed in a valid VC-2 stream. The 581 length of this padding data MAY have any value, and its contents 582 MUST be set to a series of zero bytes. 584 5. Congestion Control Considerations 586 Congestion control for RTP SHALL be used in accordance with RFC 3550 587 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 588 [RFC3551]. An additional requirement if best-effort service is being 589 used is: users of this payload format MUST monitor packet loss to 590 ensure that the packet loss rate is within acceptable parameters. 591 Circuit Breakers [I-D.ietf-avtcore-rtp-circuit-breakers] is an update 592 to RTP [RFC3550] that defines criteria for when one is required to 593 stop sending RTP Packet Streams. The circuit breakers is to be 594 implemented and followed. 596 6. Payload Format Parameters 598 This RTP payload format is identified using the video/vc2 media type 599 which is registered in accordance with RFC 4855 [RFC4855] and using 600 the template of RFC 6838 [RFC6838]. 602 6.1. Media Type Definition 604 Type name: 606 video 608 Subtype name: 610 vc2 612 Required parameters: 614 rate: The RTP timestamp clock rate. Applications using this 615 payload format SHOULD use a value of 90000. 617 profile: The VC-2 profile in use, the only currently allowed value 618 is "HQ". 620 Optional parameters: N/A 622 Encoding considerations: 624 This media type is framed and binary, see section 4.8 in RFC6838 625 [RFC6838]. 627 Security considerations: 629 Please see security consideration in RFCXXXX 631 Interoperability considerations: N/A 633 Published specification: 635 "VC-2 Video Compression", SMPTE Standard ST 2042-1 [VC2] 637 Applications that use this media type: 639 Video Communication. 641 Additional information: N/A 643 Person & email address to contact for further information: 645 james.barrett@bbc.co.uk 647 Intended usage: 649 COMMON 651 Restrictions on usage: 653 This media type depends on RTP framing, and hence is only defined 654 for transfer via RTP [RFC3550]. Transport within other framing 655 protocols is not defined at this time. 657 Author: 659 Change controller: 661 IETF Payload working group delegated from the IESG. 663 Provisional registration? (standards tree only): 665 No 667 (Any other information that the author deems interesting may be added 668 below this line.) 670 6.2. Mapping to SDP 672 The mapping of the above defined payload format media type and its 673 parameters SHALL be done according to Section 3 of RFC 4855 674 [RFC4855]. 676 6.2.1. Offer/Answer Considerations 678 All parameters are declarative. 680 7. IANA Considerations 682 This memo requests that IANA registers video/vc2 as specified in 683 Section 6.1. The media type is also requested to be added to the 684 IANA registry for "RTP Payload Format MIME types" 685 (http://www.iana.org/assignments/rtp-parameters). 687 8. Security Considerations 689 RTP packets using the payload format defined in this specification 690 are subject to the security considerations discussed in the RTP 691 specification [RFC3550] , and in any applicable RTP profile such as 692 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ 693 SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: 694 Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] 695 discusses, it is not an RTP payload format's responsibility to 696 discuss or mandate what solutions are used to meet the basic security 697 goals like confidentiality, integrity and source authenticity for RTP 698 in general. This responsibility lays on anyone using RTP in an 699 application. They can find guidance on available security mechanisms 700 and important considerations in Options for Securing RTP Sessions 701 [RFC7201]. Applications SHOULD use one or more appropriate strong 702 security mechanisms. The rest of this security consideration section 703 discusses the security impacting properties of the payload format 704 itself. 706 This RTP payload format and its media decoder do not exhibit any 707 significant non-uniformity in the receiver-side computational 708 complexity for packet processing, and thus are unlikely to pose a 709 denial-of-service threat due to the receipt of pathological data. 710 Nor does the RTP payload format contain any active content. 712 9. RFC Editor Considerations 714 Note to RFC Editor: This section may be removed after carrying out 715 all the instructions of this section. 717 RFCXXXX is to be replaced by the RFC number this specification 718 receives when published. 720 10. References 722 10.1. Normative References 724 [I-D.ietf-avtcore-rtp-circuit-breakers] 725 Perkins, C. and V. Singh, "Multimedia Congestion Control: 726 Circuit Breakers for Unicast RTP Sessions", draft-ietf- 727 avtcore-rtp-circuit-breakers-18 (work in progress), August 728 2016. 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, 732 DOI 10.17487/RFC2119, March 1997, 733 . 735 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 736 Jacobson, "RTP: A Transport Protocol for Real-Time 737 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 738 July 2003, . 740 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 741 Video Conferences with Minimal Control", STD 65, RFC 3551, 742 DOI 10.17487/RFC3551, July 2003, 743 . 745 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 746 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 747 . 749 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 750 Specifications and Registration Procedures", BCP 13, 751 RFC 6838, DOI 10.17487/RFC6838, January 2013, 752 . 754 [VC2] SMPTE, "VC-2 Video Compression", SMPTE Standard ST 2042-1, 755 2012, . 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