<?xml version="1.0"encoding="utf-8"?> <?xml-model href="rfc7991bis.rnc"?>encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" ipr="trust200902" consensus="true" docName="draft-ietf-avtcore-rtp-j2k-scl-08" number="9828" updates="" obsoletes="" sortRefs="false" symRefs="true" xml:lang="en" version="3"><front> <title abbrev="Sub-codestream<!-- [rfced] Document title a) Please review the document title, especially "sub-codestream latency JPEG 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 forsub-codestream latencySub-Codestream Latency JPEG 2000streaming</title>Streaming</title> <seriesInfoname="Internet-Draft" value="draft-ietf-avtcore-rtp-j2k-scl-08"/>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. --> <authorinitials='P.-A.'initials='P.' surname='Lemieux' fullname='Pierre-Anthony Lemieux' role="editor"> <organization>Sandflow Consulting LLC</organization> <address> <postal> <city>San Mateo</city> <region>CA</region><country>US</country><country>United States of America</country> </postal> <email>pal@sandflow.com</email> </address> </author> <authorinitials='D. S.'initials='D.' surname='Taubman' fullname='David Scott Taubman'> <organization abbrev="University of New South Wales">University of New South Wales</organization> <address> <postal> <city>Sydney</city><country>AU</country><country>Australia</country> </postal> <email>d.taubman@unsw.edu.au</email> </address> </author><area>Applications and Real-Time Area</area> <workgroup>Audio/Video Transport Core Maintenance</workgroup><date month="August" year="2025"/> <area>WIT</area> <workgroup>avtcore</workgroup> <keyword>JPEG 2000</keyword> <keyword>J2K</keyword> <keyword>HTJ2K</keyword> <keyword>low latency</keyword> <keyword>scalable</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 signal encoded as a sequence of JPEG 2000 codestreams. --> <abstract> <t>This document defines the RTP payload formatdefinesfor the streaming of a video signal encoded 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 before the entire image is availableto,to or encodedby,by the sender.</t> </abstract> </front> <middle> <section> <name>Introduction</name> <t>Thereal-time transport protocolReal-time Transport Protocol (RTP), which is specified in <xref target="RFC3550"/>, provides end-to-end network transport functions for transmitting real-timedata,data but does not define the characteristics of the data itself (the payload), which varies across applications and is defined in companion RTP payload format documents.</t> <t>This RTP payload format specifies the streaming of a video signal encoded as a sequence of JPEG 2000 codestreams (see <xref target="sec-media-description"/> for a primer on the structure of JPEG 2000 codestreams). JPEG 2000 is a flexible image codec that supports resolution and quality scalability,lossy to losslesslossy-to-lossless coding, non-iterative optimal rate control, andhigh-dynamichigh dynamic range,multi-channelmulti-channel, andsub-sampledsubsampled images. These features have made it a mainstay in high-performance applications, including medical, geospatial, archival, cinema, studiopost-productionpost-production, and TV production.</t> <t>In addition to supporting a variety offrame scanningframe-scanning techniques (progressive,interlacedinterlaced, and progressive segmented frame) and image characteristics, the payload format supports real-time image transmission (live streaming), where image content is encoded,transmittedtransmitted, and decoded continuously as it is beingproduced andproduced, with minimal latency. Target applications include real-time TV production over IP(<xref target="ov2110-0"/>),<xref target="OV2110-0"/>, remote presence, surveillance, etc. 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><li>the<li>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. Specifically, the payload format does not rely on the JPEG 2000 PLM (Packet length, main header) and PLT (Packet length, tile-part header) marker segments for recovery after RTPPacketpacket loss since these markers can only be written after the codestream is complete and are thus incompatible with sub-codestream latency. Instead, the payload format includes payload header fields (<tt>ORDH</tt>, <tt>ORDB</tt>,<tt>POS</tt><tt>POS</tt>, and <tt>PID</tt>) thatindicatesindicate whether the RTP packet contains a resynchronization (resync) point and how a recipient can restart codestream processing from that resync point. This contrasts with <xref target="RFC5371"/>, which also specifies an RTP payload format for JPEG2000,2000 but relies on codestream structures that cannot be emitted until the entire codestream is available.</li><li>as<li>As in <xref target="RFC4175"/>, the payload format defines an extended sequence number, which extends the standard (16-bit) sequence number of the RTP fixed header by storing additional (high-order) bits in the payload header (<tt>ESEQ</tt> field). This enables the payload format to accommodate high data rates without ambiguity, since the standard sequence number will roll over very quickly for high data rates likely to be encountered in this application. For example, the standard sequence number will roll over in 0.5 seconds with a1-Gbps1 Gbps video stream with RTPPacketpacket sizes of at least 1000 octets, which can be a problem for detecting loss and out-of-order RTPpacketspackets, particularly in instances where the round-trip time is greater than theroll overrollover period (0.5 seconds in this example).</li><li>the<li>The payload header optionally contains a temporal offset (<tt>PTSTAMP</tt>) relative to the first RTPPacketpacket with the same value of RTP <tt>timestamp</tt> field (<xref target="def-timestamp"/>). The higher resolution of <tt>PTSTAMP</tt> compared to the <tt>timestamp</tt> allows receivers to recover the sender's clock more rapidly.</li> </ul> <t>In addition to support for sub-codestream latency and high-precision sender clock recovery, the payload format improves on <xref target="RFC5371"/> by supporting:</t> <ul> <li>code-block caching for screen content (see <xref target="sec-send-block-caching"/>);</li><li>progressive-segmented<li>progressive segmented frame (PsF) video support (see <xreftarget="sec-signal-fmts"/>;target="sec-signal-fmts"/>); and</li> <li>explicit colorspace signaling (see <xreftarget="def-S"/>.</li>target="def-S"/>).</li> </ul> <t>Finally, the payload format also makes use of the unique scalability features of JPEG 2000 to allow an intermediate system or recipient to discard resolutions levels and/or quality layers merely by inspecting RTPPacketpacket headers (<tt>QUAL</tt> and <tt>RES</tt> fields), without having to parse the underlying codestream (see <xref target="sec-filtering"/>).</t> </section> <section> <name>Requirements Language</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>In case of conflict between the contents of a figure and the prose, the prose takes precedence.</t> </section> <section anchor="sec-media-description"> <name>Mediaformat description</name>Format Description</name> <t>The following summarizes the structure of the JPEG 2000 codestream, which is specified in detailatin <xreftarget="jpeg2000-1"/>.</t>target="JPEG2000-1"/>.</t> <t>NOTE:asAs describedatin <xref target="sec-codestream"/>, a JPEG 2000 codestream allows capabilities defined in any part of the JPEG 2000 family of standards, including those specified in <xreftarget="jpeg2000-2"/>target="JPEG2000-2"/> and <xreftarget="jpeg2000-15"/>.</t>target="JPEG2000-15"/>.</t> <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 consist of the customary Y (luma), C<sub>b</sub> (blue-difference chroma), and C<sub>r</sub> (red-difference chroma) components, with the C<sub>b</sub> and C<sub>r</sub> beingsub-sampledsubsampled by a factor of two compared to the Y component.</t> <t>An image can be further divided into contiguous rectangular tiles that are each independently coded and decoded.</t> <t>JPEG 2000 codes each image as a standalone codestream. A codestream consists of (i) marker segments, which contain coding parameters and metadata, and (ii) coded data.</t> <t>For convenience to the reader, the following lists both the abbreviated 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 in a codestream):</t><dl> <dt>CAP</dt><dl spacing="normal" newline="false" indent="7"> <dt>CAP:</dt> <dd>Extended Capabilities</dd><dt>COC</dt><dt>COC:</dt> <dd>Coding style component</dd><dt>COD</dt><dt>COD:</dt> <dd>Coding style default</dd><dt>COM</dt><dt>COM:</dt> <dd>Comment</dd><dt>EOC</dt><dt>EOC:</dt> <dd>End of codestream</dd><dt>PLM</dt><dt>PLM:</dt> <dd>Packet length, main header</dd><dt>PLT</dt><dt>PLT:</dt> <dd>Packet length, tile-part header</dd><dt>SOC</dt><dt>SOC:</dt> <dd>Start of codestream</dd><dt>SOD</dt><dt>SOD:</dt> <dd>Start of data</dd><dt>SOT</dt><dt>SOT:</dt> <dd>Start of tile-part</dd> </dl> <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 segments between the SOC and first SOT marker segment and contains information that applies to the codestream in its entirety. It is generally impossible to decode a codestream without its main header.</t> <t>The rest of the codestream consists of additional marker segments (tile-part headers) interleaved with coded image data.</t> <t>At the heart of JPEG 2000 coding is the wavelet transform, which decomposes the image into successive resolution levels, with each level 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 resolution of the previous one.</t> <t>The coded image data ultimately consists of code-blocks, each containing coded samples belonging to a rectangular (spatial) region within one resolution level of one component. Code-blocks are further collected into precincts, which, accordingly,representsrepresent code-blocks belonging to a spatial region within one resolution level of one component.</t> <t>The image coded data can be arranged into several progression orders, which dictates which aspect of the image appears first in the codestream (in terms of byte offset). The progression orders are parameterized according to:</t><dl><dl spacing="normal" newline="true"> <dt>Position (P)</dt> <dd>The first lines of the image come before the last lines of the image.</dd> <dt>Component (C)</dt> <dd>The first component of the image comes before the last component of the image.</dd> <dt>Resolution Level (R)</dt> <dd>The information needed to reconstruct the lower spatial resolutions of the image come before the information needed to reconstruct the higher spatial resolutions of the image.</dd> <dt>Quality Layer (L)</dt> <dd>The information needed to reconstruct themost-significantmost significant bits of each sample come before the information needed to reconstruct theleast-significantleast significant bit of each sample.</dd> </dl> <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 last lines of theimage and,image, and within a collection of lines, the information needed to reconstruct the lower spatial resolutions of the image come before the information needed to reconstruct the higher spatial resolutions. This progression order isparticularparticularly useful forsub-framesubframe latency operations.</t> </section> <section> <name>Videosignal description</name>Signal Description</name> <t>This RTP payload format supports three distinctvideo frametechniques for scanningtechniques:</t>video frames: </t> <ul> <li>Progressive frame</li> <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 is half the height of the image.</li> <li>Progressive segmented frame (PsF), where each frame consists of two segments. Segment 1 contains the odd lines (1, 3, 5,7,...)7, ...) of aframeframe, and Segment 2 contains the even lines (2, 4, 6,8,...)8, ...) of the same frame, where lines from the top of the frame to the bottom of the frame are numbered sequentially starting at 1.</li> </ul> <t>All frames are scanned left to right, top to bottom.</t> </section> <section> <name>Payload Format</name> <section> <name>General</name><figure anchor="fig-payload-header"> <name>Packetization<!-- [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<xref target="sec-media-description"/>Section 3 for an expansion of the SOC, SOD, SOT and EOCabbreviations.</name> <artwork type="ascii-art"> <![CDATA[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"> <name>Packetization of a Sequence of JPEG 2000 Codestreams (Not to Scale)</name> <artwork><![CDATA[ <--------------- Codestream (image) --------------> | | <----- Extended Header -----> | | | | +-----+-//-+-----+-//-+-----+--------//-----+-----+-----+--------- | SOC | .. | SOT | .. | SOD | ............. | EOC | P | SOC ... +-----+-//-+-----+-//-+-----+--------//-----+-----+-----+--------- | | | <----------> Main header | | | +------------------------------+------+--//-+-----------+--------- | Main | Body | ... | Body | Main ... +------------------------------+------+--//-+-----------+--------- | | <--------- RTP Packet ---------> ]]></artwork> </figure> <t>In <xref target="fig-payload-header"/>, P= (Optional)denotes (optional) paddingbytes ]]> </artwork> </figure>bytes. See <xref target="sec-media-description"/> for expansions of SOC, SOD, SOT, and EOC.</t> <t>Each RTP packet, as specifiedatin <xref target="RFC3550"/>, is either a Main Packet or a Body Packet.</t> <t>A Main Packet consists of the following ordered sequence of structures concatenated without gaps:</t> <ul> <li>the RTP Fixed Header;</li> <li>a Main Packet Payload Header, as specifiedatin <xref target="sec-main-packet-header"/>; and</li> <li>the payload, which consists of a JPEG 2000 codestream fragment.</li> </ul> <t>A Body Packet consists of the following ordered sequence of structures concatenated without gaps:</t> <ul> <li>the RTP Fixed Header;</li> <li>a Body Packet Payload Header, as specifiedatin <xref target="sec-body-packet-header"/>; and</li> <li>the payload, which consists of a JPEG 2000 codestream fragment.</li> </ul> <t>When concatenated, the sequence of JPEG 2000 codestream fragments emitted by the senderMUST<bcp14>MUST</bcp14> be a sequence of JPEG 2000 codestreams where two successive JPEG 2000 codestreamsMAY<bcp14>MAY</bcp14> be separated by one or more padding bytes (see <xref target="fig-payload-header"/>).</t> <t>The senderMUST<bcp14>MUST</bcp14> set the value of each padding byte to zero.</t> <t>The receiverMUST<bcp14>MUST</bcp14> ignore the values of the padding bytes.</t> <t>The JPEG 2000 codestreamsMUST<bcp14>MUST</bcp14> conform to <xref target="sec-codestream"/>.</t> <t>NOTE 1: Padding bytes can be used to achieve constant bit rate transmission.</t> <t>A JPEG 2000 codestream fragment, and thus an RTPPacket,packet, does not necessarily contain complete JPEG 2000 packets, as defined in <xreftarget="jpeg2000-1"/>.</t>target="JPEG2000-1"/>.</t> <t>A JPEG 2000 codestream Extended Header consists of the bytes between, and including, the SOC marker and the first SOD marker.</t> <t>NOTE 2: The concept of the JPEG 2000 codestream Extended Header is specific to thisdocument,document and is distinct from the JPEG 2000 codestream mainheaderheader, which is defined in <xreftarget="jpeg2000-1"/>.target="JPEG2000-1"/>. 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 subset of the codestream Extended Header (see <xref target="fig-payload-header"/>).</t> <t>The payload of a Body PacketMUST NOT<bcp14>MUST NOT</bcp14> contain any bytes of the JPEG 2000 codestream Extended Header.</t> <t>The payload of a Main PacketMUST<bcp14>MUST</bcp14> contain at least one byte of the JPEG 2000 codestream Extended Header andMAY<bcp14>MAY</bcp14> contain bytes other than those of the JPEG 2000 codestream Extended Header.</t> <t>A payloadMUST NOT<bcp14>MUST NOT</bcp14> contain bytes from more than one JPEG 2000 codestream.</t> </section><section><section anchor="rtp-fixed-header-usage"> <name>RTP Fixed Header Usage</name> <t>The following RTP header fields have a specific meaning in the context of this payload format:</t> <dl newline="true"> <dt><tt>marker</tt></dt> <dd> <dl> <dt>1</dt> <dd>The payload contains an EOC marker.</dd> <dt>0</dt> <dd>Otherwise</dd> </dl> </dd> <dt anchor="def-timestamp"><tt>timestamp</tt></dt> <dd> <t>The <tt>timestamp</tt> is the presentation time of the image to which the payload belongs.</t> <t>The <tt>timestamp</tt> clock rate is 90 kHz.</t> <t>The <tt>timestamp</tt> of successive progressive framesMUST<bcp14>MUST</bcp14> advance at regular increments based on the instantaneous video frame rate.</t> <t>The <tt>timestamp</tt> of Field 1 of successive interlaced framesMUST<bcp14>MUST</bcp14> advance at regular increments based on the instantaneous video frame rate, and the <tt>Timestamp</tt> of Field 2MUST<bcp14>MUST</bcp14> be offset from the <tt>timestamp</tt> of Field 1 by one half of the instantaneous frame period.</t> <t>The <tt>timestamp</tt> of both segments of a progressive segmented frameMUST<bcp14>MUST</bcp14> be equal.</t><t><tt>timestamp</tt><t>The <tt>timestamp</tt> of all RTP packets of a given imageMUST<bcp14>MUST</bcp14> be equal.</t> </dd> <dt anchor="def-seq"><tt>sequence number</tt></dt> <dd> <t>The low-order bits of the extended sequence number.</t> <t>The high-order bits of the extended sequence number are contained in the <tt>ESEQ</tt> field, which is specifiedatin <xreftarget="def-ESEQ"/>.</t>target="sec-main-packet-header"/>.</t> <t>The extended sequence number is calculated as follows:</t><t><tt><extended<artwork><![CDATA[ <extended sequencenumber>number> =<ESEQ field><ESEQ field> * 65536 +<sequence<sequence number field of the RTP fixedheader></tt></t></dd>header> ]]></artwork></dd> </dl> </section> <section anchor="sec-main-packet-header"> <name>Main Packet Payload Header</name> <t><xref target="fig-main-payload-header"/> specifies the structure of the payload header. Fields are interpreted as unsigned binary integers in network order.</t> <figure anchor="fig-main-payload-header"> <name>Structure of the Main Packet Payload Header</name><artwork type="ascii-art"> <![CDATA[<artwork><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MH | TP |ORDH |P|XTRAC| PTSTAMP | ESEQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|C| RSVD |*| PRIMS | TRANS | MAT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | XTRAB | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * RANGE]]> </artwork>]]></artwork> </figure> <dlnewline="true">newline="false"> <dt anchor="def-MH">MH (Codestream Main HeaderPresence): 2 bits</dt> <dd>Presence):</dt><dd><t>2 bits</t> <dlnewline="true">newline="false"> <dt>0</dt> <dd>The RTPPacketpacket is a Body Packet.</dd> <dt>1</dt> <dd>The RTPPacketpacket is a MainPacketPacket, and the codestream has more than one Main Packet. The next RTPPacketpacket is a Main Packet.</dd> <dt>2</dt> <dd>The RTPPacketpacket is a MainPacketPacket, and the codestream has more than one Main Packet. The next RTPPacketpacket is a Body Packet.</dd> <dt>3</dt> <dd>The RTPPacketpacket is a MainPacketPacket, and the codestream has exactly one Main Packet.</dd> </dl> </dd> <dt anchor="def-TP">TP (ImageType): 3 bits</dt> <dd>Type):</dt><dd><t>3 bits</t> <t>Indicates the scanning structure of the image to which the payload belongs.</t> <dlnewline="true">newline="false"> <dt>0</dt> <dd>Progressive frame.</dd> <dt>1</dt> <dd>Field 1 of an interlaced frame, where the first line of the field is the first line of the frame.</dd> <dt>2</dt> <dd>Field 2 of an interlaced frame, where the first line of the field is the second line of the frame.</dd> <dt>3</dt> <dd>Field 1 of an interlaced frame, where the first line of the field is the second line of the frame.</dd> <dt>4</dt> <dd>Field 2 of an interlaced frame, where the first line of the field is the first line of the frame.</dd> <dt>5</dt> <dd>Segment 1 of a progressive segmented frame, where the first line of the image is the first line of the frame.</dd> <dt>6</dt> <dd>Segment 2 of a progressive segmented frame, where the first line of the image is the second line of the frame.</dd> <dt>7</dt> <dd>Extension value. See Sections <xreftarget="sec-receiver-ext"/>target="sec-receiver-ext" format="counter"/> and <xreftarget="sec-sender-ext"/>.</dd>target="sec-sender-ext" format="counter"/>.</dd> </dl> </dd><dt anchor="def-ORDH">ORDH<!-- [rfced] May we remove the square brackets here and update as follows? Original: ORDH (Progression Order [Main Packet]): 3bits</dt> <dd>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 orders. --> <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 whether resync points are signaled.</t> <dlnewline="true">newline="false"> <dt>0</dt> <dd>Resync points are not necessarily signaled. The progression order can vary over the codestream.</dd> <dt>1</dt> <dd>The progression order is LRCP for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.</dd> <dt>2</dt> <dd>The progression order is RLCP for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.</dd> <dt>3</dt> <dd>The progression order is RPCL for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.</dd> <dt>4</dt> <dd>The progression order is PCRL for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.</dd> <dt>5</dt> <dd>The progression order is CPRL for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.</dd> <dt>6</dt> <dd>The progression order is PRCL for the entire codestream. The first resync point is specified in every Body Packet that contains one or more resync points.</dd> <dt>7</dt> <dd>The progression order can vary over the codestream. The first resync point is specified in every Body Packet that contains one or more resync points.</dd> </dl> <t><tt>ORDH</tt>MUST<bcp14>MUST</bcp14> be 0 if the codestream consists of more than one tile.</t> <t>NOTE: Only <tt>ORDH</tt> = 4 and <tt>ORDH</tt> = 6 allow sub-codestream latency streaming.</t> <t>NOTE: Progression order PRCL is defined in <xreftarget="jpeg2000-2"/>.target="JPEG2000-2"/>. The other progression orders are specified in <xreftarget="jpeg2000-1"/>.</t>target="JPEG2000-1"/>.</t> </dd> <dt anchor="def-P">P (Precision TimestampPresence): 1 bit</dt> <dd>Presence):</dt><dd><t>1 bit</t> <dlnewline="true">newline="false"> <dt>0</dt> <dd><tt>PTSTAMP</tt> is not used.</dd> <dt>1</dt> <dd><tt>PTSTAMP</tt> is used.</dd> </dl> </dd> <dt anchor="def-XTRAC">XTRAC (Extension PayloadLength): 3 bits</dt> <dd>Length,Length):</dt><dd><t>3 bits</t> <t>Length, in multiples of 4 bytes, of the <tt>XTRAB</tt>field.</dd>field.</t></dd> <dt anchor="def-PTSTAMP">PTSTAMP (PrecisionTimestamp): 12 bits</dt> <dd>Timestamp):</dt><dd><t>12 bits</t> <t>PTSTAMP = (<tt>timestamp</tt> + <tt>TOFF</tt>) mod 4096, if <tt>P</tt> = 1 in the Main Packet of this codestream.</t> <t><tt>TOFF</tt> is the transmission time of this RTPPacket,packet, in the timebase of the <tt>timestamp</tt> clock and relative to the first RTP packet with the same <tt>timestamp</tt> value.</t> <t><tt>TOFF</tt> = 0 in the first RTPPacketpacket with the same <tt>timestamp</tt> value.</t> <t><tt>PTSTAMP</tt> = 0, if <tt>P</tt> = 0 in the Main Packet of this codestream.</t><t>NOTE:<!-- [rfced] Will "no more than 45 ms = 4095/90,000" be clear to readers? 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 <xreftarget="sec-sender-ptstamp"/>target="sec-sender-ptstamp" format="counter"/> and <xreftarget="sec-recv-ptstamp"/>,target="sec-recv-ptstamp" format="counter"/>, <tt>PTSTAMP</tt> is intended to improve clock recovery at the receiver and only applies when the transmission time of two consecutive RTP packets with identical <tt>timestamp</tt> fields differ by no more than 45 ms = 4095/90,000. <xref target="RFC5450"/> addresses the general case whenaan RTP packet is transmitted at a time other than its nominal transmission time.</t> </dd> <dt anchor="def-ESEQ">ESEQ (Extended Sequence Number High-OrderBits): 8 bits</dt> <dd>Bits):</dt><dd> <t>8 bits</t> <t>The high-order bits of the extended sequence number.</t> <t>NOTE: The low-order bits of the extended sequence number are stored in the <tt>sequence number</tt> field of the RTP fixed header.</t> <t><xreftarget="def-seq"/>target="rtp-fixed-header-usage"/> specifies the formula to compute the extended sequence number.</t> </dd> <dt anchor="def-R">R (Codestream Main HeaderReuse): 1 bit</dt> <dd>Reuse):</dt><dd><t>1 bit</t> <t>Determines whether Main Packet and codestream main header information can be reused across codestreams.</t> <dlnewline="true">newline="false"> <dt>1</dt> <dd> <t>All Main Packets in this stream, as identified by the value 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><li>MUST<li><bcp14>MUST</bcp14> have identical Main Packet Payload Headers, with the exception of their <tt>TP</tt>, <tt>MH</tt>,<tt>ESEQ</tt><tt>ESEQ</tt>, and <tt>PTSTAMP</tt> fields;</li><li>MUST<li><bcp14>MUST</bcp14> contain the same codestream main header information, with the exception of the SOT and COM marker segments, and any pointer marker segments; and</li><li>MUST NOT<li><bcp14>MUST NOT</bcp14> contain bytes other than Extended Header bytes.</li> </ul> </dd> <dt>0</dt> <dd>Otherwise</dd> </dl> </dd> <dt anchor="def-S">S (Parameterized ColorspacePresence): 1 bit</dt> <dd>Presence):</dt><dd><t>1 bit</t> <dlnewline="true">newline="false"> <dt>0</dt> <dd><t>Component colorimetry is notspecified, andspecified; it is left to the session or the application.</t> <t><tt>PRIMS</tt>,<tt>TRANS</tt> and <tt>MAT</tt><tt>TRANS</tt>, <tt>MAT</tt>, and <tt>RANGE</tt>MUST<bcp14>MUST</bcp14> be zero.</t> </dd> <dt>1</dt> <dd> <t>Component colorimetry is specified by the <tt>PRIMS</tt>,TRANS and <tt>MAT</tt><tt>TRANS</tt>, <tt>MAT</tt>, and <tt>RANGE</tt> fields.</t> <t>The codestream componentsMUST<bcp14>MUST</bcp14> conform to one of the combinationsatin <xreftarget="t-color-map"/>.</t>target="t-color-map"/>. </t> <table anchor="t-color-map"> <name>Mapping ofcodestream componentsCodestream Components tocolor channels</name>Color Channels</name> <thead> <tr> <th rowspan="2">Combinationname</th>Name</th> <th colspan="4">Componentindex</th>Index</th> </tr> <tr> <th>0</th> <th>1</th> <th>2</th> <th>3</th> </tr> </thead> <tbody> <tr> <th>Y</th><td>Y</td><td></td><td></td><td></td> </tr> <tr> <th>YA</th><td>Y</td><td>A</td><td></td><td></td> </tr> <tr> <th>RGB</th><td>R</td><td>G</td><td>B</td><td></td> </tr> <tr> <th>RGBA</th><td>R</td><td>G</td><td>B</td><td>A</td> </tr> <tr> <th>YCbCr</th><td>Y</td><td>C<sub>B</sub></td> <td>C<sub>R</sub></td><td></td> </tr> <tr> <th>YCbCrA</th><td>Y</td><td>C<sub>B</sub></td> <td>C<sub>R</sub></td><td>A</td> </tr> </tbody><tfoot> <tr> <td colspan="5">The channel</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 channelMUST<bcp14>MUST</bcp14> map to a component with unsignedsamples.</td> </tr> </tfoot> </table>samples.</t> </dd> </dl> </dd> <dt anchor="def-C">C(Code-block(Code-Block CachingUsage): 1 bit</dt> <dd>Usage):</dt><dd><t>1 bit</t> <dlnewline="true">newline="false"> <dt>0</dt> <dd>Code-block caching is not in use.</dd> <dt>1</dt> <dd> <t>Code-block caching is in use.</t> <t><tt>R</tt>MUST<bcp14>MUST</bcp14> be equal to 1.</t> </dd> </dl> </dd> <dt anchor="def-RSVD">RSVD(Reserved): 4 bits</dt> <dd>Unassigned(Reserved):</dt><dd><t>4 bits</t> <t>Unassigned value. See Sections <xreftarget="sec-receiver-unassigned"/>target="sec-receiver-unassigned" format="counter"/> and <xreftarget="sec-sender-unassigned"/>.</dd>target="sec-sender-unassigned" format="counter"/>.</t></dd> <dt anchor="def-F">RANGE (Video Full RangeUsage): 1 bit</dt> <dd>ValueUsage):</dt><dd><t>1 bit</t> <t>Value of the VideoFullRangeFlag specified in <xreftarget="rec-itu-t-h273"/></dd>target="REC-ITU-T-H273"/>.</t></dd> <dt anchor="def-PRIMS">PRIMS (ColorPrimaries): 8 bits</dt> <dd>OnePrimaries):</dt><dd><t>8 bits</t> <t>One of the ColourPrimaries values specified in <xreftarget="rec-itu-t-h273"/></dd>target="REC-ITU-T-H273"/>.</t></dd> <dt anchor="def-TRANS">TRANS (TransferCharacteristics): 8 bits</dt> <dd>OneCharacteristics):</dt><dd><t>8 bits</t> <t>One of the TransferCharacteristics values specified in <xreftarget="rec-itu-t-h273"/></dd>target="REC-ITU-T-H273"/>.</t></dd> <dt anchor="def-MAT">MAT (Color MatrixCoefficients): 8 bits</dt> <dd>OneCoefficients):</dt><dd><t>8 bits</t> <t>One of the MatrixCoefficients values specified in <xreftarget="rec-itu-t-h273"/></dd>target="REC-ITU-T-H273"/>.</t></dd> <dt anchor="def-XTRAB">XTRAB (ExtensionPayload): variable</dt> <dd>AllowsPayload):</dt><dd><t>variable</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 <xreftarget="def-XTRAC"/>.target="sec-main-packet-header"/>. See also Sections <xreftarget="sec-receiver-xtrab"/>target="sec-receiver-xtrab" format="counter"/> and <xreftarget="sec-sender-xtrab"/>.</dd>target="sec-sender-xtrab" format="counter"/>.</t></dd> </dl> </section> <section anchor="sec-body-packet-header"> <name>Body Packet Payload Header</name> <t><xref target="fig-body-payload-header"/> specifies the structure of the Body Packet Payload Header. Fields are interpreted as unsigned binary integers in network order.</t> <figure anchor="fig-body-payload-header"> <name>Structure of the Body Packet Payload Header</name><artwork type="ascii-art"> <![CDATA[<artwork><![CDATA[ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |MH | TP |RES |*|QUAL | PTSTAMP | ESEQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | POS | PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * ORDB]]> </artwork>]]></artwork> </figure> <dlnewline="true"> <dt>MH</dt>newline="false"> <dt>MH:</dt> <dd>See <xreftarget="def-MH"/>.</dd> <dt>TP</dt>target="sec-main-packet-header"/>.</dd> <dt>TP:</dt> <dd>See <xreftarget="def-TP"/>.</dd>target="sec-main-packet-header"/>.</dd> <dt anchor="def-RES">RES (ResolutionLevels): 3 bits</dt> <dd>Levels):</dt><dd><t>3 bits</t> <dlnewline="true">newline="false"> <dt>0</dt> <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> <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 not contain any byte of any JPEG 2000 packet belonging to lower resolution levels. N<sub>L</sub> is the number of decomposition levels of the codestream.</dd> </dl> </dd> <dt anchor="def-ORDB">ORDB (Progression Order [BodyPacket]): 1 bit</dt> <dd>Packet]):</dt><dd><t>1 bit</t> <dlnewline="true">newline="false"> <dt>0</dt> <dd>No resync point is specified for the payload.</dd> <dt>1</dt> <dd>The payload contains a resync point.</dd> </dl> <t><tt>ORDB</tt>MUST<bcp14>MUST</bcp14> be 0isif the codestream consists of more than one tile.</t> </dd> <dt anchor="def-QUAL">QUAL (QualityLayers): 3 bits</dt> <dd>Layers):</dt><dd><t>3 bits</t> <dlnewline="true">newline="false"> <dt>0</dt> <dd>The payload can contribute to all quality layers.</dd> <dt>Otherwise</dt> <dd>The payload contributes only to quality layer index <tt>QUAL</tt> or above.</dd> </dl> </dd><dt>PTSTAMP</dt><dt>PTSTAMP:</dt> <dd>See <xreftarget="def-PTSTAMP"/>.</dd> <dt>ESEQ</dt>target="sec-main-packet-header"/>.</dd> <dt>ESEQ:</dt> <dd>See <xreftarget="def-ESEQ"/>.</dd>target="sec-main-packet-header"/>.</dd> <dt anchor="def-POS">POS (Resync PointOffset): 12 bits</dt> <dd>Offset):</dt><dd><t>12 bits</t> <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> <t><tt>POS</tt>MUST<bcp14>MUST</bcp14> be 0 if <tt>ORDB</tt> = 0.</t> </dd> <dt anchor="def-PID">PID (PrecinctIdentifier): 20 bits</dt> <dd>Identifier):</dt><dd><t>20 bits</t> <t>Unique identifier of the precinct of the resync point.</t><t><tt>PID<artwork><![CDATA[PID = c + s *num_components</tt></t>num_components]]></artwork> <t>where:</t> <ul> <li><em>c</em> is the index (starting from 0) of the image component to which the precinct belongs;</li> <li><em>s</em> is a sequence numberwhichthat identifies the precinct within its tile-component; and</li> <li><em>num_components</em> is the number of components of the codestream.</li> </ul> <t>If <tt>PID</tt> is present, the payloadMUST NOT<bcp14>MUST NOT</bcp14> contain codestream bytes from more than one precinct.</t> <t><tt>PID</tt>MUST<bcp14>MUST</bcp14> be 0 if <tt>ORDB</tt> = 0.</t> <t>NOTE: <tt>PID</tt> is identical to precinct identifier I specified in <xreftarget="jpeg2000-9"/>.</t>target="JPEG2000-9"/>.</t> </dd> </dl> </section> </section> <section anchor="sec-codestream"> <name>JPEG 2000codestream</name>Codestream</name> <t> A JPEG 2000 codestream consists of the bytes between, and including, the SOC and EOC markers, as defined in <xreftarget="jpeg2000-1"/>.</t>target="JPEG2000-1"/>.</t> <t>The JPEG 2000 codestreamMAY<bcp14>MAY</bcp14> include capabilities beyond those specifiedatin <xreftarget="jpeg2000-1"/>,target="JPEG2000-1"/>, including those specified in <xreftarget="jpeg2000-2"/>target="JPEG2000-2"/> and <xreftarget="jpeg2000-15"/>.</t>target="JPEG2000-15"/>.</t> <t>NOTE: The <tt>Rsiz</tt> parameter and <tt>CAP</tt> marker segments of each JPEG 2000 codestream contain detailed information on the capabilities necessary to decode the codestream.</t> <t>NOTE: The <tt>caps</tt> media type parameter defined in <xref target="sec-media-type-def"/> allows applications to signal required device capabilities.</t> <t>NOTE: The block coder specifiedatin <xreftarget="jpeg2000-15"/>target="JPEG2000-15"/> improves throughput and reduces latency compared to the original arithmetic block coder defined in <xreftarget="jpeg2000-1"/>.</t>target="JPEG2000-1"/>.</t> <t>For interlaced or progressive segmented frames, the height specified in the JPEG 2000 main headerMUST<bcp14>MUST</bcp14> be the height in lines of the field or the segment, respectively.</t> <t>If any decomposition level involves only horizontaldecompositiondecomposition, then no decomposition levelMUST<bcp14>MUST</bcp14> involve only vertical decomposition;and,conversely, if any decomposition level involves only verticaldecompositiondecomposition, then no decomposition levelMUST<bcp14>MUST</bcp14> involve only horizontal decomposition.</t> </section> <section anchor="sec-sender"> <name>Sender</name> <section> <name>Main Packet</name> <t>A Main PacketMAY<bcp14>MAY</bcp14> contain zero or more bytes of the JPEG 2000 codestream Extended Header.</t> <t>The senderMUST either<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 single Main Packet with <tt>MH</tt> = 2.</t> <t>The Main Packet Payload Headers fieldsMUST<bcp14>MUST</bcp14> be identical in all MainPacketPackets of a given codestream, with the exception of:</t> <ul> <li><tt>MH</tt>;</li> <li><tt>ESEQ</tt>; and</li> <li><tt>PTSTAMP</tt>.</li> </ul> </section> <section anchor="sec-filtering"> <name>RTP Packetfiltering</name>Filtering</name> <t>An intermediate systemMAY<bcp14>MAY</bcp14> strip out RTPPacketpackets from a codestream that are of no interest to a particular client, e.g., based on a resolution or a spatial region of interest.</t> </section> <section> <name>Resyncpoint</name>Point</name> <t>A resync point is the first byte of JPEG 2000 packet header data for a precinct and for which PID < 2<sup>24</sup>.</t> <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 zero).</t> <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 corrupted,lostlost, or deliberately discarded by an intermediate system. As a corollary, resync points can be used by an intermediate system to discard RTP packets that are not relevant to a given rendering resolution or region of interest. Resync points play a role similar to pointer marker segments, albeit tailored forhigh bandwidth low latencyhigh-bandwidth, low-latency streaming applications.</t> </section> <section anchor="sec-sender-ptstamp"> <name>PTSTAMPfield</name>Field</name> <t>A senderSHOULD<bcp14>SHOULD</bcp14> set <tt>P</tt> = 1, but only if it can generate <tt>PTSTAMP</tt> accurately.</t> <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. Specifically, a sender maintains, at least conceptually, a 32-bit counter that is incremented by a90kHz90 kHz clock. The counter is sampled at the point in time when each RTPPacketpacket is transmitted and the 12 LSBs of 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 definedatin <xreftarget="def-PTSTAMP"></xref>)target="sec-main-packet-header"></xref>) for two consecutive RTP packets with identical <tt>timestamp</tt> fieldsMUST NOT<bcp14>MUST NOT</bcp14> differ by more than 4095.</t> </section> <section> <name>RESfield</name>Field</name> <t>A senderSHOULD<bcp14>SHOULD</bcp14> set <tt>RES</tt> > 0 whenever possible.</t> <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 describedatin <xref target="recv-RES"/>.</t> </section> <section anchor="sec-sender-xtrab"> <name>Extrainformation</name>Information</name> <t>The senderMUST<bcp14>MUST</bcp14> set the value of <tt>XTRAC</tt> to 0.</t> <t>Future updates to this RTP payload format can permit other values.</t> </section> <section anchor="sec-sender-unassigned"> <name>Unassignedvalues</name>Values</name> <t>The senderMUST<bcp14>MUST</bcp14> set unassigned values to 0.</t> <t>Unassigned values are available for assignment by future updates to this RTP payload format. As specifiedatin <xreftarget="sec-receiver-unassigned"/>target="sec-receiver-unassigned"/>, these future assigned values are ignored by receivers that conform to this specification. In contrastwithto extension values(<xref target="sec-sender-ext"/>,(see <xref target="sec-sender-ext"/>), this mechanism allows updates to this RTP payload format that remain compatible with receivers that conform to this specification.</t> </section> <section anchor="sec-sender-ext"> <name>Extensionvalues</name>Values</name> <t>A senderMUST NOT<bcp14>MUST NOT</bcp14> use an extension value.</t> </section> <section anchor="sec-send-block-caching"><name>Code-block caching</name><name>Code-Block Caching</name> <t>This sectionappliesonly 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 transmitting code-blocks corresponding to static portions of the video and otherwise transmitting empty code-blocks. When <tt>C</tt> = 1, and as describedatin <xref target="sec-rcv-block-caching"/>, a receiver maintains a simple cache of previously received code-blocks, which it uses to replace empty code-blocks.</t> <t>A sender alone determines whichand whencode-blocks are replaced with emptycode-blocks.</t>code-blocks and when the replacement occurs.</t> <t>The sendercannot howevercannot, however, determine with certainty the state of the receiver'scache:cache; for example, some code-blocks might have been lost in transit, the sender doesn't know exactly when the receiver started processing the stream, etc.</t> <t>A code-block is <em>empty</em> if:</t> <ul> <li>it does not contribute code-bytes as specified in the parent JPEG 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 byte-stream are between <tt>0xFF80</tt> and<tt>0xFF8F</tt>.</li><tt>0xFF8F</tt> (if the code-block conforms to <xref target="JPEG2000-15"/>).</li> </ul> <t>NOTE:theThe last condition allows the encoder to insert padding bytes to achieve a constant bit rate even when a code-block does not contribute code-bytes, as suggestedatin Annex F.4 of <xreftarget="jpeg2000-15"/>, F.4.</t>target="JPEG2000-15"/>. </t> </section> </section> <section anchor="sec-receiver"> <name>Receiver</name> <section anchor="sec-recv-ptstamp"> <name>PTSTAMP</name> <t>Receivers can use <tt>PTSTAMP</tt> values to accelerate sender clock recovery since <tt>PTSTAMP</tt> typically updates more regularly than <tt>timestamp</tt>.</t> </section> <section> <name>QUAL</name> <t>A receiver can discard RTP packets where <tt>QUAL</tt> > N if it is interested in reconstructing an image that only incorporates quality layers N and below.</t> </section> <section anchor="recv-RES"> <name>RES</name> <t>The JPEG 2000 coding process decomposes an image using a sequence of discrete wavelettransformstransform (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"> <name>Optional discarding of Body Packets based on the value of 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 horizontal and vertical transforms. The image has nominal width and height of W x H.</name> <thead> <tr> <th>Decompositionlevel</th>Level</th> <th>Resolutionlevel</th>Level</th> <th>Sub-bands</th> <th>Keep all Body Packets with <tt>RES</tt> equal to or less than this value...</th><th>... to<th>...to decode an image with at most these dimensions</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>5</td> <td>HL1,LH1,HH1</td> <td>7</td> <td>W x H</td> </tr> <tr> <td>2</td> <td>4</td> <td>HL2,LH2,HH2</td> <td>6</td> <td>(W/2) x (H/2)</td> </tr> <tr> <td>3</td> <td>3</td> <td>HL3,LH3,HH3</td> <td>5</td> <td>(W/4) x (H/4)</td> </tr> <tr> <td>4</td> <td>2</td> <td>HL4,LH4,HH4</td> <td>4</td> <td>(W/8) x (H/8)</td> </tr> <tr> <td>5</td> <td>1</td> <td>HL5,LH5,HH5</td> <td>3</td> <td>(W/16) x (H/16)</td> </tr> <tr> <td>5</td> <td>0</td> <td>LL5</td> <td>2</td> <td>(W/32) x (H/32)</td> </tr> </tbody> </table> <t><xref target="t-res-ll-example"/> illustrates the case where each DWT stage consists of both horizontal and vertical transforms, which is the only mode supported in <xreftarget="jpeg2000-1"/>.target="JPEG2000-1"/>. The first stage transforms the image into (i) the image at half-resolution (LL1 sub-bands) and (ii) residual high-frequency data (HH1, LH1, HL1 sub-bands). The second stage transforms the image at half-resolution (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 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 the codestream.</t> <t>The decoding process reconstructs the image by reversing the coding process, starting with the lowest resolution image stored in the codestream (LL<sub>N<sub>L</sub></sub>).</t> <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, in order to reconstruct the image at quarter resolution (LL2), only sub-bands with index greater than2, e.g.,2 (e.g., HL3, LH3, HH3, HL4, LH4, HH4,etc.,etc.) are necessary. In other words, a receiver that wishes to reconstruct an image at quarter resolution could discard all RTP packets where <tt>RES</tt> >= 6 since those RTP packets can only contribute to HL1, LH1, HH1, HL2,LH2LH2, and HH2 sub-bands.</t> <t>In the case where all DWT stages consist of both horizontal and 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> > N are discarded.</t> <table anchor="t-res-lx-example"> <name>Optional discarding of Body Packets based on the value of 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 horizontal transforms. The image has nominal width and height of W x H.</name> <thead> <tr> <th>Decompositionlevel</th>Level</th> <th>Resolutionlevel</th>Level</th> <th>Sub-bands</th> <th>Keep all Body Packets with RES equal to or less than this value...</th><th>... to<th>...to decode an image with at most these dimensions</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>5</td> <td>HL1,LH1,HH1</td> <td>7</td> <td>W x H</td> </tr> <tr> <td>2</td> <td>4</td> <td>HL2,LH2,HH2</td> <td>6</td> <td>(W/2) x (H/2)</td> </tr> <tr> <td>3</td> <td>3</td> <td>HX3</td> <td>5</td> <td>(W/4) x (H/2)</td> </tr> <tr> <td>4</td> <td>2</td> <td>HX4</td> <td>4</td> <td>(W/8) x (H/2)</td> </tr> <tr> <td>5</td> <td>1</td> <td>HX5</td> <td>3</td> <td>(W/16) x (H/2)</td> </tr> <tr> <td>5</td> <td>0</td> <td>LX5</td> <td>2</td> <td>(W/32) x (H/2)</td> </tr> </tbody> </table> <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 <xreftarget="jpeg2000-2"/>.</t>target="JPEG2000-2"/>.</t> <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 image with its resolution reduced by a factor determined by the threshold value, as illustrated in Tables <xreftarget="t-res-ll-example"/>target="t-res-ll-example" format="counter"/> and <xreftarget="t-res-lx-example"/>.</t>target="t-res-lx-example" format="counter"/>.</t> </section> <section anchor="sec-receiver-xtrab"> <name>Extrainformation</name> <t>TheInformation</name> <!-- [rfced] We updated "values XTRAC" to "values of XTRAC" here. Please let us know if this is incorrect. Original: The receiver MUST accept values<tt>XTRAC</tt>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> other than 0 and <bcp14>MUST</bcp14> ignore the value of <tt>XTRAB</tt>, whose length is given by <tt>XTRAC</tt>.</t> <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 to this specification.</t> </section> <section anchor="sec-receiver-unassigned"> <name>Unassignedvalues</name>Values</name> <t>The receiverMUST<bcp14>MUST</bcp14> ignore unassigned values (see additional discussionatin <xref target="sec-sender-unassigned"/>).</t> </section> <section anchor="sec-receiver-ext"> <name>Extensionvalues</name>Values</name> <t>The receiverMUST<bcp14>MUST</bcp14> discard an RTP packet that contains any extension value.</t> </section> <section anchor="sec-rcv-block-caching"><name>Code-block caching</name><name>Code-Block Caching</name> <t>This sectionappliesonly applies if <tt>C</tt> = 1.</t> <t>When <tt>C</tt> = 1, and as specified in <xref target="sec-send-block-caching"/>, 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 definedatin <xref target="sec-send-block-caching"/>.</t><t>When<!-- [rfced] How may we improve the introductory text here? Original: When decoding a codestream, and for each code-block in thecodestream:</t> <ul> <li>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</li> <li>* 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 codestream:</t> <ul> <li> If the code-block in the codestream is empty, the receiver <bcp14>MUST</bcp14> replace it with a matching code-block from the cache, if one exists. </li> <li> If the code-block in the codestream is not empty, the receiver <bcp14>MUST</bcp14> replace any matching code-block from the cache with the code-block in the codestream. </li> </ul> <t>Two code-blocks are <em>matching</em> if the following characteristics are identical for both: spatial coordinates, resolution level, component,sub-bandsub-band, and value of the <tt>TP</tt> field of the parent RTP packet.</t> </section> </section> <section anchor="sec-media-type"> <name>Media Type</name> <section> <name>General</name> <t>This RTP payload format is identified using the media type definedatin <xreftarget="sec-media-type-def"/>, which istarget="sec-media-type-def"/>. This media type has been registered in accordance with <xref target="RFC4855"/>andusing the templateofin <xref target="RFC6838"/>.</t> </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"> <name>Definition</name> <dlnewline="true">newline="false" spacing="normal"> <dt>Typename</dt>name:</dt> <dd>video</dd> <dt>Subtypename</dt>name:</dt> <dd>jpeg2000-scl</dd> <dt>Requiredparameters</dt> <dd>None</dd>parameters:</dt> <dd>N/A</dd> <dt>Optionalparameters</dt> <dd>parameters:</dt> <dd><t><br/></t> <dl newline="true"><dt><tt>pixel</tt></dt><dt><tt>pixel</tt>:</dt> <dd> <t>Specifies the pixel format used by the video sequence.</t> <t>The parameterMUST<bcp14>MUST</bcp14> be a <tt>URI-reference</tt> as specified in <xref target="RFC3986"/>.</t> <t>If the parameter is a <tt>relative-ref</tt> as specified in <xref target="RFC3986"/>, then itMUST<bcp14>MUST</bcp14> be equal to one of the pixel formats specified in <xreftarget="t-pix-fmts"/>target="t-pix-fmts"/>, and the RTP header and payloadMUST<bcp14>MUST</bcp14> conformwithto the characteristics of that pixel format.</t> <t>If the parameter is not a <tt>relative-ref</tt>, the specification of the pixel format is left to the application that defined the URI.</t> <t>If the parameter is not specified, the pixel format is unspecified.</t> </dd><dt><tt>sample</tt></dt><dt><tt>sample</tt>:</dt> <dd> <t>Specifies the format of the samples in each component of the codestream.</t> <t>The parameterMUST<bcp14>MUST</bcp14> be a <tt>URI-reference</tt> as specified in <xref target="RFC3986"/>.</t> <t>If the parameter is a <tt>relative-ref</tt> as specified in <xref target="RFC3986"/>, then itMUST<bcp14>MUST</bcp14> be equal to one of the formats specified in <xreftarget="sec-sample-fmts"/>target="sec-sample-fmts"/>, and the streamMUST<bcp14>MUST</bcp14> conformwithto the characteristics of that format.</t> <t>If the parameter is not a <tt>relative-ref</tt>, the specification of the sample format is left to the application that defined the URI.</t> <t>If the parameter is not specified, the sample format is unspecified.</t> </dd><dt><tt>width</tt></dt><dt><tt>width</tt>:</dt> <dd> <t>Maximum width in pixels of each image. Integer between 0 and 4,294,967,295.</t> <t>The parameterMUST<bcp14>MUST</bcp14> be a sequence of 1 or more digits.</t> <t>If the parameter is not specified, the maximum width is unspecified.</t> </dd><dt><tt>height</tt></dt><dt><tt>height</tt>:</dt> <dd> <t>Maximum height in pixels of each image. Integer between 0 and 4,294,967,295.</t> <t>The parameterMUST<bcp14>MUST</bcp14> be a sequence of 1 or more digits.</t> <t>If the parameter is not specified, the maximum height is unspecified.</t> </dd><dt>signal</dt><dt><tt>signal</tt>:</dt> <dd> <t>Specifies the sequence of image types.</t> <t>The parameterMUST<bcp14>MUST</bcp14> be a <tt>URI-reference</tt> as specified in <xref target="RFC3986"/>.</t> <t>If the parameter is a <tt>relative-ref</tt> as specified in <xref target="RFC3986"/>, then itMUST<bcp14>MUST</bcp14> be equal to one of the signal formats specified in <xreftarget="sec-signal-fmts"/>target="sec-signal-fmts"/>, and the image sequenceMUST<bcp14>MUST</bcp14> conform to that signal format.</t> <t>If the parameter is not a <tt>relative-ref</tt>, the specification of the pixel format is left to the application that defined the URI.</t> <t>If the parameter is not specified, the stream consists of an arbitrary sequence of image types.</t> </dd><dt><tt>caps</tt></dt><dt><tt>caps</tt>:</dt> <dd> <t>The parameter contains a list of sets of constraints to which the stream conforms, with each set of constraints identified using an <tt>absolute-URI</tt> defined by an application.</t> <t>The parameterMUST<bcp14>MUST</bcp14> conform to the <tt>uri-list</tt> syntax expressed as follows using ABNF(<xref target="RFC5234"/>):</t><xref target="RFC5234"/>:</t> <!-- [rfced] We got an error when parsing the line of ABNF in Section 9.2. We used the parser at https://author-tools.ietf.org/abnf and added some definitions from RFCs 3986 and 5234. Please review. 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 at all --> <sourcecodetype="abnf">type="abnf"><![CDATA[ uri-list = absolute-URI *(";" absolute-URI)</sourcecode>]]></sourcecode> <t>The application that defines the <tt>absolute-URI</tt>MUST<bcp14>MUST</bcp14> ensure that it does not contain any <tt>";"</tt> character andMUST<bcp14>MUST</bcp14> associate it with a set of constraints to which the stream conforms. Such constraints can, for example, include the maximum height and width of images.</t> <t>If the parameter is not specified,constraints,constraints beyond those specified in thisdocument,document are unspecified.</t> </dd><dt><tt>cache</tt></dt><dt><tt>cache</tt>:</dt> <dd> <t>The value of the parameterMUST<bcp14>MUST</bcp14> be either <tt>false</tt> or <tt>true</tt>.</t> <t>If the parameter is <tt>true</tt>, the field <tt>C</tt>MAY<bcp14>MAY</bcp14> be 0 or 1;otherwiseotherwise, the field <tt>C</tt>MUST<bcp14>MUST</bcp14> be 0.</t> <t>If the parameter is not specified, then the parameter is equal to <tt>false</tt>.</t> </dd> </dl> </dd> <dt>Encodingconsiderations</dt>considerations:</dt> <dd>This media type is framed andbinary, seebinary. See <xref target="RFC6838" section="4.8"/>.</dd> <dt>Securityconsiderations</dt>considerations:</dt> <dd> <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 greatly depending on the characteristics of the image and the encoding parameters. For example, the JPEG 2000 syntax allows image 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> parameters of the media type specifiedatin <xref target="sec-media-type-def"/>.Implementations SHOULD thereforeTherefore, implementations <bcp14>SHOULD</bcp14> take care when processing input that influences the size of memorystructures,structures andSHOULD<bcp14>SHOULD</bcp14> fail gracefully when resource constraints are exceeded.</t> <t>See also <xref target="sec-sec"/>.</t> </dd> <dt>Interoperabilityconsiderations</dt>considerations:</dt> <dd>The RTP stream is a sequence of JPEG 2000 images. An implementation that conforms to the family of JPEG 2000 standards can decode and attempt to display each image.</dd> <dt>Publishedspecification</dt> <dd>This document</dd>specification:</dt> <dd>RFC 9828</dd> <dt>Applications that use this mediatype</dt>type:</dt> <dd>video streaming and communication</dd> <dt>Fragment identifier considerations:</dt> <dd>N/A</dd> <dt>Additional information:</dt> <dd>N/A</dd> <dt>Personand& email address to contact for furtherinformation</dt>information:</dt> <dd>Pierre-Anthony Lemieux <pal@sandflow.com></dd> <dt>Intendedusage</dt>usage:</dt> <dd>COMMON</dd> <dt>Restrictions onUsage</dt>Usage:</dt> <dd>This media type depends on RTPframing,framing and hence is only defined for use with RTP as specifiedatin <xref target="RFC3550"/>. Transport within other framing protocols is not defined at the time.</dd><dt>Author</dt> <dd><eref target="mailto:pal@sandflow.com">Pierre-Anthony<dt>Author:</dt> <dd>Pierre-Anthony Lemieux</eref></dd><pal@sandflow.com> </dd> <dt>Changecontroller</dt>controller:</dt> <dd>IETF</dd> </dl> </section> </section> <section anchor="sec-sdp"> <name>Mapping to the Session Description Protocol (SDP)</name> <t>The mapping of the payload format media type and its parameters to SDP, as specified in <xreftarget="RFC8866"/> MUSTtarget="RFC8866"/>, <bcp14>MUST</bcp14> be done according to <xref target="RFC4855" section="3"/>.</t> </section> <section anchor="sec-congestion-control"> <name>Congestioncontrol</name>Control</name> <t>Since this RTP payload format can be used in a variety of applications across many different contexts, there is no single congestion control mechanism that will work for all. Below is a non-exhaustive list of example mechanisms that can be used:</t> <ul> <li>a sender can offer several alternative streams for a given video signal, each with a different data rate corresponding to a different compression ratio;</li> <li>a sender can modulate the data rate within a stream by modulating the resolution, frame rate, or compression ratio of the underlying video signal; or</li> <li>an intermediate system can lower the data rate of a stream by discarding resolutions levels and/or quality layers, as specifiedatin <xref target="sec-filtering"/>.</li> </ul> <t>As suggestedatin <xref target="RFC3550" sectionFormat="of"section="10"/>section="10"/>, RTCP feedback can be used in the data rate adaptation process.</t> </section> <section anchor="sec-iana"> <name>IANA Considerations</name><t>This memo requests that IANA registers<t>IANA has registered the media type specifiedatin <xref target="sec-media-type"/>.</t> </section> <section anchor="sec-sec"> <name>Securityconsiderations</name>Considerations</name> <t>RTP packets using the payload format specified in this document are subject to the security considerations discussed in <xref target="RFC3550"/>,and in any applicable RTP profile such as <xref target="RFC3551"/>, <xref target="RFC4585"/>, <xref target="RFC3711"/>, and <xref target="RFC5124"/>. However, as <xref target="RFC7202"/> discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity, and source authenticity for RTP in general. This responsibilitylays onlies with anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in <xref target="RFC7201"/>. ApplicationsSHOULD<bcp14>SHOULD</bcp14> use one or more appropriate strong security mechanisms. The rest of thisSecurity Considerationssection discusses the security impacting properties of the payload format itself.</t> <t>This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for RTPPacket processing,packet processing and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data.Nor doesIn addition, the RTP payload format does not contain any active content.</t> <t>Security considerations related to the JPEG 2000 codestream contained in the payload are discussedatin <xref target="RFC3745" section="3"/>.</t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <!-- [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] --> <referenceanchor="jpeg2000-1">anchor="JPEG2000-1" target="https://www.itu.int/rec/T-REC-T.800/"> <front> <title abbrev="Rec. ITU-TT.800">Recommendation ITU-T T.800,T.800">Information technology - JPEG 2000 image coding system: Core coding system</title> <author> <organization>ITU-T</organization> </author> <dateyear="2019" month="06"/>year="2024" month="07"/> </front> <seriesInfo name="ITU-T Recommendation" value="T.800" /> </reference> <referenceanchor="jpeg2000-2">anchor="JPEG2000-2" target="https://www.itu.int/rec/T-REC-T.801/"> <front> <title abbrev="Rec. ITU-TT.801">Recommendation ITU-T T.801,T.801">Information Technology - JPEG 2000 image codingsystem:system - Extensions</title> <author> <organization>ITU-T</organization> </author> <dateyear="2021" month="06"/>year="2023" month="08"/> </front> <seriesInfo name="ITU-T Recommendation" value="T.801" /> </reference> <referenceanchor="jpeg2000-15">anchor="JPEG2000-15" target="https://www.itu.int/rec/T-REC-T.814/"> <front> <title abbrev="Rec. ITU-TT.814">Recommendation ITU-T T.814,T.814">Information technology - JPEG 2000 image coding system: High-throughput JPEG 2000</title> <author> <organization>ITU-T</organization> </author> <date year="2019" month="06"/> </front> <seriesInfo name="ITU-T Recommendation" value="T.814" /> </reference> <referenceanchor="rec-itu-t-h273">anchor="REC-ITU-T-H273" target="https://www.itu.int/rec/T-REC-H.273"> <front> <title abbrev="Rec. ITU-TH.273">Recommendation ITU-T H.273, Coding-independentH.273">Coding-independent code points for video signal type identification</title> <author> <organization>ITU-T</organization> </author> <dateyear="2021"year="2024" month="07"/> </front> <seriesInfo name="ITU-T Recommendation" value="H.273" /> </reference> <referenceanchor="jpeg2000-9">anchor="JPEG2000-9" target="https://www.itu.int/rec/T-REC-T.808"> <front> <title abbrev="Rec. ITU-TT.808">JPEGT.808">Information technology - JPEG 2000 image coding system: Interactivity tools, APIs and protocols</title> <author> <organization>ITU-T</organization> </author> <dateyear="2005" month="01"/>year="2022" month="12"/> </front> <seriesInfo name="ITU-T Recommendation" value="T.808" /> </reference> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3550.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8866.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8866.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4855.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4855.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3986.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5234.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.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.8174.xml"/> </references> <references> <name>Informative References</name> <referenceanchor="ov2110-0">anchor="OV2110-0" target="https://pub.smpte.org/latest/ov2110-0/ov2110-0-2018.pdf"> <front> <title abbrev="SMPTE OV 2110-0">Professional Media Over Managed IP Networks, Roadmap for the 2110 Document Suite</title> <author> <organization>SMPTE</organization> </author> <date year="2018" month="12" day="04"/> </front> </reference> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5371.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5371.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4175.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4175.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.6838.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3551.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.4585.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3711.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5124.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7201.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7201.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.7202.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7202.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.3745.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3745.xml"/> <xi:includehref="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5450.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5450.xml"/> </references> </references> <section anchor="sec-pixel-fmts"> <name>Pixelformats</name>Formats</name> <t><xref target="t-pix-fmts"/> defines pixel formats.</t> <table anchor="t-pix-fmts"> <name>Definedpixel formats</name>Pixel Formats</name> <thead> <tr> <th>NAME</th> <th>SAMP</th> <th>COMPS</th> <th>TRANS</th> <th>PRIMS</th> <th>MAT</th> <th>VFR</th> <th>Mapping in <xref target="t-color-map"/></th> </tr> </thead> <tbody> <tr> <td>rgb444sdr</td> <td>4:4:4</td> <td>RGB</td> <td>1</td> <td>1</td> <td>0</td> <td>0, 1</td> <td>RGB</td> </tr> <tr> <td>rgb444wcg</td> <td>4:4:4</td> <td>RGB</td> <td>1</td> <td>9</td> <td>0</td> <td>0, 1</td> <td>RGB</td> </tr> <tr> <td>rgb444pq</td> <td>4:4:4</td> <td>RGB</td> <td>16</td> <td>9</td> <td>0</td> <td>0, 1</td> <td>RGB</td> </tr> <tr> <td>rgb444hlg</td> <td>4:4:4</td> <td>RGB</td> <td>18</td> <td>9</td> <td>0</td> <td>0, 1</td> <td>RGB</td> </tr> <tr> <td>ycbcr420sdr</td> <td>4:2:0</td> <td>YCbCr</td> <td>1</td> <td>1</td> <td>1</td> <td>0</td> <td>YCbCr</td> </tr> <tr> <td>ycbcr422sdr</td> <td>4:2:2</td> <td>YCbCr</td> <td>1</td> <td>1</td> <td>1</td> <td>0</td> <td>YCbCr</td> </tr> <tr> <td>ycbcr422wcg</td> <td>4:2:2</td> <td>YCbCr</td> <td>1</td> <td>9</td> <td>9</td> <td>0</td> <td>YCbCr</td> </tr> <tr> <td>ycbcr422pq</td> <td>4:2:2</td> <td>YCbCr</td> <td>16</td> <td>9</td> <td>9</td> <td>0</td> <td>YCbCr</td> </tr> <tr> <td>ycbcr422hlg</td> <td>4:2:2</td> <td>YCbCr</td> <td>18</td> <td>9</td> <td>9</td> <td>0</td> <td>YCbCr</td> </tr> </tbody> </table> <t>Each pixel format is characterized by the following:</t> <dlnewline="true"> <dt><tt>NAME</tt></dt>newline="false" spacing="normal"> <dt><tt>NAME</tt>:</dt> <dd>Identifies the pixel format</dd><dt><tt>SAMP</tt></dt> <dd> <dl><dt><tt>SAMP</tt>:</dt> <dd><t><br/></t> <dl newline="false" indent="8"> <dt>4:2:0</dt> <dd>The C<sub>b</sub> and C<sub>r</sub> color channels are subsampled horizontally and vertically by 1/2.</dd> <dt>4:2:2</dt> <dd>The C<sub>b</sub> and C<sub>r</sub> color channels are subsampled horizontally by 1/2.</dd> <dt>4:4:4</dt> <dd>No color channels aresub-sampled.</dd>subsampled.</dd> </dl> </dd><dt><tt>COMPS</tt></dt> <dd> <dl> <dt>RGB</dt><dt><tt>COMPS</tt>:</dt> <dd><t><br/></t> <dl newline="false" indent="9"> <dt>RGB:</dt> <dd>Each codestream contains exactly three components, associated with the R,GG, and B color channels, in order.</dd><dt>YCbCr</dt><dt>YCbCr:</dt> <dd>Each codestream contains exactly three components, associated with the Y,C<sub>b</sub>C<sub>b</sub>, and C<sub>r</sub> color channels, in order.</dd> </dl> </dd><dt><tt>TRANS</tt></dt><dt><tt>TRANS</tt>:</dt> <dd> <t>Identifies the transfer characteristics allowed by the pixel format, as definedatin <xreftarget="rec-itu-t-h273"/></t>target="REC-ITU-T-H273"/>.</t> </dd><dt><tt>PRIMS</tt></dt><dt><tt>PRIMS</tt>:</dt> <dd> <t>Identifies the color primaries allowed by the pixel format, as definedatin <xreftarget="rec-itu-t-h273"/></t>target="REC-ITU-T-H273"/>.</t> </dd><dt><tt>MAT</tt></dt><dt><tt>MAT</tt>:</dt> <dd> <t>Identifies the matrix coefficients allowed by the pixel format, as definedatin <xreftarget="rec-itu-t-h273"/></t>target="REC-ITU-T-H273"/>.</t> </dd><dt><tt>VFR</tt></dt><dt><tt>VFR</tt>:</dt> <dd> <t>Allows values of the VideoFullRangeFlag definedatin <xreftarget="rec-itu-t-h273"/></t>target="REC-ITU-T-H273"/>.</t> </dd> </dl> </section> <section anchor="sec-signal-fmts"> <name>Signalformats</name>Formats</name> <dlnewline="true"> <dt><tt>prog</tt></dt>newline="false"> <dt><tt>prog</tt>:</dt> <dd>The streamMUST<bcp14>MUST</bcp14> only consist of a sequence of progressive frames.</dd><dt><tt>psf</tt></dt><dt><tt>psf</tt>:</dt> <dd>Progressive segmented frame (PsF) stream. The streamMUST<bcp14>MUST</bcp14> only consist of an alternating sequence of first segment and second segment.</dd><dt><tt>tff</tt></dt><dt><tt>tff</tt>:</dt> <dd>Interlaced stream. The streamMUST<bcp14>MUST</bcp14> only consist of an alternating sequence of first field and second field, where the first line of the first field is the first line of the frame.</dd><dt><tt>bff</tt></dt><dt><tt>bff</tt>:</dt> <dd>Interlaced stream. The streamMUST<bcp14>MUST</bcp14> only consist of an alternating sequence of first field and second field, where the first line of the first field is the second line of the frame.</dd> </dl> </section> <section anchor="sec-sample-fmts"> <name>Sampleformats</name>Formats</name> <dlnewline="true">newline="false" indent="6"> <dt><tt>8</tt></dt> <dd>All components consist of unsigned 8-bit integer samples.</dd> <dt><tt>10</tt></dt> <dd>All components consist of unsigned 10-bit integer samples.</dd> <dt><tt>12</tt></dt> <dd>All components consist of unsigned 12-bit integer samples.</dd> <dt><tt>16</tt></dt> <dd>All components consist of unsigned 16-bit integer samples.</dd> </dl> </section> </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>