Summary

  • RFC 5372 gives mh_id seven active values. Equality lets a receiver try a saved JPEG 2000 main header when the current header is missing; it does not prove that the saved parameters belong to the current frame.
  • The specification names the rollover failure directly: if six successive main-header updates disappear, a stale identifier can meet its own value again. A decoder may detect the mismatch only after decompression has been attempted.
  • Capability negotiation, header receipt, cache provenance, identifier comparison, decoder admission and displayed output are different receipts. Priority zero marks header-bearing content as important, but does not reserve its delivery.

One returned before its meaning did

The dangerous event is easy to describe without a codec diagram. A receiver stores a complete JPEG 2000 main header and the value one. The encoder later changes the parameters that govern decoding. The sender correctly advances the identifier and transmits a new header. That update is lost. The process repeats. After the values two through seven have passed without being observed, the sender changes again and returns the bounded identifier to one.

The receiver sees a familiar value. Its cache also says one. The numerical comparison is true. The historical conclusion is false.

RFC 5372 does not conceal this possibility. Its security section says that the field can distinguish at most seven main headers and that six successive missed updates can cause a decoder to try the wrong saved header. The loss may be random or intentionally introduced. The standard then recommends clearing the saved identifier and header if the decoder detects an inconsistency.

That sequence matters because it separates three moments that are easily collapsed in operations data. First, the transport presents an identifier. Second, the receiver chooses cached state and attempts decompression. Third, the decoder may discover that the state and payload are inconsistent. A dashboard that records only the first moment can report a cache hit while the decoder is already working with the wrong authority.

The field is useful because its claim is small. It is not a cryptographic digest of the header. It is not an authenticated epoch number with an unbounded lifetime. It is not a commitment to the byte sequence retained by the receiver. It is a three-bit continuity signal whose namespace is deliberately reused.

The cache coordinate was not the cached object

RFC 5372 states that mh_id and encoding parameters are not associated one-to-one. That sentence does more architectural work than the field’s name suggests. It prevents an implementation from treating the identifier as a permanent name for one parameter set.

The sender keeps the value stable while the defined encoding parameters remain unchanged between frames. When those parameters change and a new main header is sent, the sender advances the value. The comparison surface includes the SIZ marker and the functional COD, COC, RGN, QCD, QCC and POC marker segments. Those are the decoder-relevant features the protocol uses for continuity. The field does not contain them; it reports the sender’s transition state about them.

The receiver’s record therefore needs more than mh_id=1. RFC 5372 tells it to save the complete main header together with the RTP sequence number and identifier. Only the most recently received complete header should be kept. When a new identifier arrives with a complete header, the receiver should replace the old saved state.

Those instructions define a provenance tuple:

  • the RTP session and synchronization source to which the cache belongs;
  • the sequence position at which a complete header was obtained;
  • the identifier visible at that position;
  • the actual retained header bytes or a stable local fingerprint of them;
  • the observed transitions since that receipt;
  • the time and reason for any eviction or replacement.

Remove the sequence and header evidence, and the identifier becomes a label without lineage. Remove the transition history, and rollover becomes indistinguishable from continuity. Remove session identity, and equal three-bit values from unrelated streams can appear comparable.

This is the broader governance lesson. A compact protocol field may point to state without containing the state’s authority. Storing the pointer is not the same as preserving the object, its origin or its validity interval.

Header compensation was permission to attempt, not a verdict

Main-header compensation exploits a practical observation: successive JPEG 2000 video frames rarely change their encoding parameters. If a frame’s header is lost but its identifier matches the last complete header, the receiver may reuse the saved header to decode the new image data.

“May” is the right verb. Equality authorizes an economical recovery attempt under the protocol’s model. It does not certify the attempt’s outcome.

The distinction is especially important because main-header loss is consequential. The header carries essential decoding information. Without an applicable header, the image data cannot be decoded properly. Compensation avoids discarding a frame merely because repeated context was lost, but it does so by betting that the retained context still applies.

That bet can be sound in ordinary continuity. The sender is required to keep the same identifier when the governed parameters do not change. It is required to advance the identifier when they do. If the receiver observes the new complete header, it refreshes the cache. If it misses one change but then receives an unmatched identifier without a header, it cannot claim a match and should not silently treat the old state as current.

Rollover is the exceptional case where correct sender behavior, a bounded namespace and missing evidence combine. The equality test can no longer distinguish continuity from a full unseen cycle. The protocol does not make the comparison fraudulent; it makes its evidentiary limit explicit.

Six missing transitions formed one false continuity

Packet loss is often counted as a percentage. The rollover case shows why the location and semantic role of loss matter more than the average.

Losing six arbitrary media packets may reduce quality. Losing six successive parameter-transition headers can erase the entire visible history between two equal identifiers. The receiver does not merely lack six objects. It lacks the events that would have invalidated its cache.

An attacker who can selectively induce loss does not need to forge an identifier to exploit that ambiguity. Suppressing the transition-bearing headers may be sufficient to let the value cycle back into an old cache coordinate. Packet authentication can protect the packets that arrive. It cannot authenticate transitions that were never observed.

The monitoring question is therefore not only “How many packets were lost?” It is:

  • Did the loss coincide with a complete main header?
  • Was a parameter transition expected or later inferred?
  • How many identifier advances could have occurred since the retained header?
  • Did the receiver observe the 7-to-1 boundary?
  • Was compensation attempted after an unexplained gap?
  • Did the decoder reject the reconstructed input, and was the cache actually cleared?

A receiver that exposes only aggregate loss and decode success cannot answer those questions. A security control that validates source authentication but omits cache lineage also cannot answer them. Both surfaces are useful; neither subsumes the other.

