idnits 2.17.1 draft-ietf-payload-rtp-jpegxs-04.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: As per specified in RFC 3550 [RFC3550] and RFC 4175 [RFC4175], the RTP timestamp designates the sampling instant of the first octet of the frame to which the RTP packet belongs. Packets SHALL not include data from multiple frames, and all packets belonging to the same frame SHALL have the same timestamp. Several successive RTP packets will consequently have equal timestamps if they belong to the same frame (that is until the marker bit is set to 1, marking the last packet of the frame), and the timestamp is only increased when a new frame begins. -- The document date (July 29, 2020) is 1367 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) -- Looks like a reference, but probably isn't: '1' on line 1181 -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE-ST2110-10' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE-ST2110-21' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 avtcore S. Lugan 3 Internet-Draft A. Descampe 4 Intended status: Standards Track C. Damman 5 Expires: January 30, 2021 intoPIX 6 T. Richter 7 IIS 8 A. Willeme 9 UCL/ICTEAM 10 July 29, 2020 12 RTP Payload Format for ISO/IEC 21122 (JPEG XS) 13 draft-ietf-payload-rtp-jpegxs-04 15 Abstract 17 This document specifies a Real-Time Transport Protocol (RTP) payload 18 format to be used for transporting JPEG XS (ISO/IEC 21122) encoded 19 video. JPEG XS is a low-latency, lightweight image coding system. 20 Compared to an uncompressed video use case, it allows higher 21 resolutions and frame rates, while offering visually lossless 22 quality, reduced power consumption, and end-to-end latency confined 23 to a fraction of a frame. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 30, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions, Definitions, and Abbreviations . . . . . . . . . 3 61 3. Media Format Description . . . . . . . . . . . . . . . . . . 4 62 3.1. Image Data Structures . . . . . . . . . . . . . . . . . . 5 63 3.2. Codestream . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Video support box and colour specification box . . . . . 5 65 3.4. JPEG XS Frame . . . . . . . . . . . . . . . . . . . . . . 6 66 4. RTP Payload Format . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. RTP packetization . . . . . . . . . . . . . . . . . . . . 6 68 4.2. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 8 69 4.3. Payload Header Usage . . . . . . . . . . . . . . . . . . 10 70 4.4. Payload Data . . . . . . . . . . . . . . . . . . . . . . 12 71 4.5. Traffic Shaping and Delivery Timing . . . . . . . . . . . 17 72 5. Congestion Control Considerations . . . . . . . . . . . . . . 18 73 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 18 74 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 18 75 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 21 76 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 21 77 6.2.2. Media type and subtype . . . . . . . . . . . . . . . 22 78 6.2.3. Traffic shaping . . . . . . . . . . . . . . . . . . . 22 79 6.2.4. Offer/Answer Considerations . . . . . . . . . . . . . 22 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 82 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 24 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 24 85 10.2. Informative References . . . . . . . . . . . . . . . . . 26 86 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 89 1. Introduction 91 This document specifies a payload format for packetization of JPEG XS 92 encoded video signals into the Real-time Transport Protocol (RTP) 93 [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", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 Application Data Unit (ADU) 112 The unit of source data provided as payload to the transport 113 layer, and corresponding, in this RTP payload definition, to a 114 single JPEG XS frame. 116 Colour specification box (CS box) 117 A ISO colour specification box defined in ISO/IEC 21122-3 118 [ISO21122-3] that includes colour-related metadata required to 119 correctly display JPEG XS frames, such as colour primaries, 120 transfer characteristics and matrix coefficients. 122 EOC marker 123 A marker that consists of the two bytes 0xff11 indicating the end 124 of a JPEG XS codestream. 126 JPEG XS codestream 127 A sequence of bytes representing a compressed image formatted 128 according to JPEG XS Part-1 [ISO21122-1]. 130 JPEG XS codestream header 131 A sequence of bytes, starting with a SOC marker, at the beginning 132 of each JPEG XS codestream encoded in multiple markers and marker 133 segments that does not carry entropy coded data, but metadata such 134 as the frame dimension and component precision. 136 JPEG XS frame 137 A JPEG XS picture segment in the case of a progressive frame, or, 138 in the case of an interlaced frame, the concatenation of two JPEG 139 XS picture segments. 141 JPEG XS header segment 142 The concatenation of a video support box, as defined in ISO/IEC 143 21122-3 [ISO21122-3], a colour specification box, as defined in 144 ISO/IEC 21122-3 as well [ISO21122-3] and a JPEG XS codestream 145 header. 147 JPEG XS picture segment 148 The concatenation of a video support box, as defined in ISO/IEC 149 21122-3 [ISO21122-3], a colour specification box, as defined in 150 ISO/IEC 21122-3 as well [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. 180 Video support box (VS box) 181 A ISO video support box defined in ISO/IEC 21122-3 [ISO21122-3] 182 that includes metadata required to play back a JPEG XS stream, 183 such as its maximum bitrate, its subsampling structure, its buffer 184 model 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, followed by several slices, and 215 terminated by an EOC marker form a JPEG XS codestream. 217 The overall codestream format, including the definition of all 218 markers, is further defined in ISO/IEC 21122-1 [ISO21122-1]. It 219 represents sample values of a single image, bare any interpretation 220 relative to a colour space. 222 3.3. Video support box and colour specification box 224 While the information defined in the codestream is sufficient to 225 reconstruct the sample values of one image, the interpretation of the 226 samples remains undefined by the codestream itself. This 227 interpretation is given by the video support box and the colour 228 specification box which contain significant information to correctly 229 play the JPEG XS stream. The layout and syntax of these boxes, 230 together with their content, are defined in ISO/IEC 21122-3 231 [ISO21122-3]. The video support box provides information on the 232 maximum bitrate, the frame rate, the subsampling image format, the 233 timecode of the current JPEG XS frame, the profile, level and 234 sublevel used (as defined in ISO/IEC 21122-2 [ISO21122-2]), and 235 optionally on the buffer model and the mastering display metadata. 236 The colour specification box indicates the colour primaries, transfer 237 characteristics, matrix coefficients and video full range flag needed 238 to specify the colour space of the video stream. 240 3.4. JPEG XS Frame 242 The concatenation of a video support box, a colour specification box 243 and a JPEG XS codestream forms a JPEG XS picture segment. In the 244 case of a video stream made of progressive frames, each frame is made 245 of one single JPEG XS picture segment. In the case of a video stream 246 made of interlaced frames, each frame is made of two concatenated 247 JPEG XS picture segments. The codestream of each segment corresponds 248 to a field of the interlaced frame. The boxes in the first segment 249 SHALL be equal to the boxes in the second segment. Note that the 250 video information box included in each video support box contains a 251 frat field indicating if the frame is progressive or interlaced, and, 252 in case of interlaced frame, if the top field (i.e. the field 253 containing the top line of the frame) is in the first or second 254 segment (see ISO/IEC 21122-3 [ISO21122-3]). 256 4. RTP Payload Format 258 This section specifies the payload format for JPEG XS streams over 259 the Real-time Transport Protocol (RTP) [RFC3550]. 261 In order to be transported over RTP, each JPEG XS stream is 262 transported in a distinct RTP stream, identified by a distinct SSRC. 264 A JPEG XS stream is divided into Application Data Units (ADUs), each 265 ADU corresponding to a single JPEG XS frame. 267 4.1. RTP packetization 269 An ADU is made of several packetization units. If a packetization 270 unit is bigger than the maximum size of a RTP packet payload, the 271 unit is split into multiple RTP packet payloads, as illustrated in 272 Figure 1. As seen there, each packet SHALL contain (part of) one and 273 only one packetization unit. A packetization unit may extend over 274 multiple packets. The payload of every packet SHALL have the same 275 size (based e.g. on the Maximum Transfer Unit of the network), except 276 (possibly) the last packet of a packetization unit. The boundaries 277 of a packetization unit SHALL coincide with the boundaries of the 278 payload of a packet (excluding the payload header), i.e. the first 279 (resp. last) byte of the packetization unit SHALL be the first (resp. 280 last) byte of the payload (excluding its header). 282 RTP +-----+------------------------+ 283 Packet #1 | Hdr | Packetization unit #1 | 284 +-----+------------------------+ 285 RTP +-----+--------------------------------------+ 286 Packet #2 | Hdr | Packetization unit #2 | 287 +-----+--------------------------------------+ 288 RTP +-----+--------------------------------------------------+ 289 Packet #3 | Hdr | Packetization unit #3 (part 1/3) | 290 +-----+--------------------------------------------------+ 291 RTP +-----+--------------------------------------------------+ 292 Packet #4 | Hdr | Packetization unit #3 (part 2/3) | 293 +-----+--------------------------------------------------+ 294 RTP +-----+----------------------------------------------+ 295 Packet #5 | Hdr | Packetization unit #3 (part 3/3) | 296 +-----+----------------------------------------------+ 297 ... 298 RTP +-----+-----------------------------------------+ 299 Packet #P | Hdr | Packetization unit #N (part q/q) | 300 +-----+-----------------------------------------+ 302 Figure 1: Example of ADU packetization 304 There are two different packetization modes defined for this RTP 305 payload format. 307 1. Codestream packetization mode: in this mode, the packetization 308 unit SHALL be the entire codestream, preceeded by boxes. This 309 means that a progressive frame will have a single packetization 310 unit, while an interlaced frame will have two. The progressive 311 case is illustrated in Figure 2. 313 2. Slice packetization mode: in this mode, the packetization unit 314 SHALL be the slice, i.e. there SHALL be data from no more than 315 one slice per RTP packet. The first packetization unit SHALL be 316 made of the JPEG XS header segment (i.e. the concatenation of the 317 VS box, the CS box and the JPEG XS codestream header). This 318 first unit is then followed by successive units, each containing 319 one and only one slice. The packetization unit containing the 320 last slice of a JPEG XS codestream SHALL also contain the EOC 321 marker immediately following this last slice. This is 322 illustrated in Figure 3. In the case of an interlaced frame, the 323 JPEG XS header segment of the second field SHALL be in its own 324 packetization unit. 326 RTP +-----+--------------------------------------------------+ 327 Packet #1 | Hdr | VS box + CS box + JPEG XS codestream (part 1/q) | 328 +-----+--------------------------------------------------+ 329 RTP +-----+--------------------------------------------------+ 330 Packet #2 | Hdr | JPEG XS codestream (part 2/q) | 331 +-----+--------------------------------------------------+ 332 ... 333 RTP +-----+--------------------------------------+ 334 Packet #P | Hdr | JPEG XS codestream (part q/q) | 335 +-----+--------------------------------------+ 337 Figure 2: Example of codestream packetization mode 339 RTP +-----+----------------------------+ 340 Packet #1 | Hdr | JPEG XS header segment | 341 +-----+----------------------------+ 342 RTP +-----+--------------------------------------------------+ 343 Packet #2 | Hdr | Slice #1 (part 1/2) | 344 +-----+--------------------------------------------------+ 345 RTP +-----+-------------------------------------------+ 346 Packet #3 | Hdr | Slice #1 (part 2/2) | 347 +-----+-------------------------------------------+ 348 RTP +-----+--------------------------------------------------+ 349 Packet #4 | Hdr | Slice #2 (part 1/3) | 350 +-----+--------------------------------------------------+ 351 ... 352 RTP +-----+---------------------------------------+ 353 Packet #P | Hdr | Slice #N (part q/q) + EOC marker | 354 +-----+---------------------------------------+ 356 Figure 3: Example of slice packetization mode 358 Thanks to the constant bit-rate of JPEG XS, the codestream 359 packetization mode guarantees that a JPEG XS RTP stream will produce 360 a constant number of bytes per frame, and a constant number of RTP 361 packets per frame. To reach the same guarantee with the slice 362 packetization mode, an additional mechanism needs to be put in place. 363 This can involve a constraint at the rate allocation stage in the 364 JPEG XS encoder to impose a constant bit-rate at the slice level, the 365 usage of padding data, or the insertion of empty RTP packets (i.e. a 366 RTP packet whose payload data is empty). 368 4.2. RTP Header Usage 370 The format of the RTP header is specified in RFC 3550 [RFC3550] and 371 reprinted in Figure 4 for convenience. This RTP payload format uses 372 the fields of the header in a manner consistent with that 373 specification. 375 The RTP payload (and the settings for some RTP header bits) for 376 packetization units are specified in Section 4.3. 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | V |P|X| CC |M| PT | sequence number | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | timestamp | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | synchronization source (SSRC) identifier | 386 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 387 | contributing source (CSRC) identifiers | 388 | .... | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 4: RTP header according to RFC 3550 393 The version (V), padding (P), extension (X), CSRC count (CC), 394 sequence number, synchronization source (SSRC) and contributing 395 source (CSRC) fields follow their respective definitions in RFC 3550 396 [RFC3550]. 398 The remaining RTP header information to be set according to this RTP 399 payload format is set as follows: 401 Marker (M) [1 bit]: 403 The M bit is used to indicate the last packet of a frame. This 404 enables a decoder to finish decoding the frame. 406 Payload Type (PT) [7 bits]: 408 A dynamically allocated payload type field that designates the 409 payload as JPEG XS video. 411 Timestamp [32 bits]: 413 The RTP timestamp is set to the sampling timestamp of the content. 414 A 90 kHz clock rate SHOULD be used. 416 As per specified in RFC 3550 [RFC3550] and RFC 4175 [RFC4175], the 417 RTP timestamp designates the sampling instant of the first octet 418 of the frame to which the RTP packet belongs. Packets SHALL not 419 include data from multiple frames, and all packets belonging to 420 the same frame SHALL have the same timestamp. Several successive 421 RTP packets will consequently have equal timestamps if they belong 422 to the same frame (that is until the marker bit is set to 1, 423 marking the last packet of the frame), and the timestamp is only 424 increased when a new frame begins. 426 If the sampling instant does not correspond to an integer value of 427 the clock, the value SHALL be truncated to the next lowest 428 integer, with no ambiguity. 430 4.3. Payload Header Usage 432 The first four bytes of the payload of an RTP packet in this RTP 433 payload format are referred to as the payload header. Figure 5 434 illustrates the structure of this payload header. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 |T|K|L| I |F counter| SEP counter | P counter | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Figure 5: Payload header 444 The payload header consists of the following fields: 446 Transmission mode (T) [1 bit]: 448 The T bit is set to indicate that packets are sent sequentially by 449 the transmitter. A receiver could use this information to 450 dimension its input buffer(s) accordingly. If T=0, nothing can be 451 assumed about the transmission order and packets may be sent out- 452 of-order by the transmitter. If T=1, packets SHALL be sent 453 sequentially by the transmitter. 455 pacKetization mode (K) [1 bit]: 457 The K bit is set to indicate which packetization mode is used. 458 K=0 indicates codestream packetization mode, while K=1 indicates 459 slice packetization mode. If Transmission mode (T) is set to 0, 460 slice packetization mode SHALL be used and K SHALL be set to 1. 462 Last (L) [1 bit]: 464 The L bit is set to indicate the last packet of a packetization 465 unit. As the end of the frame also ends the packet containing the 466 last unit of the frame, the L bit is set whenever the M bit is 467 set. In the case of a progressive frame using the codestream 468 packetization mode, the L bit and M bit are equivalent. 470 Interlaced information (I) [2 bit]: 472 These 2 bits are used to indicate how the JPEG XS frame is scanned 473 (progressive or interlaced). In case of an interlaced frame, they 474 also indicate which JPEG XS picture segment the payload is part of 475 (first or second). 477 00: The payload is progressively scanned. 479 01: Reserved for future use. 481 10: The payload is part of the first JPEG XS picture segment of 482 an interlaced video frame. The height specified in the included 483 JPEG XS codestream header is half of the height of the entire 484 displayed image. 486 11: The payload is part of the second JPEG XS picture segment of 487 an interlaced video frame. The height specified in the included 488 JPEG XS codestream header is half of the height of the entire 489 displayed image. 491 F counter [5 bits]: 493 The frame (F) counter identifies the frame number modulo 32 to 494 which a packet belongs. Frame numbers are incremented by 1 for 495 each frame transmitted. The frame number, in addition to the 496 timestamp, may help the decoder manage its input buffer and bring 497 packets back into their natural order. 499 SEP counter [11 bits]: 501 The Slice and Extended Packet (SEP) counter is used differently 502 depending on the packetization mode. 504 * In the case of codestream packetization mode (K=0), this 505 counter resets whenever the Packet counter resets (see 506 hereunder), and increments by 1 whenever the Packet counter 507 overruns. 509 * In the case of slice packetization mode (K=1), this counter 510 identifies the slice modulo 2047 to which the packet 511 contributes. If the data belongs to the JPEG XS header 512 segment, this field SHALL have its maximal value, namely 2047 = 513 0x07ff. Otherwise, it is the slice index modulo 2047. Slice 514 indices are counted from 0 (corresponding to the top of the 515 frame). 517 P counter [11 bits]: 519 The packet (P) counter identifies the packet number modulo 2048 520 within the current packetization unit. It is set to 0 at the 521 start of the packetization unit and incremented by 1 for every 522 subsequent packet (if any) belonging to the same unit. 523 Practically, if codestream packetization mode is enabled, this 524 field counts the packets within a JPEG XS picture segment and is 525 extended by the SEP counter when it overruns. If slice 526 packetization mode is enabled, this field counts the packets 527 within a slice or within the JPEG XS header segment. 529 4.4. Payload Data 531 The payload data of a JPEG XS RTP stream consists of a concatenation 532 of multiple JPEG XS frames. 534 Each JPEG XS frame is the concatenation of one or more packetization 535 unit(s), as explained in Section 4.1. Figure 6 depicts this layout 536 for a progressive frame in the codestream packetization mode, 537 Figure 7 depicts this layout for an interlaced frame in the 538 codestream packetization mode, Figure 8 depicts this layout for a 539 progressive frame in the slice packetization mode and Figure 9 540 depicts this layout for an interlaced frame in the slice 541 packetization mode. The Frame counter value is not indicated because 542 the value is constant for all packetization units of a given frame. 544 +=====[ Packetization unit (PU) #1 ]====+ 545 | Video support box | SEP counter = 0 546 | +---------------------------------+ | P counter = 0 547 | : Sub boxes of the VS box : | 548 | +---------------------------------+ | 549 +- - - - - - - - - - - - - - - - - - - -+ 550 | Colour specification box | 551 | +---------------------------------+ | 552 | : Fields of the CS box : | 553 | +---------------------------------+ | 554 +- - - - - - - - - - - - - - - - - - - -+ 555 | JPEG XS codestream | 556 : (part 1/q) : M=0, K=0, L=0, I=00 557 +---------------------------------------+ 558 | JPEG XS codestream | SEP counter = 0 559 | (part 2/q) | P counter = 1 560 : : M=0, K=0, L=0, I=00 561 +---------------------------------------+ 562 | JPEG XS codestream | SEP counter = 0 563 | (part 3/q) | P counter = 2 564 : : M=0, K=0, L=0, I=00 565 +---------------------------------------+ 566 : : 567 +---------------------------------------+ 568 | JPEG XS codestream | SEP counter = 1 569 | (part 2049/q) | P counter = 0 570 : : M=0, K=0, L=0, I=00 571 +---------------------------------------+ 572 : : 573 +---------------------------------------+ 574 | JPEG XS codestream | SEP counter = (q-1) div 2048 575 | (part q/q) | P counter = (q-1) mod 2048 576 : : M=1, K=0, L=1, I=00 577 +=======================================+ 579 Figure 6: Example of JPEG XS Payload Data (codestream packetization 580 mode, progressive frame) 582 +=====[ Packetization unit (PU) #1 ]====+ 583 | Video support box | SEP counter = 0 584 +- - - - - - - - - - - - - - - - - - - -+ P counter = 0 585 | Colour specification box | 586 +- - - - - - - - - - - - - - - - - - - -+ 587 | JPEG XS codestream (1st field) | 588 : (part 1/q) : M=0, K=0, L=0, I=10 589 +---------------------------------------+ 590 | JPEG XS codestream (1st field) | SEP counter = 0 591 | (part 2/q) | P counter = 1 592 : : M=0, K=0, L=0, I=10 593 +---------------------------------------+ 594 : : 595 +---------------------------------------+ 596 | JPEG XS codestream (1st field) | SEP counter = 1 597 | (part 2049/q) | P counter = 0 598 : : M=0, K=0, L=0, I=10 599 +---------------------------------------+ 600 : : 601 +---------------------------------------+ 602 | JPEG XS codestream (1st field) | SEP counter = (q-1) div 2048 603 | (part q/q) | P counter = (q-1) mod 2048 604 : : M=0, K=0, L=1, I=10 605 +===============[ PU #2 ]===============+ 606 | Video support box | SEP counter = 0 607 +- - - - - - - - - - - - - - - - - - - -+ P counter = 0 608 | Colour specification box | 609 +- - - - - - - - - - - - - - - - - - - -+ 610 | JPEG XS codestream (2nd field) | 611 | (part 1/q) | 612 : : M=0, K=0, L=0, I=11 613 +---------------------------------------+ 614 | JPEG XS codestream (2nd field) | SEP counter = 0 615 | (part 2/q) | P counter = 1 616 : : M=0, K=0, L=0, I=11 617 +---------------------------------------+ 618 : : 619 +---------------------------------------+ 620 | JPEG XS codestream (2nd field) | SEP counter = (q-1) div 2048 621 | (part q/q) | P counter = (q-1) mod 2048 622 : : M=1, K=0, L=1, I=11 623 +=======================================+ 625 Figure 7: Example of JPEG XS Payload Data (codestream packetization 626 mode, interlaced frame) 628 +===[ PU #1: JPEG XS Header segment ]===+ 629 | Video support box | SEP counter = 0x07FF 630 +- - - - - - - - - - - - - - - - - - - -+ P counter = 0 631 | Colour specification box | 632 +- - - - - - - - - - - - - - - - - - - -+ 633 | JPEG XS codestream header | 634 | +---------------------------------+ | 635 | : Markers and marker segments : | 636 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=00 637 +==========[ PU #2: Slice #1 ]==========+ 638 | +---------------------------------+ | SEP counter = 0 639 | | SLH Marker | | P counter = 0 640 | +---------------------------------+ | 641 | : Entropy Coded Data : | 642 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=00 643 +==========[ PU #3: Slice #2 ]==========+ 644 | Slice #2 | SEP counter = 1 645 | (part 1/q) | P counter = 0 646 : : M=0, T=0, K=1, L=0, I=00 647 +---------------------------------------+ 648 | Slice #2 | SEP counter = 1 649 | (part 2/q) | P counter = 1 650 : : M=0, T=0, K=1, L=0, I=00 651 +---------------------------------------+ 652 : : 653 +---------------------------------------+ 654 | Slice #2 | SEP counter = 1 655 | (part q/q) | P counter = q-1 656 : : M=0, T=0, K=1, L=1, I=00 657 +=======================================+ 658 : : 659 +========[ PU #N: Slice #(N-1) ]========+ 660 | Slice #(N-1) | SEP counter = N-2 661 | (part 1/r) | P counter = 0 662 : : M=0, T=0, K=1, L=0, I=00 663 +---------------------------------------+ 664 : : 665 +---------------------------------------+ 666 | Slice #(N-1) | SEP counter = N-2 667 | (part r/r) | P counter = r-1 668 : + EOC marker : M=1, T=0, K=1, L=1, I=00 669 +=======================================+ 671 Figure 8: Example of JPEG XS Payload Data (slice packetization mode, 672 progressive frame) 674 +====[ PU #1: JPEG XS Hdr segment 1 ]===+ 675 | Video support box | SEP counter = 0x07FF 676 +- - - - - - - - - - - - - - - - - - - -+ P counter = 0 677 | Colour specification box | 678 +- - - - - - - - - - - - - - - - - - - -+ 679 | JPEG XS codestream header 1 | 680 | +---------------------------------+ | 681 | : Markers and marker segments : | 682 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=10 683 +====[ PU #2: Slice #1 (1st field) ]====+ 684 | +---------------------------------+ | SEP counter = 0 685 | | SLH Marker | | P counter = 0 686 | +---------------------------------+ | 687 | : Entropy Coded Data : | 688 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=10 689 +====[ PU #3: Slice #2 (1st field) ]====+ 690 | Slice #2 | SEP counter = 1 691 | (part 1/q) | P counter = 0 692 : : M=0, T=0, K=1, L=0, I=10 693 +---------------------------------------+ 694 | Slice #2 | SEP counter = 1 695 | (part 2/q) | P counter = 1 696 : : M=0, T=0, K=1, L=0, I=10 697 +---------------------------------------+ 698 : : 699 +---------------------------------------+ 700 | Slice #2 | SEP counter = 1 701 | (part q/q) | P counter = q-1 702 : : M=0, T=0, K=1, L=1, I=10 703 +=======================================+ 704 : : 705 +==[ PU #N: Slice #(N-1) (1st field) ]==+ 706 | Slice #(N-1) | SEP counter = N-2 707 | (part 1/r) | P counter = 0 708 : : M=0, T=0, K=1, L=0, I=10 709 +---------------------------------------+ 710 : : 711 +---------------------------------------+ 712 | Slice #(N-1) | SEP counter = N-2 713 | (part r/r) | P counter = r-1 714 : + EOC marker : M=0, T=0, K=1, L=1, I=10 715 +=======================================+ 716 +===[ PU #N+1: JPEG XS Hdr segment 2 ]==+ 717 | Video support box | SEP counter = 0x07FF 718 +- - - - - - - - - - - - - - - - - - - -+ P counter = 0 719 | Colour specification box | 720 +- - - - - - - - - - - - - - - - - - - -+ 721 | JPEG XS codestream header 2 | 722 | +---------------------------------+ | 723 | : Markers and marker segments : | 724 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=11 725 +===[ PU #N+2: Slice #1 (2nd field) ]===+ 726 | +---------------------------------+ | SEP counter = 0 727 | | SLH Marker | | P counter = 0 728 | +---------------------------------+ | 729 | : Entropy Coded Data : | 730 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=11 731 +===[ PU #N+3: Slice #2 (2nd field) ]===+ 732 | Slice #2 | SEP counter = 1 733 | (part 1/s) | P counter = 0 734 : : M=0, T=0, K=1, L=0, I=11 735 +---------------------------------------+ 736 | Slice #2 | SEP counter = 1 737 | (part 2/s) | P counter = 1 738 : : M=0, T=0, K=1, L=0, I=11 739 +---------------------------------------+ 740 : : 741 +---------------------------------------+ 742 | Slice #2 | SEP counter = 1 743 | (part s/s) | P counter = s-1 744 : : M=0, T=0, K=1, L=1, I=11 745 +=======================================+ 746 : : 747 +==[ PU #2N: Slice #(N-1) (2nd field) ]=+ 748 | Slice #(N-1) | SEP counter = N-2 749 | (part 1/t) | P counter = 0 750 : : M=0, T=0, K=1, L=0, I=11 751 +---------------------------------------+ 752 : : 753 +---------------------------------------+ 754 | Slice #(N-1) | SEP counter = N-2 755 | (part t/t) | P counter = t-1 756 : + EOC marker : M=1, T=0, K=1, L=1, I=11 757 +=======================================+ 759 Figure 9: Example of JPEG XS Payload Data (slice packetization mode, 760 interlaced frame) 762 4.5. Traffic Shaping and Delivery Timing 764 The traffic shaping and delivery timing SHALL be in accordance with 765 the Network Compatibility Model compliance definitions specified in 766 SMPTE ST 2110-21 [SMPTE-ST2110-21] for either Narrow Linear Senders 767 (Type NL) or Wide Senders (Type W). The session description SHALL 768 include a format-specific parameter of either TP=2110TPNL or 769 TP=2110TPW to indicate compliance with Type NL or Type W 770 respectively. 772 NOTE: The Virtual Receiver Buffer Model compliance definitions of ST 773 2110-21 do not apply. 775 5. Congestion Control Considerations 777 Congestion control for RTP SHALL be used in accordance with RFC 3550 778 [RFC3550], and with any applicable RTP profile: e.g., RFC 3551 779 [RFC3551]. An additional requirement if best-effort service is being 780 used is users of this payload format MUST monitor packet loss to 781 ensure that the packet loss rate is within acceptable parameters. 782 Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines 783 criteria for when one is required to stop sending RTP Packet Streams 784 and applications implementing this standard MUST comply with it. RFC 785 8085 [RFC8085] provides additional information on the best practices 786 for applying congestion control to UDP streams. 788 6. Payload Format Parameters 790 6.1. Media Type Definition 792 Type name: video 794 Subtype name: jxsv 796 Required parameters: 798 rate: The RTP timestamp clock rate. Applications using this 799 payload format SHOULD use a value of 90000. 801 transmode: Indicates if packets are sent sequentially by the 802 transmitter. A receiver could use this information to dimension 803 its input buffer(s) accordingly. If set to 0, nothing can be 804 assumed about the transmission order and packets may be sent out- 805 of-order. If value is 1, packets SHALL be sent sequentially by the 806 transmitter. 808 Optional parameters: 810 profile: The JPEG XS profile in use, as defined in ISO/IEC 21122-2 811 (JPEG XS Part 2) [ISO21122-2]. 813 level: The JPEG XS level in use, as defined in ISO/IEC 21122-2 814 (JPEG XS Part 2) [ISO21122-2]. 816 sublevel: The JPEG XS sublevel in use, as defined in ISO/IEC 817 21122-2 (JPEG XS Part 2) [ISO21122-2]. 819 sampling: Signals the colour difference signal sub-sampling 820 structure. 822 Signals utilizing the non-constant luminance Y'C'B C'R signal 823 format of Recommendation ITU-R BT.601-7, Recommendation ITU-R 824 BT.709-6, Recommendation ITU-R BT.2020-2, or Recommendation ITU-R 825 BT.2100 SHALL use the appropriate one of the following values for 826 the Media Type Parameter "sampling": 828 YCbCr-4:4:4 (4:4:4 sampling) 829 YCbCr-4:2:2 (4:2:2 sampling) 830 YCbCr-4:2:0 (4:2:0 sampling) 832 Signals utilizing the Constant Luminance Y'C C'BC C'RC signal 833 format of Recommendation ITU-R BT.2020-2 SHALL use the appropriate 834 one of the following values for the Media Type Parameter 835 "sampling": 837 CLYCbCr-4:4:4 (4:4:4 sampling) 838 CLYCbCr-4:2:2 (4:2:2 sampling) 839 CLYCbCr-4:2:0 (4:2:0 sampling) 841 Signals utilizing the constant intensity I CT CP signal format of 842 Recommendation ITU-R BT.2100 SHALL use the appropriate one of the 843 following values for the Media Type Parameter "sampling": 845 ICtCp-4:4:4 (4:4:4 sampling) 846 ICtCp-4:2:2 (4:2:2 sampling) 847 ICtCp-4:2:0 (4:2:0 sampling) 849 Signals utilizing the 4:4:4 R' G' B' or RGB signal format (such as 850 that of Recommendation ITU-R BT.601, Recommendation ITU-R BT.709, 851 Recommendation ITU-R BT.2020, Recommendation ITU-R BT.2100, SMPTE 852 ST 2065-1 or ST 2065-3) SHALL use the following value for the Media 853 Type Parameter sampling. 855 RGB RGB or R' G' B' samples 857 Signals utilizing the 4:4:4 X' Y' Z' signal format (such as defined 858 in SMPTE ST 428-1) SHALL use the following value for the Media Type 859 Parameter sampling. 861 XYZ X' Y' Z' samples 863 Key signals as defined in SMPTE RP 157 SHALL use the value key for 864 the Media Type Parameter sampling. The Key signal is represented 865 as a single component. 867 KEY samples of the key signal 869 depth: Determines the number of bits per sample. This is an 870 integer with typical values including 8, 10, 12, and 16. 872 width: Determines the number of pixels per line. This is an 873 integer between 1 and 32767. 875 height: Determines the number of lines per frame. This is an 876 integer between 1 and 32767. 878 exactframerate: Signals the frame rate in frames per second. 879 Integer frame rates SHALL be signaled as a single decimal number 880 (e.g. "25") whilst non-integer frame rates SHALL be signaled as a 881 ratio of two integer decimal numbers separated by a "forward-slash" 882 character (e.g. "30000/1001"), utilizing the numerically smallest 883 numerator value possible. 885 colorimetry: Specifies the system colorimetry used by the image 886 samples. Valid values and their specification are: 888 BT601-5 ITU Recommendation BT.601-5 889 BT709-2 ITU Recommendation BT.709-2 890 SMPTE240M SMPTE standard 240M 891 BT601 as specified in Recommendation ITU-R BT.601-7 892 BT709 as specified in Recommendation ITU-R BT.709-6 893 BT2020 as specified in Recommendation ITU-R BT.2020-2 894 BT2100 as specified in Recommendation ITU-R BT.2100 895 Table 2 titled "System colorimetry" 896 ST2065-1 as specified in SMPTE ST 2065-1 Academy Color 897 Encoding Specification (ACES) 898 ST2065-3 as specified for Academy Density Exchange 899 Encoding (ADX) in SMPTE ST 2065-3 900 XYZ as specified in ISO 11664-1 section titled 901 "1931 Observer" 903 Signals utilizing the Recommendation ITU-R BT.2100 colorimetry 904 SHOULD also signal the representational range using the optional 905 parameter RANGE defined below. 907 interlace: If this OPTIONAL parameter name is present, it indicates 908 that the video is interlaced. If this parameter name is not 909 present, the progressive video format SHALL be assumed. 911 TCS: Transfer Characteristic System. This parameter specifies the 912 transfer characteristic system of the image samples. Valid values 913 and their specification are: 915 SDR (Standard Dynamic Range) Video streams of standard 916 dynamic range, that utilize the OETF of Recommendation 917 ITU-R BT.709 or Recommendation ITU-R BT.2020. Such 918 streams SHALL be assumed to target the EOTF specified 919 in ITU-R BT.1886. 920 PQ Video streams of high dynamic range video that utilize 921 the Perceptual Quantization system of Recommendation 922 ITU-R BT.2100 923 HLG Video streams of high dynamic range video that utilize 924 the Hybrid Log-Gamma system of Recommendation ITU-R 925 BT.2100 927 RANGE: This parameter SHOULD be used to signal the encoding range 928 of the sample values within the stream. When paired with ITU Rec 929 BT.2100 colorimetry, this parameter has two allowed values NARROW 930 and FULL, corresponding to the ranges specified in table 9 of ITU 931 Rec BT.2100. In any other context, this parameter has three 932 allowed values: NARROW, FULLPROTECT, and FULL, which correspond to 933 the ranges specified in SMPTE RP 2077. In the absence of this 934 parameter, NARROW SHALL be the assumed value in either case. 936 Encoding considerations: 938 This media type is framed and binary; see Section 4.8 in RFC 6838 939 [RFC6838]. 941 Security considerations: 943 Please see the Security Considerations section in RFC XXXX 945 6.2. Mapping to SDP 947 6.2.1. General 949 A Session Description Protocol (SDP) object SHALL be created for each 950 RTP stream and it SHALL be in accordance with the provisions of SMPTE 951 ST 2110-10 [SMPTE-ST2110-10]. 953 The information carried in the media type specification has a 954 specific mapping to fields in the Session Description Protocol (SDP), 955 which is commonly used to describe RTP sessions. This information is 956 redundant with the information found in the payload data (namely, in 957 the JPEG XS header segment) and SHALL be consistent with it. In case 958 of discrepancy between parameters values found in the payload data 959 and in the SDP fields, the values from the payload data SHALL 960 prevail. 962 6.2.2. Media type and subtype 964 The media type ("video") goes in SDP "m=" as the media name. 966 The media subtype ("jxsv") goes in SDP "a=rtpmap" as the encoding 967 name, followed by a slash ("/") and the required parameter "rate" 968 corresponding to the RTP timestamp clock rate (which for the payload 969 format defined in this document SHOULD be 90000). The required 970 parameter "transmode" and the additional optional parameters go in 971 the SDP "a=fmtp" attribute by copying them directly from the MIME 972 media type string as a semicolon-separated list of parameter=value 973 pairs. 975 A sample SDP mapping for JPEG XS video is as follows: 977 m=video 30000 RTP/AVP 112 978 a=rtpmap:112 jxsv/90000 979 a=fmtp:112 transmode=1;sampling=YCbCr-4:2:2;width=1920;height=1080; 980 depth=10;colorimetry=BT709;TCS=SDR; 981 RANGE=FULL;TP=2110TPNL 983 In this example, a JPEG XS RTP stream is being sent to UDP 984 destination port 30000, with an RTP dynamic payload type of 112 and a 985 media clock rate of 90000 Hz. Note that the "a=fmtp:" line has been 986 wrapped to fit this page, and will be a single long line in the SDP 987 file. 989 6.2.3. Traffic shaping 991 The SDP object SHALL include the TP parameter (either 2110TPNL or 992 2110TPW as specified in Section 4.5) and may include the CMAX 993 parameter as specified in SMPTE ST 2110-21 [SMPTE-ST2110-21]. 995 6.2.4. Offer/Answer Considerations 997 The following considerations apply when using SDP offer/answer 998 procedures [RFC3264] to negotiate the use of the JPEG XS payload in 999 RTP: 1001 o The "encode" parameter can be used for sendrecv, sendonly, and 1002 recvonly streams. Each encode type MUST use a separate payload 1003 type number. 1005 o Any unknown parameter in an offer MUST be ignored by the receiver 1006 and MUST NOT be included in the answer. 1008 7. IANA Considerations 1010 This memo requests that IANA registers video/jxsv as specified in 1011 Section 6.1. The media type is also requested to be added to the 1012 IANA registry for "RTP Payload Format MIME types" [1]. 1014 8. Security Considerations 1016 RTP packets using the payload format defined in this specification 1017 are subject to the security considerations discussed in the RTP 1018 specification [RFC3550] and in any applicable RTP profile such as 1019 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ 1020 SAVPF [RFC5124]. This implies that confidentiality of the media 1021 streams is achieved by encryption. 1023 However, as "Securing the RTP Framework: Why RTP Does Not Mandate a 1024 Single Media Security Solution" [RFC7202] discusses, it is not an RTP 1025 payload format's responsibility to discuss or mandate what solutions 1026 are used to meet the basic security goals like confidentiality, 1027 integrity, and source authenticity for RTP in general. This 1028 responsibility lies on anyone using RTP in an application. They can 1029 find guidance on available security mechanisms and important 1030 considerations in "Options for Securing RTP Sessions" [RFC7201]. 1031 Applications SHOULD use one or more appropriate strong security 1032 mechanisms. 1034 This payload format and the JPEG XS encoding do not exhibit any 1035 substantial non-uniformity, either in output or in complexity to 1036 perform the decoding operation and thus are unlikely to pose a 1037 denial-of-service threat due to the receipt of pathological 1038 datagrams. 1040 It is important to note that HD or UHDTV JPEG XS-encoded video can 1041 have significant bandwidth requirements (typically more than 1 Gbps 1042 for ultra high-definition video, especially if using high framerate). 1043 This is sufficient to cause potential for denial-of-service if 1044 transmitted onto most currently available Internet paths. 1046 Accordingly, if best-effort service is being used, users of this 1047 payload format MUST monitor packet loss to ensure that the packet 1048 loss rate is within acceptable parameters. Packet loss is considered 1049 acceptable if a TCP flow across the same network path, and 1050 experiencing the same network conditions, would achieve an average 1051 throughput, measured on a reasonable timescale, that is not less than 1052 the RTP flow is achieving. This condition can be satisfied by 1053 implementing congestion control mechanisms to adapt the transmission 1054 rate (or the number of layers subscribed for a layered multicast 1055 session), or by arranging for a receiver to leave the session if the 1056 loss rate is unacceptably high. 1058 This payload format may also be used in networks that provide 1059 quality-of-service guarantees. If enhanced service is being used, 1060 receivers SHOULD monitor packet loss to ensure that the service that 1061 was requested is actually being delivered. If it is not, then they 1062 SHOULD assume that they are receiving best-effort service and behave 1063 accordingly. 1065 9. RFC Editor Considerations 1067 Note to RFC Editor: This section may be removed after carrying out 1068 all the instructions of this section. 1070 RFC XXXX is to be replaced by the RFC number this specification 1071 receives when published. 1073 10. References 1075 10.1. Normative References 1077 [ISO21122-1] 1078 International Organization for Standardization (ISO) - 1079 International Electrotechnical Commission (IEC), 1080 "Information technology - JPEG XS low-latency lightweight 1081 image coding system - Part 1: Core coding system", ISO/ 1082 IEC IS 21122-1, 2019, 1083 . 1085 [ISO21122-2] 1086 International Organization for Standardization (ISO) - 1087 International Electrotechnical Commission (IEC), 1088 "Information technology - JPEG XS low-latency lightweight 1089 image coding system - Part 2: Profiles and buffer models", 1090 ISO/IEC IS 21122-2, 2019, 1091 . 1093 [ISO21122-3] 1094 International Organization for Standardization (ISO) - 1095 International Electrotechnical Commission (IEC), 1096 "Information technology - JPEG XS low-latency lightweight 1097 image coding system - Part 3: Transport and container 1098 formats", ISO/IEC IS 21122-3, 2019, 1099 . 1101 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1102 Requirement Levels", BCP 14, RFC 2119, 1103 DOI 10.17487/RFC2119, March 1997, 1104 . 1106 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1107 with Session Description Protocol (SDP)", RFC 3264, 1108 DOI 10.17487/RFC3264, June 2002, 1109 . 1111 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1112 Jacobson, "RTP: A Transport Protocol for Real-Time 1113 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1114 July 2003, . 1116 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 1117 Video Conferences with Minimal Control", STD 65, RFC 3551, 1118 DOI 10.17487/RFC3551, July 2003, 1119 . 1121 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1122 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1123 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1124 . 1126 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1127 Specifications and Registration Procedures", BCP 13, 1128 RFC 6838, DOI 10.17487/RFC6838, January 2013, 1129 . 1131 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 1132 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 1133 DOI 10.17487/RFC8083, March 2017, 1134 . 1136 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1137 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1138 March 2017, . 1140 [SMPTE-ST2110-10] 1141 Society of Motion Picture and Television Engineers, "SMPTE 1142 Standard - Professional Media Over Managed IP Networks: 1143 System Timing and Definitions", SMPTE ST 2110-10:2017, 1144 2017, . 1146 [SMPTE-ST2110-21] 1147 Society of Motion Picture and Television Engineers, "SMPTE 1148 Standard - Professional Media Over Managed IP Networks: 1149 Traffic Shaping and Delivery Timing for Video", SMPTE ST 1150 2110-21:2017, 2017, 1151 . 1153 10.2. Informative References 1155 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 1156 Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, 1157 September 2005, . 1159 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1160 "Extended RTP Profile for Real-time Transport Control 1161 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1162 DOI 10.17487/RFC4585, July 2006, 1163 . 1165 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 1166 Real-time Transport Control Protocol (RTCP)-Based Feedback 1167 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 1168 2008, . 1170 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 1171 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 1172 . 1174 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 1175 Framework: Why RTP Does Not Mandate a Single Media 1176 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 1177 2014, . 1179 10.3. URIs 1181 [1] http://www.iana.org/assignments/rtp-parameters 1183 Authors' Addresses 1185 Sebastien Lugan 1186 intoPIX S.A. 1187 Rue Emile Francqui, 9 1188 1435 Mont-Saint-Guibert 1189 Belgium 1191 Phone: +32 10 23 84 70 1192 Email: rtp@intopix.com 1193 URI: http://www.intopix.com 1194 Antonin Descampe 1195 intoPIX S.A. 1196 Rue Emile Francqui, 9 1197 1435 Mont-Saint-Guibert 1198 Belgium 1200 Phone: +32 10 23 84 70 1201 Email: a.descampe@intopix.com 1202 URI: http://www.intopix.com 1204 Corentin Damman 1205 intoPIX S.A. 1206 Rue Emile Francqui, 9 1207 1435 Mont-Saint-Guibert 1208 Belgium 1210 Phone: +32 10 23 84 70 1211 Email: c.damman@intopix.com 1212 URI: http://www.intopix.com 1214 Thomas Richter 1215 Fraunhofer IIS 1216 Am Wolfsmantel 33 1217 91048 Erlangen 1218 Germany 1220 Phone: +49 9131 776 5126 1221 Email: thomas.richter@iis.fraunhofer.de 1222 URI: https://www.iis.fraunhofer.de/ 1224 Alexandre Willeme 1225 Universite catholique de Louvain 1226 Place du Levant, 2 - bte L5.04.04 1227 1348 Louvain-la-Neuve 1228 Belgium 1230 Phone: +32 10 47 80 82 1231 Email: alexandre.willeme@uclouvain.be 1232 URI: https://uclouvain.be/en/icteam