Summary

  • RFC 9627 defines a targeted RTCP command for asking a scalable-video encoder to create a layer refresh point, avoiding the broader reset of a Full Intra Request when only selected layers need renewal.
  • Its source and target SSRCs, payload type, target/current layer tuple and sequence number describe command identity. They do not acknowledge acceptance, codec action, packet delivery, decoder transition or visible improvement.
  • A defensible receipt joins negotiation, authorization, validation, congestion-aware scheduling, codec-specific refresh emission, receiver recognition, decoder state and rendered outcome.

The same sequence number appeared in three feedback packets. The sender log called all three valid. The receiver never moved above its base layer.

Nothing in that record is necessarily contradictory. RFC 9627 deliberately keeps the sequence number unchanged when a requester repeats the same Layer Refresh Request. A valid command can be lost, admitted but delayed by congestion, translated into the wrong codec action, damaged in transit or received without completing the dependencies required for an upgrade. Three copies of one instruction are not three completed refreshes.

This is the useful discipline inside LRR. It gives scalable video a smaller control instrument than “reset everything.” It does not collapse request, execution and effect into one green state.

A refresh point changes what can be decoded

A layer refresh point is a boundary after which a decoder that previously handled only some, or none, of a stream's layers can handle more of them. For a spatial enhancement layer, the refreshing picture refers to lower layers of the current picture rather than older pictures in its own layer. The encoder must also stop using those older same-layer pictures as future references.

Other layers can retain their history. That is the material difference from a Full Intra Request. FIR seeks a decoder refresh point for the whole layered bitstream under the clarification in RFC 8082. LRR can limit the work to the layer transition the receiver actually wants.

Temporal refresh has a parallel rule. The refreshed temporal layer must be nested on lower temporal layers rather than its own earlier pictures. Some temporal structures are already nested in ordinary operation. In those streams, a receiver can start the higher layer without requesting a special point, so a temporal LRR would add traffic without adding eligibility.

That definition matters operationally. A refresh is not merely an intra-coded picture somewhere in the stream. It is a codec- and layer-specific change in the reference structure that makes a stated upgrade decodable.

The tuple is a desired transition, not a result

LRR is an RTCP Payload-Specific Feedback message, registered as FMT=10. Its Feedback Control Information contains one or more entries, each directed to a media sender SSRC. The common feedback header names the command source; the ordinary common “media source” field is zero because each FCI entry carries its own target.

The target tuple combines TTID, the temporal layer, and TLID, the spatial or quality layer. The payload-type field supplies the codec mapping that gives those numbers meaning. A tuple copied without the negotiated payload map is therefore incomplete evidence.

The C flag changes the scope. With C=0, the requester asks for every layer through the target. With C=1, CTID and CLID state the highest layer it currently decodes and exclude refresh at or below that point. The target cannot be lower than the current layer on either axis, and at least one axis must rise. A receiver of an invalid downgrade or no-op tuple must discard it.

Those checks prove that the command is internally admissible. They do not prove that the request source is authorized by local policy, that the payload type matches the stream now being sent, or that the encoder has resources to act. RFC 9627 separately requires the media sender to validate payload types and layer indices against the current stream.

This is where a concise protocol field can acquire too much authority in a dashboard. TTID/TLID answer “what upgrade was requested?” CTID/CLID answer “what the requester reported it could currently decode.” Neither pair independently observes the decoder after the command.

A sequence number tracks the command, not completion

The eight-bit sequence-number space belongs to one pairing of command-source SSRC and command-target SSRC. A new command increments the value modulo 256. A repetition preserves it. The initial value is arbitrary.

That design follows the FIR reliability model in RFC 5104. A requester can repeat an outstanding command under RTCP timing rules. It stops after recognizing a complete decoder refresh point, or even an attempted refresh point damaged by packet loss. A later need becomes a new command with a new number.

The number is therefore excellent evidence for deduplicating intent. It distinguishes “same request still outstanding” from “new requested transition,” within the source-target context. It is not a sender acknowledgement. It contains no acceptance bit, execution timestamp, encoded-frame identifier or decoder result.

Wraparound makes context retention essential. Sequence 7 today can be unrelated to sequence 7 after 256 new commands. Without the source-target pair, session, time and tuple, the bare value is not a durable identity.

“As soon as possible” still has a congestion governor

After receiving a valid LRR, the encoder must send a refresh point as soon as possible. The next sentence prevents a simplistic service-level promise: the sender must respect congestion-control bandwidth limits. Refresh frames are often larger than ordinary frames, so the compliant response may be delayed.

That is not a loophole. It is an allocation of authority. The feedback path may request a more decodable stream; congestion control decides when the forward path can afford the extra work. An implementation that labels the command complete at admission hides the only state that explains the delay.

The useful states are separate: received, rejected, admitted, pending for bandwidth, scheduled, emitted, observed, decoded and rendered. A deadline can expire in any one of them. “Pending for congestion” can be correct protocol behavior and still be an unacceptable application outcome; both facts need recording.

LRR also has a strict purpose boundary. It must not be sent as a reaction to packet loss or corruption. RFC 4585 defines Picture Loss Indication for a broken prediction chain, and RFC 9627 recommends PLI for that case. LRR belongs to an explicit behavior change, such as starting a layer the receiver had deliberately discarded. Using one signal for both meanings makes retries and root-cause analysis ambiguous.

Every codec closes the loop differently

The command format is generic; satisfaction is not. H.264 SVC maps layer indices to temporal, dependency and quality identifiers. Completing a spatial refresh can require the appropriate indication on every relevant layer in decode order. An aggregate PACSI indication can be insufficient when it spans NAL units from multiple layers.

VP8 offers temporal scalability in the cited payload format. Its Y bit can identify a refresh point, but that bit switches all layers, not only the requested one. A valid LRR response can therefore carry more work than the abstract command seems to request.

H.265 uses temporal-nesting flags and NAL-unit types. A refresh can complete at once, incrementally through several temporal layers, or through an IRAP picture. A monitor that waits only for one universal “keyframe” signature will misclassify valid and invalid outcomes.

RFC 9628 gives VP9 its TID/SID mapping and recommends carrying layer and reference information in response packets so decoders and selective-forwarding middleboxes can derive the dependency chain. That recommendation exposes the real closure condition: one must show why the emitted pictures no longer depend on content unavailable to the upgrading receiver.

RFC 9626 deliberately aligns its frame-marking TID/LID syntax with LRR. That adjacency helps observation, but it does not prove causation. A correct mark can identify a refresh-like frame that would have occurred anyway. An authenticated mark remains the sender's statement about a frame, not proof that this command caused it or that the decoder used it.

Sources