Detection arrived after state selection

RFC 5372 says a standard JPEG 2000 decoder could detect an inconsistency between the wrong header and the codestream. It recommends clearing the saved identifier and header when such an inconsistency is detected.

That is a recovery control, not proof of safe anticipation. The decoder has already been given the combined input. Resources may already have been allocated. The frame may already have consumed latency budget. Depending on the implementation, the failure may appear as a decode error, a discarded frame, degraded output or a more generic pipeline fault.

The specification does not claim that every inconsistency is caught before any output, that every decoder reports the same failure, or that clearing the cache retrieves the missing correct header. Cache invalidation stops reuse of known-suspect state. It does not manufacture the absent transition.

Operations should therefore record at least four different results:

  1. the compensation decision was made;
  2. the decoder admitted the combined header and payload;
  3. decoding completed without an exposed inconsistency;
  4. an output frame was produced and reached the intended display or downstream consumer.

These results are related but not interchangeable. A decoder that accepts input has not necessarily produced the expected picture. A produced frame has not necessarily been displayed. A visible picture has not necessarily preserved the quality or semantic fidelity expected by the application.

Zero withdrew the shortcut

The value zero has a deliberately different role. When mh_id is zero, the receiver must not compensate for a lost header and must not save the header under that value.

Zero is not “the first header” and not a wildcard. It is an instruction to abstain from the cache mechanism. That makes it an important negative state in telemetry. Normalizing zero into a missing value or silently replacing it with the previous identifier would erase the sender’s chosen boundary.

The operational record should distinguish at least:

  • the field was absent because this was not the relevant payload format;
  • the receiver implemented only baseline RFC 5371 semantics and ignored the field;
  • the extension was active and the sender used zero;
  • the extension was active and a nonzero value matched a retained header;
  • the extension was active but no complete retained header existed.

All five states can look like “no cache recovery” in a coarse metric, yet they imply different capability, intent and failure paths.

SDP established a shared method, not a live cache

RFC 5372 adds mhc to the video/jpeg2000 media parameters. An offer that proposes main-header compensation uses mhc=1; an accepting answer reflects the capability. The standard’s examples also show an answer with mhc=0, declining compensation while accepting other characteristics of the stream.

The exchange is valuable evidence. It tells operators whether the peers agreed that the mechanism could be used. It does not show that the receiver later obtained a complete header, preserved the right one, observed every transition or successfully decoded a compensated frame.

This difference is familiar in other control planes but easy to forget in media pipelines. Configuration is not execution. Capability is not state. State is not outcome.

A robust incident record binds the negotiated media description to the RTP session and then records the runtime evidence separately. If the offer/answer transcript is stored in one system and decoder telemetry in another, both need a common session coordinate. Otherwise a team may prove that compensation was negotiated for a call while examining cache failures from another payload type or renegotiated segment.

Priority described importance, not delivery

RFC 5372 also gives meaning to the eight-bit priority field. Lower numbers mean greater declared importance, and zero is reserved for payloads containing a main or tile-part header. Packet-number mapping is the required default. Progression-, layer-, resolution- and component-based tables are optional and selected through the pt parameter.

This classification helps a receiver or intermediate system understand which portions of a scalable codestream matter to a chosen presentation. It does not reserve bandwidth or queue space. It does not compel a network to deliver priority-zero packets. It does not prove that a receiver loaded, decoded or displayed them.

The rollover problem makes that distinction concrete. The missing updates are likely to carry the most important classification because they contain headers. Their importance value can correctly say “protect this first” while the transport still loses them. A dashboard that converts priority zero into “header delivered” replaces a request for preferential treatment with a receipt that the protocol never issued.

Nor is a number meaningful without its selected mapping. A value derived from packet order is not equivalent to the same value derived from layer or resolution. The runtime record must retain the negotiated pt mode before interpreting the byte.

Mixed capability created an observation boundary

The extension is optional. RFC 5372 says an RFC 5371-only receiver can safely ignore mh_id and priority. In multicast, a sender may use the mechanisms even when one group member does not support them.

That compatibility is useful, but it creates unequal evidence. Two receivers can consume the same RTP stream while exposing different meanings for the same header bits. One may retain main headers, compare identifiers and select scalable packets. The other treats those bits as fields with no active extension semantics.

Fleet reporting must not infer common behavior from common packet captures. Capability belongs to each receiver and negotiation context. A group-level claim such as “main-header compensation succeeded” needs receiver-level evidence, not merely proof that the sender populated the field.

The same applies to priority-based adaptation. A capable receiver may stop loading lower-value material according to the selected mapping. A baseline receiver may ignore the field. Neither behavior alone proves what users saw across the group.

The seven-slot control model

A sound implementation can treat the cache as a seven-slot protocol only if it refuses to treat the slots as permanent identities.

For each active RTP context, it should preserve the last completely received main header, its local hash, sequence provenance, identifier and governed parameter fingerprint. It should record each observed transition and whether a complete replacement was received. It should count unexplained gaps without pretending to know how many updates occurred inside them.

Before compensation, the decision engine should ask:

  • Was mhc accepted for this exact media context?
  • Is the identifier nonzero?
  • Is there a complete cached header from this session and source?
  • Has the cache crossed a restart, renegotiation or identity change?
  • Is the observed transition history compatible with freshness?
  • Has a previous inconsistency marked the cache suspect?

After compensation, it should record decoder admission, inconsistency detection, cache clearing, complete-header reacquisition and output-frame production. If the application needs proof of display, that evidence belongs after the decoder rather than being inferred from it.

This model does not eliminate loss. It makes the consequence of missing evidence visible and limits the authority of a compact equality test.