7.2.RTP Packet Filtering

An intermediate systemMAY strip out RTP packets from a codestream that are of no interest to a particular client, e.g., based on a resolution or a spatial region of interest.¶

7.4.PTSTAMP Field

A senderSHOULD setP = 1, but only if it can generatePTSTAMP accurately.¶

PTSTAMP can be derived from the same clock that is used to produce the 32-bittimestamp field in the RTP Fixed Header. Specifically, a sender maintains, at least conceptually, a 32-bit 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 least significant bits of the sample are stored in thePTSTAMP field.¶

IfP = 1, then the transmission timeTOFF (as defined inSection 5.3) for two consecutive RTP packets with identicaltimestamp fieldsMUST NOT differ by more than 4095.¶

7.6.Extra Information

The senderMUST set the value ofXTRAC to 0.¶

Future updates to this RTP payload format can permit other values.¶

7.7.Unassigned Values

The senderMUST set unassigned values to 0.¶

Unassigned values are available for assignment by future updates to this RTP payload format. As specified inSection 8.5, these future assigned values are ignored by receivers that conform to this specification. In contrast to extension values (seeSection 7.8), this mechanism allows updates to this RTP payload format that remain compatible with receivers that conform to this specification.¶

7.8.Extension Values

A senderMUST NOT use an extension value.¶

7.9.Code-Block Caching

This section only applies ifC = 1.¶

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. WhenC = 1, a receiver maintains a simple cache of previously received code-blocks, which it uses to replace empty code-blocks (seeSection 8.7).¶

A sender alone determines which code-blocks are replaced with empty code-blocks and when the replacement occurs.¶

The sender cannot, however, determine with certainty the state of 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 stream, etc.¶

A code-block isempty if:¶

• it does not contribute code-bytes as specified in the parent JPEG 2000 packet header; or¶
• it contains an HT cleanup segment and the first two bytes of the Magsgn byte-stream are between0xFF80 and0xFF8F (if the code-block conforms to[JPEG2000-15]).¶

NOTE: The 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 suggested in Annex F.4 of[JPEG2000-15].¶

8.1.PTSTAMP

Receivers can usePTSTAMP values to accelerate sender clock recovery sincePTSTAMP typically updates more regularly thantimestamp.¶

8.3.RES

The JPEG 2000 coding process decomposes an image using a sequence of discrete wavelet transform (DWT) stages.¶

