Summary

  • The AVTCORE frame-acknowledgement draft lets a receiver report status 1 before decode has completed, provided it guarantees that it will attempt the decode. This is a deliberate latency trade, not a completed-decode receipt.
  • Recovery remains a chain of two endpoints and several later actions: the receiver must retain meaningful state, the sender must still retain a usable reference, and the next encoded unit must still be emitted, delivered, decoded and rendered.

The receiver had the frame bytes. Its scheduler had accepted the decode job. Waiting for the decoder to finish would add a round of uncertainty to an interactive video session, so the receiver returned a positive status immediately. The sender treated the bit as proof that a durable reference now existed at the far end and began a longer dependency chain from it.

The decode then failed.

That sequence is not a violation of the proposed protocol. It is the reason an operator has to read the bit as the draft defines it rather than as the word “acknowledgement” sounds. In revision 01 of RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement, a status of one means that a frame was received and either has been decoded or will be decoded. The receiver may send the positive status before completion if it guarantees an attempt. If that promised decode later fails, the receiver must request a keyframe, even when the failed unit belongs to a droppable layer.

The mechanism therefore improves coordination by sacrificing a little finality. It gives the sender earlier knowledge about the receiver's intended codec state. It does not collapse intention, execution and result into one fact.

The document itself is also an unfinished claim. Revision 01 is an active AVTCORE working-group Internet-Draft dated 6 July 2026 and expiring 7 January 2027. It is intended to be Informational. Datatracker records I-D Exists; there is no shepherd, responsible Area Director, IESG evaluation, RFC number or completed IANA assignment. The RTCP feedback format uses payload type 205 and a feedback-message type still marked TBD, with 12 suggested. None of those documentary facts proves implementation, interoperability or deployment.

A frame is not necessarily a displayed picture

The proposed Frame ID is a 16-bit serial number. It increments for every identified frame in sending order and wraps to zero. The RTP header extension should appear on the last packet of a video frame and must not appear more than once on that frame. But “frame” has a codec-state meaning here. It is any decodable bitstream unit that updates reference state used by later units. Usually that is a full frame; it may also be a no-show frame, an independently decodable tile or a slice.

That definition matters to evidence design. A positive status does not necessarily say that a picture appeared. It may concern a state-changing unit that is never shown. Even for a displayable picture, receipt and a promised decode do not establish completed decode, compositor admission, presentation time or human perception.

The extension carries two feedback-request bits. 00 identifies the frame without requesting feedback. 01 couples the current Frame ID to an implicit one-frame request. 10 carries an independent Feedback Start and Feedback Length, allowing a requested range unrelated to the current frame. 11 is reserved. This separates media chronology from the control range being queried.

The response is an RTCP transport-layer feedback message. It carries a resynchronisation flag, a start Frame ID, an eight-bit length and a one-bit status vector. A zero bit is even less specific than a one: it can mean not received, not decoded, or not expected to be decoded. A dashboard that labels every zero “packet loss” is inventing a cause the wire format did not assert.

The positive bit has a time and a speaker

The strongest safe statement is precise: for one sender/receiver SSRC pair and one Frame-ID epoch, the receiver reported at the feedback transmission time that an identified unit had been received and was decoded or committed to a decode attempt. That sentence retains the speaker, scope, time and alternative embedded in the specification.

A production record needs more. It should say whether decode was already complete or only promised, when completion later occurred, whether it succeeded, and whether a subsequent keyframe request was generated after failure. It should preserve the sender and receiver SSRCs, because the sequence and feedback state are unique to that pair. If either SSRC changes, the sequence restarts and prior state is discarded. Joining equal numeric Frame IDs across that reset manufactures continuity.

It should also retain the requested range, response range and status-window bounds. The receiver holds only a contiguous sliding window, 255 Frame IDs by default and 1–32767 when negotiated. Old entries leave in FIFO order. If a requested interval partly overlaps what remains, the receiver shifts the response start forward. If nothing requested remains, it returns length zero with the requested start. Those replies describe state retention, not whether the omitted frames were decoded or displayed.

