Summary

  • RFC 5371 places each JPEG 2000 RTP payload at a 24-bit byte offset measured from the beginning of its codestream. The coordinate can remain nonzero for the first packet seen in a layered RTP session because it names a position in the frame, not a position in that session.
  • Exact placement does not prove contiguity or decode readiness. Loss of the main header prevents image decoding; MHF classifies header material, T says whether the tile number is meaningful, and a marker closes one RTP session's contribution rather than every parallel layer.
  • Baseline receivers are told to ignore mh_id and priority. RFC 5372 assigns them extension semantics. Negotiation, packet integrity, byte reconstruction, decoder admission and displayed output therefore require different receipts.

The coordinate was exact because the claim was narrow

Imagine receiving a parcel labelled “bytes 2,810 through 4,209 of this frame.” The label is useful. It tells a reassembler where the parcel belongs and makes a gap before byte 2,810 visible. It does not say that bytes zero through 2,809 ever reached the receiver. It does not say the parcel belongs to a complete, conforming image. It says one thing precisely: where these bytes fit if the codestream is reconstructed.

That is the authority of RFC 5371's 24-bit fragment offset. The value is measured from the very beginning of each JPEG 2000 codestream, which the specification treats as a video frame. It is not relative to the RTP packet, a burst, a transport session or the first fragment observed by a monitor.

The distinction becomes sharper when scalable video is divided across multiple RTP sessions. A layer session may begin with a fragment whose offset is not zero. That is not malformed. The offset still uses the common frame origin, so the receiver can place material from several sessions on one coordinate system.

An operations dashboard that treats “first offset seen” as “start of frame received” changes the meaning of the field. A storage system that keeps only offset and payload, without frame identity, RTP session identity and received intervals, retains coordinates but loses the map they describe. Precision survives; provenance does not.

A map of intervals is not the territory between them

The useful reconstruction record is not a list of packet counts. It is an interval map. For each frame and each contributing RTP session, it records the start and end offset of every received payload, identifies overlaps and gaps, and preserves which packet supplied each range.

With that record, a receiver can prove that bytes 0–209 and 1,610–3,009 arrived while 210–1,609 did not. It can show that later material was positioned correctly. It cannot promote correct later placement into receipt of the missing range.

The difference matters because JPEG 2000 is structured. Missing bytes may remove a main header, tile-part header, packet header or compressed contribution. The numerical size of a gap does not determine its semantic consequence. A short loss in an authority-bearing header can be more destructive than a longer loss in material a decoder can bypass or degrade around.

RFC 5371 therefore pairs the absolute coordinate with fields that describe the kind and scope of material carried. Even then, those fields are descriptions of the payload, not affidavits from a decoder. Reassembly has to preserve the boundaries instead of translating them into a generic “received percentage.”

The main header was a dependency, not decorative metadata

RFC 5371 states the failure plainly: if the main header is lost, the image cannot be decoded. The header contains the common parameters that allow later codestream material to be interpreted. A tile payload may arrive intact and at the correct offset yet remain unusable because its decoding context is gone.

The two-bit MHF field classifies what the current RTP payload contains. Zero means no main header. One means a non-final fragment of a fragmented header. Two means the last fragment. Three means a whole main header is present in the payload.

Those values improve observation. They let a receiver identify header-bearing packets and distinguish a complete header in one packet from a header split across several. They do not make earlier header fragments reappear. Receiving an MHF=2 packet proves that the current payload contains the last part of a fragmented header; it does not prove that every preceding part survived.

Likewise, MHF=3 closes only the header question for that payload. It says nothing about the arrival of the tile-part data needed to finish the image. Header completeness, codestream completeness and decode outcome are three receipts.

The informative appendix recommends packing headers separately to make recovery easier. That recommendation reveals an operational choice: isolation can make an important loss easier to detect and recover, while aggregation may reduce overhead. A deployment must record which choice it made rather than assuming the standard chose for it.

A field can exist and still have no baseline meaning

Beside MHF, the payload header includes a three-bit mh_id. Its name suggests a ready-made main-header identity. Baseline RFC 5371 deliberately resists that inference. It says senders following only this specification should set mh_id to zero and receivers should ignore it.

RFC 5372 supplies the extension contract under which mh_id can identify stable encoder parameters and support main-header compensation. It also supplies rules for changes and rollover. Those semantics do not leak backward merely because the bits are present in RFC 5371's header.

The priority byte has the same architectural shape. RFC 5371 describes the field but tells a baseline sender to set it to 255 and a baseline receiver to ignore it. RFC 5372 defines priority modes and mappings for scalable processing.

