idnits 2.17.1 draft-lugan-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 (November 8, 2018) is 1993 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 860 == Unused Reference: 'RFC8085' is defined on line 809, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO15444-1' -- 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 (==), 9 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: May 12, 2019 intoPIX 6 T. Richter 7 IIS 8 A. Willeme 9 UCL/ICTEAM 10 November 8, 2018 12 RTP Payload Format for ISO/IEC 21122 (JPEG XS) 13 draft-lugan-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 allowing for an increased resolution and frame rate, while offering 21 visually lossless quality with reduced amount of resources such as 22 power and bandwidth. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 12, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions, Definitions, and Abbreviations . . . . . . . . . 3 60 3. Media Format Description . . . . . . . . . . . . . . . . . . 4 61 3.1. Image Data Structures . . . . . . . . . . . . . . . . . . 4 62 3.2. Codestream . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. Video Support Box . . . . . . . . . . . . . . . . . . . . 6 64 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Payload Header . . . . . . . . . . . . . . . . . . . . . 7 66 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 9 67 4.3. Traffic Shaping and Delivery Timing . . . . . . . . . . . 10 68 5. Congestion Control Considerations . . . . . . . . . . . . . . 10 69 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11 70 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 11 71 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 14 72 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 14 73 6.2.2. Media type and subtype . . . . . . . . . . . . . . . 14 74 6.2.3. Traffic shaping . . . . . . . . . . . . . . . . . . . 15 75 6.2.4. Offer/Answer Considerations . . . . . . . . . . . . . 15 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 16 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 10.2. Informative References . . . . . . . . . . . . . . . . . 18 82 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 This document specifies a payload format for packetization of JPEG XS 88 encoded video signals into the Real-time Transport Protocol (RTP) 89 [RFC3550]. 91 JPEG XS is a low-latency, lightweight image coding system allowing 92 for an increased resolution and frame rate, while offering visually 93 lossless quality with reduced amount of resources such as power and 94 bandwidth. 96 2. Conventions, Definitions, and Abbreviations 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 Application Data Unit: 103 The unit of source data provided as payload to the transport 104 layer, and corresponding, in this RTP payload definition, to a 105 JPEG XS frame. 107 EOC Marker 108 A marker that consists of the two bytex 0xff 0x10 indicating the 109 start of a JPEG XS codestream. 111 JPEG XS codestream: 112 A sequence of bytes representing a compressed image formatted 113 according to JPEG XS Part 1 [ISO21122-1]. 115 JPEG XS frame: 116 The concatenation of a Video Support Box, as defined in JPEG XS 117 Part 3 [ISO21122-3], and a JPEG XS codestream. 119 JPEG XS stream: 120 A JPEG XS stream is a sequence of frames, where each frame is 121 coded independently of each other. For the purpose of RTP 122 transport, each frame forms an Application Data Unit (ADU). 124 Marker: 125 A two-byte functional sequence that is part of a JPEG XS 126 codestream starting with a 0xff byte and a subsequent byte 127 defining its function. 129 Marker Segment: 130 A marker along with a 16-bit marker size and payload data 131 following the size. 133 JPEG XS Header: 134 A sequence of bytes at the beginning of each JPEG XS codestream 135 encoded in multiple markers and marker segments that does not 136 carry entropy coded data, but metadata such as the frame dimension 137 and component precision. 139 SOC Marker 140 A marker that consists of the two bytex 0xff 0x11 indicating the 141 end of a JPEG XS codestream. 143 Video Support Box: 145 A ISO video support box in the sense of ISO/IEC 15444-1 146 [ISO15444-1] defined in ISO/IEC 21122-3 [ISO21122-3] that includes 147 metadata required to play back a JPEG XS video stream, such as its 148 color space, its maximum bitrate, its subsampling structure, its 149 buffer model and its frame rate. 151 JPEG XS Header Segment: 152 The concatenation of a Video Support Box and JPEG XS header. 154 Slice: 155 The smallest independently decodable unit of a JPEG XS codestream, 156 bearing in mind that it decodes to wavelet coefficients which 157 still require inverse wavelet filtering to give an image. 159 Slice group: 160 A contiguous sequence of slices. 162 Fragment: 163 A fragment consists of one slice group, possibly preceded by a 164 JPEG XS header segment (if the slice group is the first one of a 165 JPEG XS frame), and possibly followed by the EOC marker (if the 166 slice group is the last one of a JPEG XS frame). 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 color 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 Multiple contiguous slices are combined into slice groups. Slice 196 groups along with preceding and/or following metadata form fragments. 197 A fragment, and by that the corresponding slice group, is sized such 198 that it is spread over at least two distinct RTP packets, except for 199 the last fragment of an Application Data Unit. 201 Slice groups within a frame are enumerated from top to bottom by the 202 slice group counter. That is, the first slice group of a frame is 203 slice group #0, and the slice group counter increments by 1 from top 204 to bottom for each slice group, and by that for each fragment. 206 Figure 1 shows an example of packets, slices, slice groups and 207 fragments. In this Figure, MDT indicates metadata preceding or 208 following slice groups, SlcGrp the slice groups and Slc the slices. 209 As seen there, a fragment may contain more than one slice if the 210 slices are too short to fill up an entire packet, and fragment and 211 packet boundaries need only to align at the start and the end of the 212 ADU. Fragments may extend over more than two packets, depending on 213 their size, but a packet never contains two entire fragments or more. 214 Slice group and fragment boundaries coincide, except for the first 215 and the last fragment, which include additional metadata. Unlike 216 regularly sized packets, the fragment and the slice group size may 217 vary. 219 <------------------- Application Data Unit (ADU) -------------------> 221 +-----------+-----------+-----------+-----------+-/ /-+-------------+ 222 | Packet #0 | Packet #1 | Packet #2 | Packet #3 | | Packet #n-1 | 223 +-----------+---+-------+-----------+---+-------+-/ /-+-------------+ 224 | Fragment #0 | Fragment #1 | Fragment #m-1 | 225 +---+-----------+-----------------------+---------/ /-----------+---+ 226 |MDT| SlcGrp #0 | SlcGrp #1 | SlcGrp #m-1 | M | 227 +---+-----------+-----------------------+---------/ /-----------+---+ 228 |MDT|Slc#0 Slc#1| Slc #2 | Slc #k-1 | M | 229 +---+-----------+-----------------------+---------/ /-----------+---+ 231 Figure 1: Slice Groups and Fragments 233 3.2. Codestream 235 The overall codestream format, including the definition of all 236 markers, is further defined in ISO/IEC 21122-1 [ISO21122-1]. It 237 represents sample values of a single frame, bare any interpretation 238 relative to a colorspace. 240 3.3. Video Support Box 242 While the information defined in the codestream is sufficient to 243 reconstruct the sample values of one video frame, the interpretation 244 of the samples remains undefined by the codestream itself. This 245 interpretation, including the color space, frame rate and other 246 information significant to play a JPEG XS stream are contained in the 247 Video Support Box, which precedes each JPEG XS codestream. The 248 syntax of the Video Support Box follows ISO/IEC 15444-1 [ISO15444-1]; 249 it consists of multiple subboxes, each with a particular meaning. 250 Its contents, in particular its subboxes are defined in ISO/IEC 251 21122-3 [ISO21122-3]. 253 4. Payload Format 255 This section specifies the payload format for JPEG XS video streams 256 over the Real-time Transport Protocol (RTP) [RFC3550]. 258 In order to be transported over RTP, each JPEG XS stream is 259 transported in a distinct RTP stream, identified by a distinct SSRC. 261 Each of those RTP streams is divided into Application Data Units 262 (ADUs). 264 Each ADU is split into packets, depending e.g. on the Maximum 265 Transmission unit (MTU) of the network. Every packet shall have the 266 same size, except the last packet of every ADU which could be 267 shorter. Packet boundaries shall coincide with ADU boundaries, i.e. 268 the first (resp. last) byte of an ADU shall be the first (resp. last) 269 byte of an RTP packet payload data. 271 The following figure illustrates the RTP payload header used in order 272 to 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 | Ver |f|c| SlcGrp | SlcGrpOffset | Frame counter | 287 +-----+-+-+---------+---------------------+---------------------+ 288 | Data | 289 +---------------------------------------------------------------+ 291 Figure 2: RTP and payload headers 293 4.1. Payload Header 295 The version (V), padding (P), extension (X), CSRC count (CC), 296 sequence number, synchronization source (SSRC) and contributing 297 source (CSRC) fields follow their respective definitions in RFC 3550 298 [RFC3550]. 300 The timestamp should be based on a globally synchronized 90 kHz clock 301 reference, and should correspond to the number of cycles since the 302 SMPTE Epoch (as per defined in SMPTE ST 2059-1:2015 [SMPTE-ST2059]) 303 modulo 2^32: 305 timestamp = floor(time_since_epoch*90000) % 2^32 307 where time_since_epoch is the time elapsed since the SMPTE Epoch, 308 expressed in seconds as a real number, and floor indicates rounding 309 to the next lower integer. 311 As per specified in RFC 3550 [RFC3550] and RFC 4175 [RFC4175], the 312 RTP timestamp designates the sampling instant of the first octet of 313 the frame to which the RTP packet belongs. Packets shall not include 314 data from multiple frames, and all packets belonging to the same 315 frame shall have the same timestamp. Several successive RTP packets 316 will consequently have equal timestamps if they belong to the same 317 frame (that is until the marker bit is set to 1, marking the last 318 packet of the frame), and the timestamp is only increased when a new 319 frame begins. 321 If the sampling instant does not correspond to an integer value of 322 the clock, the value shall be truncated to the next lowest integer, 323 with no ambiguity. 325 The remaining fields are defined as follows: 327 Marker (M) [1 bit]: 328 The marker bit is used to indicate the last packet of a frame. 329 This enables a decoder to finish decoding the frame, where it 330 otherwise may need to wait for the next packet to explicitly know 331 that the frame is finished. 333 Payload Type (PT) [7 bits]: 334 A dynamically allocated payload type field that designates the 335 payload as JPEG XS video. 337 Ver [3 bits]: 338 This field indicates the version number of the payload header. 339 The value of this field shall be 0 for the purpose of this edition 340 of the RFC. 342 f [1 bit]: 343 The f field shall be set if a new fragment is started within this 344 packet, i.e. if this packet contains the first byte of a fragment. 346 NOTE: The JPEG XS header segment and the first slice group form a 347 fragment. For that reason, the f-bit remains unset in the packet 348 that contains the first byte of slice group 0 but does not also 349 contains the first byte of the Video Support box. All other slice 350 groups form fragments of their own. The f bit allows a quick 351 identification of packets that start a fragment. The SlcGrpOffset 352 field (see below) can be used to identify the start of a slice 353 group. 355 c [1 bit]: 356 The c field is a one-bit field that is set if the fragment to 357 which the first byte of the packet belongs extends througout a 358 subsequent packet. 360 SlcGrp [5 bits]: 361 The SlcGrp (Slice Group) field contains the slice group index 362 modulo 32 that is contained in the fragment that is started in 363 this packet. If no fragment starts in this packet, it contains 364 the slice group index modulo 64 of the slice group that is 365 contained in the fragment to which the first byte of the payload 366 data of this packet belongs. 368 SlcGrpOffset [11 bits]: 370 This field indicates the byte offset of the slice header marker 371 (SLH, hex 0xff20, see ISO/IEC 21122-1 [ISO21122-1]) of the slice 372 group that starts in this packet, relative to the Ver field. If 373 no slice group starts in this packet, this field shall be 0. 375 NOTE: Since the payload data has a non-zero offset within a 376 packet, this field can also be used to identify whether a slice 377 group starts in a packet. If 0, no slice group starts in this 378 packet. Consequently, for all slice groups in a frame except the 379 first one, this field will be non-zero if and only if the f-field 380 is set. 382 Frame counter [11 bits]: 383 Counter indicating the current frame number modulo 2^11. The 384 frame number is incremented by one at the beginning of each frame, 385 and stays constant throughout all packets that contribute to to 386 the same frame. 388 4.2. Payload Data 390 The payload data of a JPEG XS transport stream consists of a 391 concatenation of multiple JPEG XS Frames. 393 Each JPEG XS frame is the concatenation of multiple fragments where 394 each fragment contains one and only one slice group. The first 395 fragment of a frame also contains the Video Support box and the JPEG 396 XS header, the last fragment also contains the EOC marker. Figure 3 397 depicts this layout. 399 ^ +-------------------------------------------+ ^ 400 | | Video Support Box | | 401 | | +-------------------------------------+ | | 402 | | | Sub boxes of the Video Support Box | | | 403 Frag- | +-------------------------------------+ | JPEG 404 ment | : additional sub-boxes of the VE-Box : | XS 405 #0 | +-------------------------------------+ | Header 406 | | | Seg- 407 | +-------------------------------------------+ ment 408 | | JPEG XS Header | | 409 | | +-------------------------------------+ | | 410 | | | SOC Marker | | | 411 | | +-------------------------------------+ | | 412 | | : Additional Marker Segments : | | 413 | | +-------------------------------------+ | | 414 | | | | 415 | +-------------------------------------------+ v 416 | | Slice Group #0 | 417 | | +-------------------------------------+ | 418 | | | Slice #0 of Slice Group #0 | | 419 | | | +-------------------------------+ | | 420 | | | | SLH Marker | | | 421 | | | +-------------------------------+ | | 422 | | | : Entropy Coded Data : | | 423 | | | +-------------------------------+ | | 424 | | +-------------------------------------+ | 425 | | | Slice #1 of Slice Group #0 | | 426 | | : : | 427 | | +-------------------------------------+ | 428 | | | Slice #n-1 of Slice Group #0 | | 429 | | : : | 430 v | +-------------------------------------+ | 431 ^ +-------------------------------------------+ 432 | | Slice Group #1 | 433 Frag- : : 434 ment : : 435 #1 : : 436 | : : 437 v +-------------------------------------------+ 438 : : 439 ^ +-------------------------------------------+ 440 | | Slice Group #n-1 | 441 Frag- : : 442 ment : : 443 #n-1 +-------------------------------------------+ 444 | | EOC Marker | 445 v +-------------------------------------------+ 447 Figure 3: JPEG XS Payload Data 449 4.3. Traffic Shaping and Delivery Timing 451 The traffic shaping and delivery timing shall be in accordance with 452 the Network Compatibility Model compliance definitions specified in 453 SMPTE ST 2110-21 [SMPTE-ST2110-21] for either Narrow Linear Senders 454 (Type NL) or Wide Senders (Type W). 456 NOTE: The Virtual Receiver Buffer Model compliance definitions of ST 457 2110-21 do not apply. 459 5. Congestion Control Considerations 461 Congestion control for RTP SHALL be used in accordance with RFC 3550 462 [RFC3550], and with any applicable RTP profile: e.g., RFC 3551 463 [RFC3551]. An additional requirement if best-effort service is being 464 used is users of this payload format MUST monitor packet loss to 465 ensure that the packet loss rate is within acceptable parameters. 467 Circuit Breakers [RFC8083] is an update to RTP [RFC3550] that defines 468 criteria for when one is required to stop sending RTP Packet Streams 469 and applications implementing this standard MUST comply with it. RFC 470 8085 [RFC8083] provides additional information on the best practices 471 for applying congestion control to UDP streams. 473 6. Payload Format Parameters 475 6.1. Media Type Definition 477 Type name: video 479 Subtype name: jpeg-xs 481 Required parameters: 483 rate: The RTP timestamp clock rate. Applications using this 484 payload format SHOULD use a value of 90000. 486 Optional parameters: 488 profile: The JPEG XS profile in use, as defined in JPEG XS Part 2 489 [ISO21122-2]. 491 level: The JPEG XS level in use, as defined in JPEG XS Part 2 492 [ISO21122-2]. 494 sublevel: The JPEG XS sublevel in use, as defined in JPEG XS Part 2 495 [ISO21122-2]. 497 sampling: Signals the color difference signal sub-sampling 498 structure. 500 Signals utilizing the non-constant luminance Y'C'B C'R signal 501 format of Recommendation ITU-R BT.601-7, Recommendation ITU-R 502 BT.709-6, Recommendation ITU-R BT.2020-2, or Recommendation ITU-R 503 BT.2100 shall use the appropriate one of the following values for 504 the Media Type Parameter "sampling": 506 YCbCr-4:4:4 (4:4:4 sampling) 507 YCbCr-4:2:2 (4:2:2 sampling) 508 YCbCr-4:2:0 (4:2:0 sampling) 510 Signals utilizing the Constant Luminance Y'C C'BC C'RC signal 511 format of Recommendation ITU-R BT.2020-2 shall use the appropriate 512 one of the following values for the Media Type Parameter 513 "sampling": 515 CLYCbCr-4:4:4 (4:4:4 sampling) 516 CLYCbCr-4:2:2 (4:2:2 sampling) 517 CLYCbCr-4:2:0 (4:2:0 sampling) 519 Signals utilizing the constant intensity I CT CP signal format of 520 Recommendation ITU-R BT.2100 shall use the appropriate one of the 521 following values for the Media Type Parameter "sampling": 523 ICtCp-4:4:4 (4:4:4 sampling) 524 ICtCp-4:2:2 (4:2:2 sampling) 525 ICtCp-4:2:0 (4:2:0 sampling) 527 Signals utilizing the 4:4:4 R' G' B' or RGB signal format (such as 528 that of Recommendation ITU-R BT.601, Recommendation ITU-R BT.709, 529 Recommendation ITU-R BT.2020, Recommendation ITU-R BT.2100, SMPTE 530 ST 2065-1 or ST 2065-3) shall use the following value for the Media 531 Type Parameter sampling. 533 RGB RGB or R' G' B' samples 535 Signals utilizing the 4:4:4 X' Y' Z' signal format (such as defined 536 in SMPTE ST 428-1) shall use the following value for the Media Type 537 Parameter sampling. 539 XYZ X' Y' Z' samples 541 Key signals as defined in SMPTE RP 157 shall use the value key for 542 the Media Type Parameter sampling. The Key signal is represented 543 as a single component. 545 KEY samples of the key signal 547 depth: Determines the number of bits per sample. This is an 548 integer with typical values including 8, 10, 12, and 16. 550 width: Determines the number of pixels per line. This is an 551 integer between 1 and 32767. 553 height: Determines the number of lines per frame. This is an 554 integer between 1 and 32767. 556 exactframerate: Signals the frame rate in frames per second. 557 Integer frame rates shall be signaled as a single decimal number 558 (e.g. "25") whilst non-integer frame rates shall be signaled as a 559 ratio of two integer decimal numbers separated by a "forward-slash" 560 character (e.g. "30000/1001"), utilizing the numerically smallest 561 numerator value possible. 563 colorimetry: Specifies the system colorimetry used by the image 564 samples. Valid values and their specification are: 566 BT601-5 ITU Recommendation BT.601-5 567 BT709-2 ITU Recommendation BT.709-2 568 SMPTE240M SMPTE standard 240M 569 BT601 as specified in Recommendation ITU-R BT.601-7 570 BT709 as specified in Recommendation ITU-R BT.709-6 571 BT2020 as specified in Recommendation ITU-R BT.2020-2 572 BT2100 as specified in Recommendation ITU-R BT.2100 573 Table 2 titled "System colorimetry" 574 ST2065-1 as specified in SMPTE ST 2065-1 Academy Color 575 Encoding Specification (ACES) 576 ST2065-3 as specified for Academy Density Exchange 577 Encoding (ADX) in SMPTE ST 2065-3 578 XYZ as specified in ISO 11664-1 section titled 579 "1931 Observer" 581 Signals utilizing the Recommendation ITU-R BT.2100 colorimetry 582 should also signal the representational range using the optional 583 parameter RANGE defined below. 585 interlace: If this OPTIONAL parameter name is present, it indicates 586 that the video is interlaced. If this parameter name is not 587 present, the progressive video format shall be assumed. 589 TCS: Transfer Characteristic System. This parameter specifies the 590 transfer characteristic system of the image samples. Valid values 591 and their specification are: 593 SDR (Standard Dynamic Range) Video streams of standard 594 dynamic range, that utilize the OETF of Recommendation 595 ITU-R BT.709 or Recommendation ITU-R BT.2020. Such 596 streams shall be assumed to target the EOTF specified 597 in ITU-R BT.1886. 598 PQ Video streams of high dynamic range video that utilize 599 the Perceptual Quantization system of Recommendation 600 ITU-R BT.2100 601 HLG Video streams of high dynamic range video that utilize 602 the Hybrid Log-Gamma system of Recommendation ITU-R 603 BT.2100 605 RANGE: This parameter should be used to signal the encoding range 606 of the sample values within the stream. When paired with ITU Rec 607 BT.2100 colorimetry, this parameter has two allowed values NARROW 608 and FULL, corresponding to the ranges specified in table 9 of ITU 609 Rec BT.2100. In any other context, this parameter has three 610 allowed values: NARROW, FULLPROTECT, and FULL, which correspond to 611 the ranges specified in SMPTE RP 2077. In the absence of this 612 parameter, NARROW shall be the assumed value in either case. 614 Encoding considerations: 615 This media type is framed and binary; see Section 4.8 in RFC 6838 616 [RFC6838]. 618 Security considerations: 619 Please see the Security Considerations section in RFC XXXX 621 6.2. Mapping to SDP 623 6.2.1. General 625 A Session Description Protocol (SDP) object shall be created for each 626 RTP stream and it shall be in accordance with the provisions of SMPTE 627 ST 2110-10 [SMPTE-ST2110-10]. 629 The information carried in the media type specification has a 630 specific mapping to fields in the Session Description Protocol (SDP), 631 which is commonly used to describe RTP sessions. 633 6.2.2. Media type and subtype 635 The media type ("video") goes in SDP "m=" as the media name. 637 The media subtype ("jpeg-xs") goes in SDP "a=rtpmap" as the encoding 638 name. The RTP clock rate in "a=rtpmap" MUST be 90000, which for the 639 payload format defined in this document is a 90 kHz clock. The 640 remaining parameters go in the SDP "a=fmtp" attribute by copying them 641 directly from the MIME media type string as a semicolon-separated 642 list of parameter=value pairs. 644 A sample SDP mapping for JPEG XS video is as follows: 646 m=video 30000 RTP/AVP 112 647 a=rtpmap:112 jpeg-xs/90000 648 a=fmtp:112 sampling=YCbCr-4:2:2; width=1920; height=1080; 649 depth=10; colorimetry=BT709; TCS=SDR; RANGE=FULL 651 In this example, a dynamic payload type 112 is used for JPEG XS 652 video. The RTP sampling clock is 90 kHz. Note that the "a=fmtp:" 653 line has been wrapped to fit this page, and will be a single long 654 line in the SDP file. 656 6.2.3. Traffic shaping 658 The SDP object shall include the TP parameter and may include the 659 CMAX parameter as specified in SMPTE ST 2110-21 [SMPTE-ST2110-21]. 661 6.2.4. Offer/Answer Considerations 663 The following considerations apply when using SDP offer/answer 664 procedures [RFC3264] to negotiate the use of the JPEG XS payload in 665 RTP: 667 o The "encode" parameter can be used for sendrecv, sendonly, and 668 recvonly streams. Each encode type MUST use a separate payload 669 type number. 671 o Any unknown parameter in an offer MUST be ignored by the receiver 672 and MUST NOT be included in the answer. 674 7. IANA Considerations 676 This memo requests that IANA registers video/jpeg-xs as specified in 677 Section 6.1. The media type is also requested to be added to the 678 IANA registry for "RTP Payload Format MIME types" [1]. 680 8. Security Considerations 682 RTP packets using the payload format defined in this specification 683 are subject to the security considerations discussed in the RTP 684 specification [RFC3550] and in any applicable RTP profile such as 685 RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/ 686 SAVPF [RFC5124]. This implies that confidentiality of the media 687 streams is achieved by encryption. 689 However, as "Securing the RTP Framework: Why RTP Does Not Mandate a 690 Single Media Security Solution" [RFC7202] discusses, it is not an RTP 691 payload format's responsibility to discuss or mandate what solutions 692 are used to meet the basic security goals like confidentiality, 693 integrity, and source authenticity for RTP in general. This 694 responsibility lies on anyone using RTP in an application. They can 695 find guidance on available security mechanisms and important 696 considerations in "Options for Securing RTP Sessions" [RFC7201]. 697 Applications SHOULD use one or more appropriate strong security 698 mechanisms. 700 This payload format and the JPEG XS encoding do not exhibit any 701 substantial non-uniformity, either in output or in complexity to 702 perform the decoding operation and thus are unlikely to pose a 703 denial-of-service threat due to the receipt of pathological 704 datagrams. 706 It is important to note that HD or UHDTV JPEG XS-encoded video can 707 have significant bandwidth requirements (typically more than 1 Gbps 708 for ultra high-definition video, especially if using high framerate). 709 This is sufficient to cause potential for denial-of-service if 710 transmitted onto most currently available Internet paths. 712 Accordingly, if best-effort service is being used, users of this 713 payload format MUST monitor packet loss to ensure that the packet 714 loss rate is within acceptable parameters. Packet loss is considered 715 acceptable if a TCP flow across the same network path, and 716 experiencing the same network conditions, would achieve an average 717 throughput, measured on a reasonable timescale, that is not less than 718 the RTP flow is achieving. This condition can be satisfied by 719 implementing congestion control mechanisms to adapt the transmission 720 rate (or the number of layers subscribed for a layered multicast 721 session), or by arranging for a receiver to leave the session if the 722 loss rate is unacceptably high. 724 This payload format may also be used in networks that provide 725 quality-of-service guarantees. If enhanced service is being used, 726 receivers SHOULD monitor packet loss to ensure that the service that 727 was requested is actually being delivered. If it is not, then they 728 SHOULD assume that they are receiving best-effort service and behave 729 accordingly. 731 9. RFC Editor Considerations 733 Note to RFC Editor: This section may be removed after carrying out 734 all the instructions of this section. 736 RFC XXXX is to be replaced by the RFC number this specification 737 receives when published. 739 10. References 741 10.1. Normative References 743 [ISO15444-1] 744 International Organization for Standardization (ISO) - 745 International Electrotechnical Commission (IEC), 746 "Information technology - JPEG 2000 image coding system: 747 Core coding system", ISO/IEC IS 15444-1, 2016, 748 . 750 [ISO21122-1] 751 International Organization for Standardization (ISO) - 752 International Electrotechnical Commission (IEC), 753 "Information technology - Low-latency lightweight image 754 coding system - Part 1: Core coding system", ISO/IEC DIS 755 21122-1, under development, 756 . 758 [ISO21122-2] 759 International Organization for Standardization (ISO) - 760 International Electrotechnical Commission (IEC), 761 "Information technology - Low-latency lightweight image 762 coding system - Part 2: Profiles and buffer models", ISO/ 763 IEC DIS 21122-2, under development, 764 . 766 [ISO21122-3] 767 International Organization for Standardization (ISO) - 768 International Electrotechnical Commission (IEC), 769 "Information technology - Low-latency lightweight image 770 coding system - Part 3: Transport and container formats", 771 ISO/IEC NP 21122-3, under development, 772 . 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, 776 DOI 10.17487/RFC2119, March 1997, 777 . 779 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 780 with Session Description Protocol (SDP)", RFC 3264, 781 DOI 10.17487/RFC3264, June 2002, 782 . 784 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 785 Jacobson, "RTP: A Transport Protocol for Real-Time 786 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 787 July 2003, . 789 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 790 Video Conferences with Minimal Control", STD 65, RFC 3551, 791 DOI 10.17487/RFC3551, July 2003, 792 . 794 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 795 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 796 RFC 3711, DOI 10.17487/RFC3711, March 2004, 797 . 799 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 800 Specifications and Registration Procedures", BCP 13, 801 RFC 6838, DOI 10.17487/RFC6838, January 2013, 802 . 804 [RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: 805 Circuit Breakers for Unicast RTP Sessions", RFC 8083, 806 DOI 10.17487/RFC8083, March 2017, 807 . 809 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 810 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 811 March 2017, . 813 [SMPTE-ST2110-10] 814 Society of Motion Picture and Television Engineers, "SMPTE 815 Standard - Professional Media Over Managed IP Networks: 816 System Timing and Definitions", SMPTE ST 2110-10:2017, 817 2017, . 819 [SMPTE-ST2110-21] 820 Society of Motion Picture and Television Engineers, "SMPTE 821 Standard - Professional Media Over Managed IP Networks: 822 Traffic Shaping and Delivery Timing for Video", SMPTE ST 823 2110-21:2017, 2017, 824 . 826 10.2. Informative References 828 [RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for 829 Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175, 830 September 2005, . 832 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 833 "Extended RTP Profile for Real-time Transport Control 834 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 835 DOI 10.17487/RFC4585, July 2006, 836 . 838 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 839 Real-time Transport Control Protocol (RTCP)-Based Feedback 840 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 841 2008, . 843 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 844 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 845 . 847 [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP 848 Framework: Why RTP Does Not Mandate a Single Media 849 Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 850 2014, . 852 [SMPTE-ST2059] 853 Society of Motion Picture and Television Engineers, "SMPTE 854 Standard - Generation and Alignment of Interface Signals 855 to the SMPTE Epoch", SMPTE ST 2059-1:2015, 2015, 856 . 858 10.3. URIs 860 [1] http://www.iana.org/assignments/rtp-parameters 862 Authors' Addresses 864 Sebastien Lugan 865 intoPIX S.A. 866 Rue Emile Francqui, 9 867 1435 Mont-Saint-Guibert 868 Belgium 870 Phone: +32 10 23 84 70 871 Email: s.lugan@sine.sd2.net 872 URI: http://www.intopix.com 874 Gael Rouvroy 875 intoPIX S.A. 876 Rue Emile Francqui, 9 877 1435 Mont-Saint-Guibert 878 Belgium 880 Phone: +32 10 23 84 70 881 Email: g.rouvroy@intopix.com 882 URI: http://www.intopix.com 884 Antonin Descampe 885 intoPIX S.A. 886 Rue Emile Francqui, 9 887 1435 Mont-Saint-Guibert 888 Belgium 890 Phone: +32 10 23 84 70 891 Email: a.descampe@intopix.com 892 URI: http://www.intopix.com 893 Thomas Richter 894 Fraunhofer IIS 895 Am Wolfsmantel 33 896 91048 Erlangen 897 Germany 899 Phone: +49 9131 776 5126 900 Email: thomas.richter@iis.fraunhofer.de 901 URI: https://www.iis.fraunhofer.de/ 903 Alexandre Willeme 904 Universite catholique de Louvain 905 Place du Levant, 2 - bte L5.04.04 906 1348 Louvain-la-Neuve 907 Belgium 909 Phone: +32 10 47 80 82 910 Email: alexandre.willeme@uclouvain.be 911 URI: https://uclouvain.be/en/icteam