The finite window is not a defect. It bounds memory and prevents unbounded receiver state. It means that historical certainty cannot be inferred after the evidence has been intentionally retired.

Feedback is constructed when it is sent

RTCP timing and bandwidth rules can defer a response. The status window continues moving while the message waits. The draft requires the receiver to construct the response from its window at send time, not from a frozen snapshot at request arrival. A request for frames 1 through 4 can legitimately produce statuses only for 3 and 4 if the window has advanced to 3 through 6 by transmission time.

A newer request can also supersede an older pending one. The receiver should discard the older request and answer the latest instead of building a backlog. Operationally, request receipt is not a durable promise that the original interval will receive its own answer.

That is why a meaningful trace needs multiple clocks: RTP packet arrival, frame sending order, feedback-request arrival, RTCP response transmission, decode completion and render. Sorting everything by one collection timestamp can convert correct protocol behaviour into a false outage—or hide a real one.

Resynchronisation is a two-ended decision

The R flag asks for resynchronisation. The receiver can name its latest successfully decoded Frame ID and, as space permits, report status through its latest received ID. That makes a known-good receiver reference available to the sender.

It does not make the reference available in the encoder. The sender must verify that the corresponding frame remains in its own reference buffer. It should encode the next unit from that reference, or another reference known to exist at the receiver. If no suitable reference remains sender-side, it should encode a keyframe.

There are therefore two independent retention facts: what the receiver decoded and still means by its report, and what the sender can still use. Only after the choice comes another execution chain: the recovery frame is encoded, packetised, sent, delivered, reconstructed, decoded and perhaps displayed. The initial acknowledgement proves none of those later outcomes.

The negotiated resync-timeout, from 1 to 65,535 milliseconds, is similarly bounded. It states a starvation threshold that can trigger a request. It is not a service-level promise that recovery finishes inside the same interval. The negotiated status-window-size limits outstanding state at the receiver; it does not guarantee matching capacity in the sender's reference buffer.

One SSRC can still carry independent chains

Simulcast and other structures may interleave independent dependency chains inside one SSRC. A later Frame ID decoded in one chain does not prove that an earlier frame from another chain was decoded. A single highest-acknowledged counter loses precisely the gap information the range/status design preserves.

Point-to-multipoint forwarding adds another boundary. An SFU or SFM may rewrite Frame IDs to keep each outgoing sequence contiguous. The draft says such a middlebox typically should not acknowledge a frame upstream until all active receivers have acknowledged it. “All active” is a denominator, not decoration. Without the receiver set and the translation lineage, one aggregate positive bit cannot establish which viewers were counted.

SDP declarations do not close these gaps. Advertising the header-extension URI and the RTCP feedback capability shows that endpoints negotiated a vocabulary. It does not prove that a request was sent, a response was retained, a decode completed or a session recovered.

The minimum evidence envelope

Heng Lu's reality-layer discipline suggests keeping the coordination symbol separate from executable state and observed outcome. A Frame ID and a status vector are symbolic claims. The receiver window and encoder reference buffer are live internal state. Packet delivery, successful decode, presentation and viewer experience are observations at later boundaries.

A Minimum Initial Specification for operational use does not need to standardise every codec. It needs the sender/receiver SSRC pair, Frame-ID epoch, media Frame ID, request type and interval, request-receipt time, response-send time, retained-window bounds, exact status semantics, resync flag, receiver reference, sender reference availability and the subsequent action. Decode and render observations should be separate fields, never silently filled from the bit.

Running-Code Primacy supplies the acceptance tests. Delay RTCP until the window rolls. Force a decode failure after an early positive report. Wrap the 16-bit number. Replace an SSRC. Interleave simulcast chains. Recover an old request after a newer one. Evict the receiver's chosen reference at the sender. Fan one stream through an SFU whose receiver set changes. The output should preserve uncertainty and partial state rather than converge to a convenient green label.

The protocol's early acknowledgement is valuable precisely because it is allowed to get ahead of completed work. Operators should use it to make a better recovery decision, not to erase the remaining work. The disciplined conclusion is not that the bit is unreliable. It is that the bit is reliable only for the narrower promise it actually makes.

Sources