idnits 2.17.1 draft-ietf-payload-rtp-jpegxs-16.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 (June 9, 2021) is 1050 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: December 11, 2021 UCL 6 C. Damman 7 intoPIX 8 T. Richter 9 IIS 10 T. Bruylants 11 intoPIX 12 June 9, 2021 14 RTP Payload Format for ISO/IEC 21122 (JPEG XS) 15 draft-ietf-payload-rtp-jpegxs-16 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 December 11, 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 . . . . . . . . . . . . . . . . . . . . 7 70 4.2. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 9 71 4.3. Payload Header Usage . . . . . . . . . . . . . . . . . . 11 72 4.4. Payload Data . . . . . . . . . . . . . . . . . . . . . . 13 73 5. Traffic Shaping and Delivery Timing . . . . . . . . . . . . . 18 74 6. Congestion Control Considerations . . . . . . . . . . . . . . 19 75 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 19 76 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 19 77 8. SPD Parameters . . . . . . . . . . . . . . . . . . . . . . . 24 78 8.1. Mapping of Payload Type Parameters to SDP . . . . . . . . 24 79 8.2. Usage with SDP Offer/Answer Model . . . . . . . . . . . . 25 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 82 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 83 12. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 27 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 86 13.2. Informative References . . . . . . . . . . . . . . . . . 29 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 89 1. Introduction 91 This document specifies a payload format for packetization of JPEG XS 92 [ISO21122-1] encoded video signals into the Real-time Transport 93 Protocol (RTP) [RFC3550]. 95 The JPEG XS coding system offers compression and recompression of 96 image sequences with very moderate computational resources while 97 remaining robust under multiple compression and decompression cycles 98 and mixing of content sources, e.g. embedding of subtitles, overlays 99 or logos. Typical target compression ratios ensuring visually 100 lossless quality are in the range of 2:1 to 10:1, depending on the 101 nature of the source material. The end-to-end latency can be 102 confined to a fraction of a frame, typically between a small number 103 of lines down to below a single line. 105 2. Conventions, Definitions, and Abbreviations 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 Application Data Unit (ADU) 114 The unit of source data provided as payload to the transport 115 layer, and corresponding, in this RTP payload definition, to a 116 single JPEG XS frame. 118 Colour specification box (CS box) 119 A ISO colour specification box defined in JPEG XS Part 3 120 [ISO21122-3] that includes colour-related metadata required to 121 correctly display JPEG XS frames, such as colour primaries, 122 transfer characteristics and matrix coefficients. 124 EOC marker 125 A marker that consists of the two bytes 0xff11 indicating the end 126 of a JPEG XS codestream. 128 JPEG XS codestream 129 A sequence of bytes representing a compressed image formatted 130 according to JPEG XS Part 1 [ISO21122-1]. 132 JPEG XS codestream header 133 A sequence of bytes, starting with a SOC marker, at the beginning 134 of each JPEG XS codestream encoded in multiple markers and marker 135 segments that does not carry entropy coded data, but metadata such 136 as the frame dimension and component precision. 138 JPEG XS frame 139 A JPEG XS picture segment in the case of a progressive frame, or, 140 in the case of an interlaced frame, the concatenation of two JPEG 141 XS picture segments. 143 JPEG XS header segment 144 The concatenation of a video support box [ISO21122-3], a colour 145 specification box [ISO21122-3], and a JPEG XS codestream header. 147 JPEG XS picture segment 148 The concatenation of a video support box [ISO21122-3], a colour 149 specification box [ISO21122-3], and a JPEG XS codestream. 151 JPEG XS stream 152 A sequence of JPEG XS frames. 154 Marker 155 A two-byte functional sequence that is part of a JPEG XS 156 codestream starting with a 0xff byte and a subsequent byte 157 defining its function. 159 Marker segment 160 A marker along with a 16-bit marker size and payload data 161 following the size. 163 Packetization unit 164 A portion of an Application Data Unit whose boundaries coincide 165 with boundaries of RTP packet payloads (excluding payload header), 166 i.e. the first (resp. last) byte of a packetization unit is the 167 first (resp. last) byte of a RTP packet payload (excluding its 168 payload header). 170 Slice 171 The smallest independently decodable unit of a JPEG XS codestream, 172 bearing in mind that it decodes to wavelet coefficients which 173 still require inverse wavelet filtering to give an image. 175 SOC marker 176 A marker that consists of the two bytes 0xff10 indicating the 177 start of a JPEG XS codestream. The SOC marker is considered an 178 integral part of the JPEG XS codestream header. 180 Video support box (VS box) 181 An ISO video support box, as defined in [ISO21122-3], that 182 includes metadata required to play back a JPEG XS stream, such as 183 its maximum bitrate, its subsampling structure, its buffer model 184 and its frame rate. 186 3. Media Format Description 187 3.1. Image Data Structures 189 JPEG XS is a low-latency lightweight image coding system for coding 190 continuous-tone grayscale or continuous-tone colour digital images. 192 This coding system provides an efficient representation of image 193 signals through the mathematical tool of wavelet analysis. The 194 wavelet filter process separates each component into multiple bands, 195 where each band consists of multiple coefficients describing the 196 image signal of a given component within a frequency domain specific 197 to the wavelet filter type, i.e. the particular filter corresponding 198 to the band. 200 Wavelet coefficients are grouped into precincts, where each precinct 201 includes all coefficients over all bands that contribute to a spatial 202 region of the image. 204 One or multiple precincts are furthermore combined into slices 205 consisting of an integer number of precincts. Precincts do not cross 206 slice boundaries, and wavelet coefficients in precincts that are part 207 of different slices can be decoded independently from each other. 208 Note, however, that the wavelet transformation runs across slice 209 boundaries. A slice always extends over the full width of the image, 210 but may only cover parts of its height. 212 3.2. Codestream 214 A JPEG XS codestream header, starting with an SOC marker, followed by 215 one or more slices, and terminated by an EOC marker form a JPEG XS 216 codestream. 218 The JPEG XS codestream format, including the definition of all 219 markers, is further defined in [ISO21122-1]. It represents sample 220 values of a single image, without any interpretation relative to a 221 colour space. 223 3.3. Video support box and colour specification box 225 While the information defined in the codestream is sufficient to 226 reconstruct the sample values of one image, the interpretation of the 227 samples remains undefined by the codestream itself. This 228 interpretation is given by the video support box and the colour 229 specification box which contain significant information to correctly 230 play the JPEG XS stream. The layout and syntax of these boxes, 231 together with their content, are defined in [ISO21122-3]. 233 The video support box provides information on the maximum bitrate, 234 the frame rate, the interlaced mode (progressive or interlaced), the 235 subsampling image format, the informative timecode of the current 236 JPEG XS frame, the profile, level/sublevel used, and optionally on 237 the buffer model and the mastering display metadata. 239 Note that the profile and level/sublevel, specified by respectively 240 the Ppih and Plev fields, specify limits on the capabilities needed 241 to decode the codestream and handle the output. Profiles represent a 242 limit on the required algorithmic features and parameter ranges used 243 in the codestream. The combination of level and sublevel defines a 244 lower bound on the required throughput for a decoder in respectively 245 the image (or decoded) domain and the codestream (or coded) domain. 246 The actual defined profiles and level/sublevels, along with the 247 associated values for the Ppih and Plev fields, are defined in 248 [ISO21122-2]. 250 The colour specification box indicates the colour primaries, transfer 251 characteristics, matrix coefficients and video full range flag needed 252 to specify the colour space of the video stream. 254 3.4. JPEG XS Frame 256 The concatenation of a video support box, a colour specification box, 257 and a JPEG XS codestream forms a JPEG XS picture segment. 259 In the case of a progressive video stream, each JPEG XS frame 260 consists of one single JPEG XS picture segment. 262 In the case of an interlaced video stream, each JPEG XS frame is made 263 of two concatenated JPEG XS picture segments. The codestream of each 264 picture segment corresponds exclusively to one of the two fields of 265 the interlaced frame. Both picture segments SHALL contain identical 266 boxes (i.e. concatenation of the video support box and the colour 267 specification box is byte exact the same for both picture segments of 268 the frame). 270 Note that the interlaced mode, as signaled by the frat field 271 [ISO21122-3] in the video support box, indicates either progressive, 272 interlaced top-field first, or interlaced bottom-field first mode. 273 Thus, in the case of interlaced content, its value SHALL also be 274 identical in both picture segments. 276 4. RTP Payload Format 278 This section specifies the payload format for JPEG XS streams over 279 the Real-time Transport Protocol (RTP) [RFC3550]. 281 In order to be transported over RTP, each JPEG XS stream is 282 transported in a distinct RTP stream, identified by a distinct 283 Synchronization source (SSRC) [RFC3550]. 285 A JPEG XS stream is divided into Application Data Units (ADUs), each 286 ADU corresponding to a single JPEG XS frame. 288 4.1. RTP packetization 290 An ADU is made of several packetization units. If a packetization 291 unit is bigger than the maximum size of a RTP packet payload, the 292 unit is split into multiple RTP packet payloads, as illustrated in 293 Figure 1. As seen there, each packet SHALL contain (part of) one and 294 only one packetization unit. A packetization unit may extend over 295 multiple packets. The payload of every packet SHALL have the same 296 size (based e.g. on the Maximum Transfer Unit of the network), except 297 (possibly) the last packet of a packetization unit. The boundaries 298 of a packetization unit SHALL coincide with the boundaries of the 299 payload of a packet (excluding the payload header), i.e. the first 300 (resp. last) byte of the packetization unit SHALL be the first (resp. 301 last) byte of the payload (excluding its header). 303 RTP +-----+------------------------+ 304 Packet #1 | Hdr | Packetization unit #1 | 305 +-----+------------------------+ 306 RTP +-----+--------------------------------------+ 307 Packet #2 | Hdr | Packetization unit #2 | 308 +-----+--------------------------------------+ 309 RTP +-----+--------------------------------------------------+ 310 Packet #3 | Hdr | Packetization unit #3 (part 1/3) | 311 +-----+--------------------------------------------------+ 312 RTP +-----+--------------------------------------------------+ 313 Packet #4 | Hdr | Packetization unit #3 (part 2/3) | 314 +-----+--------------------------------------------------+ 315 RTP +-----+----------------------------------------------+ 316 Packet #5 | Hdr | Packetization unit #3 (part 3/3) | 317 +-----+----------------------------------------------+ 318 ... 319 RTP +-----+-----------------------------------------+ 320 Packet #P | Hdr | Packetization unit #N (part q/q) | 321 +-----+-----------------------------------------+ 323 Figure 1: Example of ADU packetization 325 There are two different packetization modes defined for this RTP 326 payload format. 328 1. Codestream packetization mode: in this mode, the packetization 329 unit SHALL be the entire JPEG XS picture segment (i.e. codestream 330 preceded by boxes). This means that a progressive frame will 331 have a single packetization unit, while an interlaced frame will 332 have two. The progressive case is illustrated in Figure 2. 334 2. Slice packetization mode: in this mode, the packetization unit 335 SHALL be the slice, i.e. there SHALL be data from no more than 336 one slice per RTP packet. The first packetization unit SHALL be 337 made of the JPEG XS header segment (i.e. the concatenation of the 338 VS box, the CS box and the JPEG XS codestream header). This 339 first unit is then followed by successive units, each containing 340 one and only one slice. The packetization unit containing the 341 last slice of a JPEG XS codestream SHALL also contain the EOC 342 marker immediately following this last slice. This is 343 illustrated in Figure 3. In the case of an interlaced frame, the 344 JPEG XS header segment of the second field SHALL be in its own 345 packetization unit. 347 RTP +-----+--------------------------------------------------+ 348 Packet #1 | Hdr | VS box + CS box + JPEG XS codestream (part 1/q) | 349 +-----+--------------------------------------------------+ 350 RTP +-----+--------------------------------------------------+ 351 Packet #2 | Hdr | JPEG XS codestream (part 2/q) | 352 +-----+--------------------------------------------------+ 353 ... 354 RTP +-----+--------------------------------------+ 355 Packet #P | Hdr | JPEG XS codestream (part q/q) | 356 +-----+--------------------------------------+ 358 Figure 2: Example of codestream packetization mode 360 RTP +-----+----------------------------+ 361 Packet #1 | Hdr | JPEG XS header segment | 362 +-----+----------------------------+ 363 RTP +-----+--------------------------------------------------+ 364 Packet #2 | Hdr | Slice #1 (part 1/2) | 365 +-----+--------------------------------------------------+ 366 RTP +-----+-------------------------------------------+ 367 Packet #3 | Hdr | Slice #1 (part 2/2) | 368 +-----+-------------------------------------------+ 369 RTP +-----+--------------------------------------------------+ 370 Packet #4 | Hdr | Slice #2 (part 1/3) | 371 +-----+--------------------------------------------------+ 372 ... 373 RTP +-----+---------------------------------------+ 374 Packet #P | Hdr | Slice #N (part q/q) + EOC marker | 375 +-----+---------------------------------------+ 377 Figure 3: Example of slice packetization mode 379 Due to the constant bit-rate of JPEG XS, the codestream packetization 380 mode guarantees that a JPEG XS RTP stream will produce a constant 381 number of bytes per frame, and a constant number of RTP packets per 382 frame. To reach the same guarantee with the slice packetization 383 mode, an additional mechanism is required. This can involve a 384 constraint at the rate allocation stage in the JPEG XS encoder to 385 impose a constant bit-rate at the slice level, the usage of padding 386 data, or the insertion of empty RTP packets (i.e. a RTP packet whose 387 payload data is empty). 389 4.2. RTP Header Usage 391 The format of the RTP header is specified in [RFC3550] and reprinted 392 in Figure 4 for convenience. This RTP payload format uses the fields 393 of the header in a manner consistent with that specification. 395 The RTP payload (and the settings for some RTP header bits) for 396 packetization units are specified in Section 4.3. 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | V |P|X| CC |M| PT | sequence number | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | timestamp | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | synchronization source (SSRC) identifier | 406 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 407 | contributing source (CSRC) identifiers | 408 | .... | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 4: RTP header according to RFC 3550 413 The version (V), padding (P), extension (X), CSRC count (CC), 414 sequence number, synchronization source (SSRC) and contributing 415 source (CSRC) fields follow their respective definitions in 416 [RFC3550]. 418 The remaining RTP header information to be set according to this RTP 419 payload format is set as follows: 421 Marker (M) [1 bit]: 423 If progressive scan video is being transmitted, the marker bit 424 denotes the end of a video frame. If interlaced video is being 425 transmitted, it denotes the end of the field. The marker bit 426 SHALL be set to 1 for the last packet of the video frame/field. 427 It SHALL be set to 0 for all other packets. 429 Payload Type (PT) [7 bits]: 431 A dynamically allocated payload type field that designates the 432 payload as JPEG XS video. 434 Timestamp [32 bits]: 436 The RTP timestamp is set to the sampling timestamp of the content. 437 A 90 kHz clock rate SHALL be used. 439 As specified in [RFC3550] and [RFC4175], the RTP timestamp 440 designates the sampling instant of the first octet of the frame to 441 which the RTP packet belongs. Packets SHALL NOT include data from 442 multiple frames, and all packets belonging to the same frame SHALL 443 have the same timestamp. Several successive RTP packets will 444 consequently have equal timestamps if they belong to the same 445 frame (that is until the marker bit is set to 1, marking the last 446 packet of the frame), and the timestamp is only increased when a 447 new frame begins. 449 If the sampling instant does not correspond to an integer value of 450 the clock, the value SHALL be truncated to the next lowest 451 integer, with no ambiguity. 453 4.3. Payload Header Usage 455 The first four bytes of the payload of an RTP packet in this RTP 456 payload format are referred to as the payload header. Figure 5 457 illustrates the structure of this payload header. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |T|K|L| I |F counter| SEP counter | P counter | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 5: Payload header 467 The payload header consists of the following fields: 469 Transmission mode (T) [1 bit]: 471 The T bit is set to indicate that packets are sent sequentially by 472 the transmitter. This information allows a receiver to dimension 473 its input buffer(s) accordingly. If T=0, nothing can be assumed 474 about the transmission order and packets may be sent out-of-order 475 by the transmitter. If T=1, packets SHALL be sent sequentially by 476 the transmitter. 478 pacKetization mode (K) [1 bit]: 480 The K bit is set to indicate which packetization mode is used. 481 K=0 indicates codestream packetization mode, while K=1 indicates 482 slice packetization mode. In the case that the Transmission mode 483 (T) is set to 0, the slice packetization mode SHALL be used and K 484 SHALL be set to 1. 486 Last (L) [1 bit]: 488 The L bit is set to indicate the last packet of a packetization 489 unit. As the end of the frame also ends the packet containing the 490 last unit of the frame, the L bit is set whenever the M bit is 491 set. If codestream packetization mode is used, L bit and M bit 492 are equivalent. 494 Interlaced information (I) [2 bit]: 496 These 2 bits are used to indicate how the JPEG XS frame is scanned 497 (progressive or interlaced). In case of an interlaced frame, they 498 also indicate which JPEG XS picture segment the payload is part of 499 (first or second). 501 00: The payload is progressively scanned. 503 01: Reserved for future use. 505 10: The payload is part of the first JPEG XS picture segment of 506 an interlaced video frame. The height specified in the 507 included JPEG XS codestream header is half of the height of the 508 entire displayed image. 510 11: The payload is part of the second JPEG XS picture segment of 511 an interlaced video frame. The height specified in the 512 included JPEG XS codestream header is half of the height of the 513 entire displayed image. 515 F counter [5 bits]: 517 The frame (F) counter identifies the frame number modulo 32 to 518 which a packet belongs. Frame numbers are incremented by 1 for 519 each frame transmitted. The frame number, in addition to the 520 timestamp, may help the decoder manage its input buffer and bring 521 packets back into their natural order. 523 SEP counter [11 bits]: 525 The Slice and Extended Packet (SEP) counter is used differently 526 depending on the packetization mode. 528 * In the case of codestream packetization mode (K=0), this 529 counter resets whenever the Packet counter resets (see 530 hereunder), and increments by 1 whenever the Packet counter 531 overruns. 533 * In the case of slice packetization mode (K=1), this counter 534 identifies the slice modulo 2047 to which the packet 535 contributes. If the data belongs to the JPEG XS header 536 segment, this field SHALL have its maximal value, namely 2047 = 537 0x07ff. Otherwise, it is the slice index modulo 2047. Slice 538 indices are counted from 0 (corresponding to the top of the 539 frame). 541 P counter [11 bits]: 543 The packet (P) counter identifies the packet number modulo 2048 544 within the current packetization unit. It is set to 0 at the 545 start of the packetization unit and incremented by 1 for every 546 subsequent packet (if any) belonging to the same unit. 547 Practically, if codestream packetization mode is enabled, this 548 field counts the packets within a JPEG XS picture segment and is 549 extended by the SEP counter when it overruns. If slice 550 packetization mode is enabled, this field counts the packets 551 within a slice or within the JPEG XS header segment. 553 4.4. Payload Data 555 The payload data of a JPEG XS RTP stream consists of a concatenation 556 of multiple JPEG XS frames. Within the RTP stream, all of the video 557 support boxes and all of the colour specification boxes SHALL retain 558 their respective layouts for each JPEG XS frame. Thus, each video 559 support box in the RTP stream SHALL define the same sub boxes. The 560 effective values in the boxes are allowed to change under the 561 condition that their relative byte offsets SHALL NOT change. 563 Each JPEG XS frame is the concatenation of one or more packetization 564 unit(s), as explained in Section 4.1. Figure 6 depicts this layout 565 for a progressive frame in the codestream packetization mode, 566 Figure 7 depicts this layout for an interlaced frame in the 567 codestream packetization mode, Figure 8 depicts this layout for a 568 progressive frame in the slice packetization mode and Figure 9 569 depicts this layout for an interlaced frame in the slice 570 packetization mode. The Frame counter value is not indicated because 571 the value is constant for all packetization units of a given frame. 573 +=====[ Packetization unit (PU) #1 ]====+ 574 | Video support box | SEP counter=0 575 | +---------------------------------+ | P counter=0 576 | : Sub boxes of the VS box : | 577 | +---------------------------------+ | 578 +- - - - - - - - - - - - - - - - - - - -+ 579 | Colour specification box | 580 | +---------------------------------+ | 581 | : Fields of the CS box : | 582 | +---------------------------------+ | 583 +- - - - - - - - - - - - - - - - - - - -+ 584 | JPEG XS codestream | 585 : (part 1/q) : M=0, K=0, L=0, I=00 586 +---------------------------------------+ 587 | JPEG XS codestream | SEP counter=0 588 | (part 2/q) | P counter=1 589 : : M=0, K=0, L=0, I=00 590 +---------------------------------------+ 591 | JPEG XS codestream | SEP counter=0 592 | (part 3/q) | P counter=2 593 : : M=0, K=0, L=0, I=00 594 +---------------------------------------+ 595 : : 596 +---------------------------------------+ 597 | JPEG XS codestream | SEP counter=1 598 | (part 2049/q) | P counter=0 599 : : M=0, K=0, L=0, I=00 600 +---------------------------------------+ 601 : : 602 +---------------------------------------+ 603 | JPEG XS codestream | SEP counter=(q-1) div 2048 604 | (part q/q) | P counter=(q-1) mod 2048 605 : : M=1, K=0, L=1, I=00 606 +=======================================+ 608 Figure 6: Example of JPEG XS Payload Data (codestream packetization 609 mode, progressive frame) 611 +=====[ Packetization unit (PU) #1 ]====+ 612 | Video support box | SEP counter=0 613 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 614 | Colour specification box | 615 +- - - - - - - - - - - - - - - - - - - -+ 616 | JPEG XS codestream (1st field) | 617 : (part 1/q) : M=0, K=0, L=0, I=10 618 +---------------------------------------+ 619 | JPEG XS codestream (1st field) | SEP counter=0 620 | (part 2/q) | P counter=1 621 : : M=0, K=0, L=0, I=10 622 +---------------------------------------+ 623 : : 624 +---------------------------------------+ 625 | JPEG XS codestream (1st field) | SEP counter=1 626 | (part 2049/q) | P counter=0 627 : : M=0, K=0, L=0, I=10 628 +---------------------------------------+ 629 : : 630 +---------------------------------------+ 631 | JPEG XS codestream (1st field) | SEP counter=(q-1) div 2048 632 | (part q/q) | P counter=(q-1) mod 2048 633 : : M=1, K=0, L=1, I=10 634 +===============[ PU #2 ]===============+ 635 | Video support box | SEP counter=0 636 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 637 | Colour specification box | 638 +- - - - - - - - - - - - - - - - - - - -+ 639 | JPEG XS codestream (2nd field) | 640 | (part 1/q) | 641 : : M=0, K=0, L=0, I=11 642 +---------------------------------------+ 643 | JPEG XS codestream (2nd field) | SEP counter=0 644 | (part 2/q) | P counter=1 645 : : M=0, K=0, L=0, I=11 646 +---------------------------------------+ 647 : : 648 +---------------------------------------+ 649 | JPEG XS codestream (2nd field) | SEP counter=(q-1) div 2048 650 | (part q/q) | P counter=(q-1) mod 2048 651 : : M=1, K=0, L=1, I=11 652 +=======================================+ 654 Figure 7: Example of JPEG XS Payload Data (codestream packetization 655 mode, interlaced frame) 657 +===[ PU #1: JPEG XS Header segment ]===+ 658 | Video support box | SEP counter=0x07FF 659 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 660 | Colour specification box | 661 +- - - - - - - - - - - - - - - - - - - -+ 662 | JPEG XS codestream header | 663 | +---------------------------------+ | 664 | : Markers and marker segments : | 665 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=00 666 +==========[ PU #2: Slice #1 ]==========+ 667 | +---------------------------------+ | SEP counter=0 668 | | SLH Marker | | P counter=0 669 | +---------------------------------+ | 670 | : Entropy Coded Data : | 671 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=00 672 +==========[ PU #3: Slice #2 ]==========+ 673 | Slice #2 | SEP counter=1 674 | (part 1/q) | P counter=0 675 : : M=0, T=0, K=1, L=0, I=00 676 +---------------------------------------+ 677 | Slice #2 | SEP counter=1 678 | (part 2/q) | P counter=1 679 : : M=0, T=0, K=1, L=0, I=00 680 +---------------------------------------+ 681 : : 682 +---------------------------------------+ 683 | Slice #2 | SEP counter=1 684 | (part q/q) | P counter=q-1 685 : : M=0, T=0, K=1, L=1, I=00 686 +=======================================+ 687 : : 688 +========[ PU #N: Slice #(N-1) ]========+ 689 | Slice #(N-1) | SEP counter=N-2 690 | (part 1/r) | P counter=0 691 : : M=0, T=0, K=1, L=0, I=00 692 +---------------------------------------+ 693 : : 694 +---------------------------------------+ 695 | Slice #(N-1) | SEP counter=N-2 696 | (part r/r) | P counter=r-1 697 : + EOC marker : M=1, T=0, K=1, L=1, I=00 698 +=======================================+ 700 Figure 8: Example of JPEG XS Payload Data (slice packetization mode, 701 progressive frame) 703 +====[ PU #1: JPEG XS Hdr segment 1 ]===+ 704 | Video support box | SEP counter=0x07FF 705 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 706 | Colour specification box | 707 +- - - - - - - - - - - - - - - - - - - -+ 708 | JPEG XS codestream header 1 | 709 | +---------------------------------+ | 710 | : Markers and marker segments : | 711 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=10 712 +====[ PU #2: Slice #1 (1st field) ]====+ 713 | +---------------------------------+ | SEP counter=0 714 | | SLH Marker | | P counter=0 715 | +---------------------------------+ | 716 | : Entropy Coded Data : | 717 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=10 718 +====[ PU #3: Slice #2 (1st field) ]====+ 719 | Slice #2 | SEP counter=1 720 | (part 1/q) | P counter=0 721 : : M=0, T=0, K=1, L=0, I=10 722 +---------------------------------------+ 723 | Slice #2 | SEP counter=1 724 | (part 2/q) | P counter=1 725 : : M=0, T=0, K=1, L=0, I=10 726 +---------------------------------------+ 727 : : 728 +---------------------------------------+ 729 | Slice #2 | SEP counter=1 730 | (part q/q) | P counter=q-1 731 : : M=0, T=0, K=1, L=1, I=10 732 +=======================================+ 733 : : 734 +==[ PU #N: Slice #(N-1) (1st field) ]==+ 735 | Slice #(N-1) | SEP counter=N-2 736 | (part 1/r) | P counter=0 737 : : M=0, T=0, K=1, L=0, I=10 738 +---------------------------------------+ 739 : : 740 +---------------------------------------+ 741 | Slice #(N-1) | SEP counter=N-2 742 | (part r/r) | P counter=r-1 743 : + EOC marker : M=1, T=0, K=1, L=1, I=10 744 +=======================================+ 745 +===[ PU #N+1: JPEG XS Hdr segment 2 ]==+ 746 | Video support box | SEP counter=0x07FF 747 +- - - - - - - - - - - - - - - - - - - -+ P counter=0 748 | Colour specification box | 749 +- - - - - - - - - - - - - - - - - - - -+ 750 | JPEG XS codestream header 2 | 751 | +---------------------------------+ | 752 | : Markers and marker segments : | 753 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=11 754 +===[ PU #N+2: Slice #1 (2nd field) ]===+ 755 | +---------------------------------+ | SEP counter=0 756 | | SLH Marker | | P counter=0 757 | +---------------------------------+ | 758 | : Entropy Coded Data : | 759 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=11 760 +===[ PU #N+3: Slice #2 (2nd field) ]===+ 761 | Slice #2 | SEP counter=1 762 | (part 1/s) | P counter=0 763 : : M=0, T=0, K=1, L=0, I=11 764 +---------------------------------------+ 765 | Slice #2 | SEP counter=1 766 | (part 2/s) | P counter=1 767 : : M=0, T=0, K=1, L=0, I=11 768 +---------------------------------------+ 769 : : 770 +---------------------------------------+ 771 | Slice #2 | SEP counter=1 772 | (part s/s) | P counter=s-1 773 : : M=0, T=0, K=1, L=1, I=11 774 +=======================================+ 775 : : 776 +==[ PU #2N: Slice #(N-1) (2nd field) ]=+ 777 | Slice #(N-1) | SEP counter=N-2 778 | (part 1/t) | P counter=0 779 : : M=0, T=0, K=1, L=0, I=11 780 +---------------------------------------+ 781 : : 782 +---------------------------------------+ 783 | Slice #(N-1) | SEP counter=N-2 784 | (part t/t) | P counter=t-1 785 : + EOC marker : M=1, T=0, K=1, L=1, I=11 786 +=======================================+ 788 Figure 9: Example of JPEG XS Payload Data (slice packetization mode, 789 interlaced frame) 791 5. Traffic Shaping and Delivery Timing 793 In order to facilitate proper synchronization between senders and 794 receivers it is RECOMMENDED to implement traffic shaping and delivery 795 timing in accordance with the Network Compatibility Model compliance 796 definitions specified in [SMPTE-ST2110-21] for either Narrow Senders 797 (Type N), Narrow Linear Senders (Type NL), or Wide Senders (Type W). 798 In such case, the session description SHALL include a format-specific 799 parameter of either TP=2110TPN, TP=2110TPNL, or TP=2110TPW to 800 indicate compliance with Type N, Type NL, or Type W respectively. 801 The actual applied traffic shaping and timing delivery mechanism is 802 outside the scope of this memo and does not influence the payload 803 packetization. 805 NOTE: The Virtual Receiver Buffer Model compliance definitions of 806 [SMPTE-ST2110-21] do not apply. 808 6. Congestion Control Considerations 810 Congestion control for RTP SHALL be used in accordance with 811 [RFC3550], and with any applicable RTP profile: e.g., [RFC3551]. An 812 additional requirement if best-effort service is being used is users 813 of this payload format SHALL monitor packet loss to ensure that the 814 packet loss rate is within acceptable parameters. Circuit Breakers 815 [RFC8083] is an update to RTP [RFC3550] that defines criteria for 816 when one is required to stop sending RTP Packet Streams and 817 applications implementing this standard SHALL comply with it. 818 [RFC8085] provides additional information on the best practices for 819 applying congestion control to UDP streams. 821 7. Payload Format Parameters 823 This section specifies the required and optional parameters of the 824 payload format and/or the RTP stream. All parameters are 825 declarative, meaning that the information signaled by the parameters 826 is also present in the payload data, namely in the payload header 827 (see Section 4.3) or in the JPEG XS header segment [ISO21122-1] 828 [ISO21122-3]. When provided, their respective values SHALL be 829 consistent with the payload. 831 7.1. Media Type Registration 833 This registration is done using the template defined in [RFC6838] 834 and following [RFC4855]. 836 The receiver SHALL ignore any unrecognized parameter. 838 Type name: video 840 Subtype name: jxsv 842 Clock rate: 90000 844 Required parameters: 846 rate: The RTP timestamp clock rate. Applications using this 847 payload format SHALL use a value of 90000. 849 transmode: This parameter specifies the configured transmission 850 mode as defined by the Transmission mode (T) bit in the payload 851 header of Section 4.3. This value SHALL be equal to the T bit 852 value configured in the RTP stream (i.e. 0 for out-of-order- 853 allowed or 1 for sequential). 855 Optional parameters: 857 packetmode: This parameter specifies the configured packetization 858 mode as defined by the pacKetization mode (K) bit in the 859 payload header of Section 4.3. If specified, this value SHALL 860 be equal to the K bit value configured in the RTP stream (i.e. 861 0 for codestream or 1 for slice). 863 profile: The JPEG XS profile [ISO21122-2] in use. Any white 864 space in the profile name SHALL be omitted. Examples of valid 865 profile names are 'Main444.12' or 'High444.12'. 867 level: The JPEG XS level [ISO21122-2] in use. Any white space in 868 the level name SHALL be omitted. Examples of valid levels 869 names are '2k-1' or '4k-2'. 871 sublevel: The JPEG XS sublevel [ISO21122-2] in use. Any white 872 space in the sublevel name SHALL be omitted. Examples of valid 873 sublevels are 'Sublev3bpp' or 'Sublev6bpp'. 875 depth: Determines the number of bits per sample. This is an 876 integer with typical values including 8, 10, 12, and 16. 878 width: Determines the number of pixels per line. This is an 879 integer between 1 and 32767. 881 height: Determines the number of lines per frame. This is an 882 integer between 1 and 32767. 884 exactframerate: Signals the frame rate in frames per second. 885 Integer frame rates SHALL be signaled as a single decimal 886 number (e.g. "25") whilst non-integer frame rates SHALL be 887 signaled as a ratio of two integer decimal numbers separated by 888 a "forward-slash" character (e.g. "30000/1001"), utilizing the 889 numerically smallest numerator value possible. 891 interlace: If this parameter name is present, it indicates that 892 the video is interlaced, or that the video is Progressive 893 segmented Frame (PsF). If this parameter name is not present, 894 the progressive video format SHALL be assumed. 896 segmented: If this parameter name is present, and the interlace 897 parameter name is also present, then the video is a Progressive 898 segmented Frame (PsF). Signaling of this parameter without the 899 interlace parameter is forbidden. 901 sampling: Signals the colour difference signal sub-sampling 902 structure. 904 Signals utilizing the non-constant luminance Y'C'B C'R signal 905 format of Recommendation ITU-R BT.601-7, Recommendation ITU-R 906 BT.709-6, Recommendation ITU-R BT.2020-2, or Recommendation 907 ITU-R BT.2100 SHALL use the appropriate one of the following 908 values for the Media Type Parameter "sampling": 910 YCbCr-4:4:4 (4:4:4 sampling) 911 YCbCr-4:2:2 (4:2:2 sampling) 912 YCbCr-4:2:0 (4:2:0 sampling) 914 Signals utilizing the Constant Luminance Y'C C'BC C'RC signal 915 format of Recommendation ITU-R BT.2020-2 SHALL use the 916 appropriate one of the following values for the Media Type 917 Parameter "sampling": 919 CLYCbCr-4:4:4 (4:4:4 sampling) 920 CLYCbCr-4:2:2 (4:2:2 sampling) 921 CLYCbCr-4:2:0 (4:2:0 sampling) 923 Signals utilizing the constant intensity I CT CP signal format 924 of Recommendation ITU-R BT.2100 SHALL use the appropriate one 925 of the following values for the Media Type Parameter 926 "sampling": 928 ICtCp-4:4:4 (4:4:4 sampling) 929 ICtCp-4:2:2 (4:2:2 sampling) 930 ICtCp-4:2:0 (4:2:0 sampling) 932 Signals utilizing the 4:4:4 R' G' B' or RGB signal format (such 933 as that of Recommendation ITU-R BT.601, Recommendation ITU-R 934 BT.709, Recommendation ITU-R BT.2020, Recommendation ITU-R 935 BT.2100, SMPTE ST 2065-1 or ST 2065-3) SHALL use the following 936 value for the Media Type Parameter sampling. 938 RGB (RGB or R' G' B' samples) 940 Signals utilizing the 4:4:4 X' Y' Z' signal format (such as 941 defined in SMPTE ST 428-1) SHALL use the following value for 942 the Media Type Parameter sampling. 944 XYZ (X' Y' Z' samples) 946 Key signals as defined in SMPTE RP 157 SHALL use the value key 947 for the Media Type Parameter sampling. The Key signal is 948 represented as a single component. 950 KEY (Samples of the key signal) 952 Signals utilizing a colour sub-sampling other than what is 953 defined here SHALL use the following value for the Media Type 954 Parameter sampling. 956 UNSPECIFIED (Sampling signaled by the payload.) 958 colorimetry: Specifies the system colorimetry used by the image 959 samples. Valid values and their specification are: 961 BT601-5 ITU-R Recommendation BT.601-5. 962 BT709-2 ITU-R Recommendation BT.709-2. 963 SMPTE240M SMPTE ST 240M. 964 BT601 ITU-R Recommendation BT.601-7. 965 BT709 ITU-R Recommendation BT.709-6. 966 BT2020 ITU-R Recommendation BT.2020-2. 967 BT2100 ITU-R Recommendation BT.2100 968 Table 2 titled "System colorimetry". 969 ST2065-1 SMPTE ST 2065-1 Academy Color Encoding 970 Specification (ACES). 971 ST2065-3 SMPTE ST 2065-3 Academy Density Exchange 972 Encoding (ADX). 973 XYZ ISO/IEC 11664-1, section titled 974 "1931 Observer". 975 UNSPECIFIED Colorimetry is signaled in the payload by 976 the color specification box of [ISO21122-3], 977 or it must be manually coordinated between 978 sender and receiver. 980 Signals utilizing the Recommendation ITU-R BT.2100 colorimetry 981 SHOULD also signal the representational range using the 982 optional parameter RANGE defined below. Signals utilizing the 983 UNSPECIFIED colorimetry might require manual coordination 984 between the sender and the receiver. 986 TCS: Transfer Characteristic System. This parameter specifies 987 the transfer characteristic system of the image samples. Valid 988 values and their specification are: 990 SDR Standard Dynamic Range video streams that 991 utilize the OETF of ITU-R Recommendation 992 BT.709 or ITU-R Recommendation BT.2020. Such 993 streams SHALL be assumed to target the EOTF 994 specified in ITU-R Recommendation BT.1886. 995 PQ High dynamic range video streams that utilize 996 the Perceptual Quantization system of ITU-R 997 Recommendation BT.2100. 998 HLG High dynamic range video streams that utilize 999 the Hybrid Log-Gamma system of ITU-R 1000 Recommendation BT.2100. 1001 UNSPECIFIED Video streams whose transfer characteristics 1002 are signaled by the payload as specified in 1003 [ISO21122-3], or must be manually 1004 coordinated between sender and receiver. 1006 RANGE: This parameter SHOULD be used to signal the encoding range 1007 of the sample values within the stream. When paired with ITU 1008 Rec BT.2100 colorimetry, this parameter has two allowed values 1009 NARROW and FULL, corresponding to the ranges specified in table 1010 9 of ITU Rec BT.2100. In any other context, this parameter has 1011 three allowed values: NARROW, FULLPROTECT, and FULL, which 1012 correspond to the ranges specified in SMPTE RP 2077. In the 1013 absence of this parameter, and for all but the UNSPECIFIED 1014 colorimetry, NARROW SHALL be the assumed value. When paired 1015 with the UNSPECIFIED colorimetry, FULL SHALL be the default 1016 assumed value. 1018 Encoding considerations: 1019 This media type is framed in RTP and contains binary data; see 1020 Section 4.8 in [RFC6838]. 1022 Security considerations: 1023 Please see the Security Considerations (Section 10) of RFC XXXX. 1025 Interoperability considerations: 1026 None. 1028 Published specification: 1029 See RFC XXXX and its References section. 1031 Applications that use this media type: 1032 For example: SMPTE ST 2110, Video over IP, Video conferencing, 1033 Broadcast applications. 1035 Fragment identifier considerations: 1036 N/A. 1038 Additional information: 1039 None. 1041 Person & email address to contact for further information: 1042 S. Lugan and Th. Richter . 1045 Intended usage: 1046 COMMON 1048 Restrictions on usage: 1049 This media type depends on RTP framing, and hence is only defined 1050 for transfer via RTP [RFC3550]. 1052 Author: 1053 See the Authors' Addresses section of RFC XXXX. 1055 Change controller: 1056 IETF Audio/Video Transport working group delegated from the IESG. 1058 8. SPD Parameters 1060 A mapping of the parameters into the Session Description Protocol 1061 (SDP) [RFC8866] is provided for applications that use SDP. 1063 8.1. Mapping of Payload Type Parameters to SDP 1065 The media type video/jxsv string is mapped to fields in the Session 1066 Description Protocol (SDP) [RFC8866] as follows: 1068 The media type ("video") goes in SDP "m=" as the media name. 1070 The media subtype ("jxsv") goes in SDP "a=rtpmap" as the encoding 1071 name, followed by a slash ("/") and the required parameter "rate" 1072 corresponding to the RTP timestamp clock rate (which for the 1073 payload format defined in this document SHALL be 90000). 1075 The required parameter "transmode" and any of the additional 1076 optional parameters, as described in Section 7.1, go in the SDP 1077 media format description, being the "a=fmtp" attribute (Format 1078 Parameters), by copying them directly from the MIME media type 1079 string as a semicolon-separated list of parameter=value pairs. 1081 All parameters of the media format SHALL correspond to the parameters 1082 of the payload. In case of discrepancies between payload parameter 1083 values and SDP fields, the values from the payload data SHALL 1084 prevail. 1086 The receiver SHALL ignore any parameter that is not defined in 1087 Section 7.1. 1089 An example SDP mapping for JPEG XS video is as follows: 1091 m=video 30000 RTP/AVP 112 1092 a=rtpmap:112 jxsv/90000 1093 a=fmtp:112 transmode=1;sampling=YCbCr-4:2:2;width=1920; 1094 height=1080;depth=10;colorimetry=BT709;TCS=SDR; 1095 RANGE=FULL;TP=2110TPNL 1097 In this example, a JPEG XS RTP stream is to be sent to UDP 1098 destination port 30000, with an RTP dynamic payload type of 112 and a 1099 media clock rate of 90000 Hz. Note that the "a=fmtp:" line has been 1100 wrapped to fit this page, and will be a single long line in the SDP 1101 file. This example includes the TP parameter (as specified in 1102 Section 5). 1104 8.2. Usage with SDP Offer/Answer Model 1106 When JPEG XS is offered over RTP using SDP in an offer/answer model 1107 [RFC3264] for negotiation for unicast usage, the following 1108 limitations and rules apply: 1110 The "a=fmtp" attribute SHALL be present specifying the required 1111 parameter "transmode" and MAY specify any of the optional 1112 parameters, as described in Section 7.1. 1114 All parameters in the "a=fmtp" attribute indicate sending 1115 capabilities (i.e. properties of the payload). 1117 An answerer of the SDP is required to support all parameters and 1118 values of the parameters provided by the offerer; otherwise, the 1119 answerer SHALL reject the session. It falls on the offerer to use 1120 values that are expected to be supported by the answerer. If the 1121 answerer accepts the session, it SHALL reply with the exact same 1122 parameters values in the "a=fmtp" attribute as it was offered. 1124 The same RTP payload type number used in the offer SHOULD be used 1125 in the answer, as specified in [RFC3264]. 1127 9. IANA Considerations 1129 The IANA is requested to register the media type registration "video/ 1130 jxsv" as specified in Section 7.1. The media type is also requested 1131 to be added to the IANA registry for "RTP Payload Format MIME types" 1132 . 1134 10. Security Considerations 1136 RTP packets using the payload format defined in this memo are subject 1137 to the security considerations discussed in [RFC3550] and in any 1138 applicable RTP profile such as RTP/AVP [RFC3551], RTP/AVPF [RFC4585], 1139 RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124]. This implies that 1140 confidentiality of the media streams is achieved by encryption. 1142 However, as "Securing the RTP Framework: Why RTP Does Not Mandate a 1143 Single Media Security Solution" [RFC7202] discusses, it is not an RTP 1144 payload format's responsibility to discuss or mandate what solutions 1145 are used to meet the basic security goals like confidentiality, 1146 integrity, and source authenticity for RTP in general. This 1147 responsibility lies on anyone using RTP in an application. They can 1148 find guidance on available security mechanisms and important 1149 considerations in "Options for Securing RTP Sessions" [RFC7201]. 1150 Applications SHOULD use one or more appropriate strong security 1151 mechanisms. 1153 Implementations of this RTP payload format need to take appropriate 1154 security considerations into account. It is important for the 1155 decoder to be robust against malicious or malformed payloads and 1156 ensure that they do not cause the decoder to overrun its allocated 1157 memory or otherwise misbehave. An overrun in allocated memory could 1158 lead to arbitrary code execution by an attacker. The same applies to 1159 the encoder, even though problems in encoders are typically rarer. 1161 This payload format and the JPEG XS encoding do not exhibit any 1162 substantial non-uniformity, either in output or in complexity to 1163 perform the decoding operation and thus are unlikely to pose a 1164 denial-of-service threat due to the receipt of pathological 1165 datagrams. 1167 This payload format and the JPEG XS encoding do not contain code that 1168 is executable. 1170 It is important to note that HD or UHDTV JPEG XS-encoded video can 1171 have significant bandwidth requirements (typically more than 1 Gbps 1172 for ultra high-definition video, especially if using high framerate). 1173 This is sufficient to cause potential for denial-of-service if 1174 transmitted onto most currently available Internet paths. 1176 Accordingly, if best-effort service is being used, users of this 1177 payload format SHALL monitor packet loss to ensure that the packet 1178 loss rate is within acceptable parameters. Packet loss is considered 1179 acceptable if a TCP flow across the same network path, and 1180 experiencing the same network conditions, would achieve an average 1181 throughput, measured on a reasonable timescale, that is not less than 1182 the RTP flow is achieving. This condition can be satisfied by 1183 implementing congestion control mechanisms to adapt the transmission 1184 rate (or the number of layers subscribed for a layered multicast 1185 session), or by arranging for a receiver to leave the session if the 1186 loss rate is unacceptably high. 1188 This payload format may also be used in networks that provide 1189 quality-of-service guarantees. If enhanced service is being used, 1190 receivers SHOULD monitor packet loss to ensure that the service that 1191 was requested is actually being delivered. If it is not, then they 1192 SHOULD assume that they are receiving best-effort service and behave 1193 accordingly. 1195 11. Acknowledgments 1197 The authors would like to thank the following people for their 1198 valuable contributions to this memo: Arnaud Germain, Alexandre 1199 Willeme, Gael Rouvroy, Siegfried Foessel, and Jean-Baptise Lorent. 1201 12. RFC Editor Considerations 1203 Note to RFC Editor: This section may be removed after carrying out 1204 all the instructions of this section. 1206 RFC XXXX is to be replaced by the RFC number this specification 1207 receives when published. 1209 13. References 1211 13.1. Normative References 1213 [ISO21122-1] 1214 International Organization for Standardization (ISO) - 1215 International Electrotechnical Commission (IEC), 1216 "Information technology - JPEG XS low-latency lightweight 1217 image coding system - Part 1: Core coding system", ISO/ 1218 IEC IS 21122-1. 1220 [ISO21122-2] 1221 International Organization for Standardization (ISO) - 1222 International Electrotechnical Commission (IEC), 1223 "Information technology - JPEG XS low-latency lightweight 1224 image coding system - Part 2: Profiles and buffer models", 1225 ISO/IEC IS 21122-2. 1227 [ISO21122-3] 1228 International Organization for Standardization (ISO) - 1229 International Electrotechnical Commission (IEC), 1230 "Information technology - JPEG XS low-latency lightweight 1231 image coding system - Part 3: Transport and container 1232 formats", ISO/IEC IS 21122-3. 1234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1235 Requirement Levels", BCP 14, RFC 2119, 1236 DOI 10.17487/RFC2119, March 1997, 1237 . 1239 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1240 with Session Description Protocol (SDP)", RFC 3264, 1241 DOI 10.17487/RFC3264, June 2002, 1242 . 1244 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1245 Jacobson, "RTP: A Transport Protocol for Real-Time 1246 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1247 July 2003, . 1249 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1250 Video Conferences with Minimal Control", STD 65, RFC 3551, 1251 DOI 10.17487/RFC3551, July 2003, 1252 . 1254 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1255 Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, 1256 . 1258 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1259 Specifications and Registration Procedures", BCP 13, 1260 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1261 . 1263 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 1264 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 1265 DOI 10.17487/RFC8083, March 2017, 1266 . 1268 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1269 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1270 March 2017, . 1272 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1273 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1274 May 2017, . 1276 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 1277 Session Description Protocol", RFC 8866, 1278 DOI 10.17487/RFC8866, January 2021, 1279 . 1281 13.2. Informative References 1283 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1284 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1285 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1286 . 1288 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 1289 Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, 1290 September 2005, . 1292 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1293 "Extended RTP Profile for Real-time Transport Control 1294 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1295 DOI 10.17487/RFC4585, July 2006, 1296 . 1298 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1299 Real-time Transport Control Protocol (RTCP)-Based Feedback 1300 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 1301 2008, . 1303 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 1304 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 1305 . 1307 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 1308 Framework: Why RTP Does Not Mandate a Single Media 1309 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 1310 2014, . 1312 [SMPTE-ST2110-21] 1313 Society of Motion Picture and Television Engineers, "SMPTE 1314 Standard - Professional Media Over Managed IP Networks: 1315 Traffic Shaping and Delivery Timing for Video", SMPTE ST 1316 2110-21:2017, 2017, 1317 . 1319 Authors' Addresses 1321 Sebastien Lugan 1322 intoPIX S.A. 1323 Rue Emile Francqui, 9 1324 1435 Mont-Saint-Guibert 1325 Belgium 1327 Phone: +32 10 23 84 70 1328 Email: rtp@intopix.com 1329 URI: https://www.intopix.com/ 1331 Antonin Descampe 1332 Universite catholique de Louvain 1333 Place du Levant, 3 - bte L5.03.02 1334 1348 Louvain-la-Neuve 1335 Belgium 1337 Phone: +32 10 47 25 97 1338 Email: antonin.descampe@uclouvain.be 1339 URI: https://uclouvain.be/en/research-institutes/icteam 1341 Corentin Damman 1342 intoPIX S.A. 1343 Rue Emile Francqui, 9 1344 1435 Mont-Saint-Guibert 1345 Belgium 1347 Phone: +32 10 23 84 70 1348 Email: c.damman@intopix.com 1349 URI: https://www.intopix.com/ 1350 Thomas Richter 1351 Fraunhofer IIS 1352 Am Wolfsmantel 33 1353 91048 Erlangen 1354 Germany 1356 Phone: +49 9131 776 5126 1357 Email: thomas.richter@iis.fraunhofer.de 1358 URI: https://www.iis.fraunhofer.de/ 1360 Tim Bruylants 1361 intoPIX S.A. 1362 Rue Emile Francqui, 9 1363 1435 Mont-Saint-Guibert 1364 Belgium 1366 Phone: +32 10 23 84 70 1367 Email: t.bruylants@intopix.com 1368 URI: https://www.intopix.com/