This is a protocol versioning lesson hidden inside eight bytes. Schema presence is not semantic activation. A parser can expose mh_id=0 and priority=255; a dashboard can display them; neither event proves that header compensation or priority-aware forwarding was negotiated or implemented.

Automation must bind interpretation to the active contract. If it treats every populated priority byte as a QoS order, it can assign scheduling authority to a value the receiver is required to ignore. If it treats mh_id as recoverability evidence without the extension, it converts a dormant field into a fictitious control.

The tile number came with its own invalidation bit

The 16-bit tile number looks even more concrete. A number invites grouping: count losses by tile, map fragments to regions, blame one tile for a visible defect. RFC 5371 puts a one-bit gate in front of that temptation.

When T=0, the tile number is valid. When T=1, it is invalid and the receiver must ignore it. The sender must invalidate the field when the payload contains only a main header, because no tile-part bitstream is present. It must also invalidate it when the payload combines multiple tile-parts, because one number cannot describe all of them.

The byte positions remain occupied in either case. A capture may show zero or some residual value in the tile-number field while T=1. The value is not an ambiguous tile. It is outside the field's authority.

Good observability stores the validity bit with the value and prevents invalid values from entering aggregates. Weak observability strips the gate, indexes the number and later presents a false distribution with unwarranted precision.

This pattern extends beyond JPEG 2000. Protocols frequently carry sentinel flags, masks or negotiated capabilities that control the interpretation of adjacent fields. Data pipelines that flatten the message into independent columns often preserve every value and destroy the conditions under which those values mean anything.

One marker ended one session's contribution

RFC 5371 uses the RTP marker bit for the last RTP packet of a video frame. In a single session, that boundary is useful: it identifies the final packet sent for that frame in that session.

Layered delivery complicates the sentence. When a frame is sent through multiple RTP sessions, the marker is set on the last packet of the frame in each session. Three sessions can therefore produce three terminal markers for one scalable frame.

The first marker seen is not necessarily the end of the whole delivery. It may close a base layer while an enhancement layer is still in flight, or close an enhancement session whose base material was lost. Even receipt of every expected session marker does not prove there were no gaps inside those sessions.

The marker is an emission boundary as observed through a transport flow. Completion needs a manifest: which sessions and layers were part of this frame, which terminal marker was received from each, which byte intervals arrived, and which decoding policy defines a usable result.

That last question is local. A base layer may be enough for one service objective and inadequate for another. Protocol completion and product acceptance should not be fused merely because both use the word “complete.”

Codestream order was preserved without promising delivery

RFC 5371 defines a packetization unit as a main header, a tile-part header or a JPEG 2000 packet. A sender may place an arbitrary number of units into one RTP packet, but it must preserve their codestream order.

If a unit is too large once the network and RTP headers are counted, the sender may fragment it. A packet carrying a fragment of that unit must not also carry the succeeding packetization unit. The rule protects the parser from a payload whose boundary cannot be recovered reliably.

Order is a construction constraint at the sender. It does not stop the network from losing or reordering RTP packets. Sequence numbers help observe transport order; fragment offsets help recover codestream placement; unit boundaries protect parsing. None of the three is a delivery receipt.

This separation lets an investigator ask better questions. Did the sender preserve codestream order? Did the network deliver the sequence? Did the receiver place fragments by offset? Did it identify complete units? Did the decoder admit the resulting structure? A single “stream valid” boolean cannot answer where the failure occurred.

The informative recommendation to begin payloads with Start of Packet markers and end with End of Packet Header markers follows the same logic. Aligning transport and codec boundaries can make failures easier to contain. It does not guarantee that senders adopted the recommendation or that loss recovery succeeded.

SDP described an envelope, not a reservation

The video/jpeg2000 media registration makes clock rate and sampling required. It allows RGB, several YCbCr layouts, grayscale and registered extensions. It makes interlace, width and height optional, with width and height required to appear together when either is present.

The dimensions are maximum values, and their syntax extends to 4,294,967,295. That range is a statement about the field, not about memory committed by a receiver. A compliant negotiation can name an envelope that a particular decoder cannot or will not allocate in the observed operating state.

The clock has a similar boundary. Implementations must support 90 kHz and may support other rates. A sender preferring a non-90-kHz rate should also offer a 90-kHz alternative under another dynamic payload type. Offer/answer can select one declared option; it does not prove that subsequent timestamps are correct, that the receiver's clock is stable or that rendered timing met a service objective.

