From 42e5f5ad1e2f84e6f9b5895e76d91f303711ff4f Mon Sep 17 00:00:00 2001 From: enricobuehler Date: Sat, 25 Jul 2026 01:03:57 +0200 Subject: [PATCH] fix(encode/windows): two dead items the new lint leg exposed in the shipped combo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- crates/pf-encode/src/enc/windows/ffmpeg_win.rs | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/crates/pf-encode/src/enc/windows/ffmpeg_win.rs b/crates/pf-encode/src/enc/windows/ffmpeg_win.rs index d82d600f..7af4ccb3 100644 --- a/crates/pf-encode/src/enc/windows/ffmpeg_win.rs +++ b/crates/pf-encode/src/enc/windows/ffmpeg_win.rs @@ -95,6 +95,13 @@ struct AVD3D11VAFramesContext { /// AMD AMF vs Intel QSV — the two libavcodec vendor backends this module covers. #[derive(Clone, Copy, Debug, PartialEq, Eq)] pub enum WinVendor { + /// Benchmark-only, as the module header explains: native AMF replaced the libavcodec AMF path + /// in production, and the only remaining CONSTRUCTOR is the `#[cfg(feature = "amf-qsv")]` + /// latency A/B in `amf.rs` — the measurement that justifies the native backend existing. That + /// is test code, so the *lib* target constructs it nowhere and `dead_code` fires on it (the + /// crate root no longer blanket-allows that). Kept deliberately rather than deleted; the arms + /// below are what the benchmark drives. + #[allow(dead_code)] Amf, Qsv, } @@ -277,6 +284,11 @@ pub fn probe_can_encode_444(_vendor: WinVendor, _codec: Codec) -> bool { false } +/// Gated to the builds that can actually reach it: `lib.rs`'s only caller sits under +/// `cfg(all(not(feature = "qsv"), feature = "amf-qsv"))`, because with the native VPL backend +/// compiled in it is `qsv::probe_can_encode` that answers. So in the SHIPPED Windows combo +/// (`nvenc,amf-qsv,qsv`) this function has no caller at all. +#[cfg(not(feature = "qsv"))] pub fn probe_can_encode(vendor: WinVendor, codec: Codec) -> bool { // Deliberately NOT pinned to the selected render adapter (unlike `nvenc::probe_can_encode_444`): // the system-input probe passes no hwdevice, and the AMF/QSV runtimes only ever bind their own