rfc9828v1.txt   rfc9828.txt 
Internet Engineering Task Force (IETF) P. Lemieux, Ed. Internet Engineering Task Force (IETF) P.-A. Lemieux, Ed.
Request for Comments: 9828 Sandflow Consulting LLC Request for Comments: 9828 Sandflow Consulting LLC
Category: Standards Track D. Taubman Category: Standards Track D. Taubman
ISSN: 2070-1721 University of New South Wales ISSN: 2070-1721 University of New South Wales
August 2025 August 2025
RTP Payload Format for Sub-Codestream Latency JPEG 2000 Streaming RTP Payload Format for Sub-Codestream Latency JPEG 2000 Streaming
Abstract Abstract
This document defines the RTP payload format for the streaming of a This document defines the RTP payload format for the streaming of a
skipping to change at line 120 skipping to change at line 120
In addition to supporting a variety of frame-scanning techniques In addition to supporting a variety of frame-scanning techniques
(progressive, interlaced, and progressive segmented frame) and image (progressive, interlaced, and progressive segmented frame) and image
characteristics, the payload format supports real-time image characteristics, the payload format supports real-time image
transmission (live streaming), where image content is encoded, transmission (live streaming), where image content is encoded,
transmitted, and decoded continuously as it is being produced, with transmitted, and decoded continuously as it is being produced, with
minimal latency. Target applications include real-time TV production minimal latency. Target applications include real-time TV production
over IP [OV2110-0], remote presence, surveillance, etc. over IP [OV2110-0], remote presence, surveillance, etc.
Specifically: Specifically:
* The payload format allows sub-codestream latency such that the * The payload format allows sub-codestream latency such that the
first RTP packet of a given codestream to be emitted before the first RTP packet of a given codestream can be emitted before the
entire codestream is available. Specifically, the payload format entire codestream is available. Specifically, the payload format
does not rely on the JPEG 2000 PLM (Packet length, main header) does not rely on the JPEG 2000 PLM (Packet length, main header)
and PLT (Packet length, tile-part header) marker segments for and PLT (Packet length, tile-part header) marker segments for
recovery after RTP packet loss since these markers can only be recovery after RTP packet loss since these markers can only be
written after the codestream is complete and are thus incompatible written after the codestream is complete and are thus incompatible
with sub-codestream latency. Instead, the payload format includes with sub-codestream latency. Instead, the payload format includes
payload header fields (ORDH, ORDB, POS, and PID) that indicate payload header fields (ORDH, ORDB, POS, and PID) that indicate
whether the RTP packet contains a resynchronization (resync) point whether the RTP packet contains a resynchronization (resync) point
and how a recipient can restart codestream processing from that and how a recipient can restart codestream processing from that
resync point. This contrasts with [RFC5371], which also specifies resync point. This contrasts with [RFC5371], which also specifies
an RTP payload format for JPEG 2000 but relies on codestream an RTP payload format for JPEG 2000 but relies on codestream
structures that cannot be emitted until the entire codestream is structures that cannot be emitted until the entire codestream is
available. available.
* As in [RFC4175], the payload format defines an extended sequence * As in [RFC4175], the payload format defines an extended sequence
number, which extends the standard (16-bit) sequence number of the number, which extends the standard (16-bit) sequence number of the
RTP fixed header by storing additional (high-order) bits in the RTP Fixed Header by storing additional (high-order) bits in the
payload header (ESEQ field). This enables the payload format to payload header (ESEQ field). This enables the payload format to
accommodate high data rates without ambiguity, since the standard accommodate high data rates without ambiguity, since the standard
sequence number will roll over very quickly for high data rates sequence number will roll over very quickly for high data rates
likely to be encountered in this application. For example, the likely to be encountered in this application. For example, the
standard sequence number will roll over in 0.5 seconds with a 1 standard sequence number will roll over in 0.5 seconds with a 1
Gbps video stream with RTP packet sizes of at least 1000 octets, Gbps video stream with RTP packet sizes of at least 1000 octets,
which can be a problem for detecting loss and out-of-order RTP which can be a problem for detecting loss and out-of-order RTP
packets, particularly in instances where the round-trip time is packets, particularly in instances where the round-trip time is
greater than the rollover period (0.5 seconds in this example). greater than the rollover period (0.5 seconds in this example).
skipping to change at line 167 skipping to change at line 167
* code-block caching for screen content (see Section 7.9); * code-block caching for screen content (see Section 7.9);
* progressive segmented frame (PsF) video support (see Appendix B); * progressive segmented frame (PsF) video support (see Appendix B);
and and
* explicit colorspace signaling (see Section 5.3). * explicit colorspace signaling (see Section 5.3).
Finally, the payload format also makes use of the unique scalability Finally, the payload format also makes use of the unique scalability
features of JPEG 2000 to allow an intermediate system or recipient to features of JPEG 2000 to allow an intermediate system or recipient to
discard resolutions levels and/or quality layers merely by inspecting discard resolution levels and/or quality layers merely by inspecting
RTP packet headers (QUAL and RES fields), without having to parse the RTP packet headers (QUAL and RES fields), without having to parse the
underlying codestream (see Section 7.2). underlying codestream (see Section 7.2).
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at line 253 skipping to change at line 253
successive resolution level has half the horizontal and half the successive resolution level has half the horizontal and half the
vertical resolution of the previous one. vertical resolution of the previous one.
The coded image data ultimately consists of code-blocks, each The coded image data ultimately consists of code-blocks, each
containing coded samples belonging to a rectangular (spatial) region containing coded samples belonging to a rectangular (spatial) region
within one resolution level of one component. Code-blocks are within one resolution level of one component. Code-blocks are
further collected into precincts, which, accordingly, represent code- further collected into precincts, which, accordingly, represent code-
blocks belonging to a spatial region within one resolution level of blocks belonging to a spatial region within one resolution level of
one component. one component.
The image coded data can be arranged into several progression orders, The coded image data can be arranged into several progression orders,
which dictates which aspect of the image appears first in the which dictates which aspect of the image appears first in the
codestream (in terms of byte offset). The progression orders are codestream (in terms of byte offset). The progression orders are
parameterized according to: parameterized according to:
Position (P) Position (P)
The first lines of the image come before the last lines of the The first lines of the image come before the last lines of the
image. image.
Component (C) Component (C)
The first component of the image comes before the last component The first component of the image comes before the last component
skipping to change at line 427 skipping to change at line 427
sequence number sequence number
The low-order bits of the extended sequence number. The low-order bits of the extended sequence number.
The high-order bits of the extended sequence number are contained The high-order bits of the extended sequence number are contained
in the ESEQ field, which is specified in Section 5.3. in the ESEQ field, which is specified in Section 5.3.
The extended sequence number is calculated as follows: The extended sequence number is calculated as follows:
<extended sequence number> = <ESEQ field> * 65536 + <sequence <extended sequence number> = <ESEQ field> * 65536 + <sequence
number field of the RTP fixed header> number field of the RTP Fixed Header>
5.3. Main Packet Payload Header 5.3. Main Packet Payload Header
Figure 2 specifies the structure of the payload header. Fields are Figure 2 specifies the structure of the payload header. Fields are
interpreted as unsigned binary integers in network order. interpreted as unsigned binary integers in network order.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MH | TP |ORDH |P|XTRAC| PTSTAMP | ESEQ | |MH | TP |ORDH |P|XTRAC| PTSTAMP | ESEQ |
skipping to change at line 489 skipping to change at line 489
field is the first line of the frame. field is the first line of the frame.
5 Segment 1 of a progressive segmented frame, where the first 5 Segment 1 of a progressive segmented frame, where the first
line of the image is the first line of the frame. line of the image is the first line of the frame.
6 Segment 2 of a progressive segmented frame, where the first 6 Segment 2 of a progressive segmented frame, where the first
line of the image is the second line of the frame. line of the image is the second line of the frame.
7 Extension value. See Sections 8.6 and 7.8. 7 Extension value. See Sections 8.6 and 7.8.
ORDH (Progression Order [Main Packet]): 3 bits ORDH (Progression Order Flag, Main Packet): 3 bits
Specifies the progression order used by the codestream and whether Specifies the progression order used by the codestream and whether
resync points are signaled. resync points are signaled. See Section 3 for details about
progression orders.
0 Resync points are not necessarily signaled. The progression 0 Resync points are not necessarily signaled. The progression
order can vary over the codestream. order can vary over the codestream.
1 The progression order is LRCP for the entire codestream. The 1 The progression order is LRCP for the entire codestream. The
first resync point is specified in every Body Packet that first resync point is specified in every Body Packet that
contains one or more resync points. contains one or more resync points.
2 The progression order is RLCP for the entire codestream. The 2 The progression order is RLCP for the entire codestream. The
first resync point is specified in every Body Packet that first resync point is specified in every Body Packet that
skipping to change at line 527 skipping to change at line 528
6 The progression order is PRCL for the entire codestream. The 6 The progression order is PRCL for the entire codestream. The
first resync point is specified in every Body Packet that first resync point is specified in every Body Packet that
contains one or more resync points. contains one or more resync points.
7 The progression order can vary over the codestream. The first 7 The progression order can vary over the codestream. The first
resync point is specified in every Body Packet that contains resync point is specified in every Body Packet that contains
one or more resync points. one or more resync points.
ORDH MUST be 0 if the codestream consists of more than one tile. ORDH MUST be 0 if the codestream consists of more than one tile.
NOTE: Only ORDH = 4 and ORDH = 6 allow sub-codestream latency NOTE 1: Only ORDH = 4 and ORDH = 6 allow sub-codestream latency
streaming. streaming.
NOTE: Progression order PRCL is defined in [JPEG2000-2]. The NOTE 2: Progression order PRCL is defined in [JPEG2000-2]. The
other progression orders are specified in [JPEG2000-1]. other progression orders are specified in [JPEG2000-1].
P (Precision Timestamp Presence): 1 bit P (Precision Timestamp Presence): 1 bit
0 PTSTAMP is not used. 0 PTSTAMP is not used.
1 PTSTAMP is used. 1 PTSTAMP is used.
XTRAC (Extension Payload Length): 3 bits XTRAC (Extension Payload Length): 3 bits
skipping to change at line 556 skipping to change at line 557
of this codestream. of this codestream.
TOFF is the transmission time of this RTP packet, in the timebase TOFF is the transmission time of this RTP packet, in the timebase
of the timestamp clock and relative to the first RTP packet with of the timestamp clock and relative to the first RTP packet with
the same timestamp value. the same timestamp value.
TOFF = 0 in the first RTP packet with the same timestamp value. TOFF = 0 in the first RTP packet with the same timestamp value.
PTSTAMP = 0, if P = 0 in the Main Packet of this codestream. PTSTAMP = 0, if P = 0 in the Main Packet of this codestream.
NOTE: As described in Sections 7.4 and 8.1, PTSTAMP is intended to NOTE 3: As described in Sections 7.4 and 8.1, PTSTAMP is intended
improve clock recovery at the receiver and only applies when the to improve clock recovery at the receiver and only applies when
transmission time of two consecutive RTP packets with identical the transmission time of two consecutive RTP packets with
timestamp fields differ by no more than 45 ms = 4095/90,000. identical timestamp fields differ by no more than 45 ms (which is
[RFC5450] addresses the general case when an RTP packet is 4095/90,000). [RFC5450] addresses the general case when an RTP
transmitted at a time other than its nominal transmission time. packet is transmitted at a time other than its nominal
transmission time.
ESEQ (Extended Sequence Number High-Order Bits): 8 bits ESEQ (Extended Sequence Number High-Order Bits): 8 bits
The high-order bits of the extended sequence number. The high-order bits of the extended sequence number.
NOTE: The low-order bits of the extended sequence number are NOTE 4: The low-order bits of the extended sequence number are
stored in the sequence number field of the RTP fixed header. stored in the sequence number field of the RTP Fixed Header.
Section 5.2 specifies the formula to compute the extended sequence Section 5.2 specifies the formula to compute the extended sequence
number. number.
R (Codestream Main Header Reuse): 1 bit R (Codestream Main Header Reuse): 1 bit
Determines whether Main Packet and codestream main header Determines whether Main Packet and codestream main header
information can be reused across codestreams. information can be reused across codestreams.
1 All Main Packets in this stream, as identified by the value of 1 All Main Packets in this stream, as identified by the value of
the SSRC field in the RTP Fixed Header: the SSRC field in the RTP Fixed Header:
* MUST have identical Main Packet Payload Headers, with the * MUST have identical Main Packet Payload Headers, with the
exception of their TP, MH, ESEQ, and PTSTAMP fields; exception of their TP, MH, ESEQ, and PTSTAMP fields;
* MUST contain the same codestream main header information, * MUST contain the same codestream main header information
with the exception of the SOT and COM marker segments, and (with the exception of the SOT and COM marker segments and
any pointer marker segments; and any pointer marker segments); and
* MUST NOT contain bytes other than Extended Header bytes. * MUST NOT contain bytes other than Extended Header bytes.
0 Otherwise 0 Otherwise
S (Parameterized Colorspace Presence): 1 bit S (Parameterized Colorspace Presence): 1 bit
0 Component colorimetry is not specified; it is left to the 0 Component colorimetry is not specified; it is left to the
session or the application. session or the application.
skipping to change at line 699 skipping to change at line 701
RES (Resolution Levels): 3 bits RES (Resolution Levels): 3 bits
0 The payload can contribute to all resolution levels. 0 The payload can contribute to all resolution levels.
Otherwise The payload contains at least one byte of one JPEG 2000 Otherwise The payload contains at least one byte of one JPEG 2000
packet belonging to resolution level (N_L + RES - 7) but does packet belonging to resolution level (N_L + RES - 7) but does
not contain any byte of any JPEG 2000 packet belonging to lower not contain any byte of any JPEG 2000 packet belonging to lower
resolution levels. N_L is the number of decomposition levels resolution levels. N_L is the number of decomposition levels
of the codestream. of the codestream.
ORDB (Progression Order [Body Packet]): 1 bit ORDB (Progression Order Flag, Body Packet): 1 bit
0 No resync point is specified for the payload. 0 No resync point is specified for the payload.
1 The payload contains a resync point. 1 The payload contains a resync point.
ORDB MUST be 0 if the codestream consists of more than one tile. ORDB MUST be 0 if the codestream consists of more than one tile.
QUAL (Quality Layers): 3 bits QUAL (Quality Layers): 3 bits
0 The payload can contribute to all quality layers. 0 The payload can contribute to all quality layers.
skipping to change at line 733 skipping to change at line 735
POS MUST be 0 if ORDB = 0. POS MUST be 0 if ORDB = 0.
PID (Precinct Identifier): 20 bits PID (Precinct Identifier): 20 bits
Unique identifier of the precinct of the resync point. Unique identifier of the precinct of the resync point.
PID = c + s * num_components PID = c + s * num_components
where: where:
* _c_ is the index (starting from 0) of the image component to c: Index (starting from 0) of the image component to which the
which the precinct belongs; precinct belongs.
* _s_ is a sequence number that identifies the precinct within s: Sequence number that identifies the precinct within its tile-
its tile-component; and component.
* _num_components_ is the number of components of the codestream. num_components: Number of components of the codestream.
If PID is present, the payload MUST NOT contain codestream bytes If PID is present, the payload MUST NOT contain codestream bytes
from more than one precinct. from more than one precinct.
PID MUST be 0 if ORDB = 0. PID MUST be 0 if ORDB = 0.
NOTE: PID is identical to precinct identifier I specified in NOTE: PID is identical to precinct identifier I specified in
[JPEG2000-9]. [JPEG2000-9].
6. JPEG 2000 Codestream 6. JPEG 2000 Codestream
A JPEG 2000 codestream consists of the bytes between, and including, A JPEG 2000 codestream consists of the bytes between, and including,
the SOC and EOC markers, as defined in [JPEG2000-1]. the SOC and EOC markers, as defined in [JPEG2000-1].
The JPEG 2000 codestream MAY include capabilities beyond those The JPEG 2000 codestream MAY include capabilities beyond those
specified in [JPEG2000-1], including those specified in [JPEG2000-2] specified in [JPEG2000-1], including those specified in [JPEG2000-2]
and [JPEG2000-15]. and [JPEG2000-15].
NOTE: The Rsiz parameter and CAP marker segments of each JPEG 2000 NOTE 1: The Rsiz parameter and CAP marker segments of each JPEG 2000
codestream contain detailed information on the capabilities necessary codestream contain detailed information on the capabilities necessary
to decode the codestream. to decode the codestream.
NOTE: The caps media type parameter defined in Section 9.2 allows NOTE 2: The caps media type parameter defined in Section 9.2 allows
applications to signal required device capabilities. applications to signal required device capabilities.
NOTE: The block coder specified in [JPEG2000-15] improves throughput NOTE 3: The block coder specified in [JPEG2000-15] improves
and reduces latency compared to the original arithmetic block coder throughput and reduces latency compared to the original arithmetic
defined in [JPEG2000-1]. block coder defined in [JPEG2000-1].
For interlaced or progressive segmented frames, the height specified For interlaced or progressive segmented frames, the height specified
in the JPEG 2000 main header MUST be the height in lines of the field in the JPEG 2000 main header MUST be the height in lines of the field
or the segment, respectively. or the segment, respectively.
If any decomposition level involves only horizontal decomposition, If any decomposition level involves only horizontal decomposition,
then no decomposition level MUST involve only vertical decomposition; then no decomposition level MUST involve only vertical decomposition;
conversely, if any decomposition level involves only vertical conversely, if any decomposition level involves only vertical
decomposition, then no decomposition level MUST involve only decomposition, then no decomposition level MUST involve only
horizontal decomposition. horizontal decomposition.
skipping to change at line 810 skipping to change at line 812
An intermediate system MAY strip out RTP packets from a codestream An intermediate system MAY strip out RTP packets from a codestream
that are of no interest to a particular client, e.g., based on a that are of no interest to a particular client, e.g., based on a
resolution or a spatial region of interest. resolution or a spatial region of interest.
7.3. Resync Point 7.3. Resync Point
A resync point is the first byte of JPEG 2000 packet header data for A resync point is the first byte of JPEG 2000 packet header data for
a precinct and for which PID < 2^24. a precinct and for which PID < 2^24.
NOTE: Resync points cannot be specified if the codestream consists of NOTE 1: Resync points cannot be specified if the codestream consists
more than one tile (ORDB and ORDH are both equal to zero). of more than one tile (ORDB and ORDH are both equal to zero).
NOTE: A resync point can be used by a receiver to process a NOTE 2: A resync point can be used by a receiver to process a
codestream even if earlier RTP packets in the codestream have been codestream even if earlier RTP packets in the codestream have been
corrupted, lost, or deliberately discarded by an intermediate system. corrupted, lost, or deliberately discarded by an intermediate system.
As a corollary, resync points can be used by an intermediate system As a corollary, resync points can be used by an intermediate system
to discard RTP packets that are not relevant to a given rendering to discard RTP packets that are not relevant to a given rendering
resolution or region of interest. Resync points play a role similar resolution or region of interest. Resync points play a role similar
to pointer marker segments, albeit tailored for high-bandwidth, low- to pointer marker segments, albeit tailored for high-bandwidth, low-
latency streaming applications. latency streaming applications.
7.4. PTSTAMP Field 7.4. PTSTAMP Field
A sender SHOULD set P = 1, but only if it can generate PTSTAMP A sender SHOULD set P = 1, but only if it can generate PTSTAMP
accurately. accurately.
PTSTAMP can be derived from the same clock that is used to produce PTSTAMP can be derived from the same clock that is used to produce
the 32-bit timestamp field in the RTP fixed header. Specifically, a the 32-bit timestamp field in the RTP Fixed Header. Specifically, a
sender maintains, at least conceptually, a 32-bit counter that is sender maintains, at least conceptually, a 32-bit counter that is
incremented by a 90 kHz clock. The counter is sampled at the point incremented by a 90 kHz clock. The counter is sampled at the point
in time when each RTP packet is transmitted and the 12 LSBs of the in time when each RTP packet is transmitted and the 12 least
sample are stored in the PTSTAMP field. significant bits of the sample are stored in the PTSTAMP field.
If P = 1, then the transmission time TOFF (as defined in Section 5.3) If P = 1, then the transmission time TOFF (as defined in Section 5.3)
for two consecutive RTP packets with identical timestamp fields MUST for two consecutive RTP packets with identical timestamp fields MUST
NOT differ by more than 4095. NOT differ by more than 4095.
7.5. RES Field 7.5. RES Field
A sender SHOULD set RES > 0 whenever possible. A sender SHOULD set RES > 0 whenever possible.
NOTE: While a sender can always safely set RES = 0, this makes it NOTE: While a sender can always safely set RES = 0, this makes it
skipping to change at line 873 skipping to change at line 875
7.8. Extension Values 7.8. Extension Values
A sender MUST NOT use an extension value. A sender MUST NOT use an extension value.
7.9. Code-Block Caching 7.9. Code-Block Caching
This section only applies if C = 1. This section only applies if C = 1.
A sender can improve bandwidth efficiency by only occasionally A sender can improve bandwidth efficiency by only occasionally
transmitting code-blocks corresponding to static portions of the transmitting code-blocks corresponding to static portions of the
video and otherwise transmitting empty code-blocks. When C = 1, and video and otherwise transmitting empty code-blocks. When C = 1, a
as described in Section 8.7, a receiver maintains a simple cache of receiver maintains a simple cache of previously received code-blocks,
previously received code-blocks, which it uses to replace empty code- which it uses to replace empty code-blocks (see Section 8.7).
blocks.
A sender alone determines which code-blocks are replaced with empty A sender alone determines which code-blocks are replaced with empty
code-blocks and when the replacement occurs. code-blocks and when the replacement occurs.
The sender cannot, however, determine with certainty the state of the The sender cannot, however, determine with certainty the state of the
receiver's cache; for example, some code-blocks might have been lost receiver's cache; for example, some code-blocks might have been lost
in transit, the sender doesn't know exactly when the receiver started in transit, the sender doesn't know exactly when the receiver started
processing the stream, etc. processing the stream, etc.
A code-block is _empty_ if: A code-block is _empty_ if:
skipping to change at line 1015 skipping to change at line 1016
| 5 | 0 | LX5 | 2 | (W/32) x | | 5 | 0 | LX5 | 2 | (W/32) x |
| | | | | (H/2) | | | | | | (H/2) |
+---------------+------------+-------------+-----------+------------+ +---------------+------------+-------------+-----------+------------+
Table 3: Optional discarding of Body Packets based on the value Table 3: Optional discarding of Body Packets based on the value
of the RES field when decoding a reduced resolution image, in the of the RES field when decoding a reduced resolution image, in the
case where N_L = 5 and some DWT stages consist of only horizontal case where N_L = 5 and some DWT stages consist of only horizontal
transforms. The image has nominal width and height of W x H. transforms. The image has nominal width and height of W x H.
Table 3 illustrates the case where some DWT stages consist of only Table 3 illustrates the case where some DWT stages consist of only
horizontal transforms, as specified at Annex F of [JPEG2000-2]. horizontal transforms, as specified in Annex F of [JPEG2000-2].
A receiver can therefore discard all Body Packets where RES is A receiver can therefore discard all Body Packets where RES is
greater than some threshold value if it is interested in decoding an greater than some threshold value if it is interested in decoding an
image with its resolution reduced by a factor determined by the image with its resolution reduced by a factor determined by the
threshold value, as illustrated in Tables 2 and 3. threshold value, as illustrated in Tables 2 and 3.
8.4. Extra Information 8.4. Extra Information
The receiver MUST accept values of XTRAC other than 0 and MUST ignore The receiver MUST accept values of XTRAC other than 0 and MUST ignore
the value of XTRAB, whose length is given by XTRAC. the value of XTRAB, whose length is given by XTRAC.
skipping to change at line 1045 skipping to change at line 1046
8.6. Extension Values 8.6. Extension Values
The receiver MUST discard an RTP packet that contains any extension The receiver MUST discard an RTP packet that contains any extension
value. value.
8.7. Code-Block Caching 8.7. Code-Block Caching
This section only applies if C = 1. This section only applies if C = 1.
When C = 1, and as specified in Section 7.9, the sender can improve When C = 1, the sender can improve bandwidth efficiency by only
bandwidth efficiency by only occasionally transmitting code-blocks occasionally transmitting code-blocks corresponding to static
corresponding to static portions of the video and otherwise portions of the video and otherwise transmitting empty code-blocks
transmitting empty code-blocks, as defined in Section 7.9. (see Section 7.9).
When decoding a codestream, and for each code-block in the When decoding a codestream, the following procedures apply for each
codestream: code-block in the codestream:
* If the code-block in the codestream is empty, the receiver MUST * If the code-block in the codestream is empty, the receiver MUST
replace it with a matching code-block from the cache, if one replace it with a matching code-block from the cache, if one
exists. exists.
* If the code-block in the codestream is not empty, the receiver * If the code-block in the codestream is not empty, the receiver
MUST replace any matching code-block from the cache with the code- MUST replace any matching code-block from the cache with the code-
block in the codestream. block in the codestream.
Two code-blocks are _matching_ if the following characteristics are Two code-blocks are _matching_ if the following characteristics are
skipping to change at line 1250 skipping to change at line 1251
* a sender can offer several alternative streams for a given video * a sender can offer several alternative streams for a given video
signal, each with a different data rate corresponding to a signal, each with a different data rate corresponding to a
different compression ratio; different compression ratio;
* a sender can modulate the data rate within a stream by modulating * a sender can modulate the data rate within a stream by modulating
the resolution, frame rate, or compression ratio of the underlying the resolution, frame rate, or compression ratio of the underlying
video signal; or video signal; or
* an intermediate system can lower the data rate of a stream by * an intermediate system can lower the data rate of a stream by
discarding resolutions levels and/or quality layers, as specified discarding resolution levels and/or quality layers, as specified
in Section 7.2. in Section 7.2.
As suggested in Section 10 of [RFC3550], RTCP feedback can be used in As suggested in Section 10 of [RFC3550], RTCP feedback can be used in
the data rate adaptation process. the data rate adaptation process.
12. IANA Considerations 12. IANA Considerations
IANA has registered the media type specified in Section 9. IANA has registered the media type specified in Section 9.
13. Security Considerations 13. Security Considerations
skipping to change at line 1294 skipping to change at line 1295
14. References 14. References
14.1. Normative References 14.1. Normative References
[JPEG2000-1] [JPEG2000-1]
ITU-T, "Information technology - JPEG 2000 image coding ITU-T, "Information technology - JPEG 2000 image coding
system: Core coding system", ITU-T Recommendation T.800, system: Core coding system", ITU-T Recommendation T.800,
July 2024, <https://www.itu.int/rec/T-REC-T.800/>. July 2024, <https://www.itu.int/rec/T-REC-T.800/>.
[JPEG2000-2]
ITU-T, "Information Technology - JPEG 2000 image coding
system - Extensions", ITU-T Recommendation T.801, August
2023, <https://www.itu.int/rec/T-REC-T.801/>.
[JPEG2000-15] [JPEG2000-15]
ITU-T, "Information technology - JPEG 2000 image coding ITU-T, "Information technology - JPEG 2000 image coding
system: High-throughput JPEG 2000", ITU-T system: High-throughput JPEG 2000", ITU-T
Recommendation T.814, June 2019, Recommendation T.814, June 2019,
<https://www.itu.int/rec/T-REC-T.814/>. <https://www.itu.int/rec/T-REC-T.814/>.
[REC-ITU-T-H273] [JPEG2000-2]
ITU-T, "Coding-independent code points for video signal ITU-T, "Information Technology - JPEG 2000 image coding
type identification", ITU-T Recommendation H.273, July system - Extensions", ITU-T Recommendation T.801, August
2024, <https://www.itu.int/rec/T-REC-H.273>. 2023, <https://www.itu.int/rec/T-REC-T.801/>.
[JPEG2000-9] [JPEG2000-9]
ITU-T, "Information technology - JPEG 2000 image coding ITU-T, "Information technology - JPEG 2000 image coding
system: Interactivity tools, APIs and protocols", ITU-T system: Interactivity tools, APIs and protocols", ITU-T
Recommendation T.808, December 2022, Recommendation T.808, December 2022,
<https://www.itu.int/rec/T-REC-T.808>. <https://www.itu.int/rec/T-REC-T.808>.
[REC-ITU-T-H273]
ITU-T, "Coding-independent code points for video signal
type identification", ITU-T Recommendation H.273, July
2024, <https://www.itu.int/rec/T-REC-H.273>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<https://www.rfc-editor.org/info/rfc4855>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP:
Session Description Protocol", RFC 8866,
DOI 10.17487/RFC8866, January 2021,
<https://www.rfc-editor.org/info/rfc8866>.
14.2. Informative References 14.2. Informative References
[OV2110-0] SMPTE, "Professional Media Over Managed IP Networks, [OV2110-0] SMPTE, "Professional Media Over Managed IP Networks,
Roadmap for the 2110 Document Suite", 4 December 2018, Roadmap for the 2110 Document Suite", 4 December 2018,
<https://pub.smpte.org/latest/ov2110-0/ov2110-0-2018.pdf>. <https://pub.smpte.org/doc/ov2110-0/20181204-pub/>.
[RFC5371] Futemma, S., Itakura, E., and A. Leung, "RTP Payload
Format for JPEG 2000 Video Streams", RFC 5371,
DOI 10.17487/RFC5371, October 2008,
<https://www.rfc-editor.org/info/rfc5371>.
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for
Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175,
September 2005, <https://www.rfc-editor.org/info/rfc4175>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/info/rfc3551>. <https://www.rfc-editor.org/info/rfc3551>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC3745] Singer, D., Clark, R., and D. Lee, "MIME Type
Registrations for JPEG 2000 (ISO/IEC 15444)", RFC 3745,
DOI 10.17487/RFC3745, April 2004,
<https://www.rfc-editor.org/info/rfc3745>.
[RFC4175] Gharai, L. and C. Perkins, "RTP Payload Format for
Uncompressed Video", RFC 4175, DOI 10.17487/RFC4175,
September 2005, <https://www.rfc-editor.org/info/rfc4175>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>. 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5371] Futemma, S., Itakura, E., and A. Leung, "RTP Payload
Format for JPEG 2000 Video Streams", RFC 5371,
DOI 10.17487/RFC5371, October 2008,
<https://www.rfc-editor.org/info/rfc5371>.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009,
<https://www.rfc-editor.org/info/rfc5450>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>. <https://www.rfc-editor.org/info/rfc7201>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <https://www.rfc-editor.org/info/rfc7202>. 2014, <https://www.rfc-editor.org/info/rfc7202>.
[RFC3745] Singer, D., Clark, R., and D. Lee, "MIME Type
Registrations for JPEG 2000 (ISO/IEC 15444)", RFC 3745,
DOI 10.17487/RFC3745, April 2004,
<https://www.rfc-editor.org/info/rfc3745>.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, DOI 10.17487/RFC5450, March 2009,
<https://www.rfc-editor.org/info/rfc5450>.
Appendix A. Pixel Formats Appendix A. Pixel Formats
Table 4 defines pixel formats. Table 4 defines pixel formats.
+=============+=======+=======+=======+=======+===+=====+=========+ +=============+=======+=======+=======+=======+===+=====+=========+
| NAME | SAMP | COMPS | TRANS | PRIMS |MAT| VFR | Mapping | | NAME | SAMP | COMPS | TRANS | PRIMS |MAT| VFR | Mapping |
| | | | | | | | in | | | | | | | | | in |
| | | | | | | | Table 1 | | | | | | | | | Table 1 |
+=============+=======+=======+=======+=======+===+=====+=========+ +=============+=======+=======+=======+=======+===+=====+=========+
| rgb444sdr | 4:4:4 | RGB | 1 | 1 |0 | 0, | RGB | | rgb444sdr | 4:4:4 | RGB | 1 | 1 |0 | 0, | RGB |
 End of changes. 41 change blocks. 
102 lines changed or deleted 103 lines changed or added

This html diff was produced by rfcdiff 1.48.