enricobuehlerandClaude Opus 4.8 fecbec2daf fix(encode): make LTR-RFI loss recovery sound under sustained loss ...

Field report (lid-closed Intel laptop, ~6-19% sustained loss): the stream
never healed — permanent macroblock soup. Three stacked bugs:

- QSV answered RFI with PreferredRefList only, a reorder HINT per the VPL
  spec — the recovery frame could keep predicting from tainted short-term
  refs. Now rejects every other DPB candidate (RejectedRefList) and caps
  L0 at one active entry (AVC/HEVC), matching AMF's hard
  ForceLTRReferenceBitfield / NVENC invalidation semantics.
- Neither QSV nor AMF taint-swept LTR slots across losses: a slot marked
  inside the client's corrupt window became the "known-good" anchor of the
  NEXT loss, propagating corruption through every recovery. Both now drop
  slots at-or-after the loss start before picking an anchor, and guard a
  queued force whose slot the sweep emptied (no false recovery_anchor tag).
- The native plane re-anchored the FULL IDR cooldown on every successful
  RFI, so under sustained loss the client's escalating keyframe requests
  were coalesced away indefinitely (field log: dozens swallowed, one IDR
  per ~8 s). RFI now anchors a 300 ms echo window with a 2-swallow budget
  per loss episode; a client still asking past that gets its IDR.

Live-validated on Arc (qsv feature): 6/6 including the new
qsv_live_ltr_rfi_taint_sweep_declines (a loss covering every live mark
declines the RFI and falls back to IDR recovery).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-19 17:53:48 +02:00

..

src

fix(encode): make LTR-RFI loss recovery sound under sustained loss

2026-07-19 17:53:48 +02:00

Cargo.toml

perf(pyrowave): elevated GPU scheduling + global-priority encode queue

2026-07-19 01:02:01 +02:00