Summary

  • RFC 9828 permits the first RTP packet for an image to leave before the complete JPEG 2000 codestream exists, but only particular single-tile progression orders admit that operation.
  • Resynchronisation, extended sequence, timing, quality and resolution fields make failures and selective processing more tractable; none proves that a receiver restarted, reconstructed the sender clock, preserved full quality or displayed on time.
  • Acceptance evidence must follow the image from session constraints and encoder progress through network delivery, receiver state, decoded output and a common-clock glass-to-glass observation.

In a control room, an attractive metric appears first: time from capture start to the first packet on the sender's interface. A green number can be produced before the receiver has the main header it needs, before a lost region has been bypassed, before the decoder has admitted the declared capabilities and before a display has scanned out a frame. Calling that number “latency” gives one stage authority over an entire chain.

RFC 9828, published as an IETF Proposed Standard in August 2025, deliberately solves a narrower problem. JPEG 2000 represents each image as a codestream of marker segments and coded data. Its main header applies to the whole codestream and is generally indispensable to decoding. The new RTP format separates Main Packets, which carry Extended Header material, from Body Packets, which carry the progressive coded body. One RTP payload never spans two codestreams.

That separation lets transmission overlap encoding. Position-first progression can make early lines available before the final lines have been coded. Yet the permission is conditional. The Main Packet's ORDH field says whether the codestream keeps a known progression order and whether Body Packets identify resync points. RFC 9828 says only values 4 and 6—PCRL and PRCL—allow sub-codestream-latency streaming. It also requires ORDH=0 for a multi-tile codestream. A product that starts sending early with a different progression or tile layout has not satisfied this contract merely because a packet left quickly.

A resync point is an address for another attempt

A Body Packet can mark the first byte of packet-header data for a precinct. ORDB signals the presence of that resync point; POS locates it inside the RTP payload; PID identifies the precinct. This can let a receiver process later material after earlier packets were corrupted, lost or deliberately removed by an intermediary.

The word “can” carries the boundary. A resync point is unavailable for multi-tile codestreams. It does not reconstruct missing bytes. It does not certify that the decoder retained sufficient header state, supported the progression, accepted the next precinct or produced an image fit for use. The useful receipt is not that ORDB=1 appeared. It is that a named receiver, from a recorded loss pattern and state, resumed at the advertised offset and produced a bounded output.

Sequence evidence is similarly precise. The ordinary RTP sequence field contains the low 16 bits; ESEQ supplies eight high bits, creating a 24-bit extended number. This improves continuity across the 16-bit wrap. It does not deliver a packet, distinguish every loss from deliberate filtering or prove that a late packet was admitted to the intended image. Capture location remains part of the fact.

A transmission sample is not a recovered clock

Every packet belonging to one image carries the same 90 kHz RTP timestamp, representing presentation time. PTSTAMP adds a 12-bit sample tied to the sender's transmission clock. A receiver can use its more frequent changes to accelerate clock recovery. The sender should enable it only when it can generate the value accurately, and consecutive packets with the same RTP timestamp must remain within the 4095-tick, roughly 45 ms, modular interval.

Those limits are useful diagnostics, not a synchronisation certificate. A compliant field does not show that the receiver estimated the sender clock correctly, selected a suitable jitter buffer, aligned capture and display clocks or avoided queuing later in the path. RFC 5450 addresses the broader case of actual transmission time differing from nominal transmission time. Neither document turns an RTP header into a glass-to-glass stopwatch.

The same distinction applies to quality. QUAL lets a receiver discard packets belonging only to quality layers it does not need. RES lets it omit material that contributes only to higher resolutions. Such filtering is a designed feature, not necessarily a fault. But a successful lower-resolution decode cannot be reported as proof that the full-resolution, full-quality service survived. Record the target and the attained output separately.

Header reuse and code-block caching make receiver state even more important. With R=1, main-header information can be reused across codestreams. With C=1, cached non-empty code-blocks can replace later empty blocks. RFC 9828 explicitly notes that the sender cannot know the receiver cache with certainty: a block may have been lost, or the receiver may have joined late. Bandwidth saved at the sender therefore creates a state-dependency question at each receiver.

Capability promises stop at admission

The registered video/jpeg2000-scl type can carry parameters for pixel and sample format, maximum dimensions, scanning structure and application-defined capability sets. SDP can convey that session contract. Missing parameters leave properties unspecified; a capability URI obtains its meaning from the application that defines it.

Offer/answer evidence should preserve the exact parameters accepted by each receiver. It should then be joined to decoder build, enabled profile, memory limit and admission result. The syntax permits enormous dimensions—up to 2^32−1—so RFC 9828 tells implementations to bound resource use and fail gracefully. “Understands the media type” is not proof that this stream fit memory, compute, bandwidth or display limits.

The older RFC 5371 remains useful context for JPEG 2000 over RTP, while RFC 3550 defines the transport framework. Neither should be read as a deployment or performance report for the new media type. The RFC Editor record, text edition, Datatracker record and errata search establish the documentary boundary, not a product outcome.

Heng Lu's Running-Code Primacy supplies the right editorial discipline: the coordination document stays thin, while execution retains authority over operational reality. Minimum Initial Specification helps separate the common payload contract from receiver-local resource and output decisions. Reality, Not Advocacy requires the report to stop where evidence stops. These are applications by this author, not intentions attributed to the IETF.

The resulting chain has eight receipts: the negotiated session, the permitted codestream progression, actual sender timestamps and headers, packet observations at named network points, receiver header/cache state, resync outcome, decoded quality and resolution, and capture-to-display timing on a common clock. The first packet is valuable. It is simply first.