When interlace is absent, the payload must be progressive and tp=0. When interlace is present, tp identifies odd and even fields, and the header height describes half the displayed image. Receiving one field cannot prove that its partner arrived or that a deinterlacer produced the intended frame.

Negotiation evidence belongs before packet evidence in the chain. It constrains how packets should be read. It does not replace observation of how they were actually formed or processed.

Cryptographic integrity stopped before codec truth

The security section separates confidentiality, integrity and source authentication. It recommends a suitable mechanism capable of determining whether an RTP packet came from a member of the RTP session, while noting that the applicable mechanism depends on the application, transport and signalling protocol.

Those are important controls. Integrity can protect the fragment offset, validity bits and payload bytes against undetected change within the mechanism's assumptions. Source authentication can bind a packet to a session member. Confidentiality can restrict who reads the coded image.

None certifies that the authenticated member generated a conforming codestream, selected an honest offset, included every interval or stayed within the decoder's resource policy. A malicious or faulty member can sign a structurally impossible image. A protected missing packet remains missing.

Historical references such as SRTP, IPsec and TLS for RTP over TCP must also stay in chronology. They show the security landscape the document addressed in 2008. They are not a turnkey current configuration and do not prove what any named deployment uses.

The audit chain therefore needs a cryptographic receipt and a codec receipt. One identifies protected origin and integrity. The other records structural acceptance, resource decisions and output. Combining them into “secure media received” conceals which property was actually observed.

Congestion control was a measured obligation

RFC 5371 does not treat a QoS request as delivery. It tells receivers using an enhanced service to monitor packet loss and verify that the requested service is actually being provided. If not, they should assume best effort and behave accordingly.

For best-effort delivery, loss must be monitored against an acceptable condition related to a TCP flow on the same path. Adaptation can reduce transmission rate, reduce subscribed layers or leave the session when loss is too high.

This matters to the fragment thesis because a gap has several possible causes. It may reflect random loss, congestion-responsive layer withdrawal, a receiver subscription choice, capture position or sender failure. The absolute offset reveals where material is absent. It does not attribute why.

An incident record should preserve the adaptation decision with the interval map. Otherwise an intentional layer reduction can be misclassified as transport loss, or congestion loss can be laundered into an intentional scalability policy.

Priority cannot repair the evidence. In baseline RFC 5371 it is ignored. Under RFC 5372 it may express ordering importance, but importance still does not prove that a network scheduler acted on it or that a receiver obtained the data.

The later payload answered a different latency question

RFC 9828 defines a later JPEG 2000 payload for sub-codestream latency. It distinguishes main and body packets, adds resynchronization and timing signals, and supports sending portions before the complete codestream has been encoded under specified progression constraints.

That work is relevant context, not a retroactive reinterpretation of RFC 5371. The existing BTW RFC 9828 Article asks whether early packet departure proves end-to-end latency, restoration and display. This Article asks a prior reconstruction question: what does an exact position prove when the surrounding bytes and governing header may be absent?

The two questions can coexist. A later payload can reduce encode-before-send waiting and provide richer recovery aids. It still needs received intervals, decoder state and display evidence. The older payload can place fragments deterministically without claiming low latency. Neither turns a sender-side field into a receiver-side outcome.

Keeping the theses separate is part of editorial integrity. “JPEG 2000 RTP” is a family label, not permission to merge the evidence contracts of RFC 5371, RFC 5372 and RFC 9828.

The minimum useful record is small but relational

Lu Heng's Minimum Initial Specification provides a useful disclosed lens. The shared contract does not need to dictate every decoder or service policy. It does need to preserve the facts that future local decisions cannot reconstruct after the packet is gone.

For RFC 5371, that minimum is relational: negotiated payload type and parameters; frame and session identity; RTP sequence, timestamp and marker; payload flags; valid or invalid tile scope; byte offset and length; received interval; packetization-unit boundary; extension mode; and the receiver's decode result.

Storing each field independently is insufficient. The tile number depends on T. Priority and mh_id depend on the baseline or RFC 5372 contract. A marker depends on the session set. An offset depends on the frame origin. A decode result depends on the complete byte and parameter set.

Reality Layers sharpens the stop rule. The symbol 2810 is a coordinate. The observed bytes are a transport fact. A contiguous codestream is a reconstructed object. Parser acceptance is a software result. A displayed frame is a user-facing event. The legitimacy of the article comes from refusing to promote one layer into another without evidence.

RFC 5371's achievement was not that it proved a picture arrived. It made the path toward that proof inspectable. A mature evidence system should honor the same modesty.