idnits 2.17.1 draft-ietf-payload-rtp-jpegxs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 9, 2019) is 1655 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 816 -- 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 (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Payload Working Group S. Lugan 3 Internet-Draft G. Rouvroy 4 Intended status: Standards Track A. Descampe 5 Expires: April 11, 2020 intoPIX 6 T. Richter 7 IIS 8 A. Willeme 9 UCL/ICTEAM 10 October 9, 2019 12 RTP Payload Format for ISO/IEC 21122 (JPEG XS) 13 draft-ietf-payload-rtp-jpegxs-02 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 April 11, 2020. 42 Copyright Notice 44 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 4 63 3.2. Codestream . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Video support box and colour specification box . . . . . 5 65 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Payload Header . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 8 68 4.3. Traffic Shaping and Delivery Timing . . . . . . . . . . . 10 69 5. Congestion Control Considerations . . . . . . . . . . . . . . 10 70 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 10 71 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 10 72 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 13 73 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 13 74 6.2.2. Media type and subtype . . . . . . . . . . . . . . . 14 75 6.2.3. Traffic shaping . . . . . . . . . . . . . . . . . . . 14 76 6.2.4. Offer/Answer Considerations . . . . . . . . . . . . . 14 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 16 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 82 10.2. Informative References . . . . . . . . . . . . . . . . . 18 83 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 This document specifies a payload format for packetization of JPEG XS 89 encoded video signals into the Real-time Transport Protocol (RTP) 90 [RFC3550]. 92 The JPEG XS coding system offers compression and recompression of 93 image sequences with very moderate computational resources while 94 remaining robust under multiple compression and decompression cycles 95 and mixing of content sources, e.g. embedding of subtitles, overlays 96 or logos. Typical target compression ratios ensuring visually 97 lossless quality are in the range of 2:1 to 10:1, depending on the 98 nature of the source material. The end-to-end latency can be 99 confined to a fraction of a frame, typically between a small number 100 of lines down to below a single line. 102 2. Conventions, Definitions, and Abbreviations 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 Application Data Unit (ADU) 109 The unit of source data provided as payload to the transport 110 layer, and corresponding, in this RTP payload definition, to a 111 single JPEG XS frame. 113 Colour specification box 114 A ISO colour specification box defined in ISO/IEC 21122-3 115 [ISO21122-3] that includes colour-related metadata required to 116 correctly display JPEG XS frames, such as colour primaries, 117 transfer characteristics and matrix coefficients. 119 JPEG XS codestream 120 A sequence of bytes representing a compressed image formatted 121 according to JPEG XS Part 1 [ISO21122-1], except the End-Of- 122 Codestream (EOC) marker which is omitted in this payload format. 124 JPEG XS codestream header 125 A sequence of bytes at the beginning of each JPEG XS codestream 126 encoded in multiple markers and marker segments that does not 127 carry entropy coded data, but metadata such as the frame dimension 128 and component precision. 130 JPEG XS frame 131 The concatenation of a video support box, as defined in JPEG XS 132 Part 3 [ISO21122-3], a colour specification box, as defined as 133 well in JPEG XS Part 3 [ISO21122-3] and a JPEG XS codestream. 135 JPEG XS header segment 136 The concatenation of a video support box, as defined in JPEG XS 137 Part 3 [ISO21122-3], a colour specification box, as defined as 138 well in JPEG XS Part 3 [ISO21122-3] and a JPEG XS codestream 139 header. 141 JPEG XS stream 142 A sequence of JPEG XS frames 144 Marker 145 A two-byte functional sequence that is part of a JPEG XS 146 codestream starting with a 0xff byte and a subsequent byte 147 defining its function. 149 Marker segment 150 A marker along with a 16-bit marker size and payload data 151 following the size. 153 Slice 154 The smallest independently decodable unit of a JPEG XS codestream, 155 bearing in mind that it decodes to wavelet coefficients which 156 still require inverse wavelet filtering to give an image. 158 SOC marker 159 A marker that consists of the two bytes 0xff10 indicating the 160 start of a JPEG XS codestream. 162 Video support box 163 A ISO video support box defined in ISO/IEC 21122-3 [ISO21122-3] 164 that includes metadata required to play back a JPEG XS stream, 165 such as its maximum bitrate, its subsampling structure, its buffer 166 model and its frame rate. 168 3. Media Format Description 170 3.1. Image Data Structures 172 JPEG XS is a low-latency lightweight image coding system for coding 173 continuous-tone grayscale or continuous-tone colour digital images. 175 This coding system provides an efficient representation of image 176 signals through the mathematical tool of wavelet analysis. The 177 wavelet filter process separates each component into multiple bands, 178 where each band consists of multiple coefficients describing the 179 image signal of a given component within a frequency domain specific 180 to the wavelet filter type, i.e. the particular filter corresponding 181 to the band. 183 Wavelet coefficients are grouped into precincts, where each precinct 184 includes all coefficients over all bands that contribute to a spatial 185 region of the image. 187 One or multiple precincts are furthermore combined into slices 188 consisting of an integral number of precincts. Precincts do not 189 cross slice boundaries, and wavelet coefficients in precincts that 190 are part of different slices can be decoded independently from each 191 other. Note, however, that the wavelet transformation runs across 192 slice boundaries. A slice always extends over the full width of the 193 image, but may only cover parts of its height. 195 Each JPEG XS frame consists of a JPEG XS header segment followed by 196 one or multiple slices completely describing a single frame. 198 3.2. Codestream 200 The overall codestream format, including the definition of all 201 markers, is further defined in ISO/IEC 21122-1 [ISO21122-1]. It 202 represents sample values of a single frame, bare any interpretation 203 relative to a colour space. 205 3.3. Video support box and colour specification box 207 While the information defined in the codestream is sufficient to 208 reconstruct the sample values of one video frame, the interpretation 209 of the samples remains undefined by the codestream itself. This 210 interpretation is given by the video support box and the colour 211 specification box which contain significant information to correctly 212 play the JPEG XS stream. The layout and syntax of these boxes, 213 together with their content, are defined in ISO/IEC 21122-3 214 [ISO21122-3]. The video support box provides information on the 215 maximum bitrate, the frame rate, the subsampling image format, the 216 timecode of the current JPEG XS frame, the profile, level and 217 sublevel used (as defined in ISO/IEC 21122-2 [ISO21122-2]), and 218 optionally on the buffer model and the mastering display metadata. 219 The colour specification box indicates the colour primaries, transfer 220 characteristics, matrix coefficients and video full range flag needed 221 to specify the colour space of the video stream. 223 4. Payload Format 225 This section specifies the payload format for JPEG XS streams over 226 the Real-time Transport Protocol (RTP) [RFC3550]. 228 In order to be transported over RTP, each JPEG XS stream is 229 transported in a distinct RTP stream, identified by a distinct SSRC. 231 A JPEG XS stream is divided into Application Data Units (ADUs), each 232 ADU corresponding to a single JPEG XS frame. 234 An ADU is split into multiple RTP packet payloads. Figure 1 shows an 235 example of how a JPEG XS frame fits into the payload of RTP packets 236 ("Hdr" denotes a RTP packet header). As seen there, each packet 237 contains either part of the JPEG XS header segment or part of a 238 single slice. Both may extend over multiple packets. The payload of 239 every packet shall have the same size (based e.g. on the Maximum 240 Transfer Unit of the network), except (possibly) the last packet of 241 the JPEG XS header segment or a slice. The boundaries of the JPEG XS 242 header segment and of every slice shall coincide with the boundaries 243 of the payload of a packet, i.e. the first (resp. last) byte of the 244 JPEG XS header segment or a slice shall be the first (resp. last) 245 byte of the payload. 247 RTP +-----+------------------------+ 248 Packet #1 | Hdr | JPEG XS header segment | 249 +-----+------------------------+ 250 RTP +-----+---------------------------+ 251 Packet #2 | Hdr | Slice 0 | 252 +-----+---------------------------+ 253 RTP +-----+---------------------------------------------+ 254 Packet #3 | Hdr | Slice 1 (part 1/3) | 255 +-----+---------------------------------------------+ 256 RTP +-----+---------------------------------------------+ 257 Packet #4 | Hdr | Slice 1 (part 2/3) | 258 +-----+---------------------------------------------+ 259 RTP +-----+---------------------+ 260 Packet #5 | Hdr | Slice 1 (part 3/3) | 261 +-----+---------------------+ 262 ... 263 RTP +-----+-----------------------+ 264 Packet #P | Hdr | Slice N-1 (part q/q) | 265 +-----+-----------------------+ 267 Figure 1: Example of ADU defining a single JPEG XS frame 269 4.1. Payload Header 271 Figure 2 illustrates the RTP payload header used in order to 272 transport a JPEG XS stream. 274 0 1 2 3 275 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 276 +---+-+-+-------+-+-------------+-------------------------------+ 277 | V |P|X| CC |M| PT | Sequence number | 278 +---+-+-+-------+-+-------------+-------------------------------+ 279 | Timestamp | 280 +---------------------------------------------------------------+ 281 | Synchronization source (SSRC) identifier | 282 +===============================================================+ 283 | Contributing source (CSRC) identifiers | 284 | .... | 285 +-+-------------+-----------------------+-----------------------+ 286 |L|Frame counter| Slice counter | Packet counter | 287 +-+-------------+-----------------------+-----------------------+ 288 | Data | 289 +---------------------------------------------------------------+ 291 Figure 2: RTP and payload headers 293 The version (V), padding (P), extension (X), CSRC count (CC), 294 sequence number, synchronization source (SSRC) and contributing 295 source (CSRC) fields follow their respective definitions in RFC 3550 296 [RFC3550]. 298 The timestamp SHOULD be based on a 90 kHz clock reference. 300 As per specified in RFC 3550 [RFC3550] and RFC 4175 [RFC4175], the 301 RTP timestamp designates the sampling instant of the first octet of 302 the frame to which the RTP packet belongs. Packets shall not include 303 data from multiple frames, and all packets belonging to the same 304 frame shall have the same timestamp. Several successive RTP packets 305 will consequently have equal timestamps if they belong to the same 306 frame (that is until the marker bit is set to 1, marking the last 307 packet of the frame), and the timestamp is only increased when a new 308 frame begins. 310 If the sampling instant does not correspond to an integer value of 311 the clock, the value shall be truncated to the next lowest integer, 312 with no ambiguity. 314 The remaining fields are defined as follows: 316 Marker (M) [1 bit]: 317 The M bit is used to indicate the last packet of a frame. This 318 enables a decoder to finish decoding the frame, where it otherwise 319 may need to wait for the next packet to explicitly know that the 320 frame is finished. 322 Payload Type (PT) [7 bits]: 323 A dynamically allocated payload type field that designates the 324 payload as JPEG XS video. 326 Last (L) [1 bit]: 327 The L bit is set to indicate the last packet of the JPEG XS header 328 segment or a slice. It enables the decoder to already start 329 decoding a slice without having to wait for the full frame to 330 finish, and thus allows low-latency decoding. As the end of the 331 frame also ends the packet containing the last slice of the frame, 332 the L bit is set whenever the M bit is set. 334 Frame counter [7 bits]: 335 This field identifies the frame number modulo 128 to which a 336 packet belongs. Frame numbers increment by 1 for each frame 337 transmitted. The frame number, in addition to the time stamp, may 338 help the decoder to manage its input buffer and to bring packets 339 back into their natural order. 341 Slice counter [12 bits]: 342 This field identifies the slice modulo 4096 to which the packet 343 contributes. If the data belongs to the JPEG XS header segment, 344 this field shall have its maximal value, namely 4095 = 0x0fff. 345 Otherwise, it is the slice index modulo 4096. Slice indices count 346 from 0 at the top of the frame to their maximum number. 348 Packet counter [12 bits]: 349 This field identifies the packet number modulo 4096 within the 350 JPEG XS header segment or a slice. The packet counter is set to 0 351 at the start of the JPEG XS header segment and incremented by 1 352 for every subsequent packet (if any) of this JPEG XS header 353 segment. The packet counter is then reset to 0 at the start of 354 every slice, and incremented by 1 for every packet that 355 contributes to the same slice. 357 4.2. Payload Data 359 The payload data of a JPEG XS RTP stream consists of a concatenation 360 of multiple JPEG XS frames. 362 Each JPEG XS frame is the concatenation of a JPEG XS header segment 363 followed by one or several slices completely defining a single frame. 364 Figure 3 depicts this layout. 366 +--------[ JPEG XS header segment ]---------+ 367 | Video support box | Slice counter = 0x0fff 368 | +-------------------------------------+ | 369 | | Sub boxes of the video support box | | 370 | +-------------------------------------+ | 371 | : additional sub-boxes of the vs-box : | 372 | +-------------------------------------+ | 373 | | 374 +-------------------------------------------+ 375 | Colour specification box | 376 | +-------------------------------------+ | 377 | | Specification method (METH = 5) | | 378 | +-------------------------------------+ | 379 | : additional fields of the cs-box : | 380 | +-------------------------------------+ | 381 | | 382 +-------------------------------------------+ 383 | JPEG XS codestream header | 384 | +-------------------------------------+ | 385 | | SOC marker | | 386 | +-------------------------------------+ | 387 | : Additional Marker segments : | 388 | +-------------------------------------+ | 389 | | M = 0, L = 1 390 +-------------------------------------------+ 391 +----------------[ Slices ]-----------------+ 392 | Slice #0 | Slice counter = 0 393 | +-------------------------------------+ | 394 | | SLH Marker | | 395 | +-------------------------------------+ | 396 | : Entropy Coded Data : | 397 | | | | 398 | +-------------------------------------+ | 399 | | M = 0, L = 1 400 +-------------------------------------------+ 401 | Slice #1 | Slice counter = 1 402 : : M = 0, L = 1 403 +-------------------------------------------+ 404 : : 405 +-------------------------------------------+ 406 | Slice #N-1 | Slice counter = N-1 407 : : M = 1, L = 1 408 +-------------------------------------------+ 410 Figure 3: JPEG XS Payload Data 412 4.3. Traffic Shaping and Delivery Timing 414 The traffic shaping and delivery timing shall be in accordance with 415 the Network Compatibility Model compliance definitions specified in 416 SMPTE ST 2110-21 [SMPTE-ST2110-21] for either Narrow Linear Senders 417 (Type NL) or Wide Senders (Type W). The session description shall 418 include a format-specific parameter of either TP=2110TPNL or 419 TP=2110TPW to indicate compliance with Type NL or Type W 420 respectively. 422 NOTE: The Virtual Receiver Buffer Model compliance definitions of ST 423 2110-21 do not apply. 425 5. Congestion Control Considerations 427 Congestion control for RTP SHALL be used in accordance with RFC 3550 428 [RFC3550], and with any applicable RTP profile: e.g., RFC 3551 429 [RFC3551]. An additional requirement if best-effort service is being 430 used is users of this payload format MUST monitor packet loss to 431 ensure that the packet loss rate is within acceptable parameters. 432 Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines 433 criteria for when one is required to stop sending RTP Packet Streams 434 and applications implementing this standard MUST comply with it. RFC 435 8085 [RFC8085] provides additional information on the best practices 436 for applying congestion control to UDP streams. 438 6. Payload Format Parameters 440 6.1. Media Type Definition 442 Type name: video 444 Subtype name: jxsv 446 Required parameters: 448 rate: The RTP timestamp clock rate. Applications using this 449 payload format SHOULD use a value of 90000. 451 Optional parameters: 453 profile: The JPEG XS profile in use, as defined in ISO/IEC 21122-2 454 (JPEG XS Part 2) [ISO21122-2]. 456 level: The JPEG XS level in use, as defined in ISO/IEC 21122-2 457 (JPEG XS Part 2) [ISO21122-2]. 459 sublevel: The JPEG XS sublevel in use, as defined in ISO/IEC 460 21122-2 (JPEG XS Part 2) [ISO21122-2]. 462 sampling: Signals the colour difference signal sub-sampling 463 structure. 465 Signals utilizing the non-constant luminance Y'C'B C'R signal 466 format of Recommendation ITU-R BT.601-7, Recommendation ITU-R 467 BT.709-6, Recommendation ITU-R BT.2020-2, or Recommendation ITU-R 468 BT.2100 shall use the appropriate one of the following values for 469 the Media Type Parameter "sampling": 471 YCbCr-4:4:4 (4:4:4 sampling) 472 YCbCr-4:2:2 (4:2:2 sampling) 473 YCbCr-4:2:0 (4:2:0 sampling) 475 Signals utilizing the Constant Luminance Y'C C'BC C'RC signal 476 format of Recommendation ITU-R BT.2020-2 shall use the appropriate 477 one of the following values for the Media Type Parameter 478 "sampling": 480 CLYCbCr-4:4:4 (4:4:4 sampling) 481 CLYCbCr-4:2:2 (4:2:2 sampling) 482 CLYCbCr-4:2:0 (4:2:0 sampling) 484 Signals utilizing the constant intensity I CT CP signal format of 485 Recommendation ITU-R BT.2100 shall use the appropriate one of the 486 following values for the Media Type Parameter "sampling": 488 ICtCp-4:4:4 (4:4:4 sampling) 489 ICtCp-4:2:2 (4:2:2 sampling) 490 ICtCp-4:2:0 (4:2:0 sampling) 492 Signals utilizing the 4:4:4 R' G' B' or RGB signal format (such as 493 that of Recommendation ITU-R BT.601, Recommendation ITU-R BT.709, 494 Recommendation ITU-R BT.2020, Recommendation ITU-R BT.2100, SMPTE 495 ST 2065-1 or ST 2065-3) shall use the following value for the Media 496 Type Parameter sampling. 498 RGB RGB or R' G' B' samples 500 Signals utilizing the 4:4:4 X' Y' Z' signal format (such as defined 501 in SMPTE ST 428-1) shall use the following value for the Media Type 502 Parameter sampling. 504 XYZ X' Y' Z' samples 506 Key signals as defined in SMPTE RP 157 shall use the value key for 507 the Media Type Parameter sampling. The Key signal is represented 508 as a single component. 510 KEY samples of the key signal 512 depth: Determines the number of bits per sample. This is an 513 integer with typical values including 8, 10, 12, and 16. 515 width: Determines the number of pixels per line. This is an 516 integer between 1 and 32767. 518 height: Determines the number of lines per frame. This is an 519 integer between 1 and 32767. 521 exactframerate: Signals the frame rate in frames per second. 522 Integer frame rates shall be signaled as a single decimal number 523 (e.g. "25") whilst non-integer frame rates shall be signaled as a 524 ratio of two integer decimal numbers separated by a "forward-slash" 525 character (e.g. "30000/1001"), utilizing the numerically smallest 526 numerator value possible. 528 colorimetry: Specifies the system colorimetry used by the image 529 samples. Valid values and their specification are: 531 BT601-5 ITU Recommendation BT.601-5 532 BT709-2 ITU Recommendation BT.709-2 533 SMPTE240M SMPTE standard 240M 534 BT601 as specified in Recommendation ITU-R BT.601-7 535 BT709 as specified in Recommendation ITU-R BT.709-6 536 BT2020 as specified in Recommendation ITU-R BT.2020-2 537 BT2100 as specified in Recommendation ITU-R BT.2100 538 Table 2 titled "System colorimetry" 539 ST2065-1 as specified in SMPTE ST 2065-1 Academy Color 540 Encoding Specification (ACES) 541 ST2065-3 as specified for Academy Density Exchange 542 Encoding (ADX) in SMPTE ST 2065-3 543 XYZ as specified in ISO 11664-1 section titled 544 "1931 Observer" 546 Signals utilizing the Recommendation ITU-R BT.2100 colorimetry 547 should also signal the representational range using the optional 548 parameter RANGE defined below. 550 interlace: If this OPTIONAL parameter name is present, it indicates 551 that the video is interlaced. If this parameter name is not 552 present, the progressive video format shall be assumed. 554 TCS: Transfer Characteristic System. This parameter specifies the 555 transfer characteristic system of the image samples. Valid values 556 and their specification are: 558 SDR (Standard Dynamic Range) Video streams of standard 559 dynamic range, that utilize the OETF of Recommendation 560 ITU-R BT.709 or Recommendation ITU-R BT.2020. Such 561 streams shall be assumed to target the EOTF specified 562 in ITU-R BT.1886. 563 PQ Video streams of high dynamic range video that utilize 564 the Perceptual Quantization system of Recommendation 565 ITU-R BT.2100 566 HLG Video streams of high dynamic range video that utilize 567 the Hybrid Log-Gamma system of Recommendation ITU-R 568 BT.2100 570 RANGE: This parameter should be used to signal the encoding range 571 of the sample values within the stream. When paired with ITU Rec 572 BT.2100 colorimetry, this parameter has two allowed values NARROW 573 and FULL, corresponding to the ranges specified in table 9 of ITU 574 Rec BT.2100. In any other context, this parameter has three 575 allowed values: NARROW, FULLPROTECT, and FULL, which correspond to 576 the ranges specified in SMPTE RP 2077. In the absence of this 577 parameter, NARROW shall be the assumed value in either case. 579 Encoding considerations: 580 This media type is framed and binary; see Section 4.8 in RFC 6838 581 [RFC6838]. 583 Security considerations: 584 Please see the Security Considerations section in RFC XXXX 586 6.2. Mapping to SDP 588 6.2.1. General 590 A Session Description Protocol (SDP) object shall be created for each 591 RTP stream and it shall be in accordance with the provisions of SMPTE 592 ST 2110-10 [SMPTE-ST2110-10]. 594 The information carried in the media type specification has a 595 specific mapping to fields in the Session Description Protocol (SDP), 596 which is commonly used to describe RTP sessions. 598 6.2.2. Media type and subtype 600 The media type ("video") goes in SDP "m=" as the media name. 602 The media subtype ("jxsv") goes in SDP "a=rtpmap" as the encoding 603 name, followed by a slash ("/") and the required parameter "rate" 604 corresponding to the RTP timestamp clock rate (which for the payload 605 format defined in this document MUST be 90000). The optional 606 parameters go in the SDP "a=fmtp" attribute by copying them directly 607 from the MIME media type string as a semicolon-separated list of 608 parameter=value pairs. 610 A sample SDP mapping for JPEG XS video is as follows: 612 m=video 30000 RTP/AVP 112 613 a=rtpmap:112 jxsv/90000 614 a=fmtp:112 sampling=YCbCr-4:2:2; width=1920; height=1080; 615 depth=10; colorimetry=BT709; TCS=SDR; 616 RANGE=FULL; TP=2110TPNL 618 In this example, a JPEG XS RTP stream is being sent to UDP 619 destination port 30000, with an RTP dynamic payload type of 112 and a 620 media clock rate of 90000 Hz. Note that the "a=fmtp:" line has been 621 wrapped to fit this page, and will be a single long line in the SDP 622 file. 624 6.2.3. Traffic shaping 626 The SDP object shall include the TP parameter (either 2110TPNL or 627 2110TPW as specified in Section 4.3) and may include the CMAX 628 parameter as specified in SMPTE ST 2110-21 [SMPTE-ST2110-21]. 630 6.2.4. Offer/Answer Considerations 632 The following considerations apply when using SDP offer/answer 633 procedures [RFC3264] to negotiate the use of the JPEG XS payload in 634 RTP: 636 o The "encode" parameter can be used for sendrecv, sendonly, and 637 recvonly streams. Each encode type MUST use a separate payload 638 type number. 640 o Any unknown parameter in an offer MUST be ignored by the receiver 641 and MUST NOT be included in the answer. 643 7. IANA Considerations 645 This memo requests that IANA registers video/jxsv as specified in 646 Section 6.1. The media type is also requested to be added to the 647 IANA registry for "RTP Payload Format MIME types" [1]. 649 8. Security Considerations 651 RTP packets using the payload format defined in this specification 652 are subject to the security considerations discussed in the RTP 653 specification [RFC3550] and in any applicable RTP profile such as 654 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ 655 SAVPF [RFC5124]. This implies that confidentiality of the media 656 streams is achieved by encryption. 658 However, as "Securing the RTP Framework: Why RTP Does Not Mandate a 659 Single Media Security Solution" [RFC7202] discusses, it is not an RTP 660 payload format's responsibility to discuss or mandate what solutions 661 are used to meet the basic security goals like confidentiality, 662 integrity, and source authenticity for RTP in general. This 663 responsibility lies on anyone using RTP in an application. They can 664 find guidance on available security mechanisms and important 665 considerations in "Options for Securing RTP Sessions" [RFC7201]. 666 Applications SHOULD use one or more appropriate strong security 667 mechanisms. 669 This payload format and the JPEG XS encoding do not exhibit any 670 substantial non-uniformity, either in output or in complexity to 671 perform the decoding operation and thus are unlikely to pose a 672 denial-of-service threat due to the receipt of pathological 673 datagrams. 675 It is important to note that HD or UHDTV JPEG XS-encoded video can 676 have significant bandwidth requirements (typically more than 1 Gbps 677 for ultra high-definition video, especially if using high framerate). 678 This is sufficient to cause potential for denial-of-service if 679 transmitted onto most currently available Internet paths. 681 Accordingly, if best-effort service is being used, users of this 682 payload format MUST monitor packet loss to ensure that the packet 683 loss rate is within acceptable parameters. Packet loss is considered 684 acceptable if a TCP flow across the same network path, and 685 experiencing the same network conditions, would achieve an average 686 throughput, measured on a reasonable timescale, that is not less than 687 the RTP flow is achieving. This condition can be satisfied by 688 implementing congestion control mechanisms to adapt the transmission 689 rate (or the number of layers subscribed for a layered multicast 690 session), or by arranging for a receiver to leave the session if the 691 loss rate is unacceptably high. 693 This payload format may also be used in networks that provide 694 quality-of-service guarantees. If enhanced service is being used, 695 receivers SHOULD monitor packet loss to ensure that the service that 696 was requested is actually being delivered. If it is not, then they 697 SHOULD assume that they are receiving best-effort service and behave 698 accordingly. 700 9. RFC Editor Considerations 702 Note to RFC Editor: This section may be removed after carrying out 703 all the instructions of this section. 705 RFC XXXX is to be replaced by the RFC number this specification 706 receives when published. 708 10. References 710 10.1. Normative References 712 [ISO21122-1] 713 International Organization for Standardization (ISO) - 714 International Electrotechnical Commission (IEC), 715 "Information technology - JPEG XS low-latency lightweight 716 image coding system - Part 1: Core coding system", ISO/ 717 IEC PRF 21122-1, under development, 718 . 720 [ISO21122-2] 721 International Organization for Standardization (ISO) - 722 International Electrotechnical Commission (IEC), 723 "Information technology - JPEG XS low-latency lightweight 724 image coding system - Part 2: Profiles and buffer models", 725 ISO/IEC PRF 21122-2, under development, 726 . 728 [ISO21122-3] 729 International Organization for Standardization (ISO) - 730 International Electrotechnical Commission (IEC), 731 "Information technology - JPEG XS low-latency lightweight 732 image coding system - Part 3: Transport and container 733 formats", ISO/IEC FDIS 21122-3, under development, 734 . 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, 738 DOI 10.17487/RFC2119, March 1997, 739 . 741 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 742 with Session Description Protocol (SDP)", RFC 3264, 743 DOI 10.17487/RFC3264, June 2002, 744 . 746 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 747 Jacobson, "RTP: A Transport Protocol for Real-Time 748 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 749 July 2003, . 751 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 752 Video Conferences with Minimal Control", STD 65, RFC 3551, 753 DOI 10.17487/RFC3551, July 2003, 754 . 756 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 757 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 758 RFC 3711, DOI 10.17487/RFC3711, March 2004, 759 . 761 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 762 Specifications and Registration Procedures", BCP 13, 763 RFC 6838, DOI 10.17487/RFC6838, January 2013, 764 . 766 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 767 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 768 DOI 10.17487/RFC8083, March 2017, 769 . 771 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 772 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 773 March 2017, . 775 [SMPTE-ST2110-10] 776 Society of Motion Picture and Television Engineers, "SMPTE 777 Standard - Professional Media Over Managed IP Networks: 778 System Timing and Definitions", SMPTE ST 2110-10:2017, 779 2017, . 781 [SMPTE-ST2110-21] 782 Society of Motion Picture and Television Engineers, "SMPTE 783 Standard - Professional Media Over Managed IP Networks: 784 Traffic Shaping and Delivery Timing for Video", SMPTE ST 785 2110-21:2017, 2017, 786 . 788 10.2. Informative References 790 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 791 Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, 792 September 2005, . 794 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 795 "Extended RTP Profile for Real-time Transport Control 796 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 797 DOI 10.17487/RFC4585, July 2006, 798 . 800 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 801 Real-time Transport Control Protocol (RTCP)-Based Feedback 802 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 803 2008, . 805 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 806 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 807 . 809 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 810 Framework: Why RTP Does Not Mandate a Single Media 811 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 812 2014, . 814 10.3. URIs 816 [1] http://www.iana.org/assignments/rtp-parameters 818 Authors' Addresses 820 Sebastien Lugan 821 intoPIX S.A. 822 Rue Emile Francqui, 9 823 1435 Mont-Saint-Guibert 824 Belgium 826 Phone: +32 10 23 84 70 827 Email: D313B41E@dynmail.crt1.net 828 URI: http://www.intopix.com 829 Gael Rouvroy 830 intoPIX S.A. 831 Rue Emile Francqui, 9 832 1435 Mont-Saint-Guibert 833 Belgium 835 Phone: +32 10 23 84 70 836 Email: g.rouvroy@intopix.com 837 URI: http://www.intopix.com 839 Antonin Descampe 840 intoPIX S.A. 841 Rue Emile Francqui, 9 842 1435 Mont-Saint-Guibert 843 Belgium 845 Phone: +32 10 23 84 70 846 Email: a.descampe@intopix.com 847 URI: http://www.intopix.com 849 Thomas Richter 850 Fraunhofer IIS 851 Am Wolfsmantel 33 852 91048 Erlangen 853 Germany 855 Phone: +49 9131 776 5126 856 Email: thomas.richter@iis.fraunhofer.de 857 URI: https://www.iis.fraunhofer.de/ 859 Alexandre Willeme 860 Universite catholique de Louvain 861 Place du Levant, 2 - bte L5.04.04 862 1348 Louvain-la-Neuve 863 Belgium 865 Phone: +32 10 47 80 82 866 Email: alexandre.willeme@uclouvain.be 867 URI: https://uclouvain.be/en/icteam