idnits 2.17.1 draft-ietf-payload-rtp-vc2hq-08.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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: In this specification each RTP packet is used to carry data corresponding to a single Parse Info Header and its following data unit (if it has one). A single packet MAY NOT contain data from more than one Parse Info header or data unit. A single Parse Info Header and Data Unit pair MUST NOT be split accross more than one packet, the sole exception to this rule is that an Auxiliary Data Unit MAY be split between multiple packets, using the B and E flags to indicate start and end. -- The document date (August 29, 2018) is 2066 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 (~~), 2 warnings (==), 3 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 29, 2018 5 Expires: March 2, 2019 7 RTP Payload Format for VC-2 HQ Profile Video 8 draft-ietf-payload-rtp-vc2hq-08 10 Abstract 12 This memo describes an RTP Payload format for the High Quality (HQ) 13 profile of Society of Motion Picture and Television Engineers 14 Standard ST 2042-1 known as VC-2. This document describes the 15 transport of HQ Profile VC-2 in RTP packets and has applications for 16 low-complexity, high-bandwidth streaming of both lossless and lossy 17 compressed video. 19 The HQ profile of VC-2 is intended for low latency video compression 20 (with latency potentially on the order of lines of video) at high 21 data rates (with compression ratios on the order of 2:1 or 4:1). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 2, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 59 3. Media Format Description . . . . . . . . . . . . . . . . . . 3 60 4. Payload format . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 10 62 4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . 11 63 4.3. The Choice of Parse Codes (Informative) . . . . . . . . . 13 64 4.4. Stream Constraints . . . . . . . . . . . . . . . . . . . 13 65 4.5. Payload Data . . . . . . . . . . . . . . . . . . . . . . 15 66 4.5.1. Reassembling the Data . . . . . . . . . . . . . . . . 15 67 5. FEC Considerations . . . . . . . . . . . . . . . . . . . . . 17 68 6. Congestion Control Considerations . . . . . . . . . . . . . . 18 69 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 18 70 7.1. Media Type Definition . . . . . . . . . . . . . . . . . . 18 71 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 20 72 7.3. Offer/Answer Considerations . . . . . . . . . . . . . . . 20 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 75 10. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 21 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 78 11.2. Informative References . . . . . . . . . . . . . . . . . 23 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 81 1. Introduction 83 This memo specifies an RTP payload format for the video coding 84 standard Society of Motion Picture and Television Engineers ST 85 2042-1:2017 [VC2] also known as VC-2 87 The VC-2 codec is a wavelet-based codec intended primarily for 88 professional video use with high bit-rates and only low levels of 89 compression. It has been designed to be low-complexity, and 90 potentially have a very low latency through both encoder and decoder: 91 with some choices of parameters this latency may be as low as a few 92 lines of video. 94 The low level of complexity in the VC-2 codec allows for this low 95 latency operation but also means that it lacks many of the more 96 powerful compression techniques used in other codecs. As such it is 97 suitable for low compression ratios that produce coded data rates 98 around half to a quarter of that of uncompressed video, at a similar 99 visual quality. 101 The primary use for VC-2 is likely to be in professional video 102 production environments. 104 2. Conventions, Definitions and Acronyms 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 3. Media Format Description 114 The VC-2 specification defines a VC-2 stream as being composed of one 115 or more Sequences. Each Sequence is independently decodable, 116 containing all of the needed parameters and metadata for configuring 117 the decoder. 119 Each Sequence consists of a series of 13-octet Parse Info headers and 120 variable length Data Units. The Sequence begins and ends with a 121 Parse Info header and each Data Unit is preceded by a Parse Info 122 Header. Data Units come in a variety of types, and the type of a 123 Data Unit is signaled in the proceding Parse Info Header. The most 124 important types are the Sequence Header, which contains configuration 125 data needed by the decoder, and several types of Coded Picture, which 126 contain the coded data for the pictures themselves. Each picture 127 represents a frame in a progressively scanned video Sequence or a 128 field in an interlaced video Sequence. 130 The first Data Unit in a Sequence as produced by an encoder is always 131 a Sequence Header, but Sequences can be joined in the middle, so this 132 should not be assumed. 134 The High Quality (HQ) profile for VC-2 restricts the types of Parse 135 Info Headers which may appear in the Sequence (and hence also the 136 types of Data Unit) to only: 138 o Sequence Headers (which are always followed by a Data Unit), 140 o High Quality Pictures (which are always followed by a Data Unit), 142 o High Quality Fragments (which are always followed by a Data Unit), 144 o Auxiliary Data (which are always followed by a Data Unit), 145 o Padding Data (which are always followed by a Data Unit), and 147 o End of Sequence (which are never followed by a Data Unit). 149 At time of writing there is currently no definition for the use of 150 Auxiliary Data in VC-2, and Padding Data is required to be ignored by 151 all receivers. 153 Each High Quality Picture data unit contains a set of parameters for 154 the picture followed by a series of coded Slices, each representing a 155 rectangular region of the transformed picture. Slices within a 156 picture may vary in coded length, but all represent the same shape 157 and size of rectangle in the picture. 159 Each High Quality Fragment data unit contains either a set of 160 parameters for a picture or it contains a series of coded Slices. 161 Fragments carry the same data as pictures, but broken up into smaller 162 units to facilitate transmission via packet-based protocols such as 163 RTP. 165 This payload format only makes use of fragments, not pictures. 167 4. Payload format 169 In this specification each RTP packet is used to carry data 170 corresponding to a single Parse Info Header and its following data 171 unit (if it has one). A single packet MAY NOT contain data from more 172 than one Parse Info header or data unit. A single Parse Info Header 173 and Data Unit pair MUST NOT be split accross more than one packet, 174 the sole exception to this rule is that an Auxiliary Data Unit MAY be 175 split between multiple packets, using the B and E flags to indicate 176 start and end. 178 This specification only covers the transport of Sequence Headers 179 (together with their accompanying data unit), High Quality Fragments 180 (together with their accompanying data unit), Auxiliary Data 181 (together with their accompanying data unit), and (optionally) End 182 Sequence Headers and Padding Data (for which no data unit it 183 carried). 185 High Quality Pictures can be transported by converting them into an 186 equivalent set of High Quality Fragments. The size of fragments 187 should be chosen so as to fit within the MTU of the network in use. 189 For this reason this document defines six types of RTP packets in a 190 VC-2 media stream: 192 o A VC-2 Sequence Header (Figure 1) (see Section 11 of the VC-2 193 specification [VC2]), 195 o A Picture Fragment containing the VC-2 Transform Parameters for a 196 Picture (Figure 2) (see Section 14 of the VC-2 specification 197 [VC2]), 199 o A Picture Fragment containing VC-2 Coded Slices (Figure 3) for a 200 picture (see Section 14 of the VC-2 specification [VC2]), 202 o The end of a VC-2 Sequence (Figure 4)(see Section 10.5.2 of the 203 VC-2 specification [VC2]), 205 o The contents of an auxiliary data unit (Figure 5)(see 206 Section 10.4.4 of the VC-2 specification [VC2]), and 208 o An indication of the presence of a padding data unit (Figure 6) 209 (see Section 10.4.5 of the VC-2 specification [VC2]). 211 These six packet-types can be distinguished by the fact that they use 212 different codes in the "PC (Parse Code)" field, except for the two 213 types of picture fragment which both use the same value in PC but 214 have different values in the "No. of slices" field. 216 The choices of PC codes is explained in more detail in a following 217 informative section (Section 4.3). 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | V |P|X| CC |M| PT | Sequence Number | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Timestamp | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | SSRC | 227 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 228 | contributing source (CSRC) identifiers | 229 | .... | 230 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 231 | Optional Extension Header | 232 | .... | 233 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 234 | Extended Sequence Number | Reserved | PC = 0x00 | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 236 . . 237 . Variable Length Coded Sequence Header . 238 . . 239 +---------------------------------------------------------------+ 241 Figure 1: RTP Payload Format For Sequence Header 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | V |P|X| CC |M| PT | Sequence Number | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Timestamp | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | SSRC | 251 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 252 | contributing source (CSRC) identifiers | 253 | .... | 254 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 255 | Optional Extension Header | 256 | .... | 257 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 258 | Extended Sequence Number | Reserved |I|F| PC = 0xEC | 259 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 260 | Picture Number | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 262 | Slice Prefix Bytes | Slice Size Scaler | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 264 | Fragment Length | No. of Slices = 0 | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 266 . . 267 . Variable Length Coded Transform Parameters . 268 . . 269 +---------------------------------------------------------------+ 271 Figure 2: RTP Payload Format For Transform Parameters Fragment 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | V |P|X| CC |M| PT | Sequence Number | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Timestamp | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | SSRC | 281 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 282 | contributing source (CSRC) identifiers | 283 | .... | 284 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 285 | Optional Extension Header | 286 | .... | 287 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 288 | Extended Sequence Number | Reserved |I|F| PC = 0xEC | 289 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 290 | Picture Number | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 292 | Slice Prefix Bytes | Slice Size Scaler | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 294 | Fragment Length | No. of Slices | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 296 | Slice Offset X | Slice Offset Y | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 298 . . 299 . Coded Slices . 300 . . 301 +---------------------------------------------------------------+ 303 Figure 3: RTP Payload Format For Fragment Containing Slices 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | V |P|X| CC |M| PT | Sequence Number | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Timestamp | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | SSRC | 313 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 314 | contributing source (CSRC) identifiers | 315 | .... | 316 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 317 | Optional Extension Header | 318 | .... | 319 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 320 | Extended Sequence Number | Reserved | PC = 0x10 | 321 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 323 Figure 4: RTP Payload Format For End of Sequence 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | V |P|X| CC |M| PT | Sequence Number | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Timestamp | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | SSRC | 333 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 334 | contributing source (CSRC) identifiers | 335 | .... | 336 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 337 | Optional Extension Header | 338 | .... | 339 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 340 | Extended Sequence Number |B|E| Reserved | PC = 0x20 | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Data Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 . . 345 . Uncoded Payload Data . 346 . . 347 +---------------------------------------------------------------+ 349 Figure 5: RTP Payload Format For Auxiliary Data 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | V |P|X| CC |M| PT | Sequence Number | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Timestamp | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | SSRC | 359 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 360 | contributing source (CSRC) identifiers | 361 | .... | 362 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 363 | Optional Extension Header | 364 | .... | 365 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 366 | Extended Sequence Number |B|E| Reserved | PC = 0x30 | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Data Length | 369 +---------------------------------------------------------------+ 371 Figure 6: RTP Payload Format For Padding Data 373 All fields in the headers longer than a single bit are interpreted as 374 unsigned integers in network byte order. 376 4.1. RTP Header Usage 378 The fields of the RTP header have the following additional notes on 379 their useage: 381 Marker Bit (M): 1 bit The marker bit MUST be set on any packet which 382 contains the final slice in a coded picture and MUST NOT be set 383 otherwise. 385 Payload Type (PT): 7 bits A dynamically allocated payload type field 386 that designates the payload as VC-2 coded video. 388 Sequence Number: 16 bits Because the data rate of VC-2 coded streams 389 can often be very high, in the order of gigabits rather than 390 megabits per second, the standard 16-bit RTP sequence number 391 can cycle very quickly. For this reason the sequence number is 392 extended to 32-bits, and this field MUST hold the low-order 393 16-bits of this value. 395 Timestamp: 32 bits If the packet contains transform parameters or 396 coded slice data for a coded picture then the timestamp 397 corresponds to the sampling instant of the coded picture. A 398 90kHz clock SHOULD be used. A single RTP packet MUST NOT 399 contain coded data for more than one coded picture, so there is 400 no ambiguity here. 402 A Sequence Header packet SHOULD have the same timestamp as the 403 next picture which will follow it in the stream. An End of 404 Sequence packet SHOULD have the same timestamp as the previous 405 picture which appeared in the stream. 407 The remaining RTP header fields are used as specified in RTP 408 [RFC3550]. 410 4.2. Payload Header 412 The fields of the extended headers are defined as follows: 414 Extended Sequence Number: 16 bits MUST Contain the high-order 415 16-bits of the 32-bit packet sequence number. This is needed 416 since the high data rates of VC2 Sequences mean that it is 417 highly likely that the 16-bit sequence number will roll-over 418 too frequently to be of use for stream synchronisation. 420 B: 1 bit MUST be set to 1 if the packet contains the first byte of 421 an Auxiliary Data Unit, and otherwise MUST be 0. If the 422 recommendations of the Stream Contraints Section of this 423 specification (Section 4.4) are followed then every Auxiliary 424 Data Unit will be small enough to fit in a single packet and so 425 this bit (where present) will always be 1. 427 E: 1 bit MUST be set to 1 if the packet contains the final byte of 428 an Auxiliary Data Unit, and otherwise MUST be 0. If the 429 recommendations of the Stream Contraints Section of this 430 specification (Section 4.4) are followed then every Auxiliary 431 Data Unit will be small enough to fit in a single packet and so 432 this bit (where present) will always be 1. 434 I: 1 bit MUST be set to 1 if the packet contains coded picture 435 paramaters or slice data from a field in an interlaced frame, 436 and to 0 if the packet contains data from any part of a 437 progressive frame. 439 F: 1 bit MUST be set to 1 if the packet contains coded picture 440 paramaters or slice data from the second field of an interlaced 441 frame, and to 0 if the packet contains data from the first 442 field of an interlaced frame or any part of a progressive 443 frame. 445 Parse Code (PC): 8 bits Contains a Parse Code which MUST be the 446 value indicated for the type of data in the packet. 448 Data Length: 32 bits For an auxiliary data unit this contains the 449 number of bytes of data contained in the payload section of 450 this packet. If the recommendations of the Stream Contraints 451 Section of this specification (Section 4.4) are followed then 452 no Auxiliary Data Unit will be large enough to cause a packet 453 to exceed the MTU of the network. 455 Picture Number: 32 bits MUST contain the Picture Number for the 456 coded picture this packet contains data for, as described in 457 Section 12.1 of the VC-2 specification [VC2]. 459 The sender MUST send at least one transform parameters packet 460 for each coded picture and MAY include more than one as long as 461 they contain identical data. The sender MUST NOT send a packet 462 from a new picture until all the coded data from the current 463 picture has been sent. 465 If the receiver does not receive a transform parameters packet 466 for a picture then it MAY assume that the parameters are 467 unchanged since the last picture, or MAY discard the picture. 468 Choosing between these two options is left up to the 469 implementation as it will be dependent on intended use, the 470 former may result in malformed pictures, the latter will result 471 in dropped frames. Such an occurance is an indication either 472 of packet loss, joining a stream mid-picture, or of a non- 473 compliant transmitter. 475 Slice Prefix Bytes: 16 bits MUST contain the Slice Prefix Bytes 476 value for the coded picture this packet contains data for, as 477 described in Section 12.3.4 of the VC-2 specification [VC2]. 479 In the VC-2 specification this value is not restricted to 16 480 bits, but the constraints on streams specified in this document 481 (Section 4.4) do require this. 483 Slice Size Scaler: 16 bits MUST contain the Slice Size Scaler value 484 for the coded picture this packet contains data for, as 485 described in Section 12.3.4 of the VC-2 specification [VC2]. 487 In the VC-2 specification this value is not restricted to 16 488 bits, but the constraints on streams specified in this document 489 (Section 4.4) do require this. 491 Fragment Length: 16 bits MUST contain the number of bytes of data 492 contained in the coded payload section of this packet. 494 No. of Slices: 16 bits MUST contain the number of coded slices 495 contained in this packet, which MUST be 0 for a packet 496 containing transform parameters. In a packet containing coded 497 slices this number MUST be the number of whole slices contained 498 in the packet, and the packet MUST NOT contain any partial 499 slices. 501 Slice Offset X: 16 bits MUST contain the X coordinate of the first 502 slice in this packet, in slices, starting from the top left 503 corner of the picture. 505 Slice Offset Y: 16 bits MUST contain the Y coordinate of the first 506 slice in this packet, in slices, starting from the top left 507 corner of the picture. 509 4.3. The Choice of Parse Codes (Informative) 511 The "PC" field in the packets is used to carry the Parse Code which 512 identifies the type of content in the packet. This code matches the 513 value of the Parse Code used to identify each data unit in a VC-2 514 stream, as defined in the VC-2 specification, and each packet 515 contains the entire data unit. 517 The table below lists all of the parse codes currently allowed in a 518 VC-2 Sequence. The final column indicates whether the code in 519 question can be present in a stream transmitted using this 520 specification. 522 +----------+-----------+---------------------+---------------+ 523 | PC (hex) | Binary | Description | Valid | 524 +----------+-----------+---------------------+---------------+ 525 | 0x00 | 0000 0000 | Sequence Header | Yes | 526 | 0x10 | 0001 0000 | End of Sequence | Yes | 527 | 0x20 | 0010 0000 | Auxiliary Data | Yes | 528 | 0x30 | 0011 0000 | Padding Data | Yes | 529 +----------+-----------+---------------------+---------------+ 530 | 0xC8 | 1100 1000 | LD Picture | No | 531 | 0xE8 | 1110 1000 | HQ Picture | No | 532 | 0xEC | 1110 1100 | HQ Picture Fragment | Yes | 533 +----------+-----------+---------------------+---------------+ 535 Figure 7: Parse Codes and Meanings 537 4.4. Stream Constraints 539 There are some constraints which a Sequence needs to conform to in 540 order to be transmissible with this specification. 542 o The sequence MUST NOT contain Parse Info Headers with a Parse Code 543 which is not 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20 544 (Auxiliary Data), 0x30 (Padding Data) and 0xEC (High Quality 545 Picture Fragment). Some other streams MAY be convertible to meet 546 this restriction (see below). 548 o Every High Quality Picture Fragment MUST be no longer than 65535 549 bytes. This can usually be ensured by splitting large fragments 550 into several smaller fragments, except in the case where an 551 individual slice is too large, in which case see the notes below 552 on conversion. 554 o Informative note: this requirement ensures that every High Quality 555 Picture Fragment will always contain no more than 65535 slices. 557 o Every High Quality Picture Fragment SHOULD be small enough that 558 the RTP packet carrying it will fit within the network MTU size. 559 This can usually be ensured by splitting large fragments into 560 several smaller fragments, except in the case where an individual 561 slice is too large, in which case see the notes below on 562 conversion. 564 o Every High Quality Picture Fragment MUST be encoded using values 565 for Slice Prefix Bytes and Slice Size Scaler no greater than 566 65535. 568 If a Sequence intended for tranmission does not conform to these 569 restrictions then it MAY be possible to simply convert it into a form 570 that does by splitting pictures and/or large fragments into suitably 571 sized fragments. This can be done provided that the following 572 (weaker) constraints are met: 574 o The sequence does not contain Parse Info Headers with a Parse Code 575 which is not 0x00 (Sequence Header), 0x10 (End of Sequence), 0x20 576 (Auxiliary Data), 0x30 (Padding Data), 0xE8 (High Quality 577 Picture), and 0xEC (High Quality Picture Fragment). 579 o Every High Quality Picture or High Quality Picture Fragment 580 contains no slices which are individually longer than 65535 bytes. 581 Note: When this is the case the values of Slice Prefix Bytes and 582 Slice Size Scaler will necessarily also be smaller than 65535. 584 o Every High Quality Picture or High Quality Picture Fragment 585 contains no slices which are individually so large that an RTP 586 packet carrying a Fragment containing that single slice will fit 587 within the network MTU size. 589 Sending a Stream which does not meet the above requirements via this 590 mechanism is not possible unless the stream is re-encoded by a VC-2 591 Encoder so as to meet them. 593 In addition every Auxiliary Data Unit SHOULD be small enough that a 594 single RTP packet carrying it will fit within the network MTU size. 595 Since there is currently no specification for the format of Auxiliary 596 Data in VC-2 the mechanism for ensuring this with an encoder 597 implementation that includes Auxiliary Data Units will be dependent 598 upon the implementation's use for them. 600 When encoding VC-2 video intended to be transported via RTP a VC-2 601 profile and level which ensures these requirements are met SHOULD be 602 used. 604 4.5. Payload Data 606 For the Sequence Header packet type (PC = 0x00) the payload data MUST 607 be the coded Sequence Header exactly as it appears in the VC-2 608 Sequence. 610 For the Transform Parameters packet type (PC = 0xEC and No. Slices = 611 0) the payload data MUST be the variable length coded transform 612 parameters. This MUST NOT include the fragment header (since all 613 data in the picture header is already included in the packet header). 615 For the Auxiliary Data packet type (PC = 0x20) the payload data MUST 616 be a portion of the auxiliary data bytes contained in the Auxiliary 617 data unit being being transmitted. The B flag MUST be set on the 618 packet which contains the first byte, the E flag MUST be set on the 619 packet which contains the last byte, the bytes MUST be included in 620 order, and the packets MUST have contiguous sequence numbers. 622 For the Picture Fragment packet type (PC = 0xEC and No. Slices > 0) 623 the payload data MUST be a specified number of coded slices in the 624 same order that they appear in the VC-2 stream. Which slices appear 625 in the packet is identified using the Slice Offset X and Slice Offset 626 Y fields in the payload header. 628 For the End of Sequence packet type (PC = 0x10) there is no payload 629 data. 631 4.5.1. Reassembling the Data 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | 0x42 | 0x42 | 0x43 | 0x44 | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Parse Code | Next Parse Offset 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Prev Parse Offset 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | 642 +-+-+-+-+-+-+-+-+ 644 Figure 8: VC-2 Parse Info Header 646 To reassemble the data in the RTP packets into a valid VC-2 Sequence 647 the receiver SHOULD: 649 o Take the data from each packet with a Parse Code of 0x00 and 650 prepend a valid VC-2 Parse Info Header (Figure 8) with the same 651 parse code to it. The resulting Sequence Header Parse Info Header 652 and data unit MUST be included in the output stream before any 653 coded pictures which followed it in the RTP stream unless an 654 identical Sequence Header has already been included, and MAY be 655 repeated (with apropriate modfifications to the next and previous 656 header oddsets) at any point that results in a valid VC-2 stream. 658 o Take the data from each packet with a Parse Code of 0xEC and No. 659 of Slices set to 0 (which together indicates that this packet 660 contains the transform parameters for a coded picture) and prepend 661 a valid VC-2 Parse Info Header (Figure 8) followed by the picture 662 number, fragment data length, and slice count (0) to it with the 663 same parse code. 665 o Take the data from each packet with a Parse Code of 0xEC and No. 666 of Slices not set to 0 (which together indicates that this packet 667 contains coded slices) and prepend a valid VC-2 Parse Info Header 668 (Figure 8) followed by the picture number, fragment data length, 669 slice count, x offset and y offset taken from the packet header to 670 it with the same parse code. 672 o A receiver MAY combine all fragment data units (with parse code 673 0xEC) and the same picture number into a single picture data unit 674 with parse code 0xE8. If the stream is required to comply with 675 major versions 1 or 2 of the VC-2 Spec then this MUST be done. 677 o Take the data from each packet with a Parse Code of 0x20 and the B 678 bit set and prepend a valid VC-2 Parse Info Header (Figure 8) with 679 the parse code 0x20 and then take each subsequent packet with 680 parse code 0x20 without the B bit set and append their payload to 681 the growing data unit. When all packets for a particular data 682 unit have been received it SHOULD be included in the output 683 stream. The final packet for a data unit will have the E bit set. 685 o Once a data unit has been assembled, whether a Sequence Header, 686 Coded Picture Fragment, Coded Picture, or Auxiliary Data Unit, the 687 next parse offset and previous parse offset values in its Parse 688 Info Header SHOULD be filled with the offset between the start of 689 the header and the start of the next or previous. 691 o An End of Sequence Parse Info Header MAY be inserted when a packet 692 with parse code set to 0x10 is encountered, or at any other time 693 that is allowed in a valid VC-2 stream. After an End of Sequence 694 Parse Info Header is included in the output stream either the 695 stream must end or it MUST be followed by a Sequence Header 696 indicating the start of a new Sequence. The next parse offset of 697 the End of Sequence header MUST be set t 0, and the previous parse 698 offset SHOULD be filled with the offset from the start of the 699 previous parse info header in the stream. 701 o A Padding Data Parse Info Header MAY be inserted when a packet 702 with parse code set to 0x30 and the B bit set is encountered, or 703 at any other time that is allowed in a valid VC-2 stream. The 704 length of the accompanying data unit MAY have any value, and its 705 contents MUST be set to a series of zero bytes. The next parse 706 offset and previous parse offset values in its Parse Info Header 707 SHOULD be filled with the offset between the start of the header 708 and the start of the next or previous. 710 5. FEC Considerations 712 VC-2 provides no underlying protection against data loss, so it may 713 be useful to employ forward error correction to the stream. A 714 mechanism for doing this to a generic RTP stream is specified in 715 RFC5109 [RFC5109]. If making use of this mechanism to provide multi- 716 level protection then the packets SHOULD be assigned to layers based 717 upon their packet type, with the packet types in order of importance 718 being: 720 1. Sequence Headers 722 2. Fragments constaining Transform Parameters 724 3. Fragments containing coded slices 726 4. Auxiliary Data and end of Sequence 727 5. Padding 729 It is RECOMMENDED that if multi-level protection is to be used then 730 one layer will protect all Sequence Header packets, and a second will 731 protect Sequence Headers and all Fragments. If desired a third layer 732 MAY protect Auxiliary Data and End of Sequence packets. Padding data 733 SHOULD NOT be protected by FEC. 735 6. Congestion Control Considerations 737 Congestion control for RTP SHALL be used in accordance with RFC 3550 738 [RFC3550], and with any applicable RTP profile; e.g., RFC 3551 739 [RFC3551]. An additional requirement if best-effort service is being 740 used is: users of this payload format MUST monitor packet loss to 741 ensure that the packet loss rate is within acceptable parameters. 742 Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines 743 criteria for when one is required to stop sending RTP Packet Streams, 744 and applications implementing this standard MUST comply with it. RFC 745 8085 [RFC8085] provides additional information on the best practices 746 for applying congestion control to UDP streams. 748 In particular it should be noted that the expected data rate for RTP 749 sessions which use this profile is likely to be in the range of 750 gigabits per second. If used on a closed network which has been 751 correctly provisioned for the expected data rates this might not pose 752 a problem, but there is always the risk of data getting out onto the 753 open internet. 755 7. Payload Format Parameters 757 This RTP payload format is identified using the video/vc2 media type 758 which is registered in accordance with RFC 4855 [RFC4855] and using 759 the template of RFC 6838 [RFC6838]. 761 7.1. Media Type Definition 763 Type name: 765 video 767 Subtype name: 769 vc2 771 Required parameters: 773 rate: The RTP timestamp clock rate. Applications using this 774 payload format SHOULD use a value of 90000. 776 profile: The VC-2 profile in use, the only currently allowed value 777 is "HQ". 779 Optional parameters: 781 version: the VC-2 specification version in use. The only 782 currently allowed value is "3" since all Sequences transported 783 using this mechanism will contain HQ Picture Fragment data units, 784 which the VC-2 specification [VC2] defines as requiring version 3. 786 level: The VC-2 level in use. Any integer may be used. 788 Encoding considerations: 790 This media type is framed and binary, see section 4.8 in RFC6838 791 [RFC6838]. 793 Security considerations: 795 Please see security consideration in RFCXXXX 797 Interoperability considerations: N/A 799 Published specification: 801 RFC XXXX 803 Applications that use this media type: 805 Video Communication. 807 Fragment Identifier Considerations: N/A 809 Additional information: N/A 811 Person & email address to contact for further information: 813 james.barrett@bbc.co.uk 815 Intended usage: 817 COMMON 819 Restrictions on usage: 821 This media type depends on RTP framing, and hence is only defined 822 for transfer via RTP [RFC3550]. Transport within other framing 823 protocols is not defined at this time. 825 Author: 827 Change controller: 829 IETF Payload working group delegated from the IESG. 831 Provisional registration? (standards tree only): 833 No 835 7.2. Mapping to SDP 837 The mapping of the above defined payload format media type and its 838 parameters SHALL be done according to Section 3 of RFC 4855 839 [RFC4855]. 841 o The type name ("video") goes in SDP "m=" as the media name. 843 o The subtype name ("vc2") goes in SDP "a=rtpmap" as the encoding 844 name, followed by a slash ("/") and the rate parameter. 846 o The required parameter profile and the optional parameters version 847 and level, when present, are included in the "a=fmtp" attribute 848 line of SDP as a semicolon-separated list of parameter=value 849 pairs. 851 Version and level SHALL be specified in decimal when present. 853 For example, a sample SDP mapping for VC-2 could be as follows: 855 m=video 30000 RTP/AVP 112 856 a=rtpmap:112 vc2/90000 857 a=fmtp:112 profile=HQ;version=3;level=0 859 In this example, a dynamic payload type 112 is used for vc-2 data. 860 The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" line 861 after the subtype. In the "a=fmtp:" line, profile HQ, version 3, and 862 level 0 (unknown or non-standard level) are specified. 864 7.3. Offer/Answer Considerations 866 All parameters are declarative. 868 8. IANA Considerations 870 This memo requests that IANA registers video/vc2 as specified in 871 Section 7.1. The media type is also requested to be added to the 872 IANA registry for "RTP Payload Format MIME types" 873 (http://www.iana.org/assignments/rtp-parameters). 875 9. Security Considerations 877 RTP packets using the payload format defined in this specification 878 are subject to the security considerations discussed in the RTP 879 specification [RFC3550] , and in any applicable RTP profile such as 880 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/ 881 SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework: 882 Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] 883 discusses, it is not an RTP payload format's responsibility to 884 discuss or mandate what solutions are used to meet the basic security 885 goals like confidentiality, integrity and source authenticity for RTP 886 in general. This responsibility lies with anyone using RTP in an 887 application. They can find guidance on available security mechanisms 888 and important considerations in Options for Securing RTP Sessions 889 [RFC7201]. Applications SHOULD use one or more appropriate strong 890 security mechanisms. The rest of this security consideration section 891 discusses the security impacting properties of the payload format 892 itself. 894 This RTP payload format and its media decoder do not exhibit any 895 significant non-uniformity in the receiver-side computational 896 complexity for packet processing, and thus are unlikely to pose a 897 denial-of-service threat due to the receipt of pathological data. 898 Nor does the RTP payload format contain any active content. 900 To avoid buffer overruns when processing these packets the receiver 901 MUST consider both the reported fragment length and the actual 902 received size of a packet containing slice data. 904 In some cases the transmitter may need to decode variable length 905 coded headers in order to extract some data from the VC-2 bitstream 906 before assembling packets. This process is potentially subject to 907 buffer overruns if not implemented carefully. 909 10. RFC Editor Considerations 911 Note to RFC Editor: This section may be removed after carrying out 912 all the instructions of this section. 914 RFCXXXX is to be replaced by the RFC number this specification 915 receives when published. 917 11. References 919 11.1. Normative References 921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 922 Requirement Levels", BCP 14, RFC 2119, 923 DOI 10.17487/RFC2119, March 1997, 924 . 926 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 927 Jacobson, "RTP: A Transport Protocol for Real-Time 928 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 929 July 2003, . 931 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 932 Video Conferences with Minimal Control", STD 65, RFC 3551, 933 DOI 10.17487/RFC3551, July 2003, 934 . 936 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 937 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 938 . 940 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 941 Specifications and Registration Procedures", BCP 13, 942 RFC 6838, DOI 10.17487/RFC6838, January 2013, 943 . 945 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 946 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 947 DOI 10.17487/RFC8083, March 2017, 948 . 950 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 951 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 952 March 2017, . 954 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 955 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 956 May 2017, . 958 [VC2] Society of Motion Picture and Television Engineers, "VC-2 959 Video Compression", Society of Motion Picture and 960 Television Engineers Standard ST 2042-1, 2017, 961 . 963 11.2. Informative References 965 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 966 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 967 RFC 3711, DOI 10.17487/RFC3711, March 2004, 968 . 970 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 971 "Extended RTP Profile for Real-time Transport Control 972 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 973 DOI 10.17487/RFC4585, July 2006, 974 . 976 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 977 Correction", RFC 5109, DOI 10.17487/RFC5109, December 978 2007, . 980 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 981 Real-time Transport Control Protocol (RTCP)-Based Feedback 982 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 983 2008, . 985 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 986 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 987 . 989 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 990 Framework: Why RTP Does Not Mandate a Single Media 991 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 992 2014, . 994 Author's Address 996 James P. Weaver 997 BBC 999 Email: james.barrett@bbc.co.uk