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