docs(client/video): name the upstream rav1d issue next to the workaround
windows / build (aarch64-pc-windows-msvc) (pull_request) Successful in 1m13s
apple / swift (pull_request) Successful in 1m30s
apple / screenshots (pull_request) Skipped
ci / rust-arm64 (pull_request) Successful in 1m53s
ci / bun-nix (pull_request) Successful in 25s
ci / docs-site (pull_request) Successful in 1m23s
windows / build (x86_64-pc-windows-msvc) (pull_request) Successful in 2m36s
ci / web (pull_request) Successful in 2m22s
android / android (pull_request) Successful in 3m41s
ci / rust (pull_request) Successful in 6m21s

memorysafety/rav1d#1497, filed with the one-line fix and a reproducer that
needs no capture — any AV1 stream with one temporal unit removed. Written down
where the setting is, because the next person to read `av1_settings` and
wonder whether the floor is still needed should be able to check rather than
re-derive it.
This commit is contained in:
2026-08-07 17:48:54 +02:00
parent eb9203b115
commit bca63cd9ff
@@ -532,6 +532,12 @@ fn av1_settings() -> Dav1dSettings {
//
// The frame of latency this would normally cost is bought back in `decode`, which
// drains the in-flight frame in the same call instead of pipelining it — see there.
//
// Reported upstream as memorysafety/rav1d#1497, with the one-line fix
// (`is_some_and` for the `unwrap`) and a reproducer that needs no capture: any AV1
// stream with one temporal unit removed from the middle. If a release ever carries
// that fix, THIS floor is still the right default — it is what makes a decoder error
// an error — but the `bail!` in `Av1Software::new` could then relax.
settings.max_frame_delay = AV1_MIN_FRAME_CONTEXTS;
// `n_threads` drives the INTRA-frame tile/row workers, which add no delay, and now also
// floors `n_fc`. Capped at 8 — this is the rung reached because the GPU already failed,