Table 2 illustrates the case where each DWT stage consists of both horizontal and vertical transforms, which is the only mode supported in[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_L times, where N_L is the number of decomposition levels as defined in the COD and COC marker segments of the codestream.¶

The decoding process reconstructs the image by reversing the coding process, starting with the lowest resolution image stored in the codestream (LL_NL).¶

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 than 2 (e.g., HL3, LH3, HH3, HL4, LH4, HH4, etc.) are necessary. In other words, a receiver that wishes to reconstruct an image at quarter resolution could discard all RTP packets whereRES >= 6 since those RTP packets can only contribute to HL1, LH1, HH1, HL2, LH2, and HH2 sub-bands.¶

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^{7 - N} if all Body Packets whereRES > N are discarded.¶

Table 3 illustrates the case where some DWT stages consist of only horizontal transforms, as specified in Annex F of[JPEG2000-2].¶

A receiver can therefore discard all Body Packets whereRES 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 Tables2 and3.¶

8.4.Extra Information

The receiverMUST accept values ofXTRAC other than 0 andMUST ignore the value ofXTRAB, whose length is given byXTRAC.¶

Future updates to this RTP payload format can specifyXTRAB contents such that this content can be ignored by receivers that conform to this specification.¶

8.5.Unassigned Values

The receiverMUST ignore unassigned values (see additional discussion inSection 7.7).¶

8.6.Extension Values

The receiverMUST discard an RTP packet that contains any extension value.¶

8.7.Code-Block Caching

This section only applies ifC = 1.¶

WhenC = 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 (seeSection 7.9).¶

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 receiverMUST replace it with a matching code-block from the cache, if one exists.¶
• If the code-block in the codestream is not empty, the receiverMUST replace any matching code-block from the cache with the code-block in the codestream.¶

Two code-blocks arematching if the following characteristics are identical for both: spatial coordinates, resolution level, component, sub-band, and value of theTP field of the parent RTP packet.¶

9.2.Definition

Type name:

video¶

Subtype name:

jpeg2000-scl¶

Required parameters:

N/A¶

Optional parameters:

pixel:

Specifies the pixel format used by the video sequence.¶

The parameterMUST be aURI-reference as specified in[RFC3986].¶

If the parameter is arelative-ref as specified in[RFC3986], then itMUST be equal to one of the pixel formats specified inTable 4, and the RTP header and payloadMUST conform to the characteristics of that pixel format.¶

If the parameter is not arelative-ref, the specification of the pixel format is left to the application that defined the URI.¶

If the parameter is not specified, the pixel format is unspecified.¶

sample:

Specifies the format of the samples in each component of the codestream.¶

The parameterMUST be aURI-reference as specified in[RFC3986].¶

If the parameter is arelative-ref as specified in[RFC3986], then itMUST be equal to one of the formats specified inAppendix C, and the streamMUST conform to the characteristics of that format.¶

If the parameter is not arelative-ref, the specification of the sample format is left to the application that defined the URI.¶

If the parameter is not specified, the sample format is unspecified.¶

width:

Maximum width in pixels of each image. Integer between 0 and 4,294,967,295.¶

The parameterMUST be a sequence of 1 or more digits.¶

If the parameter is not specified, the maximum width is unspecified.¶

height:

Maximum height in pixels of each image. Integer between 0 and 4,294,967,295.¶

The parameterMUST be a sequence of 1 or more digits.¶

If the parameter is not specified, the maximum height is unspecified.¶

signal:

Specifies the sequence of image types.¶

The parameterMUST be aURI-reference as specified in[RFC3986].¶

If the parameter is arelative-ref as specified in[RFC3986], then itMUST be equal to one of the signal formats specified inAppendix B, and the image sequenceMUST conform to that signal format.¶

If the parameter is not arelative-ref, the specification of the pixel format is left to the application that defined the URI.¶

If the parameter is not specified, the stream consists of an arbitrary sequence of image types.¶

caps:

The parameter contains a list of sets of constraints to which the stream conforms, with each set of constraints identified using anabsolute-URI defined by an application.¶

The parameterMUST conform to theuri-list syntax expressed as follows using ABNF[RFC5234]:¶

  uri-list = absolute-URI *(";" absolute-URI)

¶

The application that defines theabsolute-URIMUST ensure that it does not contain any";" character andMUST 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.¶

If the parameter is not specified, constraints beyond those specified in this document are unspecified.¶

cache:

The value of the parameterMUST be eitherfalse ortrue.¶

If the parameter istrue, the fieldCMAY be 0 or 1; otherwise, the fieldCMUST be 0.¶

If the parameter is not specified, then the parameter is equal tofalse.¶

Encoding considerations:

This media type is framed and binary. SeeSection 4.8 of [RFC6838].¶

Security considerations:

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³² - 1 pixels, which is also captured in the syntax of theheight andwidth parameters of this media type. Therefore, implementationsSHOULD take care when processing input that influences the size of memory structures andSHOULD fail gracefully when resource constraints are exceeded.¶

See alsoSection 13.¶

Interoperability considerations:

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

Published specification:

RFC 9828¶

Applications that use this media type:

video streaming and communication¶

Fragment identifier considerations:

N/A¶

Additional information:

N/A¶

Person & email address to contact for further information:

Pierre-Anthony Lemieux <pal@sandflow.com>¶

Intended usage:

COMMON¶

Restrictions on Usage:

This media type depends on RTP framing and hence is only defined for use with RTP as specified in[RFC3550]. Transport within other framing protocols is not defined at the time.¶

Author:

Pierre-Anthony Lemieux <pal@sandflow.com>¶

Change controller:

IETF¶