forked from unom/punktfunk
enricobuehlerandClaude Opus 5
42e5f5ad1e
09aa2db3 turned on `-p pf-encode --all-targets -D warnings` for Windows and removed
the crate-wide `allow(dead_code)`; together those surfaced two genuinely-dead items
in `nvenc,amf-qsv,qsv` — the combination the installer ships — and CI went red on my
own step.
- `WinVendor::Amf`: native AMF replaced the libavcodec AMF path in production, so
the only remaining CONSTRUCTOR is the `#[cfg(feature = "amf-qsv")]` latency A/B
in amf.rs — test code, so the lib target constructs it nowhere. The module
header already says this machinery is kept deliberately for that measurement, so
it gets a targeted `#[allow(dead_code)]` naming the reason rather than deletion.
- `probe_can_encode`: `lib.rs`'s only caller is under
`cfg(all(not(feature = "qsv"), feature = "amf-qsv"))`, because with the native
VPL backend compiled in `qsv::probe_can_encode` answers instead. Gated
`#[cfg(not(feature = "qsv"))]` to match its call site.
Both are real findings the blanket allow had been hiding; neither is a behaviour
change.
WHY THIS ESCAPED MY PRE-PUSH CHECKS, since that is the useful part: the Windows
runner I verify on has no FFmpeg dev tree, so `amf-qsv` could not build there and
`ffmpeg_win.rs` was compiled by NOTHING in my matrix — the same class of blind spot
this whole audit is about, reproduced by me. CI's own FFmpeg turns out to be cached
on that box at C:\Users\Public\ffmpeg, so the verification recipe now sets
FFMPEG_DIR and covers `nvenc,amf-qsv,qsv` (the CI command and my new step) plus
`amf-qsv` without `qsv` — the combo that still uses `probe_can_encode`. All three
clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>