idnits 2.17.1 draft-ietf-payload-rtp-jpegxs-12.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 (May 3, 2021) is 1089 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. 'ISO21122-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO21122-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO21122-3' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 avtcore S. Lugan 3 Internet-Draft intoPIX 4 Intended status: Standards Track A. Descampe 5 Expires: November 4, 2021 UCL 6 C. Damman 7 intoPIX 8 T. Richter 9 IIS 10 T. Bruylants 11 intoPIX 12 May 3, 2021 14 RTP Payload Format for ISO/IEC 21122 (JPEG XS) 15 draft-ietf-payload-rtp-jpegxs-12 17 Abstract 19 This document specifies a Real-Time Transport Protocol (RTP) payload 20 format to be used for transporting JPEG XS (ISO/IEC 21122) encoded 21 video. JPEG XS is a low-latency, lightweight image coding system. 22 Compared to an uncompressed video use case, it allows higher 23 resolutions and frame rates, while offering visually lossless 24 quality, reduced power consumption, and end-to-end latency confined 25 to a fraction of a frame. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 4, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions, Definitions, and Abbreviations . . . . . . . . . 3 63 3. Media Format Description . . . . . . . . . . . . . . . . . . 4 64 3.1. Image Data Structures . . . . . . . . . . . . . . . . . . 5 65 3.2. Codestream . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Video support box and colour specification box . . . . . 5 67 3.4. JPEG XS Frame . . . . . . . . . . . . . . . . . . . . . . 6 68 4. RTP Payload Format . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. RTP packetization . . . . . . . . . . . . . . . . . . . . 6 70 4.2. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 9 71 4.3. Payload Header Usage . . . . . . . . . . . . . . . . . . 10 72 4.4. Payload Data . . . . . . . . . . . . . . . . . . . . . . 12 73 5. Traffic Shaping and Delivery Timing . . . . . . . . . . . . . 17 74 6. Congestion Control Considerations . . . . . . . . . . . . . . 18 75 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 18 76 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 18 77 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 23 78 7.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 23 79 7.2.2. Media type and subtype . . . . . . . . . . . . . . . 23 80 7.2.3. Offer/Answer Considerations . . . . . . . . . . . . . 24 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 84 11. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 26 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 87 12.2. Informative References . . . . . . . . . . . . . . . . . 27 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 90 1. Introduction 92 This document specifies a payload format for packetization of JPEG XS 93 [ISO21122-1] encoded video signals into the Real-time Transport 94 Protocol (RTP) [RFC3550]. 96 The JPEG XS coding system offers compression and recompression of 97 image sequences with very moderate computational resources while 98 remaining robust under multiple compression and decompression cycles 99 and mixing of content sources, e.g. embedding of subtitles, overlays 100 or logos. Typical target compression ratios ensuring visually 101 lossless quality are in the range of 2:1 to 10:1, depending on the 102 nature of the source material. The end-to-end latency can be 103 confined to a fraction of a frame, typically between a small number 104 of lines down to below a single line. 106 2. Conventions, Definitions, and Abbreviations 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 Application Data Unit (ADU) 115 The unit of source data provided as payload to the transport 116 layer, and corresponding, in this RTP payload definition, to a 117 single JPEG XS frame. 119 Colour specification box (CS box) 120 A ISO colour specification box defined in JPEG XS Part 3 121 [ISO21122-3] that includes colour-related metadata required to 122 correctly display JPEG XS frames, such as colour primaries, 123 transfer characteristics and matrix coefficients. 125 EOC marker 126 A marker that consists of the two bytes 0xff11 indicating the end 127 of a JPEG XS codestream. 129 JPEG XS codestream 130 A sequence of bytes representing a compressed image formatted 131 according to JPEG XS Part 1 [ISO21122-1]. 133 JPEG XS codestream header 134 A sequence of bytes, starting with a SOC marker, at the beginning 135 of each JPEG XS codestream encoded in multiple markers and marker 136 segments that does not carry entropy coded data, but metadata such 137 as the frame dimension and component precision. 139 JPEG XS frame 140 A JPEG XS picture segment in the case of a progressive frame, or, 141 in the case of an interlaced frame, the concatenation of two JPEG 142 XS picture segments. 144 JPEG XS header segment 145 The concatenation of a video support box [ISO21122-3], a colour 146 specification box [ISO21122-3], and a JPEG XS codestream header. 148 JPEG XS picture segment 149 The concatenation of a video support box [ISO21122-3], a colour 150 specification box [ISO21122-3], and a JPEG XS codestream. 152 JPEG XS stream 153 A sequence of JPEG XS frames. 155 Marker 156 A two-byte functional sequence that is part of a JPEG XS 157 codestream starting with a 0xff byte and a subsequent byte 158 defining its function. 160 Marker segment 161 A marker along with a 16-bit marker size and payload data 162 following the size. 164 Packetization unit 165 A portion of an Application Data Unit whose boundaries coincide 166 with boundaries of RTP packet payloads (excluding payload header), 167 i.e. the first (resp. last) byte of a packetization unit is the 168 first (resp. last) byte of a RTP packet payload (excluding its 169 payload header). 171 Slice 172 The smallest independently decodable unit of a JPEG XS codestream, 173 bearing in mind that it decodes to wavelet coefficients which 174 still require inverse wavelet filtering to give an image. 176 SOC marker 177 A marker that consists of the two bytes 0xff10 indicating the 178 start of a JPEG XS codestream. The SOC marker is considered an 179 integral part of the JPEG XS codestream header. 181 Video support box (VS box) 182 An ISO video support box, as defined in [ISO21122-3], that 183 includes metadata required to play back a JPEG XS stream, such as 184 its maximum bitrate, its subsampling structure, its buffer model 185 and its frame rate. 187 3. Media Format Description 188 3.1. Image Data Structures 190 JPEG XS is a low-latency lightweight image coding system for coding 191 continuous-tone grayscale or continuous-tone colour digital images. 193 This coding system provides an efficient representation of image 194 signals through the mathematical tool of wavelet analysis. The 195 wavelet filter process separates each component into multiple bands, 196 where each band consists of multiple coefficients describing the 197 image signal of a given component within a frequency domain specific 198 to the wavelet filter type, i.e. the particular filter corresponding 199 to the band. 201 Wavelet coefficients are grouped into precincts, where each precinct 202 includes all coefficients over all bands that contribute to a spatial 203 region of the image. 205 One or multiple precincts are furthermore combined into slices 206 consisting of an integer number of precincts. Precincts do not cross 207 slice boundaries, and wavelet coefficients in precincts that are part 208 of different slices can be decoded independently from each other. 209 Note, however, that the wavelet transformation runs across slice 210 boundaries. A slice always extends over the full width of the image, 211 but may only cover parts of its height. 213 3.2. Codestream 215 A JPEG XS codestream header, starting with an SOC marker, followed by 216 one or more slices, and terminated by an EOC marker form a JPEG XS 217 codestream. 219 The JPEG XS codestream format, including the definition of all 220 markers, is further defined in [ISO21122-1]. It represents sample 221 values of a single image, bare any interpretation relative to a 222 colour space. 224 3.3. Video support box and colour specification box 226 While the information defined in the codestream is sufficient to 227 reconstruct the sample values of one image, the interpretation of the 228 samples remains undefined by the codestream itself. This 229 interpretation is given by the video support box and the colour 230 specification box which contain significant information to correctly 231 play the JPEG XS stream. The layout and syntax of these boxes, 232 together with their content, are defined in [ISO21122-3]. The video 233 support box provides information on the maximum bitrate, the frame 234 rate, the frame mode (progressive or interlaced), the subsampling 235 image format, the timecode of the current JPEG XS frame, the profile, 236 level and sublevel used (as defined in [ISO21122-2]), and optionally 237 on the buffer model and the mastering display metadata. The colour 238 specification box indicates the colour primaries, transfer 239 characteristics, matrix coefficients and video full range flag needed 240 to specify the colour space of the video stream. 242 3.4. JPEG XS Frame 244 The concatenation of a video support box, a colour specification box, 245 and a JPEG XS codestream forms a JPEG XS picture segment. 247 In the case of a progressive video stream, each JPEG XS frame 248 consists of one single JPEG XS picture segment. 250 In the case of an interlaced video stream, each JPEG XS frame is made 251 of two concatenated JPEG XS picture segments. The codestream of each 252 picture segment corresponds exclusively to one of the two fields of 253 the interlaced frame. Both picture segments SHALL contain identical 254 boxes (i.e. concatenation of the video support box and the colour 255 specification box is byte exact the same for both picture segments of 256 the frame). 258 Note that the interlaced mode as signaled by the frat field in the 259 video support box indicates either progressive, interlaced top-field 260 first, or interlaced bottom-field first mode. Thus, its value too 261 SHALL be identical in both picture segments. 263 4. RTP Payload Format 265 This section specifies the payload format for JPEG XS streams over 266 the Real-time Transport Protocol (RTP) [RFC3550]. 268 In order to be transported over RTP, each JPEG XS stream is 269 transported in a distinct RTP stream, identified by a distinct 270 Synchronization source (SSRC) [RFC3550]. 272 A JPEG XS stream is divided into Application Data Units (ADUs), each 273 ADU corresponding to a single JPEG XS frame. 275 4.1. RTP packetization 277 An ADU is made of several packetization units. If a packetization 278 unit is bigger than the maximum size of a RTP packet payload, the 279 unit is split into multiple RTP packet payloads, as illustrated in 280 Figure 1. As seen there, each packet SHALL contain (part of) one and 281 only one packetization unit. A packetization unit may extend over 282 multiple packets. The payload of every packet SHALL have the same 283 size (based e.g. on the Maximum Transfer Unit of the network), except 284 (possibly) the last packet of a packetization unit. The boundaries 285 of a packetization unit SHALL coincide with the boundaries of the 286 payload of a packet (excluding the payload header), i.e. the first 287 (resp. last) byte of the packetization unit SHALL be the first (resp. 288 last) byte of the payload (excluding its header). 290 RTP +-----+------------------------+ 291 Packet #1 | Hdr | Packetization unit #1 | 292 +-----+------------------------+ 293 RTP +-----+--------------------------------------+ 294 Packet #2 | Hdr | Packetization unit #2 | 295 +-----+--------------------------------------+ 296 RTP +-----+--------------------------------------------------+ 297 Packet #3 | Hdr | Packetization unit #3 (part 1/3) | 298 +-----+--------------------------------------------------+ 299 RTP +-----+--------------------------------------------------+ 300 Packet #4 | Hdr | Packetization unit #3 (part 2/3) | 301 +-----+--------------------------------------------------+ 302 RTP +-----+----------------------------------------------+ 303 Packet #5 | Hdr | Packetization unit #3 (part 3/3) | 304 +-----+----------------------------------------------+ 305 ... 306 RTP +-----+-----------------------------------------+ 307 Packet #P | Hdr | Packetization unit #N (part q/q) | 308 +-----+-----------------------------------------+ 310 Figure 1: Example of ADU packetization 312 There are two different packetization modes defined for this RTP 313 payload format. 315 1. Codestream packetization mode: in this mode, the packetization 316 unit SHALL be the entire JPEG XS picture segment (i.e. codestream 317 preceeded by boxes). This means that a progressive frame will 318 have a single packetization unit, while an interlaced frame will 319 have two. The progressive case is illustrated in Figure 2. 321 2. Slice packetization mode: in this mode, the packetization unit 322 SHALL be the slice, i.e. there SHALL be data from no more than 323 one slice per RTP packet. The first packetization unit SHALL be 324 made of the JPEG XS header segment (i.e. the concatenation of the 325 VS box, the CS box and the JPEG XS codestream header). This 326 first unit is then followed by successive units, each containing 327 one and only one slice. The packetization unit containing the 328 last slice of a JPEG XS codestream SHALL also contain the EOC 329 marker immediately following this last slice. This is 330 illustrated in Figure 3. In the case of an interlaced frame, the 331 JPEG XS header segment of the second field SHALL be in its own 332 packetization unit. 334 RTP +-----+--------------------------------------------------+ 335 Packet #1 | Hdr | VS box + CS box + JPEG XS codestream (part 1/q) | 336 +-----+--------------------------------------------------+ 337 RTP +-----+--------------------------------------------------+ 338 Packet #2 | Hdr | JPEG XS codestream (part 2/q) | 339 +-----+--------------------------------------------------+ 340 ... 341 RTP +-----+--------------------------------------+ 342 Packet #P | Hdr | JPEG XS codestream (part q/q) | 343 +-----+--------------------------------------+ 345 Figure 2: Example of codestream packetization mode 347 RTP +-----+----------------------------+ 348 Packet #1 | Hdr | JPEG XS header segment | 349 +-----+----------------------------+ 350 RTP +-----+--------------------------------------------------+ 351 Packet #2 | Hdr | Slice #1 (part 1/2) | 352 +-----+--------------------------------------------------+ 353 RTP +-----+-------------------------------------------+ 354 Packet #3 | Hdr | Slice #1 (part 2/2) | 355 +-----+-------------------------------------------+ 356 RTP +-----+--------------------------------------------------+ 357 Packet #4 | Hdr | Slice #2 (part 1/3) | 358 +-----+--------------------------------------------------+ 359 ... 360 RTP +-----+---------------------------------------+ 361 Packet #P | Hdr | Slice #N (part q/q) + EOC marker | 362 +-----+---------------------------------------+ 364 Figure 3: Example of slice packetization mode 366 Due to the constant bit-rate of JPEG XS, the codestream packetization 367 mode guarantees that a JPEG XS RTP stream will produce a constant 368 number of bytes per frame, and a constant number of RTP packets per 369 frame. To reach the same guarantee with the slice packetization 370 mode, an additional mechanism is required. This can involve a 371 constraint at the rate allocation stage in the JPEG XS encoder to 372 impose a constant bit-rate at the slice level, the usage of padding 373 data, or the insertion of empty RTP packets (i.e. a RTP packet whose 374 payload data is empty). 376 4.2. RTP Header Usage 378 The format of the RTP header is specified in [RFC3550] and reprinted 379 in Figure 4 for convenience. This RTP payload format uses the fields 380 of the header in a manner consistent with that specification. 382 The RTP payload (and the settings for some RTP header bits) for 383 packetization units are specified in Section 4.3. 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | V |P|X| CC |M| PT | sequence number | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | timestamp | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | synchronization source (SSRC) identifier | 393 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 394 | contributing source (CSRC) identifiers | 395 | .... | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 4: RTP header according to RFC 3550 400 The version (V), padding (P), extension (X), CSRC count (CC), 401 sequence number, synchronization source (SSRC) and contributing 402 source (CSRC) fields follow their respective definitions in 403 [RFC3550]. 405 The remaining RTP header information to be set according to this RTP 406 payload format is set as follows: 408 Marker (M) [1 bit]: 410 If progressive scan video is being transmitted, the marker bit 411 denotes the end of a video frame. If interlaced video is being 412 transmitted, it denotes the end of the field. The marker bit 413 SHALL be set to 1 for the last packet of the video frame/field. 414 It SHALL be set to 0 for all other packets. 416 Payload Type (PT) [7 bits]: 418 A dynamically allocated payload type field that designates the 419 payload as JPEG XS video. 421 Timestamp [32 bits]: 423 The RTP timestamp is set to the sampling timestamp of the content. 424 A 90 kHz clock rate SHALL be used. 426 As specified in [RFC3550] and [RFC4175], the RTP timestamp 427 designates the sampling instant of the first octet of the frame to 428 which the RTP packet belongs. Packets SHALL NOT include data from 429 multiple frames, and all packets belonging to the same frame SHALL 430 have the same timestamp. Several successive RTP packets will 431 consequently have equal timestamps if they belong to the same 432 frame (that is until the marker bit is set to 1, marking the last 433 packet of the frame), and the timestamp is only increased when a 434 new frame begins. 436 If the sampling instant does not correspond to an integer value of 437 the clock, the value SHALL be truncated to the next lowest 438 integer, with no ambiguity. 440 4.3. Payload Header Usage 442 The first four bytes of the payload of an RTP packet in this RTP 443 payload format are referred to as the payload header. Figure 5 444 illustrates the structure of this payload header. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 |T|K|L| I |F counter| SEP counter | P counter | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 5: Payload header 454 The payload header consists of the following fields: 456 Transmission mode (T) [1 bit]: 458 The T bit is set to indicate that packets are sent sequentially by 459 the transmitter. This information allows a receiver to dimension 460 its input buffer(s) accordingly. If T=0, nothing can be assumed 461 about the transmission order and packets may be sent out-of-order 462 by the transmitter. If T=1, packets SHALL be sent sequentially by 463 the transmitter. 465 pacKetization mode (K) [1 bit]: 467 The K bit is set to indicate which packetization mode is used. 468 K=0 indicates codestream packetization mode, while K=1 indicates 469 slice packetization mode. In the case that the Transmission mode 470 (T) is set to 0, the slice packetization mode SHALL be used and K 471 SHALL be set to 1. 473 Last (L) [1 bit]: 475 The L bit is set to indicate the last packet of a packetization 476 unit. As the end of the frame also ends the packet containing the 477 last unit of the frame, the L bit is set whenever the M bit is 478 set. If codestream packetization mode is used, L bit and M bit 479 are equivalent. 481 Interlaced information (I) [2 bit]: 483 These 2 bits are used to indicate how the JPEG XS frame is scanned 484 (progressive or interlaced). In case of an interlaced frame, they 485 also indicate which JPEG XS picture segment the payload is part of 486 (first or second). 488 00: The payload is progressively scanned. 490 01: Reserved for future use. 492 10: The payload is part of the first JPEG XS picture segment of 493 an interlaced video frame. The height specified in the 494 included JPEG XS codestream header is half of the height of the 495 entire displayed image. 497 11: The payload is part of the second JPEG XS picture segment of 498 an interlaced video frame. The height specified in the 499 included JPEG XS codestream header is half of the height of the 500 entire displayed image. 502 F counter [5 bits]: 504 The frame (F) counter identifies the frame number modulo 32 to 505 which a packet belongs. Frame numbers are incremented by 1 for 506 each frame transmitted. The frame number, in addition to the 507 timestamp, may help the decoder manage its input buffer and bring 508 packets back into their natural order. 510 SEP counter [11 bits]: 512 The Slice and Extended Packet (SEP) counter is used differently 513 depending on the packetization mode. 515 * In the case of codestream packetization mode (K=0), this 516 counter resets whenever the Packet counter resets (see 517 hereunder), and increments by 1 whenever the Packet counter 518 overruns. 520 * In the case of slice packetization mode (K=1), this counter 521 identifies the slice modulo 2047 to which the packet 522 contributes. If the data belongs to the JPEG XS header 523 segment, this field SHALL have its maximal value, namely 2047 = 524 0x07ff. Otherwise, it is the slice index modulo 2047. Slice 525 indices are counted from 0 (corresponding to the top of the 526 frame). 528 P counter [11 bits]: 530 The packet (P) counter identifies the packet number modulo 2048 531 within the current packetization unit. It is set to 0 at the 532 start of the packetization unit and incremented by 1 for every 533 subsequent packet (if any) belonging to the same unit. 534 Practically, if codestream packetization mode is enabled, this 535 field counts the packets within a JPEG XS picture segment and is 536 extended by the SEP counter when it overruns. If slice 537 packetization mode is enabled, this field counts the packets 538 within a slice or within the JPEG XS header segment. 540 4.4. Payload Data 542 The payload data of a JPEG XS RTP stream consists of a concatenation 543 of multiple JPEG XS frames. Within the RTP stream, all of the video 544 support boxes and all of the colour specification boxes SHALL retain 545 their respective layouts for each JPEG XS frame. Thus, each video 546 support box in the RTP stream SHALL define the same sub boxes. The 547 effective values in the boxes are allowed to change under the 548 condition that their relative byte offsets SHALL NOT change. 550 Each JPEG XS frame is the concatenation of one or more packetization 551 unit(s), as explained in Section 4.1. Figure 6 depicts this layout 552 for a progressive frame in the codestream packetization mode, 553 Figure 7 depicts this layout for an interlaced frame in the 554 codestream packetization mode, Figure 8 depicts this layout for a 555 progressive frame in the slice packetization mode and Figure 9 556 depicts this layout for an interlaced frame in the slice 557 packetization mode. The Frame counter value is not indicated because 558 the value is constant for all packetization units of a given frame. 560 +=====[ Packetization unit (PU) #1 ]====+ 561 | Video support box | SEP counter=0 562 | +---------------------------------+ | P counter=0 563 | : Sub boxes of the VS box : | 564 | +---------------------------------+ | 565 +- - - - - - - - - - - - - - - - - - - -+ 566 | Colour specification box | 567 | +---------------------------------+ | 568 | : Fields of the CS box : | 569 | +---------------------------------+ | 570 +- - - - - - - - - - - - - - - - - - - -+ 571 | JPEG XS codestream | 572 : (part 1/q) : M=0, K=0, L=0, I=00 573 +---------------------------------------+ 574 | JPEG XS codestream | SEP counter=0 575 | (part 2/q) | P counter=1 576 : : M=0, K=0, L=0, I=00 577 +---------------------------------------+ 578 | JPEG XS codestream | SEP counter=0 579 | (part 3/q) | P counter=2 580 : : M=0, K=0, L=0, I=00 581 +---------------------------------------+ 582 : : 583 +---------------------------------------+ 584 | JPEG XS codestream | SEP counter=1 585 | (part 2049/q) | P counter=0 586 : : M=0, K=0, L=0, I=00 587 +---------------------------------------+ 588 : : 589 +---------------------------------------+ 590 | JPEG XS codestream | SEP counter=(q-1) div 2048 591 | (part q/q) | P counter=(q-1) mod 2048 592 : : M=1, K=0, L=1, I=00 593 +=======================================+ 595 Figure 6: Example of JPEG XS Payload Data (codestream packetization 596 mode, progressive frame) 598 +=====[ Packetization unit (PU) #1 ]====+ 599 | Video support box | SEP counter=0 600 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 601 | Colour specification box | 602 +- - - - - - - - - - - - - - - - - - - -+ 603 | JPEG XS codestream (1st field) | 604 : (part 1/q) : M=0, K=0, L=0, I=10 605 +---------------------------------------+ 606 | JPEG XS codestream (1st field) | SEP counter=0 607 | (part 2/q) | P counter=1 608 : : M=0, K=0, L=0, I=10 609 +---------------------------------------+ 610 : : 611 +---------------------------------------+ 612 | JPEG XS codestream (1st field) | SEP counter=1 613 | (part 2049/q) | P counter=0 614 : : M=0, K=0, L=0, I=10 615 +---------------------------------------+ 616 : : 617 +---------------------------------------+ 618 | JPEG XS codestream (1st field) | SEP counter=(q-1) div 2048 619 | (part q/q) | P counter=(q-1) mod 2048 620 : : M=1, K=0, L=1, I=10 621 +===============[ PU #2 ]===============+ 622 | Video support box | SEP counter=0 623 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 624 | Colour specification box | 625 +- - - - - - - - - - - - - - - - - - - -+ 626 | JPEG XS codestream (2nd field) | 627 | (part 1/q) | 628 : : M=0, K=0, L=0, I=11 629 +---------------------------------------+ 630 | JPEG XS codestream (2nd field) | SEP counter=0 631 | (part 2/q) | P counter=1 632 : : M=0, K=0, L=0, I=11 633 +---------------------------------------+ 634 : : 635 +---------------------------------------+ 636 | JPEG XS codestream (2nd field) | SEP counter=(q-1) div 2048 637 | (part q/q) | P counter=(q-1) mod 2048 638 : : M=1, K=0, L=1, I=11 639 +=======================================+ 641 Figure 7: Example of JPEG XS Payload Data (codestream packetization 642 mode, interlaced frame) 644 +===[ PU #1: JPEG XS Header segment ]===+ 645 | Video support box | SEP counter=0x07FF 646 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 647 | Colour specification box | 648 +- - - - - - - - - - - - - - - - - - - -+ 649 | JPEG XS codestream header | 650 | +---------------------------------+ | 651 | : Markers and marker segments : | 652 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=00 653 +==========[ PU #2: Slice #1 ]==========+ 654 | +---------------------------------+ | SEP counter=0 655 | | SLH Marker | | P counter=0 656 | +---------------------------------+ | 657 | : Entropy Coded Data : | 658 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=00 659 +==========[ PU #3: Slice #2 ]==========+ 660 | Slice #2 | SEP counter=1 661 | (part 1/q) | P counter=0 662 : : M=0, T=0, K=1, L=0, I=00 663 +---------------------------------------+ 664 | Slice #2 | SEP counter=1 665 | (part 2/q) | P counter=1 666 : : M=0, T=0, K=1, L=0, I=00 667 +---------------------------------------+ 668 : : 669 +---------------------------------------+ 670 | Slice #2 | SEP counter=1 671 | (part q/q) | P counter=q-1 672 : : M=0, T=0, K=1, L=1, I=00 673 +=======================================+ 674 : : 675 +========[ PU #N: Slice #(N-1) ]========+ 676 | Slice #(N-1) | SEP counter=N-2 677 | (part 1/r) | P counter=0 678 : : M=0, T=0, K=1, L=0, I=00 679 +---------------------------------------+ 680 : : 681 +---------------------------------------+ 682 | Slice #(N-1) | SEP counter=N-2 683 | (part r/r) | P counter=r-1 684 : + EOC marker : M=1, T=0, K=1, L=1, I=00 685 +=======================================+ 687 Figure 8: Example of JPEG XS Payload Data (slice packetization mode, 688 progressive frame) 690 +====[ PU #1: JPEG XS Hdr segment 1 ]===+ 691 | Video support box | SEP counter=0x07FF 692 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 693 | Colour specification box | 694 +- - - - - - - - - - - - - - - - - - - -+ 695 | JPEG XS codestream header 1 | 696 | +---------------------------------+ | 697 | : Markers and marker segments : | 698 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=10 699 +====[ PU #2: Slice #1 (1st field) ]====+ 700 | +---------------------------------+ | SEP counter=0 701 | | SLH Marker | | P counter=0 702 | +---------------------------------+ | 703 | : Entropy Coded Data : | 704 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=10 705 +====[ PU #3: Slice #2 (1st field) ]====+ 706 | Slice #2 | SEP counter=1 707 | (part 1/q) | P counter=0 708 : : M=0, T=0, K=1, L=0, I=10 709 +---------------------------------------+ 710 | Slice #2 | SEP counter=1 711 | (part 2/q) | P counter=1 712 : : M=0, T=0, K=1, L=0, I=10 713 +---------------------------------------+ 714 : : 715 +---------------------------------------+ 716 | Slice #2 | SEP counter=1 717 | (part q/q) | P counter=q-1 718 : : M=0, T=0, K=1, L=1, I=10 719 +=======================================+ 720 : : 721 +==[ PU #N: Slice #(N-1) (1st field) ]==+ 722 | Slice #(N-1) | SEP counter=N-2 723 | (part 1/r) | P counter=0 724 : : M=0, T=0, K=1, L=0, I=10 725 +---------------------------------------+ 726 : : 727 +---------------------------------------+ 728 | Slice #(N-1) | SEP counter=N-2 729 | (part r/r) | P counter=r-1 730 : + EOC marker : M=1, T=0, K=1, L=1, I=10 731 +=======================================+ 732 +===[ PU #N+1: JPEG XS Hdr segment 2 ]==+ 733 | Video support box | SEP counter=0x07FF 734 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 735 | Colour specification box | 736 +- - - - - - - - - - - - - - - - - - - -+ 737 | JPEG XS codestream header 2 | 738 | +---------------------------------+ | 739 | : Markers and marker segments : | 740 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=11 741 +===[ PU #N+2: Slice #1 (2nd field) ]===+ 742 | +---------------------------------+ | SEP counter=0 743 | | SLH Marker | | P counter=0 744 | +---------------------------------+ | 745 | : Entropy Coded Data : | 746 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=11 747 +===[ PU #N+3: Slice #2 (2nd field) ]===+ 748 | Slice #2 | SEP counter=1 749 | (part 1/s) | P counter=0 750 : : M=0, T=0, K=1, L=0, I=11 751 +---------------------------------------+ 752 | Slice #2 | SEP counter=1 753 | (part 2/s) | P counter=1 754 : : M=0, T=0, K=1, L=0, I=11 755 +---------------------------------------+ 756 : : 757 +---------------------------------------+ 758 | Slice #2 | SEP counter=1 759 | (part s/s) | P counter=s-1 760 : : M=0, T=0, K=1, L=1, I=11 761 +=======================================+ 762 : : 763 +==[ PU #2N: Slice #(N-1) (2nd field) ]=+ 764 | Slice #(N-1) | SEP counter=N-2 765 | (part 1/t) | P counter=0 766 : : M=0, T=0, K=1, L=0, I=11 767 +---------------------------------------+ 768 : : 769 +---------------------------------------+ 770 | Slice #(N-1) | SEP counter=N-2 771 | (part t/t) | P counter=t-1 772 : + EOC marker : M=1, T=0, K=1, L=1, I=11 773 +=======================================+ 775 Figure 9: Example of JPEG XS Payload Data (slice packetization mode, 776 interlaced frame) 778 5. Traffic Shaping and Delivery Timing 780 In order to facilitate proper synchronization between senders and 781 receivers it is RECOMMENDED to implement traffic shaping and delivery 782 timing in accordance with the Network Compatibility Model compliance 783 definitions specified in [SMPTE-ST2110-21] for either Narrow Linear 784 Senders (Type NL) or Wide Senders (Type W). In such case, the 785 session description SHALL include a format-specific parameter of 786 either TP=2110TPNL or TP=2110TPW to indicate compliance with Type NL 787 or Type W respectively. The actual applied traffic shaping and 788 timing delivery mechanism is outside the scope of this memo and does 789 not influence the payload packetization. 791 NOTE: The Virtual Receiver Buffer Model compliance definitions of ST 792 2110-21 do not apply. 794 6. Congestion Control Considerations 796 Congestion control for RTP SHALL be used in accordance with 797 [RFC3550], and with any applicable RTP profile: e.g., [RFC3551]. An 798 additional requirement if best-effort service is being used is users 799 of this payload format SHALL monitor packet loss to ensure that the 800 packet loss rate is within acceptable parameters. Circuit Breakers 801 [RFC8083] is an update to RTP [RFC3550] that defines criteria for 802 when one is required to stop sending RTP Packet Streams and 803 applications implementing this standard SHALL comply with it. 804 [RFC8085] provides additional information on the best practices for 805 applying congestion control to UDP streams. 807 7. Payload Format Parameters 809 This section specifies the required and optional parameters of the 810 payload format or the RTP stream. The information signaled by the 811 any of the optional parameters is also present in the payload data, 812 namely in the payload header or in the JPEG XS header segment 813 [ISO21122-1] [ISO21122-3]. When provided, their respective values 814 SHALL be consistent with the payload. The sole purpose of the 815 optional parameters is to facilitate access to the RTP stream 816 metadata. 818 7.1. Media Type Registration 820 This registration is done using the template defined in [RFC6838] 821 and following [RFC4855]. 823 The receiver SHALL ignore any unrecognized parameter. 825 Type name: video 827 Subtype name: jxsv 829 Required parameters: 831 rate: The RTP timestamp clock rate. Applications using this 832 payload format SHALL use a value of 90000. 834 transmode: This parameter specifies the configured transmission 835 mode as defined by the Transmission mode (T) bit in the payload 836 header of Section 4.3. This value SHALL be equal to the T bit 837 value configured in the RTP stream (i.e. 0 for out-of-order- 838 allowed or 1 for sequential). 840 Optional parameters: 842 packetmode: This parameter specifies the configured packetization 843 mode as defined by the pacKetization mode (K) bit in the 844 payload header of Section 4.3. If specified, this value SHALL 845 be equal to the K bit value configured in the RTP stream (i.e. 846 0 for codestream or 1 for slice). 848 profile: The JPEG XS profile [ISO21122-2] in use. Any white 849 space in the profile name SHALL be replaced by a dash (-). 850 Examples are 'Main-444.12' or 'High-444.12'. 852 level: The JPEG XS level [ISO21122-2] in use. Any white space in 853 the level name SHALL be replaced by a dash (-). Examples are 854 '2k-1' or '4k-2'. 856 sublevel: The JPEG XS sublevel [ISO21122-2] in use. Any white 857 space in the sublevel name SHALL be replaced by a dash (-). 858 Examples are 'Sublev3bpp' or 'Sublev6bpp'. 860 depth: Determines the number of bits per sample. This is an 861 integer with typical values including 8, 10, 12, and 16. 863 width: Determines the number of pixels per line. This is an 864 integer between 1 and 32767. 866 height: Determines the number of lines per frame. This is an 867 integer between 1 and 32767. 869 exactframerate: Signals the frame rate in frames per second. 870 Integer frame rates SHALL be signaled as a single decimal 871 number (e.g. "25") whilst non-integer frame rates SHALL be 872 signaled as a ratio of two integer decimal numbers separated by 873 a "forward-slash" character (e.g. "30000/1001"), utilizing the 874 numerically smallest numerator value possible. 876 interlace: If this parameter name is present, it indicates that 877 the video is interlaced, or that the video is Progressive 878 segmented Frame (PsF). If this parameter name is not present, 879 the progressive video format SHALL be assumed. 881 segmented: If this parameter name is present, and the interlace 882 parameter name is also present, then the video is a Progressive 883 segmented Frame (PsF). Signaling of this parameter without the 884 interlace parameter is forbidden. 886 sampling: Signals the colour difference signal sub-sampling 887 structure. 889 Signals utilizing the non-constant luminance Y'C'B C'R signal 890 format of Recommendation ITU-R BT.601-7, Recommendation ITU-R 891 BT.709-6, Recommendation ITU-R BT.2020-2, or Recommendation 892 ITU-R BT.2100 SHALL use the appropriate one of the following 893 values for the Media Type Parameter "sampling": 895 YCbCr-4:4:4 (4:4:4 sampling) 896 YCbCr-4:2:2 (4:2:2 sampling) 897 YCbCr-4:2:0 (4:2:0 sampling) 899 Signals utilizing the Constant Luminance Y'C C'BC C'RC signal 900 format of Recommendation ITU-R BT.2020-2 SHALL use the 901 appropriate one of the following values for the Media Type 902 Parameter "sampling": 904 CLYCbCr-4:4:4 (4:4:4 sampling) 905 CLYCbCr-4:2:2 (4:2:2 sampling) 906 CLYCbCr-4:2:0 (4:2:0 sampling) 908 Signals utilizing the constant intensity I CT CP signal format 909 of Recommendation ITU-R BT.2100 SHALL use the appropriate one 910 of the following values for the Media Type Parameter 911 "sampling": 913 ICtCp-4:4:4 (4:4:4 sampling) 914 ICtCp-4:2:2 (4:2:2 sampling) 915 ICtCp-4:2:0 (4:2:0 sampling) 917 Signals utilizing the 4:4:4 R' G' B' or RGB signal format (such 918 as that of Recommendation ITU-R BT.601, Recommendation ITU-R 919 BT.709, Recommendation ITU-R BT.2020, Recommendation ITU-R 920 BT.2100, SMPTE ST 2065-1 or ST 2065-3) SHALL use the following 921 value for the Media Type Parameter sampling. 923 RGB (RGB or R' G' B' samples) 925 Signals utilizing the 4:4:4 X' Y' Z' signal format (such as 926 defined in SMPTE ST 428-1) SHALL use the following value for 927 the Media Type Parameter sampling. 929 XYZ (X' Y' Z' samples) 931 Key signals as defined in SMPTE RP 157 SHALL use the value key 932 for the Media Type Parameter sampling. The Key signal is 933 represented as a single component. 935 KEY (Samples of the key signal) 937 Signals utilizing a colour sub-sampling other than what is 938 defined here SHALL use the following value for the Media Type 939 Parameter sampling. 941 UNSPECIFIED (Sampling signaled by the payload.) 943 colorimetry: Specifies the system colorimetry used by the image 944 samples. Valid values and their specification are: 946 BT601-5 ITU-R Recommendation BT.601-5. 947 BT709-2 ITU-R Recommendation BT.709-2. 948 SMPTE240M SMPTE ST 240M. 949 BT601 ITU-R Recommendation BT.601-7. 950 BT709 ITU-R Recommendation BT.709-6. 951 BT2020 ITU-R Recommendation BT.2020-2. 952 BT2100 ITU-R Recommendation BT.2100 953 Table 2 titled "System colorimetry". 954 ST2065-1 SMPTE ST 2065-1 Academy Color Encoding 955 Specification (ACES). 956 ST2065-3 SMPTE ST 2065-3 Academy Density Exchange 957 Encoding (ADX). 958 XYZ ISO/IEC 11664-1, section titled 959 "1931 Observer". 960 UNSPECIFIED Colorimetry is signaled in the payload by 961 the color specification box of [ISO21122-3], 962 or it must be manually coordinated between 963 sender and receiver. 965 Signals utilizing the Recommendation ITU-R BT.2100 colorimetry 966 SHOULD also signal the representational range using the 967 optional parameter RANGE defined below. Signals utilizing the 968 UNSPECIFIED colorimetry might require manual coordination 969 between the sender and the receiver. 971 TCS: Transfer Characteristic System. This parameter specifies 972 the transfer characteristic system of the image samples. Valid 973 values and their specification are: 975 SDR Standard Dynamic Range video streams that 976 utilize the OETF of ITU-R Recommendation 977 BT.709 or ITU-R Recommendation BT.2020. Such 978 streams SHALL be assumed to target the EOTF 979 specified in ITU-R Recommendation BT.1886. 980 PQ High dynamic range video streams that utilize 981 the Perceptual Quantization system of ITU-R 982 Recommendation BT.2100. 983 HLG High dynamic range video streams that utilize 984 the Hybrid Log-Gamma system of ITU-R 985 Recommendation BT.2100. 986 UNSPECIFIED Video streams whose transfer characteristics 987 are signaled by the payload as specified in 988 [ISO21122-3], or must be manually 989 coordinated between sender and receiver. 991 RANGE: This parameter SHOULD be used to signal the encoding range 992 of the sample values within the stream. When paired with ITU 993 Rec BT.2100 colorimetry, this parameter has two allowed values 994 NARROW and FULL, corresponding to the ranges specified in table 995 9 of ITU Rec BT.2100. In any other context, this parameter has 996 three allowed values: NARROW, FULLPROTECT, and FULL, which 997 correspond to the ranges specified in SMPTE RP 2077. In the 998 absence of this parameter, and for all but the UNSPECIFIED 999 colorimetry, NARROW SHALL be the assumed value. When paired 1000 with the UNSPECIFIED colorimetry, FULL SHALL be the default 1001 assumed value. 1003 Encoding considerations: 1004 This media type is framed in RTP and contains binary data; see 1005 Section 4.8 in [RFC6838]. 1007 Security considerations: 1008 Please see the Security Considerations (Section 9) of RFC XXXX. 1010 Interoperability considerations: 1011 None. 1013 Published specification: 1014 See RFC XXXX and its References section. 1016 Applications that use this media type: 1017 For example: SMPTE ST 2110, Video over IP, Video conferencing, 1018 Broadcast applications. 1020 Fragment identifier considerations: 1021 N/A. 1023 Additional information: 1024 None. 1026 Person & email address to contact for further information: 1027 S. Lugan and Th. Richter . 1030 Intended usage: 1031 COMMON 1033 Restrictions on usage: 1034 This media type depends on RTP framing, and hence is only defined 1035 for transfer via RTP [RFC3550]. 1037 Author: 1038 See the Authors' Addresses section of RFC XXXX. 1040 Change controller: 1041 IETF Audio/Video Transport working group delegated from the IESG. 1043 7.2. Mapping to SDP 1045 7.2.1. General 1047 A Session Description Protocol (SDP) [RFC8866] media description 1048 SHALL be created for each RTP stream. In a SMPTE ST 2110 system, it 1049 SHALL be in accordance with the provisions of [SMPTE-ST2110-10]. 1051 The information carried in the media type specification of 1052 Section 7.1 has a specific mapping to the SDP fields, used to 1053 describe RTP sessions. This information is redundant with the 1054 information found in the payload data (namely, in the JPEG XS header 1055 segment) and SHALL be consistent with it. In case of discrepancy 1056 between parameter values found in the payload data and in the SDP 1057 fields, the values from the payload data SHALL prevail. 1059 The receiver SHALL ignore any unrecognized parameter. 1061 7.2.2. Media type and subtype 1063 The media type ("video") goes in SDP "m=" as the media name. 1065 The media subtype ("jxsv") goes in SDP "a=rtpmap" as the encoding 1066 name, followed by a slash ("/") and the required parameter "rate" 1067 corresponding to the RTP timestamp clock rate (which for the payload 1068 format defined in this document SHALL be 90000). The required 1069 parameter "transmode" and the additional optional parameters go in 1070 the SDP "a=fmtp" attribute by copying them directly from the MIME 1071 media type string as a semicolon-separated list of parameter=value 1072 pairs. 1074 An example SDP mapping for JPEG XS video is as follows: 1076 m=video 30000 RTP/AVP 112 1077 a=rtpmap:112 jxsv/90000 1078 a=fmtp:112 transmode=1;sampling=YCbCr-4:2:2;width=1920; 1079 height=1080;depth=10;colorimetry=BT709;TCS=SDR; 1080 RANGE=FULL;TP=2110TPNL 1082 In this example, a JPEG XS RTP stream is being sent to UDP 1083 destination port 30000, with an RTP dynamic payload type of 112 and a 1084 media clock rate of 90000 Hz. Note that the "a=fmtp:" line has been 1085 wrapped to fit this page, and will be a single long line in the SDP 1086 file. This example includes the TP parameter (as specified in 1087 Section 5). 1089 7.2.3. Offer/Answer Considerations 1091 When XS is offered using An Offer/Answer Model with Session 1092 Description Protocol (SDP) [RFC3264] for negotiation for unicast 1093 usage, the following limitations and rules apply: 1095 All parameters are declarative, i.e. apply only to media sent by the 1096 entity that generated the SDP. Thus, a declarative parameter in an 1097 offer applies to media sent by the offeror, whereas a declarative 1098 parameter in an answer applies to media sent by the answerer. All 1099 parameters must be supported by both sides, i.e. the answerer SHALL 1100 either maintain all parameters or remove the media format (payload 1101 type) completely if one or more of the parameter values are not 1102 supported. 1104 8. IANA Considerations 1106 The IANA is requested to register the media type registration "video/ 1107 jxsv" as specified in Section 7.1. The media type is also requested 1108 to be added to the IANA registry for "RTP Payload Format MIME types" 1109 . 1111 9. Security Considerations 1113 RTP packets using the payload format defined in this memo are subject 1114 to the security considerations discussed in [RFC3550] and in any 1115 applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], 1116 RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124]. This implies that 1117 confidentiality of the media streams is achieved by encryption. 1119 However, as "Securing the RTP Framework: Why RTP Does Not Mandate a 1120 Single Media Security Solution" [RFC7202] discusses, it is not an RTP 1121 payload format's responsibility to discuss or mandate what solutions 1122 are used to meet the basic security goals like confidentiality, 1123 integrity, and source authenticity for RTP in general. This 1124 responsibility lies on anyone using RTP in an application. They can 1125 find guidance on available security mechanisms and important 1126 considerations in "Options for Securing RTP Sessions" [RFC7201]. 1127 Applications SHOULD use one or more appropriate strong security 1128 mechanisms. 1130 This payload format and the JPEG XS encoding do not exhibit any 1131 substantial non-uniformity, either in output or in complexity to 1132 perform the decoding operation and thus are unlikely to pose a 1133 denial-of-service threat due to the receipt of pathological 1134 datagrams. 1136 This payload format and the JPEG XS encoding do not contain code that 1137 is executable. 1139 It is important to note that HD or UHDTV JPEG XS-encoded video can 1140 have significant bandwidth requirements (typically more than 1 Gbps 1141 for ultra high-definition video, especially if using high framerate). 1142 This is sufficient to cause potential for denial-of-service if 1143 transmitted onto most currently available Internet paths. 1145 Accordingly, if best-effort service is being used, users of this 1146 payload format SHALL monitor packet loss to ensure that the packet 1147 loss rate is within acceptable parameters. Packet loss is considered 1148 acceptable if a TCP flow across the same network path, and 1149 experiencing the same network conditions, would achieve an average 1150 throughput, measured on a reasonable timescale, that is not less than 1151 the RTP flow is achieving. This condition can be satisfied by 1152 implementing congestion control mechanisms to adapt the transmission 1153 rate (or the number of layers subscribed for a layered multicast 1154 session), or by arranging for a receiver to leave the session if the 1155 loss rate is unacceptably high. 1157 This payload format may also be used in networks that provide 1158 quality-of-service guarantees. If enhanced service is being used, 1159 receivers SHOULD monitor packet loss to ensure that the service that 1160 was requested is actually being delivered. If it is not, then they 1161 SHOULD assume that they are receiving best-effort service and behave 1162 accordingly. 1164 10. Acknowledgments 1166 The authors would like to thank the following people for their 1167 valuable contributions to this memo: Arnaud Germain, Alexandre 1168 Willeme, Gael Rouvroy, Siegfried Foessel, and Jean-Baptise Lorent. 1170 11. RFC Editor Considerations 1172 Note to RFC Editor: This section may be removed after carrying out 1173 all the instructions of this section. 1175 RFC XXXX is to be replaced by the RFC number this specification 1176 receives when published. 1178 12. References 1180 12.1. Normative References 1182 [ISO21122-1] 1183 International Organization for Standardization (ISO) - 1184 International Electrotechnical Commission (IEC), 1185 "Information technology - JPEG XS low-latency lightweight 1186 image coding system - Part 1: Core coding system", ISO/ 1187 IEC IS 21122-1. 1189 [ISO21122-2] 1190 International Organization for Standardization (ISO) - 1191 International Electrotechnical Commission (IEC), 1192 "Information technology - JPEG XS low-latency lightweight 1193 image coding system - Part 2: Profiles and buffer models", 1194 ISO/IEC IS 21122-2. 1196 [ISO21122-3] 1197 International Organization for Standardization (ISO) - 1198 International Electrotechnical Commission (IEC), 1199 "Information technology - JPEG XS low-latency lightweight 1200 image coding system - Part 3: Transport and container 1201 formats", ISO/IEC IS 21122-3. 1203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1204 Requirement Levels", BCP 14, RFC 2119, 1205 DOI 10.17487/RFC2119, March 1997, 1206 . 1208 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1209 with Session Description Protocol (SDP)", RFC 3264, 1210 DOI 10.17487/RFC3264, June 2002, 1211 . 1213 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1214 Jacobson, "RTP: A Transport Protocol for Real-Time 1215 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1216 July 2003, . 1218 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1219 Video Conferences with Minimal Control", STD 65, RFC 3551, 1220 DOI 10.17487/RFC3551, July 2003, 1221 . 1223 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1224 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1225 . 1227 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1228 Specifications and Registration Procedures", BCP 13, 1229 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1230 . 1232 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 1233 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 1234 DOI 10.17487/RFC8083, March 2017, 1235 . 1237 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1238 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1239 March 2017, . 1241 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1242 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1243 May 2017, . 1245 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1246 Session Description Protocol", RFC 8866, 1247 DOI 10.17487/RFC8866, January 2021, 1248 . 1250 12.2. Informative References 1252 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1253 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1254 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1255 . 1257 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 1258 Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, 1259 September 2005, . 1261 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1262 "Extended RTP Profile for Real-time Transport Control 1263 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1264 DOI 10.17487/RFC4585, July 2006, 1265 . 1267 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1268 Real-time Transport Control Protocol (RTCP)-Based Feedback 1269 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 1270 2008, . 1272 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 1273 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 1274 . 1276 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 1277 Framework: Why RTP Does Not Mandate a Single Media 1278 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 1279 2014, . 1281 [SMPTE-ST2110-10] 1282 Society of Motion Picture and Television Engineers, "SMPTE 1283 Standard - Professional Media Over Managed IP Networks: 1284 System Timing and Definitions", SMPTE ST 2110-10:2017, 1285 2017, . 1287 [SMPTE-ST2110-21] 1288 Society of Motion Picture and Television Engineers, "SMPTE 1289 Standard - Professional Media Over Managed IP Networks: 1290 Traffic Shaping and Delivery Timing for Video", SMPTE ST 1291 2110-21:2017, 2017, 1292 . 1294 Authors' Addresses 1296 Sebastien Lugan 1297 intoPIX S.A. 1298 Rue Emile Francqui, 9 1299 1435 Mont-Saint-Guibert 1300 Belgium 1302 Phone: +32 10 23 84 70 1303 Email: rtp@intopix.com 1304 URI: https://www.intopix.com/ 1305 Antonin Descampe 1306 Universite catholique de Louvain 1307 Place du Levant, 3 - bte L5.03.02 1308 1348 Louvain-la-Neuve 1309 Belgium 1311 Phone: +32 10 47 25 97 1312 Email: antonin.descampe@uclouvain.be 1313 URI: https://uclouvain.be/en/research-institutes/icteam 1315 Corentin Damman 1316 intoPIX S.A. 1317 Rue Emile Francqui, 9 1318 1435 Mont-Saint-Guibert 1319 Belgium 1321 Phone: +32 10 23 84 70 1322 Email: c.damman@intopix.com 1323 URI: https://www.intopix.com/ 1325 Thomas Richter 1326 Fraunhofer IIS 1327 Am Wolfsmantel 33 1328 91048 Erlangen 1329 Germany 1331 Phone: +49 9131 776 5126 1332 Email: thomas.richter@iis.fraunhofer.de 1333 URI: https://www.iis.fraunhofer.de/ 1335 Tim Bruylants 1336 intoPIX S.A. 1337 Rue Emile Francqui, 9 1338 1435 Mont-Saint-Guibert 1339 Belgium 1341 Phone: +32 10 23 84 70 1342 Email: t.bruylants@intopix.com 1343 URI: https://www.intopix.com/