draft-ietf-payload-rtp-jpegxs-03.txt   draft-ietf-payload-rtp-jpegxs-04.txt 
avtcore S. Lugan avtcore S. Lugan
Internet-Draft A. Descampe Internet-Draft A. Descampe
Intended status: Standards Track C. Damman Intended status: Standards Track C. Damman
Expires: October 10, 2020 intoPIX Expires: January 30, 2021 intoPIX
T. Richter T. Richter
IIS IIS
A. Willeme A. Willeme
UCL/ICTEAM UCL/ICTEAM
April 8, 2020 July 29, 2020
RTP Payload Format for ISO/IEC 21122 (JPEG XS) RTP Payload Format for ISO/IEC 21122 (JPEG XS)
draft-ietf-payload-rtp-jpegxs-03 draft-ietf-payload-rtp-jpegxs-04
Abstract Abstract
This document specifies a Real-Time Transport Protocol (RTP) payload This document specifies a Real-Time Transport Protocol (RTP) payload
format to be used for transporting JPEG XS (ISO/IEC 21122) encoded format to be used for transporting JPEG XS (ISO/IEC 21122) encoded
video. JPEG XS is a low-latency, lightweight image coding system. video. JPEG XS is a low-latency, lightweight image coding system.
Compared to an uncompressed video use case, it allows higher Compared to an uncompressed video use case, it allows higher
resolutions and frame rates, while offering visually lossless resolutions and frame rates, while offering visually lossless
quality, reduced power consumption, and end-to-end latency confined quality, reduced power consumption, and end-to-end latency confined
to a fraction of a frame. to a fraction of a frame.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2020. This Internet-Draft will expire on January 30, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions, Definitions, and Abbreviations . . . . . . . . . 3 2. Conventions, Definitions, and Abbreviations . . . . . . . . . 3
3. Media Format Description . . . . . . . . . . . . . . . . . . 4 3. Media Format Description . . . . . . . . . . . . . . . . . . 4
3.1. Image Data Structures . . . . . . . . . . . . . . . . . . 4 3.1. Image Data Structures . . . . . . . . . . . . . . . . . . 5
3.2. Codestream . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Codestream . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Video support box and colour specification box . . . . . 5 3.3. Video support box and colour specification box . . . . . 5
3.4. JPEG XS Frame . . . . . . . . . . . . . . . . . . . . . . 5 3.4. JPEG XS Frame . . . . . . . . . . . . . . . . . . . . . . 6
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 6 4. RTP Payload Format . . . . . . . . . . . . . . . . . . . . . 6
4.1. RTP packetization . . . . . . . . . . . . . . . . . . . . 6 4.1. RTP packetization . . . . . . . . . . . . . . . . . . . . 6
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . 8 4.2. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 8
4.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Payload Header Usage . . . . . . . . . . . . . . . . . . 10
4.4. Traffic Shaping and Delivery Timing . . . . . . . . . . . 14 4.4. Payload Data . . . . . . . . . . . . . . . . . . . . . . 12
5. Congestion Control Considerations . . . . . . . . . . . . . . 14 4.5. Traffic Shaping and Delivery Timing . . . . . . . . . . . 17
6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 14 5. Congestion Control Considerations . . . . . . . . . . . . . . 18
6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 14 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 18
6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 17 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 18
6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 21
6.2.2. Media type and subtype . . . . . . . . . . . . . . . 18 6.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 21
6.2.3. Traffic shaping . . . . . . . . . . . . . . . . . . . 18 6.2.2. Media type and subtype . . . . . . . . . . . . . . . 22
6.2.4. Offer/Answer Considerations . . . . . . . . . . . . . 18 6.2.3. Traffic shaping . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6.2.4. Offer/Answer Considerations . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document specifies a payload format for packetization of JPEG XS This document specifies a payload format for packetization of JPEG XS
encoded video signals into the Real-time Transport Protocol (RTP) encoded video signals into the Real-time Transport Protocol (RTP)
[RFC3550]. [RFC3550].
The JPEG XS coding system offers compression and recompression of The JPEG XS coding system offers compression and recompression of
image sequences with very moderate computational resources while image sequences with very moderate computational resources while
remaining robust under multiple compression and decompression cycles remaining robust under multiple compression and decompression cycles
skipping to change at page 3, line 43 skipping to change at page 3, line 44
A sequence of bytes representing a compressed image formatted A sequence of bytes representing a compressed image formatted
according to JPEG XS Part-1 [ISO21122-1]. according to JPEG XS Part-1 [ISO21122-1].
JPEG XS codestream header JPEG XS codestream header
A sequence of bytes, starting with a SOC marker, at the beginning A sequence of bytes, starting with a SOC marker, at the beginning
of each JPEG XS codestream encoded in multiple markers and marker of each JPEG XS codestream encoded in multiple markers and marker
segments that does not carry entropy coded data, but metadata such segments that does not carry entropy coded data, but metadata such
as the frame dimension and component precision. as the frame dimension and component precision.
JPEG XS frame JPEG XS frame
The concatenation of a video support box, as defined in ISO/IEC A JPEG XS picture segment in the case of a progressive frame, or,
21122-3 [ISO21122-3], a colour specification box, as defined in in the case of an interlaced frame, the concatenation of two JPEG
ISO/IEC 21122-3 [ISO21122-3] as well, and either one JPEG XS XS picture segments.
codestream in the case of a progressive frame or two JPEG XS
codestreams in the case of an interlaced frame.
JPEG XS header segment JPEG XS header segment
The concatenation of a video support box, as defined in ISO/IEC The concatenation of a video support box, as defined in ISO/IEC
21122-3 [ISO21122-3], a colour specification box, as defined in 21122-3 [ISO21122-3], a colour specification box, as defined in
ISO/IEC 21122-3 as well [ISO21122-3] and a JPEG XS codestream ISO/IEC 21122-3 as well [ISO21122-3] and a JPEG XS codestream
header. header.
JPEG XS picture segment
The concatenation of a video support box, as defined in ISO/IEC
21122-3 [ISO21122-3], a colour specification box, as defined in
ISO/IEC 21122-3 as well [ISO21122-3] and a JPEG XS codestream.
JPEG XS stream JPEG XS stream
A sequence of JPEG XS frames. A sequence of JPEG XS frames.
Marker Marker
A two-byte functional sequence that is part of a JPEG XS A two-byte functional sequence that is part of a JPEG XS
codestream starting with a 0xff byte and a subsequent byte codestream starting with a 0xff byte and a subsequent byte
defining its function. defining its function.
Marker segment Marker segment
A marker along with a 16-bit marker size and payload data A marker along with a 16-bit marker size and payload data
following the size. following the size.
Packetization unit Packetization unit
A portion of a Application Data Unit whose boundaries shall A portion of an Application Data Unit whose boundaries coincide
coincide with boundaries of RTP packet payloads, i.e. the first with boundaries of RTP packet payloads (excluding payload header),
(resp. last) byte of a packetization unit shall be the first i.e. the first (resp. last) byte of a packetization unit is the
(resp. last) byte of a RTP packet payload. first (resp. last) byte of a RTP packet payload (excluding its
payload header).
Slice Slice
The smallest independently decodable unit of a JPEG XS codestream, The smallest independently decodable unit of a JPEG XS codestream,
bearing in mind that it decodes to wavelet coefficients which bearing in mind that it decodes to wavelet coefficients which
still require inverse wavelet filtering to give an image. still require inverse wavelet filtering to give an image.
SOC marker SOC marker
A marker that consists of the two bytes 0xff10 indicating the A marker that consists of the two bytes 0xff10 indicating the
start of a JPEG XS codestream. start of a JPEG XS codestream.
skipping to change at page 5, line 50 skipping to change at page 6, line 12
timecode of the current JPEG XS frame, the profile, level and timecode of the current JPEG XS frame, the profile, level and
sublevel used (as defined in ISO/IEC 21122-2 [ISO21122-2]), and sublevel used (as defined in ISO/IEC 21122-2 [ISO21122-2]), and
optionally on the buffer model and the mastering display metadata. optionally on the buffer model and the mastering display metadata.
The colour specification box indicates the colour primaries, transfer The colour specification box indicates the colour primaries, transfer
characteristics, matrix coefficients and video full range flag needed characteristics, matrix coefficients and video full range flag needed
to specify the colour space of the video stream. to specify the colour space of the video stream.
3.4. JPEG XS Frame 3.4. JPEG XS Frame
The concatenation of a video support box, a colour specification box The concatenation of a video support box, a colour specification box
and one or two JPEG XS codestreams forms a JPEG XS frame. In the and a JPEG XS codestream forms a JPEG XS picture segment. In the
case of a video stream made of progressive frames, only one case of a video stream made of progressive frames, each frame is made
codestream follows the boxes. In the case of a video stream made of of one single JPEG XS picture segment. In the case of a video stream
interlaced frames, two codestreams follow the boxes, each made of interlaced frames, each frame is made of two concatenated
corresponding to a field of the interlaced frame. The video JPEG XS picture segments. The codestream of each segment corresponds
information box included in the video support box contains a frat to a field of the interlaced frame. The boxes in the first segment
field indicating if the frame is progressive or interlaced (see ISO/ SHALL be equal to the boxes in the second segment. Note that the
IEC 21122-3 [ISO21122-3]). This information can also be found in video information box included in each video support box contains a
each RTP packet header (see Section 4.2). frat field indicating if the frame is progressive or interlaced, and,
in case of interlaced frame, if the top field (i.e. the field
containing the top line of the frame) is in the first or second
segment (see ISO/IEC 21122-3 [ISO21122-3]).
4. Payload Format 4. RTP Payload Format
This section specifies the payload format for JPEG XS streams over This section specifies the payload format for JPEG XS streams over
the Real-time Transport Protocol (RTP) [RFC3550]. the Real-time Transport Protocol (RTP) [RFC3550].
In order to be transported over RTP, each JPEG XS stream is In order to be transported over RTP, each JPEG XS stream is
transported in a distinct RTP stream, identified by a distinct SSRC. transported in a distinct RTP stream, identified by a distinct SSRC.
A JPEG XS stream is divided into Application Data Units (ADUs), each A JPEG XS stream is divided into Application Data Units (ADUs), each
ADU corresponding to a single JPEG XS frame. ADU corresponding to a single JPEG XS frame.
4.1. RTP packetization 4.1. RTP packetization
An ADU is made of several packetization units. If a packetization An ADU is made of several packetization units. If a packetization
unit is bigger than the maximum size of a RTP packet payload, the unit is bigger than the maximum size of a RTP packet payload, the
unit is split into multiple RTP packet payloads, as illustrated in unit is split into multiple RTP packet payloads, as illustrated in
Figure 1. As seen there, each packet shall contain (part of) one and Figure 1. As seen there, each packet SHALL contain (part of) one and
only one packetization unit. A packetization unit may extend over only one packetization unit. A packetization unit may extend over
multiple packets. The payload of every packet shall have the same multiple packets. The payload of every packet SHALL have the same
size (based e.g. on the Maximum Transfer Unit of the network), except size (based e.g. on the Maximum Transfer Unit of the network), except
(possibly) the last packet of a packetization unit. The boundaries (possibly) the last packet of a packetization unit. The boundaries
of a packetization unit shall coincide with the boundaries of the of a packetization unit SHALL coincide with the boundaries of the
payload of a packet, i.e. the first (resp. last) byte of the payload of a packet (excluding the payload header), i.e. the first
packetization unit shall be the first (resp. last) byte of the (resp. last) byte of the packetization unit SHALL be the first (resp.
payload. last) byte of the payload (excluding its header).
RTP +-----+------------------------+ RTP +-----+------------------------+
Packet #1 | Hdr | Packetization unit #1 | Packet #1 | Hdr | Packetization unit #1 |
+-----+------------------------+ +-----+------------------------+
RTP +-----+--------------------------------------+ RTP +-----+--------------------------------------+
Packet #2 | Hdr | Packetization unit #2 | Packet #2 | Hdr | Packetization unit #2 |
+-----+--------------------------------------+ +-----+--------------------------------------+
RTP +-----+--------------------------------------------------+ RTP +-----+--------------------------------------------------+
Packet #3 | Hdr | Packetization unit #3 (part 1/3) | Packet #3 | Hdr | Packetization unit #3 (part 1/3) |
+-----+--------------------------------------------------+ +-----+--------------------------------------------------+
skipping to change at page 7, line 31 skipping to change at page 7, line 31
RTP +-----+-----------------------------------------+ RTP +-----+-----------------------------------------+
Packet #P | Hdr | Packetization unit #N (part q/q) | Packet #P | Hdr | Packetization unit #N (part q/q) |
+-----+-----------------------------------------+ +-----+-----------------------------------------+
Figure 1: Example of ADU packetization Figure 1: Example of ADU packetization
There are two different packetization modes defined for this RTP There are two different packetization modes defined for this RTP
payload format. payload format.
1. Codestream packetization mode: in this mode, the packetization 1. Codestream packetization mode: in this mode, the packetization
unit shall be the entire codestream, preceeded by boxes, if any. unit SHALL be the entire codestream, preceeded by boxes. This
This means that a progressive frame will have a single means that a progressive frame will have a single packetization
packetization unit, while an interlaced frame will have two. The unit, while an interlaced frame will have two. The progressive
progressive case is illustrated in Figure 2. case is illustrated in Figure 2.
2. Slice packetization mode: in this mode, the packetization unit 2. Slice packetization mode: in this mode, the packetization unit
shall be the slice, i.e. there shall be data from no more than SHALL be the slice, i.e. there SHALL be data from no more than
one slice per RTP packet. The first packetization unit shall be one slice per RTP packet. The first packetization unit SHALL be
made of the JPEG XS header segment (i.e. the concatenation of the made of the JPEG XS header segment (i.e. the concatenation of the
VS box, the CS box and the JPEG XS codestream header). This VS box, the CS box and the JPEG XS codestream header). This
first unit is then followed by successive units, each containing first unit is then followed by successive units, each containing
one and only one slice. The packetization unit containing the one and only one slice. The packetization unit containing the
last slice of a JPEG XS codestream shall also contain the EOC last slice of a JPEG XS codestream SHALL also contain the EOC
marker immediately following this last slice. This is marker immediately following this last slice. This is
illustrated in Figure 3. In the case of interlaced frame, the illustrated in Figure 3. In the case of an interlaced frame, the
JPEG XS codestream header of the second field shall be in its own JPEG XS header segment of the second field SHALL be in its own
packetization unit. packetization unit.
RTP +-----+--------------------------------------------------+ RTP +-----+--------------------------------------------------+
Packet #1 | Hdr | VS box + CS box + JPEG XS codestream (part 1/q) | Packet #1 | Hdr | VS box + CS box + JPEG XS codestream (part 1/q) |
+-----+--------------------------------------------------+ +-----+--------------------------------------------------+
RTP +-----+--------------------------------------------------+ RTP +-----+--------------------------------------------------+
Packet #2 | Hdr | JPEG XS codestream (part 2/q) | Packet #2 | Hdr | JPEG XS codestream (part 2/q) |
+-----+--------------------------------------------------+ +-----+--------------------------------------------------+
... ...
RTP +-----+--------------------------------------+ RTP +-----+--------------------------------------+
skipping to change at page 8, line 41 skipping to change at page 8, line 41
RTP +-----+---------------------------------------+ RTP +-----+---------------------------------------+
Packet #P | Hdr | Slice #N (part q/q) + EOC marker | Packet #P | Hdr | Slice #N (part q/q) + EOC marker |
+-----+---------------------------------------+ +-----+---------------------------------------+
Figure 3: Example of slice packetization mode Figure 3: Example of slice packetization mode
Thanks to the constant bit-rate of JPEG XS, the codestream Thanks to the constant bit-rate of JPEG XS, the codestream
packetization mode guarantees that a JPEG XS RTP stream will produce packetization mode guarantees that a JPEG XS RTP stream will produce
a constant number of bytes per frame, and a constant number of RTP a constant number of bytes per frame, and a constant number of RTP
packets per frame. To reach the same guarantee with the slice packets per frame. To reach the same guarantee with the slice
packetization mode, an additional constraint needs to be set at the packetization mode, an additional mechanism needs to be put in place.
rate allocation stage in the JPEG XS encoder. For instance, one This can involve a constraint at the rate allocation stage in the
option would be to impose a constant bit-rate at the slice level. JPEG XS encoder to impose a constant bit-rate at the slice level, the
usage of padding data, or the insertion of empty RTP packets (i.e. a
RTP packet whose payload data is empty).
4.2. Payload Header 4.2. RTP Header Usage
Figure 4 illustrates the RTP payload header used in order to The format of the RTP header is specified in RFC 3550 [RFC3550] and
transport a JPEG XS stream. reprinted in Figure 4 for convenience. This RTP payload format uses
the fields of the header in a manner consistent with that
specification.
The RTP payload (and the settings for some RTP header bits) for
packetization units are specified in Section 4.3.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | sequence number | | V |P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | | timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier | | synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers | | contributing source (CSRC) identifiers |
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|K|L| I |F counter| SEP counter | P counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RTP and payload headers Figure 4: RTP header according to RFC 3550
The version (V), padding (P), extension (X), CSRC count (CC), The version (V), padding (P), extension (X), CSRC count (CC),
sequence number, synchronization source (SSRC) and contributing sequence number, synchronization source (SSRC) and contributing
source (CSRC) fields follow their respective definitions in RFC 3550 source (CSRC) fields follow their respective definitions in RFC 3550
[RFC3550]. [RFC3550].
The timestamp SHOULD be based on a 90 kHz clock reference. The remaining RTP header information to be set according to this RTP
payload format is set as follows:
As per specified in RFC 3550 [RFC3550] and RFC 4175 [RFC4175], the
RTP timestamp designates the sampling instant of the first octet of
the frame to which the RTP packet belongs. Packets shall not include
data from multiple frames, and all packets belonging to the same
frame shall have the same timestamp. Several successive RTP packets
will consequently have equal timestamps if they belong to the same
frame (that is until the marker bit is set to 1, marking the last
packet of the frame), and the timestamp is only increased when a new
frame begins.
If the sampling instant does not correspond to an integer value of
the clock, the value shall be truncated to the next lowest integer,
with no ambiguity.
The remaining fields are defined as follows:
Marker (M) [1 bit]: Marker (M) [1 bit]:
The M bit is used to indicate the last packet of a frame. This The M bit is used to indicate the last packet of a frame. This
enables a decoder to finish decoding the frame. enables a decoder to finish decoding the frame.
Payload Type (PT) [7 bits]: Payload Type (PT) [7 bits]:
A dynamically allocated payload type field that designates the A dynamically allocated payload type field that designates the
payload as JPEG XS video. payload as JPEG XS video.
Timestamp [32 bits]:
The RTP timestamp is set to the sampling timestamp of the content.
A 90 kHz clock rate SHOULD be used.
As per specified in RFC 3550 [RFC3550] and RFC 4175 [RFC4175], the
RTP timestamp designates the sampling instant of the first octet
of the frame to which the RTP packet belongs. Packets SHALL not
include data from multiple frames, and all packets belonging to
the same frame SHALL have the same timestamp. Several successive
RTP packets will consequently have equal timestamps if they belong
to the same frame (that is until the marker bit is set to 1,
marking the last packet of the frame), and the timestamp is only
increased when a new frame begins.
If the sampling instant does not correspond to an integer value of
the clock, the value SHALL be truncated to the next lowest
integer, with no ambiguity.
4.3. Payload Header Usage
The first four bytes of the payload of an RTP packet in this RTP
payload format are referred to as the payload header. Figure 5
illustrates the structure of this payload header.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|K|L| I |F counter| SEP counter | P counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Payload header
The payload header consists of the following fields:
Transmission mode (T) [1 bit]: Transmission mode (T) [1 bit]:
The T bit is set to indicate that packets are sent sequentially by The T bit is set to indicate that packets are sent sequentially by
the transmitter. A receiver could use this information to the transmitter. A receiver could use this information to
dimension its input buffer(s) accordingly. If T=0, nothing can be dimension its input buffer(s) accordingly. If T=0, nothing can be
assumed about the transmission order and packets may be sent out- assumed about the transmission order and packets may be sent out-
of-order by the transmitter. If T=1, packets must be sent of-order by the transmitter. If T=1, packets SHALL be sent
sequentially by the transmitter. sequentially by the transmitter.
pacKetization mode (K) [1 bit]: pacKetization mode (K) [1 bit]:
The K bit is set to indicate which packetization mode is used. The K bit is set to indicate which packetization mode is used.
K=0 indicates codestream packetization mode, while K=1 indicates K=0 indicates codestream packetization mode, while K=1 indicates
slice packetization mode. If Transmission mode (T) is set to 0, slice packetization mode. If Transmission mode (T) is set to 0,
slice packetization mode must be used and K must be set to 1. slice packetization mode SHALL be used and K SHALL be set to 1.
Last (L) [1 bit]: Last (L) [1 bit]:
The L bit is set to indicate the last packet of a packetization The L bit is set to indicate the last packet of a packetization
unit. As the end of the frame also ends the packet containing the unit. As the end of the frame also ends the packet containing the
last unit of the frame, the L bit is set whenever the M bit is last unit of the frame, the L bit is set whenever the M bit is
set. In the case of a progressive frame using the codestream set. In the case of a progressive frame using the codestream
packetization mode, the L bit and M bit are equivalent. packetization mode, the L bit and M bit are equivalent.
Interlaced mode (I) [2 bit]: Interlaced information (I) [2 bit]:
These 2 bits are used to indicate how the JPEG XS frame is scanned These 2 bits are used to indicate how the JPEG XS frame is scanned
(progressive or interlaced). (progressive or interlaced). In case of an interlaced frame, they
also indicate which JPEG XS picture segment the payload is part of
(first or second).
00: The payload is progressively scanned. 00: The payload is progressively scanned.
01: Reserved for future use. 01: Reserved for future use.
10: The payload is part of the first field of an interlaced video 10: The payload is part of the first JPEG XS picture segment of
frame. The height specified in the JPEG XS picture header is an interlaced video frame. The height specified in the included
half of the height of the entire displayed image. JPEG XS codestream header is half of the height of the entire
displayed image.
11: The payload is part of the second field of an interlaced 11: The payload is part of the second JPEG XS picture segment of
video frame. The height specified in the JPEG XS picture header an interlaced video frame. The height specified in the included
is half of the height of the entire displayed image. JPEG XS codestream header is half of the height of the entire
displayed image.
F counter [5 bits]: F counter [5 bits]:
The frame (F) counter identifies the frame number modulo 32 to The frame (F) counter identifies the frame number modulo 32 to
which a packet belongs. Frame numbers are incremented by 1 for which a packet belongs. Frame numbers are incremented by 1 for
each frame transmitted. The frame number, in addition to the time each frame transmitted. The frame number, in addition to the
stamp, may help the decoder manage its input buffer and bring timestamp, may help the decoder manage its input buffer and bring
packets back into their natural order. packets back into their natural order.
SEP counter [11 bits]: SEP counter [11 bits]:
The Slice and Extended Packet (SEP) counter is used differently The Slice and Extended Packet (SEP) counter is used differently
depending on the packetization mode. depending on the packetization mode.
* In the case of codestream packetization mode (K=0), this * In the case of codestream packetization mode (K=0), this
counter resets whenever the Packet counter resets (see counter resets whenever the Packet counter resets (see
hereunder), and increments by 1 whenever the Packet counter hereunder), and increments by 1 whenever the Packet counter
overruns. overruns.
* In the case of slice packetization mode (K=1), this counter * In the case of slice packetization mode (K=1), this counter
identifies the slice modulo 2047 to which the packet identifies the slice modulo 2047 to which the packet
skipping to change at page 11, line 13 skipping to change at page 11, line 45
depending on the packetization mode. depending on the packetization mode.
* In the case of codestream packetization mode (K=0), this * In the case of codestream packetization mode (K=0), this
counter resets whenever the Packet counter resets (see counter resets whenever the Packet counter resets (see
hereunder), and increments by 1 whenever the Packet counter hereunder), and increments by 1 whenever the Packet counter
overruns. overruns.
* In the case of slice packetization mode (K=1), this counter * In the case of slice packetization mode (K=1), this counter
identifies the slice modulo 2047 to which the packet identifies the slice modulo 2047 to which the packet
contributes. If the data belongs to the JPEG XS header contributes. If the data belongs to the JPEG XS header
segment, this field shall have its maximal value, namely 2047 = segment, this field SHALL have its maximal value, namely 2047 =
0x07ff. Otherwise, it is the slice index modulo 2047. Slice 0x07ff. Otherwise, it is the slice index modulo 2047. Slice
indices are counted from 0 (corresponding to the top of the indices are counted from 0 (corresponding to the top of the
frame). frame).
P counter [11 bits]: P counter [11 bits]:
The packet (P) counter identifies the packet number modulo 2048 The packet (P) counter identifies the packet number modulo 2048
within the current packetization unit. It is set to 0 at the within the current packetization unit. It is set to 0 at the
start of the packetization unit and incremented by 1 for every start of the packetization unit and incremented by 1 for every
subsequent packet (if any) belonging to the same unit. subsequent packet (if any) belonging to the same unit.
Practically, if codestream packetization mode is enabled, this Practically, if codestream packetization mode is enabled, this
field counts the packets within a codestream and is extended by field counts the packets within a JPEG XS picture segment and is
the SEP counter when it overruns. If slice packetization mode is extended by the SEP counter when it overruns. If slice
enabled, this field counts the packets within a slice or within packetization mode is enabled, this field counts the packets
the JPEG XS header segment. within a slice or within the JPEG XS header segment.
4.3. Payload Data 4.4. Payload Data
The payload data of a JPEG XS RTP stream consists of a concatenation The payload data of a JPEG XS RTP stream consists of a concatenation
of multiple JPEG XS frames. of multiple JPEG XS frames.
Each JPEG XS frame is the concatenation of one or more packetization Each JPEG XS frame is the concatenation of one or more packetization
unit(s), as explained in Section 4.1. Figure 5 depicts this layout unit(s), as explained in Section 4.1. Figure 6 depicts this layout
for an interlaced frame in the codestream packetization mode and for a progressive frame in the codestream packetization mode,
Figure 6 depicts this layout for a progressive frame in the slice Figure 7 depicts this layout for an interlaced frame in the
codestream packetization mode, Figure 8 depicts this layout for a
progressive frame in the slice packetization mode and Figure 9
depicts this layout for an interlaced frame in the slice
packetization mode. The Frame counter value is not indicated because packetization mode. The Frame counter value is not indicated because
the value is constant for all packetization units of a given frame. the value is constant for all packetization units of a given frame.
+=====[ Packetization unit (PU) #1 ]====+ +=====[ Packetization unit (PU) #1 ]====+
| Video support box | SEP counter = 0 | Video support box | SEP counter = 0
| +---------------------------------+ | P counter = 0 | +---------------------------------+ | P counter = 0
| : Sub boxes of the VS box : | | : Sub boxes of the VS box : |
| +---------------------------------+ | | +---------------------------------+ |
+- - - - - - - - - - - - - - - - - - - -+ +- - - - - - - - - - - - - - - - - - - -+
| Colour specification box | | Colour specification box |
| +---------------------------------+ | | +---------------------------------+ |
| : Fields of the CS box : | | : Fields of the CS box : |
| +---------------------------------+ | | +---------------------------------+ |
+- - - - - - - - - - - - - - - - - - - -+ +- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream (field 0) | | JPEG XS codestream |
: (part 1/q) : M=0, K=0, L=0, I=10 : (part 1/q) : M=0, K=0, L=0, I=00
+---------------------------------------+ +---------------------------------------+
| JPEG XS codestream (field 0) | SEP counter = 0 | JPEG XS codestream | SEP counter = 0
| (part 2/q) | P counter = 1 | (part 2/q) | P counter = 1
: : M=0, K=0, L=0, I=10 : : M=0, K=0, L=0, I=00
+---------------------------------------+ +---------------------------------------+
| JPEG XS codestream (field 0) | SEP counter = 0 | JPEG XS codestream | SEP counter = 0
| (part 3/q) | P counter = 2 | (part 3/q) | P counter = 2
: : M=0, K=0, L=0, I=00
+---------------------------------------+
: :
+---------------------------------------+
| JPEG XS codestream | SEP counter = 1
| (part 2049/q) | P counter = 0
: : M=0, K=0, L=0, I=00
+---------------------------------------+
: :
+---------------------------------------+
| JPEG XS codestream | SEP counter = (q-1) div 2048
| (part q/q) | P counter = (q-1) mod 2048
: : M=1, K=0, L=1, I=00
+=======================================+
Figure 6: Example of JPEG XS Payload Data (codestream packetization
mode, progressive frame)
+=====[ Packetization unit (PU) #1 ]====+
| Video support box | SEP counter = 0
+- - - - - - - - - - - - - - - - - - - -+ P counter = 0
| Colour specification box |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream (1st field) |
: (part 1/q) : M=0, K=0, L=0, I=10
+---------------------------------------+
| JPEG XS codestream (1st field) | SEP counter = 0
| (part 2/q) | P counter = 1
: : M=0, K=0, L=0, I=10 : : M=0, K=0, L=0, I=10
+---------------------------------------+ +---------------------------------------+
: : : :
+---------------------------------------+ +---------------------------------------+
| JPEG XS codestream (field 0) | SEP counter = 1 | JPEG XS codestream (1st field) | SEP counter = 1
| (part 2049/q) | P counter = 0 | (part 2049/q) | P counter = 0
: : M=0, K=0, L=0, I=10 : : M=0, K=0, L=0, I=10
+---------------------------------------+ +---------------------------------------+
: : : :
+---------------------------------------+ +---------------------------------------+
| JPEG XS codestream (field 0) | SEP counter = (q-1) div 2048 | JPEG XS codestream (1st field) | SEP counter = (q-1) div 2048
| (part q/q) | P counter = (q-1) mod 2048 | (part q/q) | P counter = (q-1) mod 2048
: : M=0, K=0, L=1, I=10 : : M=0, K=0, L=1, I=10
+===============[ PU #2 ]===============+ +===============[ PU #2 ]===============+
| JPEG XS codestream (field 1) | SEP counter = 0 | Video support box | SEP counter = 0
| (part 1/q) | P counter = 0 +- - - - - - - - - - - - - - - - - - - -+ P counter = 0
| Colour specification box |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream (2nd field) |
| (part 1/q) |
: : M=0, K=0, L=0, I=11 : : M=0, K=0, L=0, I=11
+---------------------------------------+ +---------------------------------------+
| JPEG XS codestream (field 1) | SEP counter = 0 | JPEG XS codestream (2nd field) | SEP counter = 0
| (part 2/q) | P counter = 1 | (part 2/q) | P counter = 1
: : M=0, K=0, L=0, I=11 : : M=0, K=0, L=0, I=11
+---------------------------------------+ +---------------------------------------+
: : : :
+---------------------------------------+ +---------------------------------------+
| JPEG XS codestream (field 1) | SEP counter = (q-1) div 2048 | JPEG XS codestream (2nd field) | SEP counter = (q-1) div 2048
| (part q/q) | P counter = (q-1) mod 2048 | (part q/q) | P counter = (q-1) mod 2048
: : M=1, K=0, L=1, I=11 : : M=1, K=0, L=1, I=11
+=======================================+ +=======================================+
Figure 5: Example of JPEG XS Payload Data (codestream packetization Figure 7: Example of JPEG XS Payload Data (codestream packetization
mode, interlaced frame) mode, interlaced frame)
+====[ PU#1: JPEG XS Header segment ]===+ +===[ PU #1: JPEG XS Header segment ]===+
| Video support box | SEP counter = 0x07FF | Video support box | SEP counter = 0x07FF
| +---------------------------------+ | P counter = 0 +- - - - - - - - - - - - - - - - - - - -+ P counter = 0
| : Sub boxes of the VS box : |
| +---------------------------------+ |
+- - - - - - - - - - - - - - - - - - - -+
| Colour specification box | | Colour specification box |
| +---------------------------------+ |
| : Fields of the CS box : |
| +---------------------------------+ |
+- - - - - - - - - - - - - - - - - - - -+ +- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream header | | JPEG XS codestream header |
| +---------------------------------+ | | +---------------------------------+ |
| : Markers and marker segments : | | : Markers and marker segments : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=00 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=00
+==========[ PU#2: Slice #1 ]===========+ +==========[ PU #2: Slice #1 ]==========+
| +---------------------------------+ | SEP counter = 0 | +---------------------------------+ | SEP counter = 0
| | SLH Marker | | P counter = 0 | | SLH Marker | | P counter = 0
| +---------------------------------+ | | +---------------------------------+ |
| : Entropy Coded Data : | | : Entropy Coded Data : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=00 | +---------------------------------+ | M=0, T=0, K=1, L=1, I=00
+==========[ PU#3: Slice #2 ]===========+ +==========[ PU #3: Slice #2 ]==========+
| Slice #2 | SEP counter = 1 | Slice #2 | SEP counter = 1
| (part 1/q) | P counter = 0 | (part 1/q) | P counter = 0
: : M=0, T=0, K=1, L=0, I=00 : : M=0, T=0, K=1, L=0, I=00
+---------------------------------------+ +---------------------------------------+
| Slice #2 | SEP counter = 1 | Slice #2 | SEP counter = 1
| (part 2/q) | P counter = 1 | (part 2/q) | P counter = 1
: : M=0, T=0, K=1, L=0, I=00 : : M=0, T=0, K=1, L=0, I=00
+---------------------------------------+ +---------------------------------------+
: : : :
+---------------------------------------+ +---------------------------------------+
| Slice #2 | SEP counter = 1 | Slice #2 | SEP counter = 1
| (part q/q) | P counter = q-1 | (part q/q) | P counter = q-1
: : M=0, T=0, K=1, L=1, I=00 : : M=0, T=0, K=1, L=1, I=00
+=======================================+ +=======================================+
: : : :
+========[ PU#N: Slice #(N-1) ]=========+ +========[ PU #N: Slice #(N-1) ]========+
| Slice #(N-1) | SEP counter = N-2 | Slice #(N-1) | SEP counter = N-2
| (part 1/r) | P counter = 0 | (part 1/r) | P counter = 0
: : M=0, T=0, K=1, L=0, I=00 : : M=0, T=0, K=1, L=0, I=00
+---------------------------------------+ +---------------------------------------+
: : : :
+---------------------------------------+ +---------------------------------------+
| Slice #(N-1) | SEP counter = N-2 | Slice #(N-1) | SEP counter = N-2
| (part r/r) | P counter = r-1 | (part r/r) | P counter = r-1
: + EOC marker : M=1, T=0, K=1, L=1, I=00 : + EOC marker : M=1, T=0, K=1, L=1, I=00
+=======================================+ +=======================================+
Figure 6: Example of JPEG XS Payload Data (slice packetization mode, Figure 8: Example of JPEG XS Payload Data (slice packetization mode,
progressive frame) progressive frame)
4.4. Traffic Shaping and Delivery Timing +====[ PU #1: JPEG XS Hdr segment 1 ]===+
| Video support box | SEP counter = 0x07FF
+- - - - - - - - - - - - - - - - - - - -+ P counter = 0
| Colour specification box |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream header 1 |
| +---------------------------------+ |
| : Markers and marker segments : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=10
+====[ PU #2: Slice #1 (1st field) ]====+
| +---------------------------------+ | SEP counter = 0
| | SLH Marker | | P counter = 0
| +---------------------------------+ |
| : Entropy Coded Data : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=10
+====[ PU #3: Slice #2 (1st field) ]====+
| Slice #2 | SEP counter = 1
| (part 1/q) | P counter = 0
: : M=0, T=0, K=1, L=0, I=10
+---------------------------------------+
| Slice #2 | SEP counter = 1
| (part 2/q) | P counter = 1
: : M=0, T=0, K=1, L=0, I=10
+---------------------------------------+
: :
+---------------------------------------+
| Slice #2 | SEP counter = 1
| (part q/q) | P counter = q-1
: : M=0, T=0, K=1, L=1, I=10
+=======================================+
: :
+==[ PU #N: Slice #(N-1) (1st field) ]==+
| Slice #(N-1) | SEP counter = N-2
| (part 1/r) | P counter = 0
: : M=0, T=0, K=1, L=0, I=10
+---------------------------------------+
: :
+---------------------------------------+
| Slice #(N-1) | SEP counter = N-2
| (part r/r) | P counter = r-1
: + EOC marker : M=0, T=0, K=1, L=1, I=10
+=======================================+
+===[ PU #N+1: JPEG XS Hdr segment 2 ]==+
| Video support box | SEP counter = 0x07FF
+- - - - - - - - - - - - - - - - - - - -+ P counter = 0
| Colour specification box |
+- - - - - - - - - - - - - - - - - - - -+
| JPEG XS codestream header 2 |
| +---------------------------------+ |
| : Markers and marker segments : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=11
+===[ PU #N+2: Slice #1 (2nd field) ]===+
| +---------------------------------+ | SEP counter = 0
| | SLH Marker | | P counter = 0
| +---------------------------------+ |
| : Entropy Coded Data : |
| +---------------------------------+ | M=0, T=0, K=1, L=1, I=11
+===[ PU #N+3: Slice #2 (2nd field) ]===+
| Slice #2 | SEP counter = 1
| (part 1/s) | P counter = 0
: : M=0, T=0, K=1, L=0, I=11
+---------------------------------------+
| Slice #2 | SEP counter = 1
| (part 2/s) | P counter = 1
: : M=0, T=0, K=1, L=0, I=11
+---------------------------------------+
: :
+---------------------------------------+
| Slice #2 | SEP counter = 1
| (part s/s) | P counter = s-1
: : M=0, T=0, K=1, L=1, I=11
+=======================================+
: :
+==[ PU #2N: Slice #(N-1) (2nd field) ]=+
| Slice #(N-1) | SEP counter = N-2
| (part 1/t) | P counter = 0
: : M=0, T=0, K=1, L=0, I=11
+---------------------------------------+
: :
+---------------------------------------+
| Slice #(N-1) | SEP counter = N-2
| (part t/t) | P counter = t-1
: + EOC marker : M=1, T=0, K=1, L=1, I=11
+=======================================+
The traffic shaping and delivery timing shall be in accordance with Figure 9: Example of JPEG XS Payload Data (slice packetization mode,
interlaced frame)
4.5. Traffic Shaping and Delivery Timing
The traffic shaping and delivery timing SHALL be in accordance with
the Network Compatibility Model compliance definitions specified in the Network Compatibility Model compliance definitions specified in
SMPTE ST 2110-21 [SMPTE-ST2110-21] for either Narrow Linear Senders SMPTE ST 2110-21 [SMPTE-ST2110-21] for either Narrow Linear Senders
(Type NL) or Wide Senders (Type W). The session description shall (Type NL) or Wide Senders (Type W). The session description SHALL
include a format-specific parameter of either TP=2110TPNL or include a format-specific parameter of either TP=2110TPNL or
TP=2110TPW to indicate compliance with Type NL or Type W TP=2110TPW to indicate compliance with Type NL or Type W
respectively. respectively.
NOTE: The Virtual Receiver Buffer Model compliance definitions of ST NOTE: The Virtual Receiver Buffer Model compliance definitions of ST
2110-21 do not apply. 2110-21 do not apply.
5. Congestion Control Considerations 5. Congestion Control Considerations
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
skipping to change at page 14, line 44 skipping to change at page 18, line 36
Type name: video Type name: video
Subtype name: jxsv Subtype name: jxsv
Required parameters: Required parameters:
rate: The RTP timestamp clock rate. Applications using this rate: The RTP timestamp clock rate. Applications using this
payload format SHOULD use a value of 90000. payload format SHOULD use a value of 90000.
transmission mode: Indicates if packets are sent sequentially by transmode: Indicates if packets are sent sequentially by the
the transmitter. A receiver could use this information to transmitter. A receiver could use this information to dimension
dimension its input buffer(s) accordingly. If set to 0, nothing its input buffer(s) accordingly. If set to 0, nothing can be
can be assumed about the transmission order and packets may be sent assumed about the transmission order and packets may be sent out-
out-of-order. If value is 1, packets must be sent sequentially by of-order. If value is 1, packets SHALL be sent sequentially by the
the transmitter. transmitter.
Optional parameters: Optional parameters:
profile: The JPEG XS profile in use, as defined in ISO/IEC 21122-2 profile: The JPEG XS profile in use, as defined in ISO/IEC 21122-2
(JPEG XS Part 2) [ISO21122-2]. (JPEG XS Part 2) [ISO21122-2].
level: The JPEG XS level in use, as defined in ISO/IEC 21122-2 level: The JPEG XS level in use, as defined in ISO/IEC 21122-2
(JPEG XS Part 2) [ISO21122-2]. (JPEG XS Part 2) [ISO21122-2].
sublevel: The JPEG XS sublevel in use, as defined in ISO/IEC sublevel: The JPEG XS sublevel in use, as defined in ISO/IEC
21122-2 (JPEG XS Part 2) [ISO21122-2]. 21122-2 (JPEG XS Part 2) [ISO21122-2].
sampling: Signals the colour difference signal sub-sampling sampling: Signals the colour difference signal sub-sampling
structure. structure.
Signals utilizing the non-constant luminance Y'C'B C'R signal Signals utilizing the non-constant luminance Y'C'B C'R signal
format of Recommendation ITU-R BT.601-7, Recommendation ITU-R format of Recommendation ITU-R BT.601-7, Recommendation ITU-R
BT.709-6, Recommendation ITU-R BT.2020-2, or Recommendation ITU-R BT.709-6, Recommendation ITU-R BT.2020-2, or Recommendation ITU-R
BT.2100 shall use the appropriate one of the following values for BT.2100 SHALL use the appropriate one of the following values for
the Media Type Parameter "sampling": the Media Type Parameter "sampling":
YCbCr-4:4:4 (4:4:4 sampling) YCbCr-4:4:4 (4:4:4 sampling)
YCbCr-4:2:2 (4:2:2 sampling) YCbCr-4:2:2 (4:2:2 sampling)
YCbCr-4:2:0 (4:2:0 sampling) YCbCr-4:2:0 (4:2:0 sampling)
Signals utilizing the Constant Luminance Y'C C'BC C'RC signal Signals utilizing the Constant Luminance Y'C C'BC C'RC signal
format of Recommendation ITU-R BT.2020-2 shall use the appropriate format of Recommendation ITU-R BT.2020-2 SHALL use the appropriate
one of the following values for the Media Type Parameter one of the following values for the Media Type Parameter
"sampling": "sampling":
CLYCbCr-4:4:4 (4:4:4 sampling) CLYCbCr-4:4:4 (4:4:4 sampling)
CLYCbCr-4:2:2 (4:2:2 sampling) CLYCbCr-4:2:2 (4:2:2 sampling)
CLYCbCr-4:2:0 (4:2:0 sampling) CLYCbCr-4:2:0 (4:2:0 sampling)
Signals utilizing the constant intensity I CT CP signal format of Signals utilizing the constant intensity I CT CP signal format of
Recommendation ITU-R BT.2100 shall use the appropriate one of the Recommendation ITU-R BT.2100 SHALL use the appropriate one of the
following values for the Media Type Parameter "sampling": following values for the Media Type Parameter "sampling":
ICtCp-4:4:4 (4:4:4 sampling) ICtCp-4:4:4 (4:4:4 sampling)
ICtCp-4:2:2 (4:2:2 sampling) ICtCp-4:2:2 (4:2:2 sampling)
ICtCp-4:2:0 (4:2:0 sampling) ICtCp-4:2:0 (4:2:0 sampling)
Signals utilizing the 4:4:4 R' G' B' or RGB signal format (such as Signals utilizing the 4:4:4 R' G' B' or RGB signal format (such as
that of Recommendation ITU-R BT.601, Recommendation ITU-R BT.709, that of Recommendation ITU-R BT.601, Recommendation ITU-R BT.709,
Recommendation ITU-R BT.2020, Recommendation ITU-R BT.2100, SMPTE Recommendation ITU-R BT.2020, Recommendation ITU-R BT.2100, SMPTE
ST 2065-1 or ST 2065-3) shall use the following value for the Media ST 2065-1 or ST 2065-3) SHALL use the following value for the Media
Type Parameter sampling. Type Parameter sampling.
RGB RGB or R' G' B' samples RGB RGB or R' G' B' samples
Signals utilizing the 4:4:4 X' Y' Z' signal format (such as defined Signals utilizing the 4:4:4 X' Y' Z' signal format (such as defined
in SMPTE ST 428-1) shall use the following value for the Media Type in SMPTE ST 428-1) SHALL use the following value for the Media Type
Parameter sampling. Parameter sampling.
XYZ X' Y' Z' samples XYZ X' Y' Z' samples
Key signals as defined in SMPTE RP 157 shall use the value key for Key signals as defined in SMPTE RP 157 SHALL use the value key for
the Media Type Parameter sampling. The Key signal is represented the Media Type Parameter sampling. The Key signal is represented
as a single component. as a single component.
KEY samples of the key signal KEY samples of the key signal
depth: Determines the number of bits per sample. This is an depth: Determines the number of bits per sample. This is an
integer with typical values including 8, 10, 12, and 16. integer with typical values including 8, 10, 12, and 16.
width: Determines the number of pixels per line. This is an width: Determines the number of pixels per line. This is an
integer between 1 and 32767. integer between 1 and 32767.
height: Determines the number of lines per frame. This is an height: Determines the number of lines per frame. This is an
integer between 1 and 32767. integer between 1 and 32767.
exactframerate: Signals the frame rate in frames per second. exactframerate: Signals the frame rate in frames per second.
Integer frame rates shall be signaled as a single decimal number Integer frame rates SHALL be signaled as a single decimal number
(e.g. "25") whilst non-integer frame rates shall be signaled as a (e.g. "25") whilst non-integer frame rates SHALL be signaled as a
ratio of two integer decimal numbers separated by a "forward-slash" ratio of two integer decimal numbers separated by a "forward-slash"
character (e.g. "30000/1001"), utilizing the numerically smallest character (e.g. "30000/1001"), utilizing the numerically smallest
numerator value possible. numerator value possible.
colorimetry: Specifies the system colorimetry used by the image colorimetry: Specifies the system colorimetry used by the image
samples. Valid values and their specification are: samples. Valid values and their specification are:
BT601-5 ITU Recommendation BT.601-5 BT601-5 ITU Recommendation BT.601-5
BT709-2 ITU Recommendation BT.709-2 BT709-2 ITU Recommendation BT.709-2
SMPTE240M SMPTE standard 240M SMPTE240M SMPTE standard 240M
skipping to change at page 17, line 6 skipping to change at page 20, line 46
BT2100 as specified in Recommendation ITU-R BT.2100 BT2100 as specified in Recommendation ITU-R BT.2100
Table 2 titled "System colorimetry" Table 2 titled "System colorimetry"
ST2065-1 as specified in SMPTE ST 2065-1 Academy Color ST2065-1 as specified in SMPTE ST 2065-1 Academy Color
Encoding Specification (ACES) Encoding Specification (ACES)
ST2065-3 as specified for Academy Density Exchange ST2065-3 as specified for Academy Density Exchange
Encoding (ADX) in SMPTE ST 2065-3 Encoding (ADX) in SMPTE ST 2065-3
XYZ as specified in ISO 11664-1 section titled XYZ as specified in ISO 11664-1 section titled
"1931 Observer" "1931 Observer"
Signals utilizing the Recommendation ITU-R BT.2100 colorimetry Signals utilizing the Recommendation ITU-R BT.2100 colorimetry
should also signal the representational range using the optional SHOULD also signal the representational range using the optional
parameter RANGE defined below. parameter RANGE defined below.
interlace: If this OPTIONAL parameter name is present, it indicates interlace: If this OPTIONAL parameter name is present, it indicates
that the video is interlaced. If this parameter name is not that the video is interlaced. If this parameter name is not
present, the progressive video format shall be assumed. present, the progressive video format SHALL be assumed.
TCS: Transfer Characteristic System. This parameter specifies the TCS: Transfer Characteristic System. This parameter specifies the
transfer characteristic system of the image samples. Valid values transfer characteristic system of the image samples. Valid values
and their specification are: and their specification are:
SDR (Standard Dynamic Range) Video streams of standard SDR (Standard Dynamic Range) Video streams of standard
dynamic range, that utilize the OETF of Recommendation dynamic range, that utilize the OETF of Recommendation
ITU-R BT.709 or Recommendation ITU-R BT.2020. Such ITU-R BT.709 or Recommendation ITU-R BT.2020. Such
streams shall be assumed to target the EOTF specified streams SHALL be assumed to target the EOTF specified
in ITU-R BT.1886. in ITU-R BT.1886.
PQ Video streams of high dynamic range video that utilize PQ Video streams of high dynamic range video that utilize
the Perceptual Quantization system of Recommendation the Perceptual Quantization system of Recommendation
ITU-R BT.2100 ITU-R BT.2100
HLG Video streams of high dynamic range video that utilize HLG Video streams of high dynamic range video that utilize
the Hybrid Log-Gamma system of Recommendation ITU-R the Hybrid Log-Gamma system of Recommendation ITU-R
BT.2100 BT.2100
RANGE: This parameter should be used to signal the encoding range RANGE: This parameter SHOULD be used to signal the encoding range
of the sample values within the stream. When paired with ITU Rec of the sample values within the stream. When paired with ITU Rec
BT.2100 colorimetry, this parameter has two allowed values NARROW BT.2100 colorimetry, this parameter has two allowed values NARROW
and FULL, corresponding to the ranges specified in table 9 of ITU and FULL, corresponding to the ranges specified in table 9 of ITU
Rec BT.2100. In any other context, this parameter has three Rec BT.2100. In any other context, this parameter has three
allowed values: NARROW, FULLPROTECT, and FULL, which correspond to allowed values: NARROW, FULLPROTECT, and FULL, which correspond to
the ranges specified in SMPTE RP 2077. In the absence of this the ranges specified in SMPTE RP 2077. In the absence of this
parameter, NARROW shall be the assumed value in either case. parameter, NARROW SHALL be the assumed value in either case.
Encoding considerations: Encoding considerations:
This media type is framed and binary; see Section 4.8 in RFC 6838 This media type is framed and binary; see Section 4.8 in RFC 6838
[RFC6838]. [RFC6838].
Security considerations: Security considerations:
Please see the Security Considerations section in RFC XXXX Please see the Security Considerations section in RFC XXXX
6.2. Mapping to SDP 6.2. Mapping to SDP
6.2.1. General 6.2.1. General
A Session Description Protocol (SDP) object shall be created for each A Session Description Protocol (SDP) object SHALL be created for each
RTP stream and it shall be in accordance with the provisions of SMPTE RTP stream and it SHALL be in accordance with the provisions of SMPTE
ST 2110-10 [SMPTE-ST2110-10]. ST 2110-10 [SMPTE-ST2110-10].
The information carried in the media type specification has a The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP), specific mapping to fields in the Session Description Protocol (SDP),
which is commonly used to describe RTP sessions. which is commonly used to describe RTP sessions. This information is
redundant with the information found in the payload data (namely, in
the JPEG XS header segment) and SHALL be consistent with it. In case
of discrepancy between parameters values found in the payload data
and in the SDP fields, the values from the payload data SHALL
prevail.
6.2.2. Media type and subtype 6.2.2. Media type and subtype
The media type ("video") goes in SDP "m=" as the media name. The media type ("video") goes in SDP "m=" as the media name.
The media subtype ("jxsv") goes in SDP "a=rtpmap" as the encoding The media subtype ("jxsv") goes in SDP "a=rtpmap" as the encoding
name, followed by a slash ("/") and the required parameter "rate" name, followed by a slash ("/") and the required parameter "rate"
corresponding to the RTP timestamp clock rate (which for the payload corresponding to the RTP timestamp clock rate (which for the payload
format defined in this document SHOULD be 90000), followed by a slash format defined in this document SHOULD be 90000). The required
("/") and the required parameter "transmission mode" set to 1 if parameter "transmode" and the additional optional parameters go in
packets are sent sequentially by the transmitter, or 0 if
transmission order is not constrained. The optional parameters go in
the SDP "a=fmtp" attribute by copying them directly from the MIME the SDP "a=fmtp" attribute by copying them directly from the MIME
media type string as a semicolon-separated list of parameter=value media type string as a semicolon-separated list of parameter=value
pairs. pairs.
A sample SDP mapping for JPEG XS video is as follows: A sample SDP mapping for JPEG XS video is as follows:
m=video 30000 RTP/AVP 112 m=video 30000 RTP/AVP 112
a=rtpmap:112 jxsv/90000/1 a=rtpmap:112 jxsv/90000
a=fmtp:112 sampling=YCbCr-4:2:2; width=1920; height=1080; a=fmtp:112 transmode=1;sampling=YCbCr-4:2:2;width=1920;height=1080;
depth=10; colorimetry=BT709; TCS=SDR; depth=10;colorimetry=BT709;TCS=SDR;
RANGE=FULL; TP=2110TPNL RANGE=FULL;TP=2110TPNL
In this example, a JPEG XS RTP stream is being sent to UDP In this example, a JPEG XS RTP stream is being sent to UDP
destination port 30000, with an RTP dynamic payload type of 112 and a destination port 30000, with an RTP dynamic payload type of 112 and a
media clock rate of 90000 Hz. Note that the "a=fmtp:" line has been media clock rate of 90000 Hz. Note that the "a=fmtp:" line has been
wrapped to fit this page, and will be a single long line in the SDP wrapped to fit this page, and will be a single long line in the SDP
file. file.
6.2.3. Traffic shaping 6.2.3. Traffic shaping
The SDP object shall include the TP parameter (either 2110TPNL or The SDP object SHALL include the TP parameter (either 2110TPNL or
2110TPW as specified in Section 4.4) and may include the CMAX 2110TPW as specified in Section 4.5) and may include the CMAX
parameter as specified in SMPTE ST 2110-21 [SMPTE-ST2110-21]. parameter as specified in SMPTE ST 2110-21 [SMPTE-ST2110-21].
6.2.4. Offer/Answer Considerations 6.2.4. Offer/Answer Considerations
The following considerations apply when using SDP offer/answer The following considerations apply when using SDP offer/answer
procedures [RFC3264] to negotiate the use of the JPEG XS payload in procedures [RFC3264] to negotiate the use of the JPEG XS payload in
RTP: RTP:
o The "encode" parameter can be used for sendrecv, sendonly, and o The "encode" parameter can be used for sendrecv, sendonly, and
recvonly streams. Each encode type MUST use a separate payload recvonly streams. Each encode type MUST use a separate payload
skipping to change at page 20, line 33 skipping to change at page 24, line 31
10. References 10. References
10.1. Normative References 10.1. Normative References
[ISO21122-1] [ISO21122-1]
International Organization for Standardization (ISO) - International Organization for Standardization (ISO) -
International Electrotechnical Commission (IEC), International Electrotechnical Commission (IEC),
"Information technology - JPEG XS low-latency lightweight "Information technology - JPEG XS low-latency lightweight
image coding system - Part 1: Core coding system", ISO/ image coding system - Part 1: Core coding system", ISO/
IEC PRF 21122-1, under development, IEC IS 21122-1, 2019,
<https://www.iso.org/standard/74535.html>. <https://www.iso.org/standard/74535.html>.
[ISO21122-2] [ISO21122-2]
International Organization for Standardization (ISO) - International Organization for Standardization (ISO) -
International Electrotechnical Commission (IEC), International Electrotechnical Commission (IEC),
"Information technology - JPEG XS low-latency lightweight "Information technology - JPEG XS low-latency lightweight
image coding system - Part 2: Profiles and buffer models", image coding system - Part 2: Profiles and buffer models",
ISO/IEC PRF 21122-2, under development, ISO/IEC IS 21122-2, 2019,
<https://www.iso.org/standard/74536.html>. <https://www.iso.org/standard/74536.html>.
[ISO21122-3] [ISO21122-3]
International Organization for Standardization (ISO) - International Organization for Standardization (ISO) -
International Electrotechnical Commission (IEC), International Electrotechnical Commission (IEC),
"Information technology - JPEG XS low-latency lightweight "Information technology - JPEG XS low-latency lightweight
image coding system - Part 3: Transport and container image coding system - Part 3: Transport and container
formats", ISO/IEC FDIS 21122-3, under development, formats", ISO/IEC IS 21122-3, 2019,
<https://www.iso.org/standard/74537.html>. <https://www.iso.org/standard/74537.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002, DOI 10.17487/RFC3264, June 2002,
 End of changes. 89 change blocks. 
170 lines changed or deleted 338 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/