Summary

  • RFC 2029 placed an eight-byte CellB header at the start of every RTP payload: two 16-bit cell coordinates for the packet’s first 4×4 block, followed by the image width and height in pixels.
  • It also required every multi-byte CellB code to stay inside one packet. A receiver that lost a packet could therefore begin a later intact packet on a code boundary and at a declared location instead of inheriting a partial code from the missing bytes.
  • The mechanism localised damage; it did not reconstruct loss. Coordinates, dimensions, one timestamp per frame and the final-packet Marker cannot by themselves prove that earlier cells arrived, quantisation tables agree, decoding succeeded, the frame is continuous or a viewer saw acceptable video.

Packet loss creates two different absences. The obvious one is content: bytes that were sent but never arrived. The subtler one is context. If a receiver does not know where the next bytes belong or whether they begin in the middle of an instruction, one missing packet can make later data unintelligible too.

RFC 2029, published in October 1996 for carrying Sun’s CellB video over RTP, addressed that second absence with eight repeated bytes. It did not promise to recover the lost picture. It made the next surviving part of the picture easier to locate and parse.

A packet carried its own place on the canvas

At the beginning of every CellB RTP payload, RFC 2029 put four 16-bit unsigned integers in network byte order. The first pair recorded the X and Y location of the packet’s first cell. The second pair recorded the width and height of the image.

The units matter. X and Y were cell coordinates, not pixel coordinates. Each CellB cell described a 4×4 block of pixels. Width and height, by contrast, were expressed in pixels. A packet could therefore say, in effect: begin interpreting my compressed data at this block on a canvas of this size.

Image size could change only between frames, yet the format repeated width and height in every packet. That repetition looks inefficient if all packets arrive. Under loss, it removes a dependency: a later packet need not recover the dimensions from an earlier packet that may be missing.

This is a spatial claim, not a spatial proof. The header does not contain a map of every cell that should have preceded it. It does not attest that its coordinates are truthful, that no region overlaps, or that the payload will reach the bottom-right edge of the declared image. It gives the decoder an address at which to continue; it does not issue a receipt for the rest of the canvas.

The next packet did not begin with half an instruction

CellB’s stream mixed code lengths. An ordinary cell code was four bytes and described one 4×4 cell. A one-byte skip code told the decoder to pass over between one and 32 cells. Two other one-byte instructions could announce a new luminance or chrominance quantisation table, each followed by 512 bytes of table data.

RFC 2029 allowed an implementer to choose any packet size up to a full frame, but imposed one decisive rule: every multi-byte code had to be wholly contained within a packet. A packet boundary could not cut through an ordinary four-byte cell code or strand part of a table update in the next packet.

The location header and the containment rule solved different parts of the same recovery problem. The header anchored the first cell in space. Code containment anchored the payload in syntax. If one packet vanished, the next intact packet did not arrive as the unknown second half of an instruction whose beginning was gone.

That is local resynchronisation, not lost-data recovery. Nothing in RFC 2029’s payload format adds retransmission, forward-error correction, redundant cells or a reconstruction recipe. The missing packet remains missing. The value of the design is that the loss need not automatically corrupt the parsing of every packet that follows.

A frame label was not a frame inventory

RFC 2029 used the RTP clock at 90 kHz. All packets carrying one frame shared the same RTP timestamp, and the RTP Marker bit identified the end of the frame. Those fields supplied a temporal boundary around the spatially addressed packets.

But a shared timestamp says that packets are assigned to the same frame; it does not enumerate the frame’s members. A Marker says that the sender declared one packet to be last; it does not certify that every packet before it arrived. RTP sequence numbers can reveal a gap in the transmitted packet sequence and help restore order, but RTP itself explicitly does not guarantee delivery, timely delivery, in-order arrival or quality of service.

The distinction is operationally important. A receiver may possess a packet with a valid-looking coordinate, the expected frame timestamp and the Marker set, while still missing a packet from the middle of that frame. The surviving metadata tells the receiver where and when the packet claims to belong. It does not turn the claim into evidence of completeness.

The quantisation tables expose the deepest state boundary

CellB cell codes did not carry literal colour values for every pixel. Their U/V and Y/Y fields indexed chrominance and luminance vector tables. The meaning of a later index therefore depended on which tables the receiver currently held.

RFC 2029 described instructions for replacing either table with 512 new bytes. It noted that its sample encoder and decoder did not implement the feature, while future CellB codecs might. Because the update is a multi-byte code, the containment rule prevents a table from being divided across packets. That protects the update’s syntax when its packet arrives intact.

It does not protect the update from the loss of the entire packet. If a packet carrying a new table disappears, a later packet can still arrive on a clean code boundary, advertise a precise cell coordinate and use the correct frame timestamp. The receiver may nevertheless interpret its indices through an older table. The pixel positions can be known while the pixel values are wrong.

This is not an accident report in the RFC; it is the evidence limit implied by two parts of its design. Position metadata can break a spatial dependency. Packet-contained codes can break a byte-boundary dependency. Neither establishes that all earlier state transitions were received.

Four layers of evidence should remain separate

RFC 2029 becomes clearer when its signals are read as a short hierarchy.

First, the RTP sequence number can indicate transport order and missing packets. Second, the CellB header declares spatial placement and image size. Third, code containment lets an intact packet begin at a syntactically valid boundary. Fourth, the timestamp and Marker declare frame membership and its last packet.

Content integrity lies beyond all four. So do successful decoding, coherent rendering and human viewing. To support those claims, an observer would need additional evidence: captured payloads, validated coordinate and coverage rules, the applicable quantisation-table state, decoder results, render output, playout timing and—if the claim concerns experience—measurement at the viewer.

The IANA registry still records CelB as fixed RTP payload type 25 with a 90 kHz clock and a reference to RFC 2029. That is durable evidence of an assigned parameter. It is not evidence that CelB is widely implemented or carried on today’s networks. RFC 2029 remains listed as a Proposed Standard, but status, registration, deployment and performance are four different facts.

The historical achievement was narrower and more useful than a promise of resilience without limits. RFC 2029 gave each surviving packet enough local context to re-enter a compressed picture at a declared coordinate and a valid code boundary. It contained the blast radius of missing bytes. It also made the boundary of the evidence visible: knowing where the next block belongs is not the same as knowing that the picture survived.

Sources