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. |