rfc9828.original.xml   rfc9828.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
category="std" ipr="trust200902" consensus="true" std" ipr="trust200902" consensus="true" docName="draft-ietf-avtcore-rtp-j2k-scl-
docName="draft-ietf-avtcore-rtp-j2k-scl-08" xml:lang="en" version="3"> 08" number="9828" updates="" obsoletes="" sortRefs="false" symRefs="true" xml:la
<front> ng="en" version="3">
<title abbrev="Sub-codestream latency J2K over RTP">RTP Payload Format for
sub-codestream latency JPEG 2000 streaming</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-avtcore-rtp-j2k-scl-08"/ > <!-- [rfced] Document title
<author initials='P.-A.' surname='Lemieux' fullname='Pierre-Anthony Lemieux' a) Please review the document title, especially "sub-codestream latency JPEG
role="editor"> 2000 streaming". Would updating as follows (or in another way) improve
clarity?
Original:
RTP Payload Format for sub-codestream latency JPEG 2000 streaming
Current (title case):
RTP Payload Format for Sub-Codestream Latency JPEG 2000 Streaming
Perhaps:
RTP Payload Format for JPEG 2000 Streaming and Sub-Codestream Latency
b) We updated the abbreviated title (appears in the running header at the top
of each page in the pdf output) as follows because "JPEG 2000" (rather than "J2K
")
is used in this document. Are any further updates needed to align with the
document title?
Original:
Sub-codestream latency J2K over RTP
Current:
Sub-Codestream Latency JPEG 2000 over RTP
-->
<front>
<title abbrev="Sub-Codestream Latency JPEG 2000 over RTP">RTP Payload Format
for
Sub-Codestream Latency JPEG 2000 Streaming</title>
<seriesInfo name="RFC" value="9828"/>
<!-- [rfced] This is a question for Pierre-Anthony. In the first-page header
for this document, your name appears as "P.-A. Lemieux". However, we note
that in RFCs 7302 and 7972, your name appears as "P. Lemieux". We have
updated to use the single initial for consistency with those RFCs, but
please let us know if you prefer otherwise.
-->
<author initials='P.' surname='Lemieux' fullname='Pierre-Anthony Lemieux' ro le="editor">
<organization>Sandflow Consulting LLC</organization> <organization>Sandflow Consulting LLC</organization>
<address> <address>
<postal> <postal>
<city>San Mateo</city> <city>San Mateo</city>
<region>CA</region> <region>CA</region>
<country>US</country> <country>United States of America</country>
</postal> </postal>
<email>pal@sandflow.com</email> <email>pal@sandflow.com</email>
</address> </address>
</author> </author>
<author initials='D. S.' surname='Taubman' fullname='David Scott Taubman'> <author initials='D.' surname='Taubman' fullname='David Scott Taubman'>
<organization abbrev="University of New South Wales">University of New <organization abbrev="University of New South Wales">University of New
South Wales</organization> South Wales</organization>
<address> <address>
<postal> <postal>
<city>Sydney</city> <city>Sydney</city>
<country>AU</country> <country>Australia</country>
</postal> </postal>
<email>d.taubman@unsw.edu.au</email> <email>d.taubman@unsw.edu.au</email>
</address> </address>
</author> </author>
<date month="August" year="2025"/>
<area>Applications and Real-Time Area</area> <area>WIT</area>
<workgroup>Audio/Video Transport Core Maintenance</workgroup> <workgroup>avtcore</workgroup>
<keyword>JPEG 2000</keyword> <keyword>JPEG 2000</keyword>
<keyword>J2K</keyword> <keyword>J2K</keyword>
<keyword>HTJ2K</keyword> <keyword>HTJ2K</keyword>
<keyword>low latency</keyword> <keyword>low latency</keyword>
<keyword>scalable</keyword> <keyword>scalable</keyword>
<keyword>streaming</keyword> <keyword>streaming</keyword>
<!-- [rfced] Abstract: We have updated this sentence as follows. Let us know
any concerns.
Original:
This RTP payload format defines the streaming of a video signal
encoded as a sequence of JPEG 2000 codestreams.
Perhaps:
This document defines the RTP payload format for the streaming of a video sig
nal
encoded as a sequence of JPEG 2000 codestreams.
-->
<abstract> <abstract>
<t>This RTP payload format defines the streaming of a video signal encoded <t>This document defines the RTP payload format for the streaming of a vid eo signal encoded
as a sequence of JPEG 2000 codestreams. The format allows sub-codestream as a sequence of JPEG 2000 codestreams. The format allows sub-codestream
latency, such that the first RTP packet for a given image can be emitted latency, such that the first RTP packet for a given image can be emitted
before the entire image is available to, or encoded by, the sender.</t> before the entire image is available to or encoded by the sender.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<t>The real-time transport protocol (RTP), which is specified in <xref <t>The Real-time Transport Protocol (RTP), which is specified in <xref
target="RFC3550"/>, provides end-to-end network transport functions for target="RFC3550"/>, provides end-to-end network transport functions for
transmitting real-time data, but does not define the characteristics of transmitting real-time data but does not define the characteristics of
the data itself (the payload), which varies across applications and is the data itself (the payload), which varies across applications and is
defined in companion RTP payload format documents.</t> defined in companion RTP payload format documents.</t>
<t>This RTP payload format specifies the streaming of a video signal <t>This RTP payload format specifies the streaming of a video signal
encoded as a sequence of JPEG 2000 codestreams (see <xref encoded as a sequence of JPEG 2000 codestreams (see <xref
target="sec-media-description"/> for a primer on the structure of JPEG target="sec-media-description"/> for a primer on the structure of JPEG
2000 codestreams). JPEG 2000 is a flexible image codec that supports 2000 codestreams). JPEG 2000 is a flexible image codec that supports
resolution and quality scalability, lossy to lossless coding, resolution and quality scalability, lossy-to-lossless coding,
non-iterative optimal rate control, and high-dynamic range, multi-channel non-iterative optimal rate control, and high dynamic range, multi-channel,
and sub-sampled images. These features have made it a mainstay in and subsampled images. These features have made it a mainstay in
high-performance applications, including medical, geospatial, archival, high-performance applications, including medical, geospatial, archival,
cinema, studio post-production and TV production.</t> cinema, studio post-production, and TV production.</t>
<t>In addition to supporting a variety of frame scanning techniques <t>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 transmission characteristics, the payload format supports real-time image transmission
(live streaming), where image content is encoded, transmitted and decoded (live streaming), where image content is encoded, transmitted, and decoded
continuously as it is being produced and with minimal latency. Target continuously as it is being produced, with minimal latency. Target
applications include real-time TV production over IP (<xref applications include real-time TV production over IP <xref
target="ov2110-0"/>), remote presence, surveillance, etc. target="OV2110-0"/>, remote presence, surveillance, etc.
Specifically:</t> Specifically:</t>
<!-- [rfced] Please clarify "to be emitted" here.
Original:
* the payload format allows sub-codestream latency such that the
first RTP packet of a given codestream to be emitted before the
entire codestream is available.
Perhaps:
* The payload format allows sub-codestream latency such that the
first RTP packet of a given codestream is emitted before the
entire codestream is available.
Or:
* The payload format allows sub-codestream latency such that the
first RTP packet of a given codestream can be emitted before the
entire codestream is available.
-->
<ul> <ul>
<li>the payload format allows sub-codestream latency such that the first <li>The payload format allows sub-codestream latency such that the first
RTP packet of a given codestream to be emitted before the entire RTP packet of a given codestream to be emitted before the entire
codestream is available. Specifically, the payload format does not rely codestream is available. Specifically, the payload format does not rely
on the JPEG 2000 PLM and PLT marker segments for recovery after RTP on the JPEG 2000 PLM (Packet length, main header) and PLT (Packet length
Packet loss since these markers can only be written after the codestream , tile-part header) marker segments for recovery after RTP
packet loss since these markers can only be written after the codestream
is complete and are thus incompatible with sub-codestream latency. is complete and are thus incompatible with sub-codestream latency.
Instead, the payload format includes payload header fields Instead, the payload format includes payload header fields
(<tt>ORDH</tt>, <tt>ORDB</tt>, <tt>POS</tt> and <tt>PID</tt>) that (<tt>ORDH</tt>, <tt>ORDB</tt>, <tt>POS</tt>, and <tt>PID</tt>) that
indicates whether the RTP packet contains a resynchronization (resync) indicate whether the RTP packet contains a resynchronization (resync)
point and how a recipient can restart codestream processing from that point and how a recipient can restart codestream processing from that
resync point. This contrasts with <xref target="RFC5371"/>, which also resync point. This contrasts with <xref target="RFC5371"/>, which also
specifies an RTP payload format for JPEG 2000, but relies on codestream specifies 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.</li> available.</li>
<li>as in <xref target="RFC4175"/>, the payload format defines an <li>As in <xref target="RFC4175"/>, the payload format defines an
extended sequence number, which extends the standard (16-bit) sequence extended sequence number, which extends the standard (16-bit) sequence
number of the RTP fixed header by storing additional (high-order) bits number of the RTP fixed header by storing additional (high-order) bits
in the payload header (<tt>ESEQ</tt> field). This enables the payload in the payload header (<tt>ESEQ</tt> field). This enables the payload
format to accommodate high data rates without ambiguity, since the format to accommodate high data rates without ambiguity, since the
standard sequence number will roll over very quickly for high data rates standard sequence number will roll over very quickly for high data rates
likely to be encountered in this application. For example, the standard likely to be encountered in this application. For example, the standard
sequence number will roll over in 0.5 seconds with a 1-Gbps video stream sequence number will roll over in 0.5 seconds with a 1 Gbps video stream
with RTP Packet sizes of at least 1000 octets, which can be a problem with RTP packet sizes of at least 1000 octets, which can be a problem
for detecting loss and out-of-order RTP packets particularly in for detecting loss and out-of-order RTP packets, particularly in
instances where the round-trip time is greater than the roll over period instances where the round-trip time is greater than the rollover period
(0.5 seconds in this example).</li> (0.5 seconds in this example).</li>
<li>the payload header optionally contains a temporal offset <li>The payload header optionally contains a temporal offset
(<tt>PTSTAMP</tt>) relative to the first RTP Packet with the same value (<tt>PTSTAMP</tt>) relative to the first RTP packet with the same value
of RTP <tt>timestamp</tt> field (<xref target="def-timestamp"/>). The of RTP <tt>timestamp</tt> field (<xref target="def-timestamp"/>). The
higher resolution of <tt>PTSTAMP</tt> compared to the <tt>timestamp</tt> higher resolution of <tt>PTSTAMP</tt> compared to the <tt>timestamp</tt>
allows receivers to recover the sender's clock more rapidly.</li> allows receivers to recover the sender's clock more rapidly.</li>
</ul> </ul>
<t>In addition to support for sub-codestream latency and high-precision <t>In addition to support for sub-codestream latency and high-precision
sender clock recovery, the payload format improves on <xref sender clock recovery, the payload format improves on <xref
target="RFC5371"/> by supporting:</t> target="RFC5371"/> by supporting:</t>
<ul> <ul>
<li>code-block caching for screen content (see <xref <li>code-block caching for screen content (see <xref
target="sec-send-block-caching"/>);</li> target="sec-send-block-caching"/>);</li>
<li>progressive-segmented frame (PsF) video support (see <xref <li>progressive segmented frame (PsF) video support (see <xref
target="sec-signal-fmts"/>; and</li> target="sec-signal-fmts"/>); and</li>
<li>explicit colorspace signaling (see <xref target="def-S"/>.</li> <li>explicit colorspace signaling (see <xref target="def-S"/>).</li>
</ul> </ul>
<t>Finally, the payload format also makes use of the unique scalability <t>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 RTP discard resolutions levels and/or quality layers merely by inspecting RTP
Packet headers (<tt>QUAL</tt> and <tt>RES</tt> fields), without having to packet headers (<tt>QUAL</tt> and <tt>RES</tt> fields), without having to
parse the underlying codestream (see <xref target="sec-filtering"/>).</t> parse the underlying codestream (see <xref target="sec-filtering"/>).</t>
</section> </section>
<section> <section>
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>In case of conflict between the contents of a figure and the prose, the <t>In case of conflict between the contents of a figure and the prose, the
prose takes precedence.</t> prose takes precedence.</t>
</section> </section>
<section anchor="sec-media-description"> <section anchor="sec-media-description">
<name>Media format description</name> <name>Media Format Description</name>
<t>The following summarizes the structure of the JPEG 2000 codestream, <t>The following summarizes the structure of the JPEG 2000 codestream,
which is specified in detail at <xref target="jpeg2000-1"/>.</t> which is specified in detail in <xref target="JPEG2000-1"/>.</t>
<t>NOTE: as described at <xref target="sec-codestream"/>, a JPEG 2000 <t>NOTE: As described in <xref target="sec-codestream"/>, a JPEG 2000
codestream allows capabilities defined in any part of the JPEG 2000 family codestream allows capabilities defined in any part of the JPEG 2000 family
of standards, including those specified in <xref target="jpeg2000-2"/> and of standards, including those specified in <xref target="JPEG2000-2"/> and
<xref target="jpeg2000-15"/>.</t> <xref target="JPEG2000-15"/>.</t>
<t>JPEG 2000 represents an image as one or more components, each uniformly <t>JPEG 2000 represents an image as one or more components, each uniformly
sampled on a common rectangular reference grid. For example, an image can sampled on a common rectangular reference grid. For example, an image can
consist of the customary Y (luma), C<sub>b</sub> (blue-difference chroma), consist of the customary Y (luma), C<sub>b</sub> (blue-difference chroma),
and C<sub>r</sub> (red-difference chroma) components, with the and C<sub>r</sub> (red-difference chroma) components, with the
C<sub>b</sub> and C<sub>r</sub> being sub-sampled by a factor of two C<sub>b</sub> and C<sub>r</sub> being subsampled by a factor of two
compared to the Y component.</t> compared to the Y component.</t>
<t>An image can be further divided into contiguous rectangular tiles that <t>An image can be further divided into contiguous rectangular tiles that
are each independently coded and decoded.</t> are each independently coded and decoded.</t>
<t>JPEG 2000 codes each image as a standalone codestream. A codestream <t>JPEG 2000 codes each image as a standalone codestream. A codestream
consists of (i) marker segments, which contain coding parameters and consists of (i) marker segments, which contain coding parameters and
metadata, and (ii) coded data.</t> metadata, and (ii) coded data.</t>
<t>For convenience to the reader, the following lists both the abbreviated <t>For convenience to the reader, the following lists both the abbreviated
and full names of marker segments that are mentioned in this specification and full names of marker segments that are mentioned in this specification
(several other marker segments are defined by JPEG 2000 and can be present (several other marker segments are defined by JPEG 2000 and can be present
in a codestream):</t> in a codestream):</t>
<dl> <dl spacing="normal" newline="false" indent="7">
<dt>CAP</dt> <dt>CAP:</dt>
<dd>Extended Capabilities</dd> <dd>Extended Capabilities</dd>
<dt>COC</dt> <dt>COC:</dt>
<dd>Coding style component</dd> <dd>Coding style component</dd>
<dt>COD</dt> <dt>COD:</dt>
<dd>Coding style default</dd> <dd>Coding style default</dd>
<dt>COM</dt> <dt>COM:</dt>
<dd>Comment</dd> <dd>Comment</dd>
<dt>EOC</dt> <dt>EOC:</dt>
<dd>End of codestream</dd> <dd>End of codestream</dd>
<dt>PLM</dt> <dt>PLM:</dt>
<dd>Packet length, main header</dd> <dd>Packet length, main header</dd>
<dt>PLT</dt> <dt>PLT:</dt>
<dd>Packet length, tile-part header</dd> <dd>Packet length, tile-part header</dd>
<dt>SOC</dt> <dt>SOC:</dt>
<dd>Start of codestream</dd> <dd>Start of codestream</dd>
<dt>SOD</dt> <dt>SOD:</dt>
<dd>Start of data</dd> <dd>Start of data</dd>
<dt>SOT</dt> <dt>SOT:</dt>
<dd>Start of tile-part</dd> <dd>Start of tile-part</dd>
</dl> </dl>
<t>The codestream starts with an SOC marker segment and ends with an EOC <t>The codestream starts with an SOC marker segment and ends with an EOC
marker segment. The main header of the codestream consists of marker marker segment. The main header of the codestream consists of marker
segments between the SOC and first SOT marker segment and contains segments between the SOC and first SOT marker segment and contains
information that applies to the codestream in its entirety. It is information that applies to the codestream in its entirety. It is
generally impossible to decode a codestream without its main header.</t> generally impossible to decode a codestream without its main header.</t>
<t>The rest of the codestream consists of additional marker segments <t>The rest of the codestream consists of additional marker segments
skipping to change at line 228 skipping to change at line 289
<t>At the heart of JPEG 2000 coding is the wavelet transform, which <t>At the heart of JPEG 2000 coding is the wavelet transform, which
decomposes the image into successive resolution levels, with each level decomposes the image into successive resolution levels, with each level
related to the next one by a spatial factor of two, i.e., each related to the next one by a spatial factor of two, i.e., each
successive resolution level has half the horizontal and half the vertical successive resolution level has half the horizontal and half the vertical
resolution of the previous one.</t> resolution of the previous one.</t>
<t>The coded image data ultimately consists of code-blocks, each <t>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 further within one resolution level of one component. Code-blocks are further
collected into precincts, which, accordingly, represents code-blocks collected into precincts, which, accordingly, represent code-blocks
belonging to a spatial region within one resolution level of one belonging to a spatial region within one resolution level of one
component.</t> component.</t>
<t>The image coded data can be arranged into several progression orders, <t>The image coded data can be arranged into several progression orders,
which dictates which aspect of the image appears first in the codestream which dictates which aspect of the image appears first in the codestream
(in terms of byte offset). The progression orders are parameterized (in terms of byte offset). The progression orders are parameterized
according to:</t> according to:</t>
<dl> <dl spacing="normal" newline="true">
<dt>Position (P)</dt> <dt>Position (P)</dt>
<dd>The first lines of the image come before the last lines of the <dd>The first lines of the image come before the last lines of the
image.</dd> image.</dd>
<dt>Component (C)</dt> <dt>Component (C)</dt>
<dd>The first component of the image comes before the last component of <dd>The first component of the image comes before the last component of
the image.</dd> the image.</dd>
<dt>Resolution Level (R)</dt> <dt>Resolution Level (R)</dt>
<dd>The information needed to reconstruct the lower spatial resolutions <dd>The information needed to reconstruct the lower spatial resolutions
of the image come before the information needed to reconstruct the of the image come before the information needed to reconstruct the
higher spatial resolutions of the image.</dd> higher spatial resolutions of the image.</dd>
<dt>Quality Layer (L)</dt> <dt>Quality Layer (L)</dt>
<dd>The information needed to reconstruct the most-significant bits of <dd>The information needed to reconstruct the most significant bits of
each sample come before the information needed to reconstruct the each sample come before the information needed to reconstruct the
least-significant bit of each sample.</dd> least significant bit of each sample.</dd>
</dl> </dl>
<t>For example, in the PRCL progression order, the information needed to <t>For example, in the PRCL progression order, the information needed to
reconstruct the first lines of the image come before that needed to reconstruct the first lines of the image come before that needed to
reconstruct the last lines of the image and, within a collection of lines, reconstruct the last lines of the image, and within a collection of lines,
the information needed to reconstruct the lower spatial resolutions of the the information needed to reconstruct the lower spatial resolutions of the
image come before the information needed to reconstruct the higher spatial image come before the information needed to reconstruct the higher spatial
resolutions. This progression order is particular useful for sub-frame resolutions. This progression order is particularly useful for subframe
latency operations.</t> latency operations.</t>
</section> </section>
<section> <section>
<name>Video signal description</name> <name>Video Signal Description</name>
<t>This RTP payload format supports three distinct video frame scanning <t>This RTP payload format supports three distinct techniques for scanning
techniques:</t> video frames:
</t>
<ul> <ul>
<li>Progressive frame</li> <li>Progressive frame</li>
<li>Interlaced frame, where each frame consists of two fields. Field 1 <li>Interlaced frame, where each frame consists of two fields. Field 1
occurs earlier in time than Field 2. The height in lines of each field occurs earlier in time than Field 2. The height in lines of each field
is half the height of the image.</li> is half the height of the image.</li>
<li>Progressive segmented frame (PsF), where each frame consists of two <li>Progressive segmented frame (PsF), where each frame consists of two
segments. Segment 1 contains the odd lines (1, 3, 5, 7,...) of a frame segments. Segment 1 contains the odd lines (1, 3, 5, 7, ...) of a frame,
and Segment 2 contains the even lines (2, 4, 6, 8,...) of the same and Segment 2 contains the even lines (2, 4, 6, 8, ...) of the same
frame, where lines from the top of the frame to the bottom of the frame frame, where lines from the top of the frame to the bottom of the frame
are numbered sequentially starting at 1.</li> are numbered sequentially starting at 1.</li>
</ul> </ul>
<t>All frames are scanned left to right, top to bottom.</t> <t>All frames are scanned left to right, top to bottom.</t>
</section> </section>
<section> <section>
<name>Payload Format</name> <name>Payload Format</name>
<section> <section>
<name>General</name> <name>General</name>
<!-- [rfced] Figure 1
a) FYI - We moved both the text defining "P" in the figure and the sentence
about expansions in the figure title. These now follow the figure. Let us know
any concerns.
Original:
P = (Optional) padding bytes
Figure 1: Packetization of a sequence of JPEG 2000 codestreams
(not to scale). See Section 3 for an expansion of the SOC, SOD,
SOT and EOC abbreviations.
Updated:
Figure 1: Packetization of a sequence of JPEG 2000 codestreams
(not to scale).
In Figure 1, P denotes (optional) padding bytes. See Section 3 for
expansions of SOC, SOD, SOT, and EOC.
b) Would you like to add text before the figure to introduce it? If so, please
provide that text.
-->
<figure anchor="fig-payload-header"> <figure anchor="fig-payload-header">
<name>Packetization of a sequence of JPEG 2000 codestreams (not to <name>Packetization of a Sequence of JPEG 2000 Codestreams (Not to
scale). See <xref target="sec-media-description"/> for an expansion of Scale)</name>
the SOC, SOD, SOT and EOC abbreviations.</name> <artwork><![CDATA[
<artwork type="ascii-art">
<![CDATA[
<--------------- Codestream (image) --------------> <--------------- Codestream (image) -------------->
| | | |
<----- Extended Header -----> | <----- Extended Header -----> |
| | | | | |
+-----+-//-+-----+-//-+-----+--------//-----+-----+-----+--------- +-----+-//-+-----+-//-+-----+--------//-----+-----+-----+---------
| SOC | .. | SOT | .. | SOD | ............. | EOC | P | SOC ... | SOC | .. | SOT | .. | SOD | ............. | EOC | P | SOC ...
+-----+-//-+-----+-//-+-----+--------//-----+-----+-----+--------- +-----+-//-+-----+-//-+-----+--------//-----+-----+-----+---------
| | | | | |
<----------> Main header | <----------> Main header |
| | | |
+------------------------------+------+--//-+-----------+--------- +------------------------------+------+--//-+-----------+---------
| Main | Body | ... | Body | Main ... | Main | Body | ... | Body | Main ...
+------------------------------+------+--//-+-----------+--------- +------------------------------+------+--//-+-----------+---------
| | | |
<--------- RTP Packet ---------> <--------- RTP Packet --------->
]]></artwork>
P = (Optional) padding bytes
]]>
</artwork>
</figure> </figure>
<t>In <xref target="fig-payload-header"/>, P denotes (optional) padding
<t>Each RTP packet, as specified at <xref target="RFC3550"/>, is either bytes. See <xref target="sec-media-description"/> for expansions of
SOC, SOD, SOT, and EOC.</t>
<t>Each RTP packet, as specified in <xref target="RFC3550"/>, is either
a Main Packet or a Body Packet.</t> a Main Packet or a Body Packet.</t>
<t>A Main Packet consists of the following ordered sequence of <t>A Main Packet consists of the following ordered sequence of
structures concatenated without gaps:</t> structures concatenated without gaps:</t>
<ul> <ul>
<li>the RTP Fixed Header;</li> <li>the RTP Fixed Header;</li>
<li>a Main Packet Payload Header, as specified at <xref <li>a Main Packet Payload Header, as specified in <xref
target="sec-main-packet-header"/>; and</li> target="sec-main-packet-header"/>; and</li>
<li>the payload, which consists of a JPEG 2000 codestream <li>the payload, which consists of a JPEG 2000 codestream
fragment.</li> fragment.</li>
</ul> </ul>
<t>A Body Packet consists of the following ordered sequence of <t>A Body Packet consists of the following ordered sequence of
structures concatenated without gaps:</t> structures concatenated without gaps:</t>
<ul> <ul>
<li>the RTP Fixed Header;</li> <li>the RTP Fixed Header;</li>
<li>a Body Packet Payload Header, as specified at <xref <li>a Body Packet Payload Header, as specified in <xref
target="sec-body-packet-header"/>; and</li> target="sec-body-packet-header"/>; and</li>
<li>the payload, which consists of a JPEG 2000 codestream <li>the payload, which consists of a JPEG 2000 codestream
fragment.</li> fragment.</li>
</ul> </ul>
<t>When concatenated, the sequence of JPEG 2000 codestream fragments <t>When concatenated, the sequence of JPEG 2000 codestream fragments
emitted by the sender MUST be a sequence of JPEG 2000 codestreams where emitted by the sender <bcp14>MUST</bcp14> be a sequence of JPEG 2000 cod
two successive JPEG 2000 codestreams MAY be separated by one or more estreams where
two successive JPEG 2000 codestreams <bcp14>MAY</bcp14> be separated by
one or more
padding bytes (see <xref target="fig-payload-header"/>).</t> padding bytes (see <xref target="fig-payload-header"/>).</t>
<t>The sender MUST set the value of each padding byte to zero.</t> <t>The sender <bcp14>MUST</bcp14> set the value of each padding byte to zero.</t>
<t>The receiver MUST ignore the values of the padding bytes.</t> <t>The receiver <bcp14>MUST</bcp14> ignore the values of the padding byt es.</t>
<t>The JPEG 2000 codestreams MUST conform to <xref <t>The JPEG 2000 codestreams <bcp14>MUST</bcp14> conform to <xref
target="sec-codestream"/>.</t> target="sec-codestream"/>.</t>
<t>NOTE 1: Padding bytes can be used to achieve constant bit rate <t>NOTE 1: Padding bytes can be used to achieve constant bit rate
transmission.</t> transmission.</t>
<t>A JPEG 2000 codestream fragment, and thus an RTP Packet, does not <t>A JPEG 2000 codestream fragment, and thus an RTP packet, does not
necessarily contain complete JPEG 2000 packets, as defined in <xref necessarily contain complete JPEG 2000 packets, as defined in <xref
target="jpeg2000-1"/>.</t> target="JPEG2000-1"/>.</t>
<t>A JPEG 2000 codestream Extended Header consists of the bytes between, <t>A JPEG 2000 codestream Extended Header consists of the bytes between,
and including, the SOC marker and the first SOD marker.</t> and including, the SOC marker and the first SOD marker.</t>
<t>NOTE 2: The concept of JPEG 2000 codestream Extended Header is <t>NOTE 2: The concept of the JPEG 2000 codestream Extended Header is
specific to this document, and is distinct from the JPEG 2000 codestream specific to this document and is distinct from the JPEG 2000 codestream
main header which is defined in <xref target="jpeg2000-1"/>. The main header, which is defined in <xref target="JPEG2000-1"/>. The
codestream main header consists of the bytes between, and including, the codestream main header consists of the bytes between, and including, the
SOC marker and the first SOT marker. The codestream main header is a SOC marker and the first SOT marker. The codestream main header is a
subset of the codestream Extended Header (see <xref subset of the codestream Extended Header (see <xref
target="fig-payload-header"/>).</t> target="fig-payload-header"/>).</t>
<t>The payload of a Body Packet MUST NOT contain any bytes of the JPEG <t>The payload of a Body Packet <bcp14>MUST NOT</bcp14> contain any byte s of the JPEG
2000 codestream Extended Header.</t> 2000 codestream Extended Header.</t>
<t>The payload of a Main Packet MUST contain at least one byte of the <t>The payload of a Main Packet <bcp14>MUST</bcp14> contain at least one
JPEG 2000 codestream Extended Header and MAY contain bytes other than byte of the
JPEG 2000 codestream Extended Header and <bcp14>MAY</bcp14> contain byte
s other than
those of the JPEG 2000 codestream Extended Header.</t> those of the JPEG 2000 codestream Extended Header.</t>
<t>A payload MUST NOT contain bytes from more than one JPEG 2000 <t>A payload <bcp14>MUST NOT</bcp14> contain bytes from more than one JP EG 2000
codestream.</t> codestream.</t>
</section> </section>
<section> <section anchor="rtp-fixed-header-usage">
<name>RTP Fixed Header Usage</name> <name>RTP Fixed Header Usage</name>
<t>The following RTP header fields have a specific meaning in the <t>The following RTP header fields have a specific meaning in the
context of this payload format:</t> context of this payload format:</t>
<dl newline="true"> <dl newline="true">
<dt><tt>marker</tt></dt> <dt><tt>marker</tt></dt>
<dd> <dd>
<dl> <dl>
<dt>1</dt> <dt>1</dt>
skipping to change at line 405 skipping to change at line 487
</dl> </dl>
</dd> </dd>
<dt anchor="def-timestamp"><tt>timestamp</tt></dt> <dt anchor="def-timestamp"><tt>timestamp</tt></dt>
<dd> <dd>
<t>The <tt>timestamp</tt> is the presentation time of the image to <t>The <tt>timestamp</tt> is the presentation time of the image to
which the payload belongs.</t> which the payload belongs.</t>
<t>The <tt>timestamp</tt> clock rate is 90 kHz.</t> <t>The <tt>timestamp</tt> clock rate is 90 kHz.</t>
<t>The <tt>timestamp</tt> of successive progressive frames MUST <t>The <tt>timestamp</tt> of successive progressive frames <bcp14>MU ST</bcp14>
advance at regular increments based on the instantaneous video frame advance at regular increments based on the instantaneous video frame
rate.</t> rate.</t>
<t>The <tt>timestamp</tt> of Field 1 of successive interlaced frames <t>The <tt>timestamp</tt> of Field 1 of successive interlaced frames
MUST advance at regular increments based on the instantaneous video <bcp14>MUST</bcp14> advance at regular increments based on the insta
frame rate, and the <tt>Timestamp</tt> of Field 2 MUST be offset ntaneous video
frame rate, and the <tt>Timestamp</tt> of Field 2 <bcp14>MUST</bcp14
> be offset
from the <tt>timestamp</tt> of Field 1 by one half of the from the <tt>timestamp</tt> of Field 1 by one half of the
instantaneous frame period.</t> instantaneous frame period.</t>
<t>The <tt>timestamp</tt> of both segments of a progressive <t>The <tt>timestamp</tt> of both segments of a progressive
segmented frame MUST be equal.</t> segmented frame <bcp14>MUST</bcp14> be equal.</t>
<t><tt>timestamp</tt> of all RTP packets of a given image MUST be <t>The <tt>timestamp</tt> of all RTP packets of a given image <bcp14 >MUST</bcp14> be
equal.</t> equal.</t>
</dd> </dd>
<dt anchor="def-seq"><tt>sequence number</tt></dt> <dt anchor="def-seq"><tt>sequence number</tt></dt>
<dd> <dd>
<t>The low-order bits of the extended sequence number.</t> <t>The low-order bits of the extended sequence number.</t>
<t>The high-order bits of the extended sequence number are contained <t>The high-order bits of the extended sequence number are contained
in the <tt>ESEQ</tt> field, which is specified at <xref in the <tt>ESEQ</tt> field, which is specified in <xref
target="def-ESEQ"/>.</t> target="sec-main-packet-header"/>.</t>
<t>The extended sequence number is calculated as follows:</t> <t>The extended sequence number is calculated as follows:</t>
<t><tt>&lt;extended sequence number&gt; = &lt;ESEQ field&gt; * 65536 + <artwork><![CDATA[
&lt;sequence number field of the RTP fixed header&gt;</tt></t></dd> <extended sequence number> = <ESEQ field> * 65536 + <sequence
number field of the RTP fixed header>
]]></artwork></dd>
</dl> </dl>
</section> </section>
<section anchor="sec-main-packet-header"> <section anchor="sec-main-packet-header">
<name>Main Packet Payload Header</name> <name>Main Packet Payload Header</name>
<t><xref target="fig-main-payload-header"/> specifies the structure of t he <t><xref target="fig-main-payload-header"/> specifies the structure of t he
payload header. Fields are interpreted as unsigned binary integers in payload header. Fields are interpreted as unsigned binary integers in
network order.</t> network order.</t>
<figure anchor="fig-main-payload-header"> <figure anchor="fig-main-payload-header">
<name>Structure of the Main Packet Payload Header</name> <name>Structure of the Main Packet Payload Header</name>
<artwork type="ascii-art"> <artwork><![CDATA[
<![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|C| RSVD |*| PRIMS | TRANS | MAT | |R|S|C| RSVD |*| PRIMS | TRANS | MAT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| XTRAB | | XTRAB |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* RANGE * RANGE
]]> ]]></artwork>
</artwork>
</figure> </figure>
<dl newline="true"> <dl newline="false">
<dt anchor="def-MH">MH (Codestream Main Header Presence): 2 bits</dt> <dt anchor="def-MH">MH (Codestream Main Header Presence):</dt><dd><t>2
<dd> bits</t>
<dl newline="true"> <dl newline="false">
<dt>0</dt> <dt>0</dt>
<dd>The RTP Packet is a Body Packet.</dd> <dd>The RTP packet is a Body Packet.</dd>
<dt>1</dt> <dt>1</dt>
<dd>The RTP Packet is a Main Packet and the codestream has more <dd>The RTP packet is a Main Packet, and the codestream has more
than one Main Packet. The next RTP Packet is a Main Packet.</dd> than one Main Packet. The next RTP packet is a Main Packet.</dd>
<dt>2</dt> <dt>2</dt>
<dd>The RTP Packet is a Main Packet and the codestream has more <dd>The RTP packet is a Main Packet, and the codestream has more
than one Main Packet. The next RTP Packet is a Body Packet.</dd> than one Main Packet. The next RTP packet is a Body Packet.</dd>
<dt>3</dt> <dt>3</dt>
<dd>The RTP Packet is a Main Packet and the codestream has exactly <dd>The RTP packet is a Main Packet, and the codestream has exactl y
one Main Packet.</dd> one Main Packet.</dd>
</dl> </dl>
</dd> </dd>
<dt anchor="def-TP">TP (Image Type): 3 bits</dt> <dt anchor="def-TP">TP (Image Type):</dt><dd><t>3 bits</t>
<dd>
<t>Indicates the scanning structure of the image to which the <t>Indicates the scanning structure of the image to which the
payload belongs.</t> payload belongs.</t>
<dl newline="true"> <dl newline="false">
<dt>0</dt> <dt>0</dt>
<dd>Progressive frame.</dd> <dd>Progressive frame.</dd>
<dt>1</dt> <dt>1</dt>
<dd>Field 1 of an interlaced frame, where the first line of the <dd>Field 1 of an interlaced frame, where the first line of the
field is the first line of the frame.</dd> field is the first line of the frame.</dd>
<dt>2</dt> <dt>2</dt>
<dd>Field 2 of an interlaced frame, where the first line of the <dd>Field 2 of an interlaced frame, where the first line of the
field is the second line of the frame.</dd> field is the second line of the frame.</dd>
skipping to change at line 512 skipping to change at line 592
<dt>5</dt> <dt>5</dt>
<dd>Segment 1 of a progressive segmented frame, where the <dd>Segment 1 of a progressive segmented frame, where the
first line of the image is the first line of the frame.</dd> first line of the image is the first line of the frame.</dd>
<dt>6</dt> <dt>6</dt>
<dd>Segment 2 of a progressive segmented frame, where the <dd>Segment 2 of a progressive segmented frame, where the
first line of the image is the second line of the frame.</dd> first line of the image is the second line of the frame.</dd>
<dt>7</dt> <dt>7</dt>
<dd>Extension value. See <xref target="sec-receiver-ext"/> and <dd>Extension value. See Sections <xref target="sec-receiver-ext"
<xref target="sec-sender-ext"/>.</dd> format="counter"/> and
<xref target="sec-sender-ext" format="counter"/>.</dd>
</dl> </dl>
</dd> </dd>
<dt anchor="def-ORDH">ORDH (Progression Order [Main Packet]): 3 <!-- [rfced] May we remove the square brackets here and update as follows?
bits</dt>
<dd> Original:
ORDH (Progression Order [Main Packet]): 3 bits
...
ORDB (Progression Order [Body Packet]): 1 bit
Perhaps:
ORDH (Progression Order of Main Packet): 3 bits
...
ORDB (Progression Order of Body Packet): 1 bit
-->
<!-- [rfced] Would it be helpful to add a pointer to Section 3 here? This
section mentions LRCP, RLCP, RPCL, PCRL, CPRL, and PRCL - the pattern is
explained in Section 3.
Original:
ORDH (Progression Order [Main Packet]): 3 bits
Specifies the progression order used by the codestream and whether
resync points are signaled.
Perhaps:
ORDH (Progression Order of Main Packet): 3 bits
Specifies the progression order used by the codestream and whether
resync points are signaled. See Section 3 for details about progression or
ders.
-->
<dt anchor="def-ORDH">ORDH (Progression Order [Main Packet]):</dt>
<dd><t>3 bits</t>
<t>Specifies the progression order used by the codestream and <t>Specifies the progression order used by the codestream and
whether resync points are signaled.</t> whether resync points are signaled.</t>
<dl newline="true"> <dl newline="false">
<dt>0</dt> <dt>0</dt>
<dd>Resync points are not necessarily signaled. The progression <dd>Resync points are not necessarily signaled. The progression
order can vary over the codestream.</dd> order can vary over the codestream.</dd>
<dt>1</dt> <dt>1</dt>
<dd>The progression order is LRCP for the entire codestream. The <dd>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.</dd> contains one or more resync points.</dd>
<dt>2</dt> <dt>2</dt>
skipping to change at line 563 skipping to change at line 672
<dd>The progression order is PRCL for the entire codestream. The <dd>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.</dd> contains one or more resync points.</dd>
<dt>7</dt> <dt>7</dt>
<dd>The progression order can vary over the codestream. The <dd>The progression order can vary over the 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.</dd> contains one or more resync points.</dd>
</dl> </dl>
<t><tt>ORDH</tt> MUST be 0 if the codestream consists of more than <t><tt>ORDH</tt> <bcp14>MUST</bcp14> be 0 if the codestream consis ts of more than
one tile.</t> one tile.</t>
<t>NOTE: Only <tt>ORDH</tt> = 4 and <tt>ORDH</tt> = 6 allow <t>NOTE: Only <tt>ORDH</tt> = 4 and <tt>ORDH</tt> = 6 allow
sub-codestream latency streaming.</t> sub-codestream latency streaming.</t>
<t>NOTE: Progression order PRCL is defined in <xref <t>NOTE: Progression order PRCL is defined in <xref
target="jpeg2000-2"/>. The other progression orders are specified target="JPEG2000-2"/>. The other progression orders are specified
in <xref target="jpeg2000-1"/>.</t> in <xref target="JPEG2000-1"/>.</t>
</dd> </dd>
<dt anchor="def-P">P (Precision Timestamp Presence): 1 bit</dt> <dt anchor="def-P">P (Precision Timestamp Presence):</dt><dd><t>1 bit<
<dd> /t>
<dl newline="true"> <dl newline="false">
<dt>0</dt> <dt>0</dt>
<dd><tt>PTSTAMP</tt> is not used.</dd> <dd><tt>PTSTAMP</tt> is not used.</dd>
<dt>1</dt> <dt>1</dt>
<dd><tt>PTSTAMP</tt> is used.</dd> <dd><tt>PTSTAMP</tt> is used.</dd>
</dl> </dl>
</dd> </dd>
<dt anchor="def-XTRAC">XTRAC (Extension Payload Length): 3 bits</dt> <dt anchor="def-XTRAC">XTRAC (Extension Payload Length):</dt><dd><t>3
<dd>Length, in multiples of 4 bytes, of the <tt>XTRAB</tt> field.</dd> bits</t>
<t>Length, in multiples of 4 bytes, of the <tt>XTRAB</tt> field.</t></
dd>
<dt anchor="def-PTSTAMP">PTSTAMP (Precision Timestamp): 12 bits</dt> <dt anchor="def-PTSTAMP">PTSTAMP (Precision Timestamp):</dt><dd><t>12
<dd> bits</t>
<t>PTSTAMP = (<tt>timestamp</tt> + <tt>TOFF</tt>) mod 4096, if <t>PTSTAMP = (<tt>timestamp</tt> + <tt>TOFF</tt>) mod 4096, if
<tt>P</tt> = 1 in the Main Packet of this codestream.</t> <tt>P</tt> = 1 in the Main Packet of this codestream.</t>
<t><tt>TOFF</tt> is the transmission time of this RTP Packet, in the <t><tt>TOFF</tt> is the transmission time of this RTP packet, in the
timebase of the <tt>timestamp</tt> clock and relative to the first timebase of the <tt>timestamp</tt> clock and relative to the first
RTP packet with the same <tt>timestamp</tt> value.</t> RTP packet with the same <tt>timestamp</tt> value.</t>
<t><tt>TOFF</tt> = 0 in the first RTP Packet with the same <t><tt>TOFF</tt> = 0 in the first RTP packet with the same
<tt>timestamp</tt> value.</t> <tt>timestamp</tt> value.</t>
<t><tt>PTSTAMP</tt> = 0, if <tt>P</tt> = 0 in the Main Packet of thi s <t><tt>PTSTAMP</tt> = 0, if <tt>P</tt> = 0 in the Main Packet of thi s
codestream.</t> codestream.</t>
<t>NOTE: As described at <xref target="sec-sender-ptstamp"/> and <!-- [rfced] Will "no more than 45 ms = 4095/90,000" be clear to readers?
<xref target="sec-recv-ptstamp"/>, <tt>PTSTAMP</tt> is intended to
Original:
NOTE: As described in Sections 7.4 and 8.1, PTSTAMP is intended to
improve clock recovery at the receiver and only applies when the
transmission time of two consecutive RTP packets with identical
timestamp fields differ by no more than 45 ms = 4095/90,000.
Perhaps:
NOTE: As described in Sections 7.4 and 8.1, PTSTAMP is intended to
improve clock recovery at the receiver and only applies when the
transmission time of two consecutive RTP packets with identical
timestamp fields differ by no more than 45 ms (which is 4095/90,000).
-->
<t>NOTE: As described in Sections <xref target="sec-sender-ptstamp"
format="counter"/> and
<xref target="sec-recv-ptstamp" format="counter"/>, <tt>PTSTAMP</tt>
is intended to
improve clock recovery at the receiver and only applies when the improve clock recovery at the receiver and only applies when the
transmission time of two consecutive RTP packets with identical transmission time of two consecutive RTP packets with identical
<tt>timestamp</tt> fields differ by no more than 45 ms = <tt>timestamp</tt> fields differ by no more than 45 ms =
4095/90,000. <xref target="RFC5450"/> addresses the general 4095/90,000. <xref target="RFC5450"/> addresses the general
case when a RTP packet is transmitted at a time other than its case when an RTP packet is transmitted at a time other than its
nominal transmission time.</t> nominal transmission time.</t>
</dd> </dd>
<dt anchor="def-ESEQ">ESEQ (Extended Sequence Number High-Order Bits): <dt anchor="def-ESEQ">ESEQ (Extended Sequence Number High-Order Bits):
8 bits</dt> </dt><dd>
<dd> <t>8 bits</t>
<t>The high-order bits of the extended sequence number.</t> <t>The high-order bits of the extended sequence number.</t>
<t>NOTE: The low-order bits of the extended sequence number are <t>NOTE: The low-order bits of the extended sequence number are
stored in the <tt>sequence number</tt> field of the RTP fixed stored in the <tt>sequence number</tt> field of the RTP fixed
header.</t> header.</t>
<t><xref target="def-seq"/> specifies the formula to compute the <t><xref target="rtp-fixed-header-usage"/> specifies the formula to compute the
extended sequence number.</t> extended sequence number.</t>
</dd> </dd>
<dt anchor="def-R">R (Codestream Main Header Reuse): 1 bit</dt> <dt anchor="def-R">R (Codestream Main Header Reuse):</dt><dd><t>1 bit<
<dd> /t>
<t>Determines whether Main Packet and codestream main header <t>Determines whether Main Packet and codestream main header
information can be reused across codestreams.</t> information can be reused across codestreams.</t>
<dl newline="true"> <dl newline="false">
<dt>1</dt> <dt>1</dt>
<dd> <dd>
<t>All Main Packets in this stream, as identified by the value <t>All Main Packets in this stream, as identified by the value
of the <tt>SSRC</tt> field in the RTP Fixed Header:</t> of the <tt>SSRC</tt> field in the RTP Fixed Header:</t>
<!-- [rfced] It may be unclear to readers what is being connected by "and" in
this sentence. How may we clarify?
Original:
* MUST contain the same codestream main header information,
with the exception of the SOT and COM marker segments, and
any pointer marker segments; and
Perhaps:
* MUST contain the same codestream main header information
(with the exception of the SOT and COM marker segments) and
any pointer marker segments; and
Or:
* MUST contain the same codestream main header information
(with the exception of the SOT and COM marker segments and
any pointer marker segments); and
-->
<ul> <ul>
<li>MUST have identical Main Packet Payload Headers, with the <li><bcp14>MUST</bcp14> have identical Main Packet Payload Hea
exception of their <tt>TP</tt>, <tt>MH</tt>, <tt>ESEQ</tt> and ders, with the
exception of their <tt>TP</tt>, <tt>MH</tt>, <tt>ESEQ</tt>, an
d
<tt>PTSTAMP</tt> fields;</li> <tt>PTSTAMP</tt> fields;</li>
<li>MUST contain the same codestream main header information, <li><bcp14>MUST</bcp14> contain the same codestream main heade r information,
with the exception of the SOT and COM marker segments, and any with the exception of the SOT and COM marker segments, and any
pointer marker segments; and</li> pointer marker segments; and</li>
<li>MUST NOT contain bytes other than Extended Header <li><bcp14>MUST NOT</bcp14> contain bytes other than Extended Header
bytes.</li> bytes.</li>
</ul> </ul>
</dd> </dd>
<dt>0</dt> <dt>0</dt>
<dd>Otherwise</dd> <dd>Otherwise</dd>
</dl> </dl>
</dd> </dd>
<dt anchor="def-S">S (Parameterized Colorspace Presence): 1 bit</dt> <dt anchor="def-S">S (Parameterized Colorspace Presence):</dt><dd><t>1
<dd> bit</t>
<dl newline="true"> <dl newline="false">
<dt>0</dt> <dt>0</dt>
<dd><t>Component colorimetry is not specified, and left to the <dd><t>Component colorimetry is not specified; it is left to the
session or the application.</t> session or the application.</t>
<t><tt>PRIMS</tt>, <tt>TRANS</tt> and <tt>MAT</tt> and <t><tt>PRIMS</tt>, <tt>TRANS</tt>, <tt>MAT</tt>, and
<tt>RANGE</tt> <tt>RANGE</tt>
MUST be zero.</t> <bcp14>MUST</bcp14> be zero.</t>
</dd> </dd>
<dt>1</dt> <dt>1</dt>
<dd> <dd>
<t>Component colorimetry is specified by the <tt>PRIMS</tt>, <t>Component colorimetry is specified by the <tt>PRIMS</tt>,
TRANS and <tt>MAT</tt> and <tt>RANGE</tt> fields.</t> <tt>TRANS</tt>, <tt>MAT</tt>, and <tt>RANGE</tt> fields.</t>
<t>The codestream components MUST conform to one of the
combinations at <xref target="t-color-map"/>.</t> <t>The codestream components <bcp14>MUST</bcp14> conform to one
of the
combinations in <xref target="t-color-map"/>. </t>
<table anchor="t-color-map"> <table anchor="t-color-map">
<name>Mapping of codestream components to color <name>Mapping of Codestream Components to Color
channels</name> Channels</name>
<thead> <thead>
<tr> <tr>
<th rowspan="2">Combination name</th> <th rowspan="2">Combination Name</th>
<th colspan="4">Component index</th> <th colspan="4">Component Index</th>
</tr> </tr>
<tr> <tr>
<th>0</th> <th>0</th>
<th>1</th> <th>1</th>
<th>2</th> <th>2</th>
<th>3</th> <th>3</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
skipping to change at line 701 skipping to change at line 842
</tr> </tr>
<tr> <tr>
<th>YCbCr</th><td>Y</td><td>C<sub>B</sub></td> <th>YCbCr</th><td>Y</td><td>C<sub>B</sub></td>
<td>C<sub>R</sub></td><td></td> <td>C<sub>R</sub></td><td></td>
</tr> </tr>
<tr> <tr>
<th>YCbCrA</th><td>Y</td><td>C<sub>B</sub></td> <th>YCbCrA</th><td>Y</td><td>C<sub>B</sub></td>
<td>C<sub>R</sub></td><td>A</td> <td>C<sub>R</sub></td><td>A</td>
</tr> </tr>
</tbody> </tbody>
<tfoot>
<tr>
<td colspan="5">The channel <tt>A</tt> is an opacity
channel. The minimum sample value (0) indicates a
completely transparent sample, and the maximum sample
value (as determined by the bit depth of the codestream
component) indicates a completely opaque sample. The
opacity channel MUST map to a component with unsigned
samples.</td>
</tr>
</tfoot>
</table> </table>
<t>Channel <tt>A</tt> is an opacity channel. The minimum
sample value (0) indicates a completely transparent sample,
and the maximum sample value (as determined by the bit depth
of the codestream component) indicates a completely opaque
sample. The opacity channel <bcp14>MUST</bcp14> map to a
component with unsigned samples.</t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
<dt anchor="def-C">C (Code-block Caching Usage): 1 bit</dt> <dt anchor="def-C">C (Code-Block Caching Usage):</dt><dd><t>1 bit</t>
<dd> <dl newline="false">
<dl newline="true">
<dt>0</dt> <dt>0</dt>
<dd>Code-block caching is not in use.</dd> <dd>Code-block caching is not in use.</dd>
<dt>1</dt> <dt>1</dt>
<dd> <dd>
<t>Code-block caching is in use.</t> <t>Code-block caching is in use.</t>
<t><tt>R</tt> MUST be equal to 1.</t> <t><tt>R</tt> <bcp14>MUST</bcp14> be equal to 1.</t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
<dt anchor="def-RSVD">RSVD (Reserved): 4 bits</dt> <dt anchor="def-RSVD">RSVD (Reserved):</dt><dd><t>4 bits</t>
<dd>Unassigned value. See <xref target="sec-receiver-unassigned"/> and <t>Unassigned value. See Sections <xref target="sec-receiver-unassigne
<xref target="sec-sender-unassigned"/>.</dd> d" format="counter"/> and
<xref target="sec-sender-unassigned" format="counter"/>.</t></dd>
<dt anchor="def-F">RANGE (Video Full Range Usage): 1 bit</dt> <dt anchor="def-F">RANGE (Video Full Range Usage):</dt><dd><t>1 bit</t
<dd>Value of the VideoFullRangeFlag specified in <xref >
target="rec-itu-t-h273"/></dd> <t>Value of the VideoFullRangeFlag specified in <xref
target="REC-ITU-T-H273"/>.</t></dd>
<dt anchor="def-PRIMS">PRIMS (Color Primaries): 8 bits</dt> <dt anchor="def-PRIMS">PRIMS (Color Primaries):</dt><dd><t>8 bits</t>
<dd>One of the ColourPrimaries values specified in <xref <t>One of the ColourPrimaries values specified in <xref
target="rec-itu-t-h273"/></dd> target="REC-ITU-T-H273"/>.</t></dd>
<dt anchor="def-TRANS">TRANS (Transfer Characteristics): 8 bits</dt> <dt anchor="def-TRANS">TRANS (Transfer Characteristics):</dt><dd><t>8
<dd>One of the TransferCharacteristics values specified in bits</t>
<xref target="rec-itu-t-h273"/></dd> <t>One of the TransferCharacteristics values specified in
<xref target="REC-ITU-T-H273"/>.</t></dd>
<dt anchor="def-MAT">MAT (Color Matrix Coefficients): 8 bits</dt> <dt anchor="def-MAT">MAT (Color Matrix Coefficients):</dt><dd><t>8 bit
<dd>One of the MatrixCoefficients values specified in <xref s</t>
target="rec-itu-t-h273"/></dd> <t>One of the MatrixCoefficients values specified in <xref
target="REC-ITU-T-H273"/>.</t></dd>
<dt anchor="def-XTRAB">XTRAB (Extension Payload): variable</dt> <dt anchor="def-XTRAB">XTRAB (Extension Payload):</dt><dd><t>variable<
<dd>Allows the contents of the Main Packet Payload Header to be /t>
<t>Allows the contents of the Main Packet Payload Header to be
extended in the future. The size of the field is determined by <xref extended in the future. The size of the field is determined by <xref
target="def-XTRAC"/>. See also <xref target="sec-receiver-xtrab"/> and target="sec-main-packet-header"/>. See also Sections <xref target="sec
<xref target="sec-sender-xtrab"/>.</dd> -receiver-xtrab" format="counter"/> and
<xref target="sec-sender-xtrab" format="counter"/>.</t></dd>
</dl> </dl>
</section> </section>
<section anchor="sec-body-packet-header"> <section anchor="sec-body-packet-header">
<name>Body Packet Payload Header</name> <name>Body Packet Payload Header</name>
<t><xref target="fig-body-payload-header"/> specifies the structure of <t><xref target="fig-body-payload-header"/> specifies the structure of
the Body Packet Payload Header. Fields are interpreted as unsigned the Body Packet Payload Header. Fields are interpreted as unsigned
binary integers in network order.</t> binary integers in network order.</t>
<figure anchor="fig-body-payload-header"> <figure anchor="fig-body-payload-header">
<name>Structure of the Body Packet Payload Header</name> <name>Structure of the Body Packet Payload Header</name>
<artwork type="ascii-art"> <artwork><![CDATA[
<![CDATA[
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 |RES |*|QUAL | PTSTAMP | ESEQ | |MH | TP |RES |*|QUAL | PTSTAMP | ESEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| POS | PID | | POS | PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* ORDB * ORDB
]]> ]]></artwork>
</artwork>
</figure> </figure>
<dl newline="true"> <dl newline="false">
<dt>MH</dt> <dt>MH:</dt>
<dd>See <xref target="def-MH"/>.</dd> <dd>See <xref target="sec-main-packet-header"/>.</dd>
<dt>TP</dt> <dt>TP:</dt>
<dd>See <xref target="def-TP"/>.</dd> <dd>See <xref target="sec-main-packet-header"/>.</dd>
<dt anchor="def-RES">RES (Resolution Levels): 3 bits</dt> <dt anchor="def-RES">RES (Resolution Levels):</dt><dd><t>3 bits</t>
<dd> <dl newline="false">
<dl newline="true">
<dt>0</dt> <dt>0</dt>
<dd>The payload can contribute to all resolution levels.</dd> <dd>The payload can contribute to all resolution levels.</dd>
<!-- [rfced] Would it be helpful to update the "Otherwise" part below as
follows? Right now, it is part of <dl> in the xml file; the suggested
update changes it to appear in <t>. (Note: We will update the QUAL
definition in the same way.)
Current:
RES (Resolution Levels): 3 bits
0 The payload can contribute to all resolution levels.
Otherwise The payload contains at least one byte of one JPEG 2000
packet belonging to resolution level (N_L + RES - 7) but does
not contain any byte of any JPEG 2000 packet belonging to lower
resolution levels. N_L is the number of decomposition levels
of the codestream.
Perhaps:
RES (Resolution Levels): 3 bits
0 The payload can contribute to all resolution levels.
Otherwise, the payload contains at least one byte of one JPEG 2000
packet belonging to resolution level (N_L + RES - 7) but does
not contain any byte of any JPEG 2000 packet belonging to lower
resolution levels. N_L is the number of decomposition levels
of the codestream.
-->
<dt>Otherwise</dt> <dt>Otherwise</dt>
<dd>The payload contains at least one byte of one JPEG 2000 packet <dd>The payload contains at least one byte of one JPEG 2000 packet
belonging to resolution level (N<sub>L</sub> + RES - 7) but does belonging to resolution level (N<sub>L</sub> + 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<sub>L</sub> is the number of decomposition resolution levels. N<sub>L</sub> is the number of decomposition
levels of the codestream.</dd> levels of the codestream.</dd>
</dl> </dl>
</dd> </dd>
<dt anchor="def-ORDB">ORDB (Progression Order [Body Packet]): 1 <dt anchor="def-ORDB">ORDB (Progression Order [Body Packet]):</dt><dd>
bit</dt> <t>1
<dd> bit</t>
<dl newline="true"> <dl newline="false">
<dt>0</dt> <dt>0</dt>
<dd>No resync point is specified for the payload.</dd> <dd>No resync point is specified for the payload.</dd>
<dt>1</dt> <dt>1</dt>
<dd>The payload contains a resync point.</dd> <dd>The payload contains a resync point.</dd>
</dl> </dl>
<t><tt>ORDB</tt> MUST be 0 is the codestream consists of more than <t><tt>ORDB</tt> <bcp14>MUST</bcp14> be 0 if the codestream consis ts of more than
one tile.</t> one tile.</t>
</dd> </dd>
<dt anchor="def-QUAL">QUAL (Quality Layers): 3 bits</dt> <dt anchor="def-QUAL">QUAL (Quality Layers):</dt><dd><t>3 bits</t>
<dd> <dl newline="false">
<dl newline="true">
<dt>0</dt> <dt>0</dt>
<dd>The payload can contribute to all quality layers.</dd> <dd>The payload can contribute to all quality layers.</dd>
<dt>Otherwise</dt> <dt>Otherwise</dt>
<dd>The payload contributes only to quality layer index <dd>The payload contributes only to quality layer index
<tt>QUAL</tt> or above.</dd> <tt>QUAL</tt> or above.</dd>
</dl> </dl>
</dd> </dd>
<dt>PTSTAMP</dt> <dt>PTSTAMP:</dt>
<dd>See <xref target="def-PTSTAMP"/>.</dd> <dd>See <xref target="sec-main-packet-header"/>.</dd>
<dt>ESEQ</dt> <dt>ESEQ:</dt>
<dd>See <xref target="def-ESEQ"/>.</dd> <dd>See <xref target="sec-main-packet-header"/>.</dd>
<dt anchor="def-POS">POS (Resync Point Offset): 12 bits</dt> <dt anchor="def-POS">POS (Resync Point Offset):</dt><dd><t>12 bits</t>
<dd>
<t>Byte offset from the start of the payload to the first byte of <t>Byte offset from the start of the payload to the first byte of
the resync point belonging to the precinct identified by PID.</t> the resync point belonging to the precinct identified by PID.</t>
<t><tt>POS</tt> MUST be 0 if <tt>ORDB</tt> = 0.</t> <t><tt>POS</tt> <bcp14>MUST</bcp14> be 0 if <tt>ORDB</tt> = 0.</t>
</dd> </dd>
<dt anchor="def-PID">PID (Precinct Identifier): 20 bits</dt> <dt anchor="def-PID">PID (Precinct Identifier):</dt><dd><t>20 bits</t>
<dd>
<t>Unique identifier of the precinct of the resync point.</t> <t>Unique identifier of the precinct of the resync point.</t>
<t><tt>PID = c + s * num_components</tt></t> <artwork><![CDATA[PID = c + s * num_components]]></artwork>
<t>where:</t> <t>where:</t>
<ul> <ul>
<li><em>c</em> is the index (starting from 0) of the image <li><em>c</em> is the index (starting from 0) of the image
component to which the precinct belongs;</li> component to which the precinct belongs;</li>
<li><em>s</em> is a sequence number which identifies the precinct <li><em>s</em> is a sequence number that identifies the precinct
within its tile-component; and</li> within its tile-component; and</li>
<li><em>num_components</em> is the number of components of the <li><em>num_components</em> is the number of components of the
codestream.</li> codestream.</li>
</ul> </ul>
<t>If <tt>PID</tt> is present, the payload MUST NOT contain <t>If <tt>PID</tt> is present, the payload <bcp14>MUST NOT</bcp14> c ontain
codestream bytes from more than one precinct.</t> codestream bytes from more than one precinct.</t>
<t><tt>PID</tt> MUST be 0 if <tt>ORDB</tt> = 0.</t> <t><tt>PID</tt> <bcp14>MUST</bcp14> be 0 if <tt>ORDB</tt> = 0.</t>
<t>NOTE: <tt>PID</tt> is identical to precinct identifier I <t>NOTE: <tt>PID</tt> is identical to precinct identifier I
specified in <xref target="jpeg2000-9"/>.</t> specified in <xref target="JPEG2000-9"/>.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="sec-codestream"> <section anchor="sec-codestream">
<name>JPEG 2000 codestream</name> <name>JPEG 2000 Codestream</name>
<t> A JPEG 2000 codestream consists of the bytes between, and including, <t> A JPEG 2000 codestream consists of the bytes between, and including,
the SOC and EOC markers, as defined in <xref target="jpeg2000-1"/>.</t> the SOC and EOC markers, as defined in <xref target="JPEG2000-1"/>.</t>
<t>The JPEG 2000 codestream MAY include capabilities beyond those <t>The JPEG 2000 codestream <bcp14>MAY</bcp14> include capabilities beyo
specified at <xref target="jpeg2000-1"/>, including those specified in nd those
<xref target="jpeg2000-2"/> and <xref target="jpeg2000-15"/>.</t> specified in <xref target="JPEG2000-1"/>, including those specified in
<xref target="JPEG2000-2"/> and <xref target="JPEG2000-15"/>.</t>
<t>NOTE: The <tt>Rsiz</tt> parameter and <tt>CAP</tt> marker segments of <t>NOTE: The <tt>Rsiz</tt> parameter and <tt>CAP</tt> marker segments of
each JPEG 2000 codestream contain detailed information on the each JPEG 2000 codestream contain detailed information on the
capabilities necessary to decode the codestream.</t> capabilities necessary to decode the codestream.</t>
<t>NOTE: The <tt>caps</tt> media type parameter defined in <t>NOTE: The <tt>caps</tt> media type parameter defined in
<xref target="sec-media-type-def"/> allows applications to signal <xref target="sec-media-type-def"/> allows applications to signal
required device capabilities.</t> required device capabilities.</t>
<t>NOTE: The block coder specified at <xref target="jpeg2000-15"/> <t>NOTE: The block coder specified in <xref target="JPEG2000-15"/>
improves throughput and reduces latency compared to the original improves throughput and reduces latency compared to the original
arithmetic block coder defined in <xref target="jpeg2000-1"/>.</t> arithmetic block coder defined in <xref target="JPEG2000-1"/>.</t>
<t>For interlaced or progressive segmented frames, the height specified <t>For interlaced or progressive segmented frames, the height specified
in the JPEG 2000 main header MUST be the height in lines of the field or in the JPEG 2000 main header <bcp14>MUST</bcp14> be the height in lines of the field or
the segment, respectively.</t> the segment, respectively.</t>
<t>If any decomposition level involves only horizontal decomposition <t>If any decomposition level involves only horizontal decomposition,
then no decomposition level MUST involve only vertical decomposition; then no decomposition level <bcp14>MUST</bcp14> involve only vertical de
and, conversely, if any decomposition level involves only vertical composition;
decomposition then no decomposition level MUST involve only horizontal conversely, if any decomposition level involves only vertical
decomposition, then no decomposition level <bcp14>MUST</bcp14> involve o
nly horizontal
decomposition.</t> decomposition.</t>
</section> </section>
<section anchor="sec-sender"> <section anchor="sec-sender">
<name>Sender</name> <name>Sender</name>
<section> <section>
<name>Main Packet</name> <name>Main Packet</name>
<t>A Main Packet MAY contain zero or more bytes of the JPEG 2000 <t>A Main Packet <bcp14>MAY</bcp14> contain zero or more bytes of the JP EG 2000
codestream Extended Header.</t> codestream Extended Header.</t>
<t>The sender MUST either emit a single Main Packet with <tt>MH</tt> = <t>The sender <bcp14>MUST</bcp14> emit either a single Main Packet with <tt>MH</tt> =
3, or one or more Main Packets with <tt>MH</tt> = 1 followed by a 3, or one or more Main Packets with <tt>MH</tt> = 1 followed by a
single Main Packet with <tt>MH</tt> = 2.</t> single Main Packet with <tt>MH</tt> = 2.</t>
<t>The Main Packet Payload Headers fields MUST be identical in all Main <t>The Main Packet Payload Headers fields <bcp14>MUST</bcp14> be identic
Packet of a given codestream, with the exception of:</t> al in all Main
Packets of a given codestream, with the exception of:</t>
<ul> <ul>
<li><tt>MH</tt>;</li> <li><tt>MH</tt>;</li>
<li><tt>ESEQ</tt>; and</li> <li><tt>ESEQ</tt>; and</li>
<li><tt>PTSTAMP</tt>.</li> <li><tt>PTSTAMP</tt>.</li>
</ul> </ul>
</section> </section>
<section anchor="sec-filtering"> <section anchor="sec-filtering">
<name>RTP Packet filtering</name> <name>RTP Packet Filtering</name>
<t>An intermediate system MAY strip out RTP Packet from a codestream <t>An intermediate system <bcp14>MAY</bcp14> 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.</t> resolution or a spatial region of interest.</t>
</section> </section>
<section> <section>
<name>Resync point</name> <name>Resync Point</name>
<t>A resync point is the first byte of JPEG 2000 packet header data for <t>A resync point is the first byte of JPEG 2000 packet header data for
a precinct and for which PID &lt; 2<sup>24</sup>.</t> a precinct and for which PID &lt; 2<sup>24</sup>.</t>
<t>NOTE: Resync points cannot be specified if the codestream consists of <t>NOTE: Resync points cannot be specified if the codestream consists of
more than one tile (<tt>ORDB</tt> and <tt>ORDH</tt> are both equal to more than one tile (<tt>ORDB</tt> and <tt>ORDH</tt> are both equal to
zero).</t> zero).</t>
<t>NOTE: A resync point can be used by a receiver to process a <t>NOTE: 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. As corrupted, lost, or deliberately discarded by an intermediate system. As
a corollary, resync points can be used by an intermediate system to a corollary, resync points can be used by an intermediate system to
discard RTP packets that are not relevant to a given rendering discard RTP packets that are not relevant to a given rendering
resolution or region of interest. Resync points play a role similar to resolution or region of interest. Resync points play a role similar to
pointer marker segments, albeit tailored for high bandwidth low latency pointer marker segments, albeit tailored for high-bandwidth, low-latency
streaming applications.</t> streaming applications.</t>
</section> </section>
<section anchor="sec-sender-ptstamp"> <section anchor="sec-sender-ptstamp">
<name>PTSTAMP field</name> <name>PTSTAMP Field</name>
<t>A sender SHOULD set <tt>P</tt> = 1, but only if it can generate <t>A sender <bcp14>SHOULD</bcp14> set <tt>P</tt> = 1, but only if it can generate
<tt>PTSTAMP</tt> accurately.</t> <tt>PTSTAMP</tt> accurately.</t>
<t><tt>PTSTAMP</tt> can be derived from the same clock that is used to <t><tt>PTSTAMP</tt> can be derived from the same clock that is used to
produce the 32-bit <tt>timestamp</tt> field in the RTP fixed header. produce the 32-bit <tt>timestamp</tt> field in the RTP fixed header.
Specifically, a sender maintains, at least conceptually, a 32-bit Specifically, a sender maintains, at least conceptually, a 32-bit
counter that is incremented by a 90kHz clock. The counter is sampled at counter that is 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 point in time when each RTP packet is transmitted and the 12 LSBs of
the sample are stored in the <tt>PTSTAMP</tt> field.</t> the sample are stored in the <tt>PTSTAMP</tt> field.</t>
<t>If <tt>P</tt> = 1, then the transmission time <tt>TOFF</tt> (as <t>If <tt>P</tt> = 1, then the transmission time <tt>TOFF</tt> (as
defined at <xref target="def-PTSTAMP"></xref>) for two consecutive RTP defined in <xref target="sec-main-packet-header"></xref>) for two consec
packets with identical <tt>timestamp</tt> fields MUST NOT differ by more utive RTP
packets with identical <tt>timestamp</tt> fields <bcp14>MUST NOT</bcp14>
differ by more
than 4095.</t> than 4095.</t>
</section> </section>
<section> <section>
<name>RES field</name> <name>RES Field</name>
<t>A sender SHOULD set <tt>RES</tt> &gt; 0 whenever possible.</t> <t>A sender <bcp14>SHOULD</bcp14> set <tt>RES</tt> &gt; 0 whenever possi
ble.</t>
<t>NOTE: While a sender can always safely set <tt>RES</tt> = 0, this <t>NOTE: While a sender can always safely set <tt>RES</tt> = 0, this
makes it more difficult to discard RTP packets based on resolution, as makes it more difficult to discard RTP packets based on resolution, as
described at <xref target="recv-RES"/>.</t> described in <xref target="recv-RES"/>.</t>
</section> </section>
<section anchor="sec-sender-xtrab"> <section anchor="sec-sender-xtrab">
<name>Extra information</name> <name>Extra Information</name>
<t>The sender MUST set the value of <tt>XTRAC</tt> to 0.</t> <t>The sender <bcp14>MUST</bcp14> set the value of <tt>XTRAC</tt> to 0.<
/t>
<t>Future updates to this RTP payload format can permit other <t>Future updates to this RTP payload format can permit other
values.</t> values.</t>
</section> </section>
<section anchor="sec-sender-unassigned"> <section anchor="sec-sender-unassigned">
<name>Unassigned values</name> <name>Unassigned Values</name>
<t>The sender MUST set unassigned values to 0.</t> <t>The sender <bcp14>MUST</bcp14> set unassigned values to 0.</t>
<t>Unassigned values are available for assignment by future updates to <t>Unassigned values are available for assignment by future updates to
this RTP payload format. As specified at <xref this RTP payload format. As specified in <xref
target="sec-receiver-unassigned"/> these future assigned values are target="sec-receiver-unassigned"/>, these future assigned values are
ignored by receivers that conform to this specification. In contrast ignored by receivers that conform to this specification. In contrast
with extension values (<xref target="sec-sender-ext"/>, this mechanism to extension values (see <xref target="sec-sender-ext"/>), this mechanis m
allows updates to this RTP payload format that remain compatible with allows updates to this RTP payload format that remain compatible with
receivers that conform to this specification.</t> receivers that conform to this specification.</t>
</section> </section>
<section anchor="sec-sender-ext"> <section anchor="sec-sender-ext">
<name>Extension values</name> <name>Extension Values</name>
<t>A sender MUST NOT use an extension value.</t> <t>A sender <bcp14>MUST NOT</bcp14> use an extension value.</t>
</section> </section>
<section anchor="sec-send-block-caching"> <section anchor="sec-send-block-caching">
<name>Code-block caching</name> <name>Code-Block Caching</name>
<t>This section applies only if <tt>C</tt> = 1.</t> <t>This section only applies if <tt>C</tt> = 1.</t>
<!-- [rfced] How may we update "and as described at Section 8.7" and "and as
specified in Section 7.9" here for clarity?
Original:
When C = 1, and
as described at Section 8.7, a receiver maintains a simple cache of
previously received code-blocks, which it uses to replace empty code-
blocks.
...
When C = 1, and as specified in Section 7.9, the sender can improve
bandwidth efficiency by only occasionally transmitting code-blocks
corresponding to static portions of the video and otherwise
transmitting empty code-blocks, as defined in Section 7.9.
Perhaps (add parenthetical at end):
When C = 1, a receiver maintains a simple cache of
previously received code-blocks, which it uses to replace empty code-
blocks (see Section 8.7).
...
When C = 1, the sender can improve
bandwidth efficiency by only occasionally transmitting code-blocks
corresponding to static portions of the video and otherwise
transmitting empty code-blocks (see Section 7.9).
-->
<t>A sender can improve bandwidth efficiency by only occasionally <t>A sender can improve bandwidth efficiency by only occasionally
transmitting code-blocks corresponding to static portions of the video transmitting code-blocks corresponding to static portions of the video
and otherwise transmitting empty code-blocks. When <tt>C</tt> = 1, and and otherwise transmitting empty code-blocks. When <tt>C</tt> = 1, and
as described at <xref target="sec-rcv-block-caching"/>, a receiver as described in <xref target="sec-rcv-block-caching"/>, a receiver
maintains a simple cache of previously received code-blocks, which it maintains a simple cache of previously received code-blocks, which it
uses to replace empty code-blocks.</t> uses to replace empty code-blocks.</t>
<t>A sender alone determines which and when code-blocks are replaced <t>A sender alone determines which code-blocks are replaced
with empty code-blocks.</t> with empty code-blocks and when the replacement occurs.</t>
<t>The sender cannot however determine with certainty the state of the <t>The sender cannot, however, determine with certainty the state of the
receiver's cache: some code-blocks might have been lost in transit, the receiver's cache; for example, some code-blocks might have been lost in
transit, the
sender doesn't know exactly when the receiver started processing the sender doesn't know exactly when the receiver started processing the
stream, etc.</t> stream, etc.</t>
<t>A code-block is <em>empty</em> if:</t> <t>A code-block is <em>empty</em> if:</t>
<ul> <ul>
<li>it does not contribute code-bytes as specified in the parent JPEG <li>it does not contribute code-bytes as specified in the parent JPEG
2000 packet header; or</li> 2000 packet header; or</li>
<li>if the code-block conforms to <xref target="jpeg2000-15"/>, <li>it
contains an HT cleanup segment and the first two bytes of the Magsgn contains an HT cleanup segment and the first two bytes of the Magsgn
byte-stream are between <tt>0xFF80</tt> and <tt>0xFF8F</tt>.</li> byte-stream are between <tt>0xFF80</tt> and <tt>0xFF8F</tt> (if the co de-block conforms to <xref target="JPEG2000-15"/>).</li>
</ul> </ul>
<t>NOTE: the last condition allows the encoder to insert padding bytes <t>NOTE: The last condition allows the encoder to insert padding bytes
to achieve a constant bit rate even when a code-block does not to achieve a constant bit rate even when a code-block does not
contribute code-bytes, as suggested at <xref target="jpeg2000-15"/>, contribute code-bytes, as suggested in Annex F.4 of <xref target="JPEG20
F.4.</t> 00-15"/>.
</t>
</section> </section>
</section> </section>
<section anchor="sec-receiver"> <section anchor="sec-receiver">
<name>Receiver</name> <name>Receiver</name>
<section anchor="sec-recv-ptstamp"> <section anchor="sec-recv-ptstamp">
<name>PTSTAMP</name> <name>PTSTAMP</name>
<t>Receivers can use <tt>PTSTAMP</tt> values to accelerate sender clock <t>Receivers can use <tt>PTSTAMP</tt> values to accelerate sender clock
skipping to change at line 1068 skipping to change at line 1250
<t>A receiver can discard RTP packets where <tt>QUAL</tt> &gt; N if it <t>A receiver can discard RTP packets where <tt>QUAL</tt> &gt; N if it
is interested in reconstructing an image that only incorporates quality is interested in reconstructing an image that only incorporates quality
layers N and below.</t> layers N and below.</t>
</section> </section>
<section anchor="recv-RES"> <section anchor="recv-RES">
<name>RES</name> <name>RES</name>
<t>The JPEG 2000 coding process decomposes an image using a sequence of <t>The JPEG 2000 coding process decomposes an image using a sequence of
discrete wavelet transforms (DWT) stages.</t> discrete wavelet transform (DWT) stages.</t>
<!-- [rfced] The titles of Tables 2 and 3 are very long. We suggest including
shorter titles and folding the information in the current titles into the
text describing the figures. What are your thoughts? If you agree, please
provide updated titles and text in OLD/NEW format. Also, would it be
helpful to move the figures to appear after the text describing them?
Original:
Table 2: Optional discarding of Body Packets based on the value
of the RES field when decoding a reduced resolution image, in the
case where N_L = 5 and all DWT stages consist of both horizontal
and vertical transforms. The image has nominal width and height
of W x H.
...
Table 3: Optional discarding of Body Packets based on the value
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
transforms. The image has nominal width and height of W x H.
-->
<table anchor="t-res-ll-example"> <table anchor="t-res-ll-example">
<name>Optional discarding of Body Packets based on the value of the <name>Optional discarding of Body Packets based on the value of the
<tt>RES</tt> field when decoding a reduced resolution image, in the <tt>RES</tt> field when decoding a reduced resolution image, in the
case where N<sub>L</sub> = 5 and all DWT stages consist of both case where N<sub>L</sub> = 5 and all DWT stages consist of both
horizontal and vertical transforms. The image has nominal width and horizontal and vertical transforms. The image has nominal width and
height of W x H.</name> height of W x H.</name>
<thead> <thead>
<tr> <tr>
<th>Decomposition level</th> <th>Decomposition Level</th>
<th>Resolution level</th> <th>Resolution Level</th>
<th>Sub-bands</th> <th>Sub-bands</th>
<th>Keep all Body Packets with <tt>RES</tt> equal to or less than <th>Keep all Body Packets with <tt>RES</tt> equal to or less than
this value...</th> this value...</th>
<th>... to decode an image with at most these dimensions</th> <th>...to decode an image with at most these dimensions</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>1</td> <td>1</td>
<td>5</td> <td>5</td>
<td>HL1,LH1,HH1</td> <td>HL1,LH1,HH1</td>
<td>7</td> <td>7</td>
<td>W x H</td> <td>W x H</td>
</tr> </tr>
skipping to change at line 1134 skipping to change at line 1335
<td>0</td> <td>0</td>
<td>LL5</td> <td>LL5</td>
<td>2</td> <td>2</td>
<td>(W/32) x (H/32)</td> <td>(W/32) x (H/32)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t><xref target="t-res-ll-example"/> illustrates the case where each DWT <t><xref target="t-res-ll-example"/> illustrates the case where each DWT
stage consists of both horizontal and vertical transforms, which is the stage consists of both horizontal and vertical transforms, which is the
only mode supported in <xref target="jpeg2000-1"/>. The first stage only mode supported in <xref target="JPEG2000-1"/>. The first stage
transforms the image into (i) the image at half-resolution (LL1 transforms the image into (i) the image at half-resolution (LL1
sub-bands) and (ii) residual high-frequency data (HH1, LH1, HL1 sub-bands) and (ii) residual high-frequency data (HH1, LH1, HL1
sub-bands). The second stage transforms the image at half-resolution sub-bands). The second stage transforms the image at half-resolution
(LL1 sub-bands) into the image at quarter resolution (LL2 sub-bands) and (LL1 sub-bands) into the image at quarter resolution (LL2 sub-bands) and
residual high-frequency data (HH2, LH2, HL2 sub-bands). This process is residual high-frequency data (HH2, LH2, HL2 sub-bands). This process is
repeated N<sub>L</sub> times, where N<sub>L</sub> is the number of repeated N<sub>L</sub> times, where N<sub>L</sub> is the number of
decomposition levels as defined in the COD and COC marker segments of decomposition levels as defined in the COD and COC marker segments of
the codestream.</t> the codestream.</t>
<t>The decoding process reconstructs the image by reversing the coding <t>The decoding process reconstructs the image by reversing the coding
process, starting with the lowest resolution image stored in the process, starting with the lowest resolution image stored in the
codestream (LL<sub>N<sub>L</sub></sub>).</t> codestream (LL<sub>N<sub>L</sub></sub>).</t>
<t>As a result, it is possible to reconstruct a lower resolution of the <t>As a result, it is possible to reconstruct a lower resolution of the
image by stopping the decoding process at a selected stage. For example, image by stopping the decoding process at a selected stage. For example,
in order to reconstruct the image at quarter resolution (LL2), only in order to reconstruct the image at quarter resolution (LL2), only
sub-bands with index greater than 2, e.g., HL3, LH3, HH3, HL4, LH4, HH4, sub-bands with index greater than 2 (e.g., HL3, LH3, HH3, HL4, LH4, HH4,
etc., are necessary. In other words, a receiver that wishes to etc.) are necessary. In other words, a receiver that wishes to
reconstruct an image at quarter resolution could discard all RTP packets reconstruct an image at quarter resolution could discard all RTP packets
where <tt>RES</tt> &gt;= 6 since those RTP packets can only contribute where <tt>RES</tt> &gt;= 6 since those RTP packets can only contribute
to HL1, LH1, HH1, HL2, LH2 and HH2 sub-bands.</t> to HL1, LH1, HH1, HL2, LH2, and HH2 sub-bands.</t>
<t>In the case where all DWT stages consist of both horizontal and <t>In the case where all DWT stages consist of both horizontal and
vertical transforms, the maximum decodable resolution is reduced by a vertical transforms, the maximum decodable resolution is reduced by a
factor of 2<sup>7 - N</sup> if all Body Packets where <tt>RES</tt> &gt; factor of 2<sup>7 - N</sup> if all Body Packets where <tt>RES</tt> &gt;
N are discarded.</t> N are discarded.</t>
<table anchor="t-res-lx-example"> <table anchor="t-res-lx-example">
<name>Optional discarding of Body Packets based on the value of the <name>Optional discarding of Body Packets based on the value of the
<tt>RES</tt> field when decoding a reduced resolution image, in the <tt>RES</tt> field when decoding a reduced resolution image, in the
case where N<sub>L</sub> = 5 and some DWT stages consist of only case where N<sub>L</sub> = 5 and some DWT stages consist of only
horizontal transforms. The image has nominal width and height of W x horizontal transforms. The image has nominal width and height of W x
H.</name> H.</name>
<thead> <thead>
<tr> <tr>
<th>Decomposition level</th> <th>Decomposition Level</th>
<th>Resolution level</th> <th>Resolution Level</th>
<th>Sub-bands</th> <th>Sub-bands</th>
<th>Keep all Body Packets with RES equal to or less than this <th>Keep all Body Packets with RES equal to or less than this
value...</th> value...</th>
<th>... to decode an image with at most these dimensions</th> <th>...to decode an image with at most these dimensions</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td>1</td> <td>1</td>
<td>5</td> <td>5</td>
<td>HL1,LH1,HH1</td> <td>HL1,LH1,HH1</td>
<td>7</td> <td>7</td>
<td>W x H</td> <td>W x H</td>
</tr> </tr>
skipping to change at line 1226 skipping to change at line 1427
<td>0</td> <td>0</td>
<td>LX5</td> <td>LX5</td>
<td>2</td> <td>2</td>
<td>(W/32) x (H/2)</td> <td>(W/32) x (H/2)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t><xref target="t-res-lx-example"/> illustrates the case where some DWT <t><xref target="t-res-lx-example"/> illustrates the case where some DWT
stages consist of only horizontal transforms, as specified at Annex F of stages consist of only horizontal transforms, as specified at Annex F of
<xref target="jpeg2000-2"/>.</t> <xref target="JPEG2000-2"/>.</t>
<t>A receiver can therefore discard all Body Packets where <tt>RES</tt> is <t>A receiver can therefore discard all Body Packets where <tt>RES</tt> 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 <xref target="t-res-ll-example"/> and threshold value, as illustrated in Tables <xref target="t-res-ll-example
<xref target="t-res-lx-example"/>.</t> " format="counter"/> and
<xref target="t-res-lx-example" format="counter"/>.</t>
</section> </section>
<section anchor="sec-receiver-xtrab"> <section anchor="sec-receiver-xtrab">
<name>Extra information</name> <name>Extra Information</name>
<t>The receiver MUST accept values <tt>XTRAC</tt> other than 0 and MUST <!-- [rfced] We updated "values XTRAC" to "values of XTRAC" here. Please let us
know if this is incorrect.
Original:
The receiver MUST accept values XTRAC other than 0 and MUST ignore
the value of XTRAB, whose length is given by XTRAC.
Perhaps:
The receiver MUST accept values of XTRAC other than 0 and MUST ignore
the value of XTRAB, whose length is given by XTRAC.
-->
<t>The receiver <bcp14>MUST</bcp14> accept values of <tt>XTRAC</tt> othe
r than 0 and <bcp14>MUST</bcp14>
ignore the value of <tt>XTRAB</tt>, whose length is given by ignore the value of <tt>XTRAB</tt>, whose length is given by
<tt>XTRAC</tt>.</t> <tt>XTRAC</tt>.</t>
<t>Future updates to this RTP payload format can specify <tt>XTRAB</tt> <t>Future updates to this RTP payload format can specify <tt>XTRAB</tt>
contents such that this content can be ignored by receivers that conform contents such that this content can be ignored by receivers that conform
to this specification.</t> to this specification.</t>
</section> </section>
<section anchor="sec-receiver-unassigned"> <section anchor="sec-receiver-unassigned">
<name>Unassigned values</name> <name>Unassigned Values</name>
<t>The receiver MUST ignore unassigned values (see additional discussion <t>The receiver <bcp14>MUST</bcp14> ignore unassigned values (see additi
at <xref target="sec-sender-unassigned"/>).</t> onal discussion
in <xref target="sec-sender-unassigned"/>).</t>
</section> </section>
<section anchor="sec-receiver-ext"> <section anchor="sec-receiver-ext">
<name>Extension values</name> <name>Extension Values</name>
<t>The receiver MUST discard an RTP packet that contains any extension <t>The receiver <bcp14>MUST</bcp14> discard an RTP packet that contains
any extension
value.</t> value.</t>
</section> </section>
<section anchor="sec-rcv-block-caching"> <section anchor="sec-rcv-block-caching">
<name>Code-block caching</name> <name>Code-Block Caching</name>
<t>This section applies only if <tt>C</tt> = 1.</t> <t>This section only applies if <tt>C</tt> = 1.</t>
<t>When <tt>C</tt> = 1, and as specified in <xref <t>When <tt>C</tt> = 1, and as specified in <xref
target="sec-send-block-caching"/>, the sender can improve bandwidth target="sec-send-block-caching"/>, the sender can improve bandwidth
efficiency by only occasionally transmitting code-blocks corresponding efficiency by only occasionally transmitting code-blocks corresponding
to static portions of the video and otherwise transmitting empty to static portions of the video and otherwise transmitting empty
code-blocks, as defined at <xref target="sec-send-block-caching"/>.</t> code-blocks, as defined in <xref target="sec-send-block-caching"/>.</t>
<!-- [rfced] How may we improve the introductory text here?
Original:
When decoding a codestream, and for each code-block in the
codestream:
* if the code-block in the codestream is empty, the receiver MUST
replace it with a matching code-block from the cache, if one
exists; or
* if the code-block in the codestream is not empty, the receiver
MUST replace any matching code-block from the cache with the code-
block in the codestream.
Perhaps:
When decoding a codestream, the following procedures apply for each
code-block in the codestream:
* If the code-block in the codestream is empty, the receiver MUST
replace it with a matching code-block from the cache, if one
exist.
* If the code-block in the codestream is not empty, the receiver
MUST replace any matching code-block from the cache with the code-
block in the codestream.
-->
<t>When decoding a codestream, and for each code-block in the <t>When decoding a codestream, and for each code-block in the
codestream:</t> codestream:</t>
<ul> <ul>
<li> <li>
if the code-block in the codestream is empty, the receiver MUST If the code-block in the codestream is empty, the receiver <bcp14>MU
replace it with a matching code-block from the cache, if one exists; ST</bcp14>
or replace it with a matching code-block from the cache, if one exists.
</li> </li>
<li> <li>
if the code-block in the codestream is not empty, the receiver MUST If the code-block in the codestream is not empty, the receiver <bcp1 4>MUST</bcp14>
replace any matching code-block from the cache with the code-block replace any matching code-block from the cache with the code-block
in the codestream. in the codestream.
</li> </li>
</ul> </ul>
<t>Two code-blocks are <em>matching</em> if the following <t>Two code-blocks are <em>matching</em> if the following
characteristics are identical for both: spatial coordinates, resolution characteristics are identical for both: spatial coordinates, resolution
level, component, sub-band and value of the <tt>TP</tt> field of the level, component, sub-band, and value of the <tt>TP</tt> field of the
parent RTP packet.</t> parent RTP packet.</t>
</section> </section>
</section> </section>
<section anchor="sec-media-type"> <section anchor="sec-media-type">
<name>Media Type</name> <name>Media Type</name>
<section> <section>
<name>General</name> <name>General</name>
<t>This RTP payload format is identified using the media type defined at <t>This RTP payload format is identified using the media type defined in
<xref target="sec-media-type-def"/>, which is registered in accordance <xref target="sec-media-type-def"/>. This media type has been registered
with <xref target="RFC4855"/> and using the template of <xref in accordance
with <xref target="RFC4855"/> using the template in <xref
target="RFC6838"/>.</t> target="RFC6838"/>.</t>
</section> </section>
<!-- [rfced] Media Type Template
a) Section 5.6 of RFC 6838 notes the following:
"N/A", written exactly that way, can be used in any field if desired
to emphasize the fact that it does not apply or that the question was
not omitted by accident. Do not use 'none' or other words that could
be mistaken for a response.
We have thus made the following update to the template in Section 9.2 of this
document. Let us know any concerns.
Original:
Required parameters: None
Updated:
Required parameters: N/A
b) We note that the template in Section 9.2 does not contain the "Fragment
identifier considerations:" and "Additional information:" sections of the
template defined in RFC 6838. We have added these as shown below. Let us know
if "N/A" is incorrect.
Updated:
Fragment identifier considerations: N/A
Additional information: N/A
-->
<section anchor="sec-media-type-def"> <section anchor="sec-media-type-def">
<name>Definition</name> <name>Definition</name>
<dl newline="true"> <dl newline="false" spacing="normal">
<dt>Type name</dt> <dt>Type name:</dt>
<dd>video</dd> <dd>video</dd>
<dt>Subtype name</dt> <dt>Subtype name:</dt>
<dd>jpeg2000-scl</dd> <dd>jpeg2000-scl</dd>
<dt>Required parameters</dt> <dt>Required parameters:</dt>
<dd>None</dd> <dd>N/A</dd>
<dt>Optional parameters</dt> <dt>Optional parameters:</dt>
<dd> <dd><t><br/></t>
<dl newline="true"> <dl newline="true">
<dt><tt>pixel</tt></dt> <dt><tt>pixel</tt>:</dt>
<dd> <dd>
<t>Specifies the pixel format used by the video sequence.</t> <t>Specifies the pixel format used by the video sequence.</t>
<t>The parameter <bcp14>MUST</bcp14> be a <tt>URI-reference</tt>
<t>The parameter MUST be a <tt>URI-reference</tt> as specified i as specified in
n
<xref target="RFC3986"/>.</t> <xref target="RFC3986"/>.</t>
<t>If the parameter is a <tt>relative-ref</tt> as specified in <t>If the parameter is a <tt>relative-ref</tt> as specified in
<xref target="RFC3986"/>, then it MUST be equal to one of the <xref target="RFC3986"/>, then it <bcp14>MUST</bcp14> be equal t
pixel formats specified in <xref target="t-pix-fmts"/> and the o one of the
RTP header and payload MUST conform with the characteristics of pixel formats specified in <xref target="t-pix-fmts"/>, and the
RTP header and payload <bcp14>MUST</bcp14> conform to the charac
teristics of
that pixel format.</t> that pixel format.</t>
<t>If the parameter is not a <tt>relative-ref</tt>, the <t>If the parameter is not a <tt>relative-ref</tt>, the
specification of the pixel format is left to the application tha t specification of the pixel format is left to the application tha t
defined the URI.</t> defined the URI.</t>
<t>If the parameter is not specified, the pixel format is <t>If the parameter is not specified, the pixel format is
unspecified.</t> unspecified.</t>
</dd> </dd>
<dt><tt>sample</tt></dt> <dt><tt>sample</tt>:</dt>
<dd> <dd>
<t>Specifies the format of the samples in each component of the <t>Specifies the format of the samples in each component of the
codestream.</t> codestream.</t>
<t>The parameter <bcp14>MUST</bcp14> be a <tt>URI-reference</tt>
<t>The parameter MUST be a <tt>URI-reference</tt> as specified i as specified in
n
<xref target="RFC3986"/>.</t> <xref target="RFC3986"/>.</t>
<t>If the parameter is a <tt>relative-ref</tt> as specified in <t>If the parameter is a <tt>relative-ref</tt> as specified in
<xref target="RFC3986"/>, then it MUST be equal to one of the <xref target="RFC3986"/>, then it <bcp14>MUST</bcp14> be equal t
formats specified in <xref target="sec-sample-fmts"/> and the o one of the
stream MUST conform with the characteristics of that format.</t> formats specified in <xref target="sec-sample-fmts"/>, and the
stream <bcp14>MUST</bcp14> conform to the characteristics of tha
t format.</t>
<t>If the parameter is not a <tt>relative-ref</tt>, the <t>If the parameter is not a <tt>relative-ref</tt>, the
specification of the sample format is left to the application th at specification of the sample format is left to the application th at
defined the URI.</t> defined the URI.</t>
<t>If the parameter is not specified, the sample format is <t>If the parameter is not specified, the sample format is
unspecified.</t> unspecified.</t>
</dd> </dd>
<dt><tt>width</tt></dt> <dt><tt>width</tt>:</dt>
<dd> <dd>
<t>Maximum width in pixels of each image. Integer between 0 and <t>Maximum width in pixels of each image. Integer between 0 and
4,294,967,295.</t> 4,294,967,295.</t>
<t>The parameter <bcp14>MUST</bcp14> be a sequence of 1 or more
<t>The parameter MUST be a sequence of 1 or more digits.</t> digits.</t>
<t>If the parameter is not specified, the maximum width is <t>If the parameter is not specified, the maximum width is
unspecified.</t> unspecified.</t>
</dd> </dd>
<dt><tt>height</tt></dt> <dt><tt>height</tt>:</dt>
<dd> <dd>
<t>Maximum height in pixels of each image. Integer between 0 and <t>Maximum height in pixels of each image. Integer between 0 and
4,294,967,295.</t> 4,294,967,295.</t>
<t>The parameter <bcp14>MUST</bcp14> be a sequence of 1 or more
<t>The parameter MUST be a sequence of 1 or more digits.</t> digits.</t>
<t>If the parameter is not specified, the maximum height is <t>If the parameter is not specified, the maximum height is
unspecified.</t> unspecified.</t>
</dd> </dd>
<dt>signal</dt> <dt><tt>signal</tt>:</dt>
<dd> <dd>
<t>Specifies the sequence of image types.</t> <t>Specifies the sequence of image types.</t>
<t>The parameter <bcp14>MUST</bcp14> be a <tt>URI-reference</tt>
<t>The parameter MUST be a <tt>URI-reference</tt> as specified as specified
in <xref target="RFC3986"/>.</t> in <xref target="RFC3986"/>.</t>
<t>If the parameter is a <tt>relative-ref</tt> as specified in <t>If the parameter is a <tt>relative-ref</tt> as specified in
<xref target="RFC3986"/>, then it MUST be equal to one of the <xref target="RFC3986"/>, then it <bcp14>MUST</bcp14> be equal t
signal formats specified in <xref target="sec-signal-fmts"/> and o one of the
the image sequence MUST conform to that signal format.</t> signal formats specified in <xref target="sec-signal-fmts"/>, an
d
the image sequence <bcp14>MUST</bcp14> conform to that signal fo
rmat.</t>
<t>If the parameter is not a <tt>relative-ref</tt>, the <t>If the parameter is not a <tt>relative-ref</tt>, the
specification of the pixel format is left to the application specification of the pixel format is left to the application
that defined the URI.</t> that defined the URI.</t>
<t>If the parameter is not specified, the stream consists of an <t>If the parameter is not specified, the stream consists of an
arbitrary sequence of image types.</t> arbitrary sequence of image types.</t>
</dd> </dd>
<dt><tt>caps</tt></dt> <dt><tt>caps</tt>:</dt>
<dd> <dd>
<t>The parameter contains a list of sets of constraints to <t>The parameter contains a list of sets of constraints to
which the stream conforms, with each set of constraints which the stream conforms, with each set of constraints
identified using an <tt>absolute-URI</tt> defined by an identified using an <tt>absolute-URI</tt> defined by an
application.</t> application.</t>
<t>The parameter <bcp14>MUST</bcp14> conform to the <tt>uri-list
</tt> syntax
expressed as follows using ABNF <xref target="RFC5234"/>:</t>
<t>The parameter MUST conform to the <tt>uri-list</tt> syntax <!-- [rfced] We got an error when parsing the line of ABNF in Section 9.2. We
expressed using ABNF (<xref target="RFC5234"/>):</t> used the parser at https://author-tools.ietf.org/abnf and added some definitions
<sourcecode type="abnf"> from RFCs 3986 and 5234. Please review.
uri-list = absolute-URI *(";" absolute-URI)
</sourcecode>
<t>The application that defines the <tt>absolute-URI</tt> MUST This is one of the definitions we added when parsing:
path-empty = 0<pchar>
And it seems to be causing this error:
(61:27): fyi: absolute repeat count of zero means this element may not occur a
t all
-->
<sourcecode type="abnf"><![CDATA[
uri-list = absolute-URI *(";" absolute-URI)
]]></sourcecode>
<t>The application that defines the <tt>absolute-URI</tt> <bcp14
>MUST</bcp14>
ensure that it does not contain any <tt>";"</tt> character and ensure that it does not contain any <tt>";"</tt> character and
MUST associate it with a set of constraints to which the stream <bcp14>MUST</bcp14> associate it with a set of constraints to wh ich the stream
conforms. Such constraints can, for example, include the maximum conforms. Such constraints can, for example, include the maximum
height and width of images.</t> height and width of images.</t>
<t>If the parameter is not specified, constraints beyond those
<t>If the parameter is not specified, constraints, beyond those specified in this document are unspecified.</t>
specified in this document, are unspecified.</t>
</dd> </dd>
<dt><tt>cache</tt></dt> <dt><tt>cache</tt>:</dt>
<dd> <dd>
<t>The value of the parameter MUST be either <tt>false</tt> or <t>The value of the parameter <bcp14>MUST</bcp14> be either <tt> false</tt> or
<tt>true</tt>.</t> <tt>true</tt>.</t>
<t>If the parameter is <tt>true</tt>, the field <tt>C</tt> <bcp1
<t>If the parameter is <tt>true</tt>, the field <tt>C</tt> MAY 4>MAY</bcp14>
be 0 or 1; otherwise the field <tt>C</tt> MUST be 0.</t> be 0 or 1; otherwise, the field <tt>C</tt> <bcp14>MUST</bcp14> b
e 0.</t>
<t>If the parameter is not specified, then the parameter is <t>If the parameter is not specified, then the parameter is
equal to <tt>false</tt>.</t> equal to <tt>false</tt>.</t>
</dd> </dd>
</dl> </dl>
</dd> </dd>
<dt>Encoding considerations</dt> <dt>Encoding considerations:</dt>
<dd>This media type is framed and binary, see <xref target="RFC6838" <dd>This media type is framed and binary. See <xref target="RFC6838"
section="4.8"/>.</dd> section="4.8"/>.</dd>
<dt>Security considerations</dt> <dt>Security considerations:</dt>
<dd> <dd>
<t>JPEG 2000 is a flexible image format. As a result, the size of <t>JPEG 2000 is a flexible image format. As a result, the size of
the memory structures required to process JPEG 2000 images can vary the memory structures required to process JPEG 2000 images can vary
greatly depending on the characteristics of the image and the greatly depending on the characteristics of the image and the
encoding parameters. For example, the JPEG 2000 syntax allows image encoding parameters. For example, the JPEG 2000 syntax allows image
height and width up to 2<sup>32</sup> - 1 pixels, which is also height and width up to 2<sup>32</sup> - 1 pixels, which is also
captured in the syntax of the <tt>height</tt> and <tt>width</tt> captured in the syntax of the <tt>height</tt> and <tt>width</tt>
parameters of the media type specified at <xref parameters of the media type specified in <xref
target="sec-media-type-def"/>. Implementations SHOULD therefore take target="sec-media-type-def"/>. Therefore, implementations <bcp14>SHO
ULD</bcp14> take
care when processing input that influences the size of memory care when processing input that influences the size of memory
structures, and SHOULD fail gracefully when resource constraints are structures and <bcp14>SHOULD</bcp14> fail gracefully when resource c onstraints are
exceeded.</t> exceeded.</t>
<t>See also <xref target="sec-sec"/>.</t> <t>See also <xref target="sec-sec"/>.</t>
</dd> </dd>
<dt>Interoperability considerations</dt> <dt>Interoperability considerations:</dt>
<dd>The RTP stream is a sequence of JPEG 2000 images. An <dd>The RTP stream is a sequence of JPEG 2000 images. An
implementation that conforms to the family of JPEG 2000 standards can implementation that conforms to the family of JPEG 2000 standards can
decode and attempt to display each image.</dd> decode and attempt to display each image.</dd>
<dt>Published specification</dt> <dt>Published specification:</dt>
<dd>This document</dd> <dd>RFC 9828</dd>
<dt>Applications that use this media type</dt> <dt>Applications that use this media type:</dt>
<dd>video streaming and communication</dd> <dd>video streaming and communication</dd>
<dt>Person and email address to contact for further information</dt> <dt>Fragment identifier considerations:</dt>
<dd>N/A</dd>
<dt>Additional information:</dt>
<dd>N/A</dd>
<dt>Person &amp; email address to contact for further information:</dt
>
<dd>Pierre-Anthony Lemieux &lt;pal@sandflow.com&gt;</dd> <dd>Pierre-Anthony Lemieux &lt;pal@sandflow.com&gt;</dd>
<dt>Intended usage</dt> <dt>Intended usage:</dt>
<dd>COMMON</dd> <dd>COMMON</dd>
<dt>Restrictions on Usage</dt> <dt>Restrictions on Usage:</dt>
<dd>This media type depends on RTP framing, and hence is only defined <dd>This media type depends on RTP framing and hence is only defined
for use with RTP as specified at <xref target="RFC3550"/>. Transport for use with RTP as specified in <xref target="RFC3550"/>. Transport
within other framing protocols is not defined at the time.</dd> within other framing protocols is not defined at the time.</dd>
<dt>Author</dt> <dt>Author:</dt>
<dd><eref target="mailto:pal@sandflow.com">Pierre-Anthony Lemieux <dd>Pierre-Anthony Lemieux &lt;pal@sandflow.com&gt;
</eref></dd> </dd>
<dt>Change controller</dt> <dt>Change controller:</dt>
<dd>IETF</dd> <dd>IETF</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="sec-sdp"> <section anchor="sec-sdp">
<name>Mapping to the Session Description Protocol (SDP)</name> <name>Mapping to the Session Description Protocol (SDP)</name>
<t>The mapping of the payload format media type and its parameters to <t>The mapping of the payload format media type and its parameters to
SDP, as specified in <xref target="RFC8866"/> MUST be done according to SDP, as specified in <xref target="RFC8866"/>, <bcp14>MUST</bcp14> be done according to
<xref target="RFC4855" section="3"/>.</t> <xref target="RFC4855" section="3"/>.</t>
</section> </section>
<section anchor="sec-congestion-control"> <section anchor="sec-congestion-control">
<name>Congestion control</name> <name>Congestion Control</name>
<t>Since this RTP payload format can be used in a variety of applications <t>Since this RTP payload format can be used in a variety of applications
across many different contexts, there is no single congestion control across many different contexts, there is no single congestion control
mechanism that will work for all. Below is a non-exhaustive list of exampl e mechanism that will work for all. Below is a non-exhaustive list of exampl e
mechanisms that can be used:</t> mechanisms that can be used:</t>
<ul> <ul>
<li>a sender can offer several alternative streams for a given video <li>a sender can offer several alternative streams for a given video
signal, each with a different data rate corresponding to a different signal, each with a different data rate corresponding to a different
compression ratio;</li> compression ratio;</li>
<li>a sender can modulate the data rate within a stream by modulating <li>a sender can modulate the data rate within a stream by modulating
the resolution, frame rate, or compression ratio of the underlying video the resolution, frame rate, or compression ratio of the underlying video
signal; or</li> signal; or</li>
<li>an intermediate system can lower the data rate of a stream by <li>an intermediate system can lower the data rate of a stream by
discarding resolutions levels and/or quality layers, as specified at discarding resolutions levels and/or quality layers, as specified in
<xref target="sec-filtering"/>.</li> <xref target="sec-filtering"/>.</li>
</ul> </ul>
<t>As suggested at <xref target="RFC3550" sectionFormat="of" section="10"/ > RTCP feedback can <t>As suggested in <xref target="RFC3550" sectionFormat="of" section="10"/ >, RTCP feedback can
be used in the data rate adaptation process.</t> be used in the data rate adaptation process.</t>
</section> </section>
<section anchor="sec-iana"> <section anchor="sec-iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This memo requests that IANA registers the media type specified at <t>IANA has registered the media type specified in
<xref target="sec-media-type"/>.</t> <xref target="sec-media-type"/>.</t>
</section> </section>
<section anchor="sec-sec"> <section anchor="sec-sec">
<name>Security considerations</name> <name>Security Considerations</name>
<t>RTP packets using the payload format specified in this document are <t>RTP packets using the payload format specified in this document are
subject to the security considerations discussed in <xref subject to the security considerations discussed in <xref
target="RFC3550"/> , and in any applicable RTP profile such as <xref target="RFC3550"/> and in any applicable RTP profile such as <xref
target="RFC3551"/>, <xref target="RFC4585"/>, <xref target="RFC3711"/>, target="RFC3551"/>, <xref target="RFC4585"/>, <xref target="RFC3711"/>, an
d
<xref target="RFC5124"/>. However, as <xref target="RFC7202"/> discusses, <xref target="RFC5124"/>. However, as <xref target="RFC7202"/> discusses,
it is not an RTP payload format's responsibility to discuss or mandate it is not an RTP payload format's responsibility to discuss or mandate
what solutions are used to meet the basic security goals like what solutions are used to meet the basic security goals like
confidentiality, integrity, and source authenticity for RTP in general. confidentiality, integrity, and source authenticity for RTP in general.
This responsibility lays on anyone using RTP in an application. They can This responsibility lies with anyone using RTP in an application. They can
find guidance on available security mechanisms and important find guidance on available security mechanisms and important
considerations in <xref target="RFC7201"/>. Applications SHOULD use one or considerations in <xref target="RFC7201"/>. Applications <bcp14>SHOULD</bc
more appropriate strong security mechanisms. The rest of this Security p14> use one or
Considerations section discusses the security impacting properties of the more appropriate strong security mechanisms. The rest of this
section discusses the security impacting properties of the
payload format itself.</t> payload format itself.</t>
<t>This RTP payload format and its media decoder do not exhibit any <t>This RTP payload format and its media decoder do not exhibit any
significant non-uniformity in the receiver-side computational complexity significant non-uniformity in the receiver-side computational complexity
for RTP Packet processing, and thus are unlikely to pose a for RTP packet processing and thus are unlikely to pose a
denial-of-service threat due to the receipt of pathological data. Nor does denial-of-service threat due to the receipt of pathological data. In addit
the RTP payload format contain any active content.</t> ion,
the RTP payload format does not contain any active content.</t>
<t>Security considerations related to the JPEG 2000 codestream contained <t>Security considerations related to the JPEG 2000 codestream contained
in the payload are discussed at <xref target="RFC3745" section="3"/>.</t> in the payload are discussed in <xref target="RFC3745" section="3"/>.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="jpeg2000-1">
<!-- [rfced] References
a) Would you like the references to be alphabetized or left in their current
order?
b) The following references have been withdrawn or superseded and replaced by
newer versions. We updated the dates to the most recent version and added
URLs. Please review to ensure correctness.
[jpeg2000-1]
[jpeg2000-2]
[rec-itu-t-h273]
[jpeg2000-9]
c) FYI - We added URLs to the following reference entries. Please review.
[jpeg2000-15]
[ov2110-0]
-->
<reference anchor="JPEG2000-1" target="https://www.itu.int/rec/T-REC-T.8
00/">
<front> <front>
<title abbrev="Rec. ITU-T T.800">Recommendation ITU-T T.800, JPEG <title abbrev="Rec. ITU-T T.800">Information technology - JPEG 2000
2000 image coding system: Core coding system</title> image
coding system: Core coding system</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2019" month="06"/> <date year="2024" month="07"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="T.800" />
</reference> </reference>
<reference anchor="jpeg2000-2">
<reference anchor="JPEG2000-2" target="https://www.itu.int/rec/T-REC-T.8
01/">
<front> <front>
<title abbrev="Rec. ITU-T T.801">Recommendation ITU-T T.801, JPEG <title abbrev="Rec. ITU-T T.801">Information Technology - JPEG 2000
2000 image coding system: Extensions</title> image
coding system - Extensions</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="06"/> <date year="2023" month="08"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="T.801" />
</reference> </reference>
<reference anchor="jpeg2000-15">
<reference anchor="JPEG2000-15" target="https://www.itu.int/rec/T-REC-T.
814/">
<front> <front>
<title abbrev="Rec. ITU-T T.814">Recommendation ITU-T T.814, JPEG <title abbrev="Rec. ITU-T T.814">Information technology - JPEG 2000
2000 image coding system: High-throughput JPEG 2000</title> image
coding system: High-throughput JPEG 2000</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2019" month="06"/> <date year="2019" month="06"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="T.814" />
</reference> </reference>
<reference anchor="rec-itu-t-h273">
<reference anchor="REC-ITU-T-H273" target="https://www.itu.int/rec/T-REC
-H.273">
<front> <front>
<title abbrev="Rec. ITU-T H.273">Recommendation ITU-T H.273, <title abbrev="Rec. ITU-T H.273">Coding-independent code points fo
Coding-independent code points for video signal type r video signal type
identification</title> identification</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2021" month="07"/> <date year="2024" month="07"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="H.273" />
</reference> </reference>
<reference anchor="jpeg2000-9">
<reference anchor="JPEG2000-9" target="https://www.itu.int/rec/T-REC-T
.808">
<front> <front>
<title abbrev="Rec. ITU-T T.808">JPEG 2000 image coding system: <title abbrev="Rec. ITU-T T.808">Information technology - JPEG 200
Interactivity tools, APIs and protocols</title> 0 image
coding system: Interactivity tools, APIs and protocols</title>
<author> <author>
<organization>ITU-T</organization> <organization>ITU-T</organization>
</author> </author>
<date year="2005" month="01"/> <date year="2022" month="12"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="T.808" />
</reference> </reference>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
.3550.xml"/> .3550.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
.8866.xml"/> .8866.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
.4855.xml"/> .4855.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
.3986.xml"/> .3986.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
.5234.xml"/> .5234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC .2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC .2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC .8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC .8174.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="ov2110-0"> <reference anchor="OV2110-0" target="https://pub.smpte.org/latest/ov2110 -0/ov2110-0-2018.pdf">
<front> <front>
<title abbrev="SMPTE OV 2110-0">Professional Media Over Managed IP <title abbrev="SMPTE OV 2110-0">Professional Media Over Managed IP
Networks, Roadmap for the 2110 Document Suite</title> Networks, Roadmap for the 2110 Document Suite</title>
<author> <author>
<organization>SMPTE</organization> <organization>SMPTE</organization>
</author> </author>
<date year="2018" month="12" day="04"/> <date year="2018" month="12" day="04"/>
</front> </front>
</reference> </reference>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
371.xml"/> 371.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
175.xml"/> 175.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
838.xml"/> 838.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
551.xml"/> 551.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
585.xml"/> 585.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
711.xml"/> 711.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
124.xml"/> 124.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
201.xml"/> 201.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
202.xml"/> 202.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
745.xml"/> 745.xml"/>
<xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
450.xml"/> 450.xml"/>
</references> </references>
</references> </references>
<section anchor="sec-pixel-fmts"> <section anchor="sec-pixel-fmts">
<name>Pixel formats</name> <name>Pixel Formats</name>
<t><xref target="t-pix-fmts"/> defines pixel formats.</t> <t><xref target="t-pix-fmts"/> defines pixel formats.</t>
<table anchor="t-pix-fmts"> <table anchor="t-pix-fmts">
<name>Defined pixel formats</name> <name>Defined Pixel Formats</name>
<thead> <thead>
<tr> <tr>
<th>NAME</th> <th>NAME</th>
<th>SAMP</th> <th>SAMP</th>
<th>COMPS</th> <th>COMPS</th>
<th>TRANS</th> <th>TRANS</th>
<th>PRIMS</th> <th>PRIMS</th>
<th>MAT</th> <th>MAT</th>
<th>VFR</th> <th>VFR</th>
<th>Mapping in <xref target="t-color-map"/></th> <th>Mapping in <xref target="t-color-map"/></th>
skipping to change at line 1763 skipping to change at line 2057
<td>18</td> <td>18</td>
<td>9</td> <td>9</td>
<td>9</td> <td>9</td>
<td>0</td> <td>0</td>
<td>YCbCr</td> <td>YCbCr</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Each pixel format is characterized by the following:</t> <t>Each pixel format is characterized by the following:</t>
<dl newline="true"> <dl newline="false" spacing="normal">
<dt><tt>NAME</tt></dt> <dt><tt>NAME</tt>:</dt>
<dd>Identifies the pixel format</dd> <dd>Identifies the pixel format</dd>
<dt><tt>SAMP</tt></dt> <dt><tt>SAMP</tt>:</dt>
<dd> <dd><t><br/></t>
<dl> <dl newline="false" indent="8">
<dt>4:2:0</dt> <dt>4:2:0</dt>
<dd>The C<sub>b</sub> and C<sub>r</sub> color channels are <dd>The C<sub>b</sub> and C<sub>r</sub> color channels are
subsampled horizontally and vertically by 1/2.</dd> subsampled horizontally and vertically by 1/2.</dd>
<dt>4:2:2</dt> <dt>4:2:2</dt>
<dd>The C<sub>b</sub> and C<sub>r</sub> color channels are <dd>The C<sub>b</sub> and C<sub>r</sub> color channels are
subsampled horizontally by 1/2.</dd> subsampled horizontally by 1/2.</dd>
<dt>4:4:4</dt> <dt>4:4:4</dt>
<dd>No color channels are sub-sampled.</dd> <dd>No color channels are subsampled.</dd>
</dl> </dl>
</dd> </dd>
<dt><tt>COMPS</tt></dt> <dt><tt>COMPS</tt>:</dt>
<dd> <dd><t><br/></t>
<dl> <dl newline="false" indent="9">
<dt>RGB</dt> <dt>RGB:</dt>
<dd>Each codestream contains exactly three components, associated <dd>Each codestream contains exactly three components, associated
with the R, G and B color channels, in order.</dd> with the R, G, and B color channels, in order.</dd>
<dt>YCbCr</dt> <dt>YCbCr:</dt>
<dd>Each codestream contains exactly three components, associated <dd>Each codestream contains exactly three components, associated
with the Y, C<sub>b</sub> and C<sub>r</sub> color channels, in with the Y, C<sub>b</sub>, and C<sub>r</sub> color channels, in
order.</dd> order.</dd>
</dl> </dl>
</dd> </dd>
<dt><tt>TRANS</tt></dt> <dt><tt>TRANS</tt>:</dt>
<dd> <dd>
<t>Identifies the transfer characteristics allowed by the pixel <t>Identifies the transfer characteristics allowed by the pixel
format, as defined at <xref target="rec-itu-t-h273"/></t> format, as defined in <xref target="REC-ITU-T-H273"/>.</t>
</dd> </dd>
<dt><tt>PRIMS</tt></dt> <dt><tt>PRIMS</tt>:</dt>
<dd> <dd>
<t>Identifies the color primaries allowed by the pixel <t>Identifies the color primaries allowed by the pixel
format, as defined at <xref target="rec-itu-t-h273"/></t> format, as defined in <xref target="REC-ITU-T-H273"/>.</t>
</dd> </dd>
<dt><tt>MAT</tt></dt> <dt><tt>MAT</tt>:</dt>
<dd> <dd>
<t>Identifies the matrix coefficients allowed by the pixel <t>Identifies the matrix coefficients allowed by the pixel
format, as defined at <xref target="rec-itu-t-h273"/></t> format, as defined in <xref target="REC-ITU-T-H273"/>.</t>
</dd> </dd>
<dt><tt>VFR</tt></dt> <dt><tt>VFR</tt>:</dt>
<dd> <dd>
<t>Allows values of the VideoFullRangeFlag defined at <xref target="re c-itu-t-h273"/></t> <t>Allows values of the VideoFullRangeFlag defined in <xref target="RE C-ITU-T-H273"/>.</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="sec-signal-fmts"> <section anchor="sec-signal-fmts">
<name>Signal formats</name> <name>Signal Formats</name>
<dl newline="true"> <dl newline="false">
<dt><tt>prog</tt></dt> <dt><tt>prog</tt>:</dt>
<dd>The stream MUST only consist of a sequence of progressive <dd>The stream <bcp14>MUST</bcp14> only consist of a sequence of progres
sive
frames.</dd> frames.</dd>
<dt><tt>psf</tt></dt> <dt><tt>psf</tt>:</dt>
<dd>Progressive segmented frame (PsF) stream. The stream MUST only <dd>Progressive segmented frame (PsF) stream. The stream <bcp14>MUST</bc
p14> only
consist of an alternating sequence of first segment and second consist of an alternating sequence of first segment and second
segment.</dd> segment.</dd>
<dt><tt>tff</tt></dt> <dt><tt>tff</tt>:</dt>
<dd>Interlaced stream. The stream MUST only consist of an alternating <dd>Interlaced stream. The stream <bcp14>MUST</bcp14> only consist of an
alternating
sequence of first field and second field, where the first line of the sequence of first field and second field, where the first line of the
first field is the first line of the frame.</dd> first field is the first line of the frame.</dd>
<dt><tt>bff</tt></dt> <dt><tt>bff</tt>:</dt>
<dd>Interlaced stream. The stream MUST only consist of an alternating <dd>Interlaced stream. The stream <bcp14>MUST</bcp14> only consist of an
alternating
sequence of first field and second field, where the first line of the sequence of first field and second field, where the first line of the
first field is the second line of the frame.</dd> first field is the second line of the frame.</dd>
</dl> </dl>
</section> </section>
<section anchor="sec-sample-fmts"> <section anchor="sec-sample-fmts">
<name>Sample formats</name> <name>Sample Formats</name>
<dl newline="true"> <dl newline="false" indent="6">
<dt><tt>8</tt></dt> <dt><tt>8</tt></dt>
<dd>All components consist of unsigned 8-bit integer samples.</dd> <dd>All components consist of unsigned 8-bit integer samples.</dd>
<dt><tt>10</tt></dt> <dt><tt>10</tt></dt>
<dd>All components consist of unsigned 10-bit integer samples.</dd> <dd>All components consist of unsigned 10-bit integer samples.</dd>
<dt><tt>12</tt></dt> <dt><tt>12</tt></dt>
<dd>All components consist of unsigned 12-bit integer samples.</dd> <dd>All components consist of unsigned 12-bit integer samples.</dd>
<dt><tt>16</tt></dt> <dt><tt>16</tt></dt>
<dd>All components consist of unsigned 16-bit integer samples.</dd> <dd>All components consist of unsigned 16-bit integer samples.</dd>
</dl> </dl>
</section> </section>
</back> </back>
<!-- [rfced] Notes
a) In cases like the following with "stacked" notes (there are
several instances in the document), may we update as shown below?
Original:
NOTE: Only ORDH = 4 and ORDH = 6 allow sub-codestream latency
streaming.
NOTE: Progression order PRCL is defined in [jpeg2000-2]. The
other progression orders are specified in [jpeg2000-1].
Perhaps:
NOTES:
* Only ORDH = 4 and ORDH = 6 allow sub-codestream latency
streaming.
* Progression order PRCL is defined in [jpeg2000-2]. The
other progression orders are specified in [jpeg2000-1].
b) Section 5.1 has numbered notes (i.e., NOTE 1 and NOTE 2), but we don't see
this in other sections. Would you like to make these notes consistent with the
others in the document?
c) Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
.
-->
<!-- [rfced] Terminology
a) We note inconsistencies in the terms below throughout the text. Should
these be uniform? If so, please let us know which form is preferred.
coded image data vs. image coded data
resolutions level vs. resolution level
Fixed Header vs. fixed header
Payload Header vs. payload header
Note: "main header" is consistently lowercase, and "Extended Header" is
consistently capitalized in this document.
b) We note inconsistencies in the term listed below. We chose the form on the
right. Please let us know any objections.
RTP Packet vs. RTP packet
-->
<!-- [rfced] Text styling
a) The file below lists terms enclosed in <tt> in this document.
Please review to ensure the usage of <tt> is correct and consistent. Let
us know if any updates are needed.
https://www.rfc-editor.org/authors/rfc9828-TT.txt
Note: In the html and pdf outputs, the text enclosed in <tt> appears in
fixed-width font. In the txt output, the text enclosed in <tt> has no
text formatting.
b) FYI - We updated <tt> to <artwork> for the following equations:
Original:
<extended sequence number> = <ESEQ field> * 65536 + <sequence
number field of the RTP fixed header>
...
PID = c + s * num_components
c) The following are the instances of <em> in the document. Please review and
confirm that the <em> is needed.
<em>empty</em>
<em>matching</em>
<em>c</em>
<em>s</em>
<em>num_components</em>
Note: In the html and pdf outputs, the text enclosed in <em> appears in
italics. In the txt output, the text enclosed in <em> appears with an
underline character before and after.
-->
<!-- [rfced] Abbreviations
a) Should "LSBs" be expanded as "least significant bits" here (or perhaps just
use the expansion since this is the only instance in the document)? Our list
also includes the expansion "Locator-Status-Bit". See
https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list.
Original:
The counter is sampled at the point
in time when each RTP Packet is transmitted and the 12 LSBs of the
sample are stored in the PTSTAMP field.
b) How should "HT" be expanded? Below is the only instance in the document.
Original:
* if the code-block conforms to [jpeg2000-15], contains an HT
cleanup segment and the first two bytes of the Magsgn byte-stream
are between 0xFF80 and 0xFF8F.
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc> </rfc>
 End of changes. 297 change blocks. 
516 lines changed or deleted 1016 lines changed or added

This html diff was produced by rfcdiff 1.48.