Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery
Extracted elements (24)
Progression-based ordering excludes the position axis (handled via tile number field) to save priority value space, unlike packet-number-based ordering. This makes progression-based ordering more efficient for codestreams with many positions.
The main header compensation scheme exploits the fact that successive JPEG 2000 video frames rarely change encoding parameters, making it highly likely that a prior frame's header can substitute for a lost current header. This avoids retransmission while enabling recovery from header loss.
The priority field enables receivers in a multicast environment with heterogeneous capabilities (e.g., TV vs. mobile) to independently select which packets are vital for their display quality, allowing a single sender to serve all clients without per-client streams or additional signaling.
Implementations following this document are expected to interoperate with implementations of RFC 5371 alone. Receivers that do not support these extensions can safely ignore the mh_id and priority field values, and in a multicast environment senders MAY use these mechanisms even if some clients do not support them.
If any headers (main header or tile-part header) are packed into the RTP payload, the sender MUST set the priority value to 0.
If encode parameters change, the sender MUST increment the mh_id value by one, and when mh_id becomes greater than 7 MUST set it back to 1.
If the JPEG 2000 codestream packet value is greater than 255 in packet-number-based ordering, the sender MUST set the payload priority value to 255.
If the mh_id field is set to 0, the receiver MUST NOT save the main header and MUST NOT compensate for lost headers.
In the SDP Offer/Answer model, if the optional parameter "mhc" is used it MUST appear in the offer with value "1", and if accepted it MUST appear in the answer. If "pt" is used, it MUST appear in the offer as a complete comma-separated list of supported priority table definitions, and the answer MUST contain a single selected definition.
Packet-number-based priority mapping is REQUIRED to be supported by all clients implementing this specification; other priority mapping tables (progression, layer, resolution, component-based) are OPTIONAL.
The initial value of mh_id MUST be 1 at the beginning of the session.
The mh_id value MUST be incremented by 1 every time a new main header is transmitted. Once the mh_id value becomes greater than 7, it SHOULD roll over to 1.
The new optional SDP parameters mhc and pt, if present, MUST be included in the "a=fmtp" line of SDP as a semicolon-separated list of parameter=value pairs.
The sender MUST transmit RTP packets with the same mh_id value if the encoder parameters (SIZ, COD, COC, RGN, QCD, QCC, POC marker segments) of the current frame are the same as the previous frame.
When there are multiple JPEG 2000 packets in the same RTP payload packet, the sender MUST set the payload packet priority value to the lowest (most important) JPEG 2000 packet priority among those packed.
Layer-based ordering maps all JPEG 2000 packets from layer n to priority value n+1, up to a maximum of 255. Resolution-based and component-based orderings follow the same scheme for their respective axes.
Progression-based ordering assigns priority based on the triple <layer, resolution, component> using order-specific formulas (LRCP, RLCP, RPCL, PCRL, CPRL), with minimum priority value of 1. Position is excluded since receivers can identify it from the tile number field.
The main header compensation scheme requires receivers to save the last completely received JPEG 2000 main header along with its mh_id and RTP sequence number. If the current frame's mh_id matches the saved value and the header is lost, the saved header may be used for decoding.
The media type "video/jpeg2000" is extended with two optional parameters: "mhc" (Main Header Compensation, value "1" to enable) and "pt" (Priority Table, a comma-separated list of: default, progression, layer, resolution, component).
The mh_id (Main Header Identification) field is 3 bits in the RTP payload header. It identifies the current JPEG 2000 main header version; value 0 has special meaning (no compensation), values 1–7 are used cyclically to track header changes.
The priority field is 8 bits in the RTP payload header. Value 0 is reserved for payloads containing a header (main or tile-part); values 1–255 indicate decreasing importance of the JPEG 2000 packet data contained in the RTP payload.
This document extends the "video/jpeg2000" media type registered in RFC 5371 with additional optional parameters mhc and pt, as specified in Section 5.
The mh_id field can identify a maximum of 7 different main headers. If severe packet loss (random or attacker-introduced) causes 6 successive main header updates to be lost, the decoder will attempt decompression using an incorrect main header. Standard JPEG 2000 decoders should detect the codestream inconsistency; it is recommended to clear the saved mh_id and header upon detecting such inconsistency.
The RTP payload header for JPEG 2000 is 64 bits: tp (2 bits), MHF (2 bits), mh_id (3 bits), T (1 bit), priority (8 bits), tile number (16 bits), reserved (8 bits), fragment offset (24 bits).