The Layer Refresh Request (LRR) RTCP Feedback Message
Extracted elements (27)
LRR is designed to allow selective layer refresh without refreshing the entire stream (as FIR would require), minimizing coding overhead to only those parts of the stream that actually need refreshing at any given time.
The LRR retransmission, reliability, and multipoint conference model follows the FIR model (RFC 5104 Section 3.5.1) to leverage established mechanisms for those concerns.
For H.264 SVC, if the temporal_id_nesting flag is set in the Scalability Information SEI, receivers SHOULD NOT send temporal LRR messages because every frame is implicitly a temporal layer refresh point.
For H.265, if vps_temporal_id_nesting_flag or sps_temporal_id_nesting_flag is set, receivers SHOULD NOT send temporal LRR messages as every frame is implicitly a temporal layer refresh point.
For MRST and MRMT scalability transmission mechanisms, the 'media source' SSRC in the LRR FCI is set to the SSRC of the RTP stream containing the layer indicated by the Current Layer Index (if C=1) or the base encoded stream (if C=0); for MRMT the LRR is sent on the RTP session carrying that stream.
The TTID, TLID, CTID, and CLID field syntax matches by design the TID and LID fields in the Video Frame Marking RTP Header Extension (RFC 9626), enabling consistent layer identification across mechanisms.
VP8's Y bit implies a layer switch of all layers rather than just the layer in which it is sent, meaning not every layer switch point can be identified; this can cause some transmission inefficiency when LRR is used with VP8.
A receiver receiving an LRR feedback packet where the C bit is set but TTID is less than CTID or TLID is less than CLID MUST discard the request.
An LRR MUST NOT be sent as a reaction to picture losses due to packet loss or corruption; a PLI (Picture Loss Indication) is RECOMMENDED instead. LRR SHOULD be used only when there is an explicit change in decoder behavior.
For MRST and MRMT mechanisms, on receipt of an LRR the sender MUST refresh all the layers requested in the stream, simultaneously in decode order.
For VP8 streams, on receipt of an LRR a sender that supports LRRs MUST encode the stream so it can set the Y bit in a packet whose temporal layer is at or below the target layer index.
Media senders receiving LRR feedback packets MUST validate that the payload types and layer indices are valid for the stream currently being sent, and discard the requests if not.
New RTP packetization specifications for scalable codecs SHOULD define how the temporal and layer ID fields of LRR are to be used, and if the payload also uses the Video Frame Marking header extension (RFC 9626), the syntax MUST be defined in the same manner as the TID and LID fields in that header.
The FCI field of an LRR message MUST contain one or more LRR entries, and the LRR feedback message length MUST be set to 2+3*N 32-bit words, where N is the number of FCI entries.
The sequence number SHALL be increased by 1 for each new LRR command (modulo 256); a retransmission SHALL NOT increase the sequence number.
The 'SSRC of media source' field in the common RTCP feedback header SHALL be set to zero; the media sender SSRCs to which LRR applies are carried in the FCI entries.
Upon reception of an LRR, the encoder MUST send a decoder refresh point as soon as possible, while respecting bandwidth limits imposed by congestion control.
When the C bit is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be less than CLID; at least one of TTID or TLID MUST be greater than CTID or CLID respectively, ensuring the target layer is an upgrade from the current layer.
A 'layer refresh point' is defined as a point after which a decoder that could previously decode only some layers can decode a greater number; for spatial layers this requires encoding that references only lower-layer subpictures of the current picture and no prior pictures of that layer.
The LRR is identified by RTCP PT=PSFB and FMT=10. The C flag indicates whether Current Temporal-layer ID (CTID) and Current Layer ID (CLID) are present; if C=0, the sender requests refresh of all layers up to and including the target layer.
The Payload Type field (7 bits) in the LRR FCI carries the RTP payload type for which the LRR is being requested, providing context for interpreting the TTID and TLID layer index fields.
RFC 9627 registers 'LRR' (Layer Refresh Request Command) with value 10 in the IANA 'FMT Values for PSFB Payload Types' registry under 'Real-Time Transport Protocol (RTP) Parameters'.
All security considerations of FIR feedback packets (RFC 5104) apply to LRR. Additionally, senders MUST validate that payload types and layer indices in received LRR packets are valid for the stream being sent and discard invalid requests, preventing malicious or erroneous requests from triggering unnecessary refresh points.
Each LRR FCI entry is 96 bits (3 32-bit words): SSRC (32 bits), then Seq nr. (8 bits) / C flag (1 bit) / Payload Type (7 bits) / Reserved (16 bits), then RES (5 bits) / TTID (3 bits) / TLID (8 bits) / RES (5 bits) / CTID (3 bits) / CLID (8 bits).
H.264 SVC layer index fields: RES (5 bits) | TID (3 bits) | R (1 bit) | DID (3 bits) | QID (4 bits), where R and RES MUST be set to zero on transmission and ignored on reception.
H.265 layer index fields: RES (5 bits) | TID (3 bits) | RES (2 bits) | layer ID (6 bits); RES fields MUST be set to zero on transmission and ignored on reception.
VP8 layer index field: RES (5 bits) | TID (3 bits) | RES (8 bits); RES fields MUST be set to zero on transmission and ignored on reception. VP8 does not support spatial scalability so TLID/CLID are unused.