6 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Fable 5	3f4ad08869	test(encode/ffmpeg_win): extract the decision logic and pin it with unit tests ... The QSV open-failure fallback (1,400 lines, 23 unsafe, 0 tests) follows the vaapi.rs treatment: the device-free decisions now live in named functions with their contracts pinned — the per-vendor zero-copy default matrix (AMF on-glass-validated on, QSV opt-in), the PUNKTFUNK_FFWIN_POLL_MS clamp-before-µs-conversion (the 27.7-hour-spin class), the readback routing table with its mid-stream depth-change guard, the swscale source map, the QSV display-remoting latency contract (async_depth=1/low_power=1/ look_ahead=0/forced_idr=1/scenario) and the AMF no-B-frames contract, and the per-vendor zero-copy pool bind flags. A probe smoke rides along #[ignore]d for the runner. No FFI plumbing chased; no behavior changes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 10:50:33 +02:00
enricobuehlerandClaude Opus 5	e680096c6a	perf(encode): stop re-reading the environment on every submit and poll ... `std::env::var` was on three per-frame paths. Measured on `.173` (Windows, 57 environment variables, 2M iterations): **121.9 ns** per call for the NVENC in-flight cap and **114.9 ns** per call for the ffmpeg poll spin, against **0.9 ns** once memoized. On Linux, 32 ns → 1.5 ns. ⚠ Those numbers deflate the filing, and that is worth recording: the audit ranked this as a hot-path defect, but ~120 ns/frame is ~0.003% of a frame budget. The fix is still right — it is free, and it takes a global environment lock off the encode thread — but nobody should schedule it ahead of anything on the strength of the "hot path" framing. The severity RANKING was also inverted, and the measurement confirms why. The site the audit called worst — `nvenc_cuda`'s backpressure loop condition — costs a default session nothing, because the condition short-circuits on `async_rt.is_some()` and the default session never engages the two-thread retrieve. The one that actually pays every frame is Windows `submit`, which consults `async_inflight_cap()` in BOTH arms of the ring-depth match, sync mode included, where the result is then thrown away. Windows `poll` is the second unconditional one, and the audit ranked it last. Memoized inside each helper rather than latched into a session field. Nothing in the workspace mutates these variables at runtime (enumerated: no `set_var` for either key anywhere in first-party code, and the Windows service's arbitrary-key `host.env` loader runs in the SCM supervisor, which re-execs the host as a child and never opens an encoder itself). A field would instead change WHEN the value is read — and the Windows `cap` composes the env with `input_ring_depth`, which `set_input_ring_depth` may change after open, so freezing that half would reintroduce the in-place-overwrite bug the ring term exists to prevent. Two deliberate behaviour changes ride along on `PUNKTFUNK_FFWIN_POLL_MS`, so "behaviour-preserving" describes the memoization only, not this whole commit: - **A 1000 ms ceiling.** The reachable hazard was never the overflow — that needed `ms >= 1.8e16` — it was a slipped digit: `=100000000` was a 27.7-hour spin of the encode thread. - **`.trim()`, now on all three parsers.** An earlier draft applied the house rule (WP7.8) to one of the three, which left `PUNKTFUNK_NVENC_ASYNC=" 1 "` working while `PUNKTFUNK_NVENC_ASYNC_DEPTH=" 6 "` silently fell back to 4 — and memoization would have frozen that silent fallback for the process lifetime. Reachable: the Windows `host.env` loader trims around `=` before stripping quotes, so `=" 2 "` yields a value with inner spaces. ⚠ Correction to an earlier draft of this message, which asserted that the audit's `saturating_mul` proposal would relocate an overflow panic into release builds. That is FALSE and the code comment now says so: `Duration::from_micros(u64::MAX)` is ~1.8e13 seconds, six orders of magnitude below `Duration`'s ceiling, so `Instant + Duration` neither overflows nor panics (measured, with and without debug assertions). `saturating_mul` is still wrong, for a different reason — it sets a deadline ~584,000 years out on a spin that provably never produces the owed AU, i.e. it wedges the encode thread permanently. A hang, not a panic. WP6.1. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 17:55:59 +02:00
enricobuehlerandClaude Opus 5	42e5f5ad1e	fix(encode/windows): two dead items the new lint leg exposed in the shipped combo ... 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>	2026-07-25 01:04:04 +02:00
enricobuehlerandClaude Opus 5	6be174dc9c	fix(encode/windows): the encode bit depth must follow the pixels, not the negotiation ... All three Windows backends derived it the same wrong way — `bit_depth >= 10 || matches!(format, P010 | Rgb10a2)` at ffmpeg_win.rs:154, amf.rs:1275 and qsv.rs:777 — so the NEGOTIATED depth could force a 10-bit encoder over an 8-bit capture. That combination is not hypothetical. A client advertises 10-bit, the handshake negotiates bit_depth=10, and then enabling advanced colour on the IDD virtual display fails — at which point the capturer says exactly that and delivers 8-bit NV12 anyway ("10-bit HDR was negotiated but enabling advanced color on the virtual display FAILED — encoding 8-bit SDR"). Every vendor then lost the session, each in its own way: - native AMF and native QSV derived `expected = P010`, saw Nv12, and bail!'d at open; - the libavcodec path accepted the open, built a P010 encoder, and then failed EVERY submit forever, because its per-frame check recomputes the depth from the frame and never matches. reset() could not help: the rebuild re-derived the same wrong depth from the same stored bit_depth. The host burned MAX_ENCODER_RESETS and ended the session. The last one is the worst of the three because it IS the fallback: native QSV correctly refuses this input at open, and lib.rs then falls back to the ffmpeg path "for robustness" — which accepted it and died per frame instead. Since the duplication was the bug, the fix is one shared `ten_bit_input()` in codec.rs that all three call, and it follows the delivered pixels. That also keeps the stream HONEST rather than merely alive: the depth selects the colour signalling (BT.2020 PQ vs BT.709) and the staging surface format, so an 8-bit capture now produces an 8-bit stream that says it is SDR — which is what the capturer already reported it was sending. It warns when the negotiated depth is discarded. The negotiated depth stays an upper bound. The session LABEL may still claim HDR; that mismatch lives in the negotiation, not in the encoder, and is not addressed here. `is_10bit_format` keeps its (now format-only) definition and is used by submit_d3d11's per-frame check, so the predicate the encoder was built from and the one it re-checks per frame cannot drift. That check can now only fire on a genuine mid-stream depth change. Verified `--all-targets -D warnings` on Windows (no features / pyrowave / qsv / nvenc,qsv; 31 tests) and Linux (default; shipped nvenc+vulkan-encode+pyrowave). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Opus 4.8	232b41e88b	fix(pf-encode/windows): cover the Linux HDR pixel formats in the win swscale match ... The GNOME 50 HDR work added PixelFormat::X2Rgb10 / X2Bgr10 but only taught the Linux encoders about them. `sws_src` in the Windows-gated ffmpeg_win.rs matches PixelFormat exhaustively, so the Windows host stopped compiling: error[E0004]: non-exhaustive patterns: `X2Rgb10` and `X2Bgr10` not covered --> crates\pf-encode\src\enc\windows\ffmpeg_win.rs:132:14 Linux CI never caught it — the file is cfg(windows), so `cargo clippy --workspace` on the Linux runner never compiles it. Both are Linux-only screencast formats (the Windows HDR path stays Rgb10a2/P010, per the PixelFormat docs), so they join the existing bail arm. Spelled out rather than folded into a `_` catch-all so the next PixelFormat addition breaks this match again on purpose. Verified: cargo check --workspace --all-targets --features nvenc,amf-qsv on the Windows box (192.168.1.173). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 10:30:33 +02:00
enricobuehlerandClaude Opus 4.8	9a36ea2132	refactor(host/W6.2): extract the video encode backends into the pf-encode crate ... encode.rs + encode/* (NVENC, VAAPI, native AMF, AMF/QSV ffmpeg, direct-SDK NVENC/CUDA, raw Vulkan-Video, PyroWave, openh264) move into crates/pf-encode behind one Encoder trait + open_video selector (plan §W6). The crate speaks the shared frame vocabulary (pf-frame: CapturedFrame/PixelFormat + the DXGI identity D3d11Frame/make_device) and pf-zerocopy (CUDA context/buffers), and NEVER pf-capture — the capture→encode edge is one-way (ZeroCopyPolicy, prior commit). Dep moves: the heavy encoder deps (ffmpeg-next, the NVENC SDK, openh264, pyrowave-sys) move from the host to pf-encode; the host's nvenc/amf-qsv/vulkan-encode/pyrowave features now FORWARD to pf-encode/*. The host keeps a mod-encode shim (pub use pf_encode) so every crate::encode::* path (negotiator + GameStream/native/mgmt planes) is unchanged. resolve_render_adapter_luid moves from the host's windows/win_adapter.rs into pf-gpu (both pf-encode and pf-capture need it as a peer of GPU selection); its 5 call sites (encode amf/nvenc, capture idd_push/synthetic_nv12, vdisplay manager) rewire to pf_gpu::resolve_render_adapter_luid and win_adapter.rs is deleted. pf-frame's make_device gains a # Safety section (public-unsafe-fn lint, latent since the pf-frame carve — a full-workspace -D warnings clippy catches it). Verified: Linux clippy -D warnings (pf-encode + host nvenc,vulkan-encode,pyrowave --all-targets) + 13/13 pf-encode + 299/299 host tests; Windows clippy -D warnings (pf-encode nvenc,amf-qsv --all-targets + host nvenc,amf-qsv --all-targets) Finished exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 10:42:51 +02:00