Summary

  • draft-ietf-avtcore-rtp-jpegxs-3ed-08 retains the RTP packetization and payload structure of RFC 9134 for legacy modes while adding third-edition JPEG XS features, notably Temporal Differential Coding, or TDC.
  • A non-TDC codestream is independently decodable. A TDC codestream may instead require quantized wavelet coefficients reconstructed from the preceding codestream and preserved in the correct progressive or field-specific buffer.
  • Exact SDP acceptance, a valid current payload and an advertised fbblevel establish declarations and syntax. They do not prove that prior state survived loss, that required memory bandwidth was sustained, that a picture decoded correctly or that the requested media service reached the viewer.

The receipt arrives before the picture

Consider a receiver that accepts an offer containing the JPEG XS media parameters, echoes those values exactly and then receives a syntactically valid RTP stream. The new Slice Line Indicator marker appears where expected. Every control-plane receipt looks orderly. The next picture can still depend on data reconstructed from the previous codestream.

That is the important change introduced by the third-edition payload specification. JPEG XS without TDC permits each codestream to be decoded as a stand-alone picture. TDC introduces temporal dependence: quantized wavelet coefficients from a preceding codestream can become input to the current one. Progressive video uses one frame buffer for that lineage; interlaced or progressive segmented frame material uses two buffers, one for each field. A receiver can therefore understand the current packet and still lack the correct historical state.

The document is revision 08, dated 22 September 2026. Datatracker places it in the RFC Editor Queue, with Proposed Standard as the intended status, and the draft says it would obsolete RFC 9134. It remains an Internet-Draft. Queue position is evidence of process state, not evidence of publication as an RFC, implementation, deployment or interoperable output.

Compatibility preserves the envelope, not the past

The revision deliberately preserves RFC 9134's RTP packetization, header formats and overall payload structure for modes that do not use the new temporal feature. This is a valuable compatibility property. It narrows the change that endpoints and intermediaries must absorb.

It does not make temporal state backwards compatible. For TDC, the SLI marker delimits a slice. In RTP slice packetization, SLI and the older SLH marker perform the same packetization role. That tells a sender and receiver where a transport unit can be separated. It does not turn the slice into an independently recoverable temporal unit.

This is where a tidy packet trace can mislead. RTP sequence numbers and marker boundaries describe transport order and packetization. TDC state describes a decoder dependency that crosses pictures. A packet boundary is not automatically a recovery boundary. A receiver that loses or mis-associates the coefficients needed for the next picture needs an explicit recovery policy; syntax alone cannot recreate history.

fbblevel is a requirement, not a measurement

Revision 08 adds the optional fbblevel media parameter. It is permitted only when TDC is in use, and it must agree with the Frame Buffer Bandwidth level signalled in the JPEG XS picture segment. Its meaning is carefully limited: it expresses a lower bound on the read and write bandwidth required of the frame buffer.

The parameter does not meter the decoder while it runs. An endpoint can truthfully advertise support for a level and later encounter contention, throttling, memory-placement effects or another local limit. None of those outcomes is asserted by the draft, but the distinction follows directly from what fbblevel is: a declared lower bound rather than an observation of sustained service.

Most media parameters in this payload, with rate treated separately, duplicate information carried in the payload. They are declarative. If SDP and payload disagree, payload data prevails. An operator therefore needs both records. The offer/answer exchange shows what the parties agreed to attempt; the payload shows what the sender actually signalled for the coded picture.

Exact echo is a capability contract

In unicast offer/answer, an answerer must support all the parameter values in the offer or reject the offer. If it accepts, it echoes the exact parameters. This creates a crisp compatibility decision and prevents a quiet partial acceptance.

It does not collapse the rest of the media path into that decision. Exact echo does not prove that the correct prior coefficients occupy the correct buffer, that packet loss did not sever the dependency, that the decoder sustained the required buffer bandwidth, or that a rendered frame reached the application. Session acceptance is a capability contract. Media success is a chain of later facts.

The transport guidance preserves the same distinction. Best-effort use requires monitoring packet loss and applying congestion control. A receiver using an enhanced service is also expected to verify that the requested service is actually being delivered. Reservation, negotiation and delivery are separate observations.

Five receipts, not one green light

Lu Heng's Minimum Initial Specification provides a useful boundary here. The shared standard should define the minimum deterministic envelope: parameter meanings, packetization, precedence and the coded dependency. Local systems still decide how to provision memory, detect missing history, recover and expose outcome.

Running-Code Primacy then puts the deployed decoder above the presentation layer of the negotiation. The offer is not false; it is simply not the final witness. Reality-layer discipline keeps five facts separate: negotiated capability, payload declaration, received packet history, decoder-state continuity and observed output. Turning them into one “session accepted” field would give a symbolic receipt authority over a physical result it never measured.

Sources and limits

These sources specify formats, negotiation rules and operational considerations. They do not establish a named implementation, deployment, interoperability result, benchmark, loss response, decoder defect, incident, rendered-image quality or adoption rate. The separation of receipts is an operational analysis, not a claim that any deployed system has failed.