131 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	aa070f2d55	feat(ffi): hand-mirrored C structs are now layout-checked at compile time ... The sharpest memory-safety risk left in this codebase is not an `unsafe` block — it is a hand-written `#[repr(C)]` mirror of an external C struct. Get a field offset wrong and nothing fails to compile and nothing reliably crashes: the library reads a pointer, a length or a pitch out of the wrong bytes. Eleven such structs across five files had NO check at all. Guarded here, each next to the struct it protects: * `AVCUDADeviceContext`, and `AVD3D11VADeviceContext`/`AVD3D11VAFramesContext`. `ffmpeg-sys-next` binds none of them, so these mirrors are the only definitions — and we WRITE through them (`cuda_ctx`, `device`, `bind_flags`). ⚠ The D3D11VA pair is duplicated VERBATIM in two crates (pf-encode's `ffmpeg_win.rs`, pf-client-core's `video_d3d11.rs`) because neither can depend on the other; they must agree with libav and with each other, and now a drift in either is a build error. * The six cuda.h structs. Three were already asserted — but only in `#[cfg(test)]`, so the check ran when someone ran the tests and never in a release build. They are `const` now. The other three, including `CUDA_MEMCPY2D` which is filled on EVERY zero-copy frame, had nothing. * `MsghdrX`, Darwin's `msghdr_x`, which `libc` does not expose. Its layout is not reviewable by eye: the 32-bit fields force padding before each following pointer, so `msg_iov` sits at 16 and not 12. `sendmsg_x`/`recvmsg_x` take the pointer and length from it. * `IPolicyConfigVtbl` — the sharpest of the set. It mirrors an UNDOCUMENTED COM interface, and `set_default_endpoint` is called by SLOT INDEX through a ten-entry `_reserved` gap that carries no names to anchor a review. A field added or resized above it does not break the build; it calls a different function pointer through a mismatched signature. Every assertion is `const _: () = assert!(..)`, so it holds on every build including release and cannot be skipped. The compiler verified the numbers — the sizes and offsets asserted here are the ones the target actually produces, on each platform that compiles the struct. Verified: Linux .21 fmt + both CI clippy steps rc=0 (CUDA + libav CUDA mirrors); Windows .47 full CI clippy set rc=0 + pf-capture tests (D3D11VA pair, COM vtable); macOS `cargo check -p punktfunk-core` (MsghdrX — the only platform that compiles it).	2026-07-29 08:48:42 +02:00
sassycrownandOpenAI Codex	22936bbc89	fix(vaapi): use FFmpeg bt2020nc matrix name ... FFmpeg rejects bt2020 as an out_color_matrix value. Use its canonical bt2020nc name for non-constant-luminance BT.2020, matching the existing AVCOL_SPC_BT2020_NCL encoder VUI. Co-Authored-By: OpenAI Codex <noreply@openai.com>	2026-07-29 00:26:57 +02:00
enricobuehler	60a85a1344	refactor(encode/windows): fourth fence off — ffmpeg_win.rs, and D3d11Hw::new joins VaapiHw ... 47 sites, 25 of them raw pointer dereferences: the same libav shape as `vaapi.rs`, so the same verdict — a proof here carries an argument rather than restating a call. `D3d11Hw::new` loses its marker for exactly the reason `VaapiHw::new` did, and the trio is now the clearest statement of the rule in the tree: `CudaHw::new` KEEPS it (handed a `CUcontext`), `VaapiHw::new` and `D3d11Hw::new` do not (a borrowed COM wrapper and scalars, opening what they need themselves). Three near-identical libav context builders, sorted by whether a caller can hand them something broken. Also unmarked, all for the same reason — no parameter a caller can get wrong: `immediate_context` and `ensure_staging` (`&ID3D11Device` IS the live-device guarantee), `send` and `ensure_sws` (only scalars, operating on the `AVFrame`/`SwsContext` the struct owns from its constructor to `Drop`), and `test_hw_device`, whose `# Safety` section described its own body — "calls the DXGI enumeration FFI and `make_device`" — while taking a single `u32`. `open_win_encoder` keeps its marker (raw `*mut AVBufferRef` pair) and gains the proof it lacked, including the null case the system path relies on: both refs may be null, the `is_null` guards keep `av_buffer_ref` off that path, and the refs it does take are new ones the codec context adopts. `D3d11Hw::new`'s proof records the ordering the multithread-protection fix depends on — the device store must precede `av_hwdevice_ctx_init`, which reads it. 14 fenced files -> 10. Verified on the Intel box .47: `-p pf-encode --features nvenc,amf-qsv,qsv` clippy `-D warnings` rc=0, the full Windows CI clippy set rc=0, pf-capture's 18 tests pass, and — because this is the live D3D11VA construct path, not dead code — `d3d11hw_alloc_drop_cycles` passes on real Intel silicon: 8 construct/drop cycles, no abort. Linux .21: fmt + both CI clippy steps rc=0.	2026-07-29 00:20:35 +02:00
enricobuehler	8e7ba00d2d	refactor(encode/linux): third fence off — vaapi.rs, and VaapiHw::new needed no marker at all ... Same criterion as the last two: `vaapi.rs`'s sites are pointer dereferences and libav ctx calls, not ash, so a proof here carries an argument. Three regions, three arguments. `VaapiHw::new` also loses its `unsafe fn` outright, and the contrast with its CUDA twin is the whole point: `CudaHw::new` keeps the marker because it is HANDED a `CUcontext` the caller must vouch for, while this one takes four scalars and opens the VAAPI device itself. Two functions of near-identical shape, opposite answers, decided by whether a caller can supply something broken. The other two regions keep their markers (`open_vaapi_encoder`/`_mode` are handed raw `*mut AVBufferRef`s) and gain the proofs they lacked. The encoder-config block now records the fact that makes it sound rather than obvious: `av_buffer_ref` returns a NEW reference the codec context adopts, so the callee shares the caller's device/frames buffers instead of consuming them — which is also why the low-power entrypoint ladder can retry with the same two pointers after a failed attempt. The frames-pool block reuses the `CudaHw::new` argument: alloc returns null-or-initialized and `AvBuffer::from_raw` rejects null, so the `?` leaves before any field store can run. One call site dropped its `unsafe {}` and its comment with it — the comment argued that libav was initialized, which is a real precondition of the call but not one a caller can violate, so it is now a note rather than a contract. 14 fenced files -> 11. Verified on .21 (fmt + both CI clippy steps rc=0) and, because this is the live VAAPI construct path rather than dead code, ON THE AMD 780M (.116, pf-build distrobox): `vaapi_cpu_encode_smoke`, `dmabuf_inner_alloc_drop_cycles` and `vaapi_probe_smoke` all pass — 3 passed / 0 failed, H265 + AV1 probes still true in both 8- and 10-bit.	2026-07-29 00:20:35 +02:00
enricobuehler	d72822ced7	refactor(encode/linux): second fence off — CudaHw::new's pointer walk gets its proof ... `linux/mod.rs`'s fifteen sites are the same kind as `video_vulkan.rs`'s, not the ash kind: nine raw pointer dereferences and six libav calls, all inside `CudaHw::new`, which had no `unsafe` block and therefore no proof of the one thing worth proving here — that the pointer chain it walks is live. The marker STAYS (`cu_ctx: *mut c_void` is a `CUcontext` the caller must supply valid). The body is now two blocks, one per phase, because there are two distinct arguments to make. Both turn on the same non-obvious fact: `av_hwdevice_ctx_alloc`/`av_hwframe_ctx_alloc` return null or a ref whose `data` libav has ALREADY initialized, and `AvBuffer::from_raw` rejects null — so the `?` leaves before any of the field stores below it can run. That is what makes the `(*dev_ctx)`/`(*fc)` writes in-bounds stores on live allocations rather than a hope, and it is exactly the reasoning that was missing. The device block also records the ordering constraint that was implicit: `cuda_ctx` must be stored BEFORE `av_hwdevice_ctx_init`, which reads it. Two files now need no exemption: 14 fenced -> 12. Both were removable for the same reason — their sites are pointer dereferences, where a proof carries an argument, unlike the ash backends where it could only restate the call. That is the criterion for which fence to attack next, not file size. Verified on .21: fmt + `clippy --workspace --all-targets -- -D warnings` + the feature-gated `-p pf-encode --features nvenc,vulkan-encode,pyrowave` step, all rc=0 with no allow in either file.	2026-07-29 00:20:35 +02:00
enricobuehler	6de325a6b6	fix(ci): the unsafe lint said warn while CI enforced it as deny, and main went red ... `unsafe_op_in_unsafe_fn = "warn"` was adopted workspace-wide in 39513528 on the assumption that `warn` is a soft setting you can clear at leisure. It is not: ci.yml runs `cargo clippy … -D warnings`, which promotes it to a hard error, so main has failed on EVERY commit since — Linux `rust` and `rust-arm64` both dying on `pf-client-core` with 70 E0133 errors, and windows-host.yml alongside them. A lint level that understates its own severity is worse than a strict one, so this states what CI already does — `deny` — and writes the exemptions down instead. Fourteen GPU/FFI backend files take `#![allow(unsafe_op_in_unsafe_fn)]`, each with its reason and the workspace Cargo.toml carrying the argument in full. They are not "not done yet": measured across them, 64% of the sites are a single third-party FFI call (ash, pyrowave-sys, libav, the NVENC/AMF entry tables), and of the 44 `unsafe fn`s only 4 have a body containing no unsafe operation at all. Since pf-encode also denies `undocumented_unsafe_blocks`, narrowing them means a hand-written SAFETY comment per line that could only restate the signature — the exact noise that made `unsafe` stop meaning anything here before. Everything else stays at zero and enforced, and each allow is removable on its own terms. Two smaller things this had to clear, both invisible to the job that would have caught them: - `service.rs`: `undocumented_unsafe_blocks` wants the proof on EACH block, and a comment covering a group of consecutive `unsafe` statements only credits the first — so the two `OwnedHandle` wraps became their own statements. Windows-gated, so only the .47 gate sees it. 37a42078 fixed the same class of failure in pf-frame/dxgi.rs concurrently; that fix is taken as-is here. - `clients/linux/ui_settings.rs`: `show`'s deletion left its doc comment stranded on `show_scoped`, which silently merged two unrelated doc blocks onto one fn. Removed. Verified by running the real CI commands, not proxies: on .21 fmt + `clippy --workspace --all-targets -- -D warnings` + the feature-gated `-p pf-encode --features nvenc,vulkan-encode,pyrowave` + build + test, all rc=0; on the Intel box .47 all four windows-host.yml clippy invocations, all rc=0. The arm64 job lints pf-client-core and punktfunk-client-linux, both covered here.	2026-07-28 22:32:30 +02:00
enricobuehler	a3843b6996	test(encode): the VAAPI dmabuf path verified on AMD silicon, and its owner-only fields say so ... Closes the last unverified leg of the AvBuffer work. `DmabufInner` was the heaviest ownership change in the crate — four owned objects (DRM device, derived VAAPI device, DRM-PRIME frames ctx, filter graph) whose eight failure branches each repeated the same four-line unwind, once inside a macro, plus a ninth copy in `Drop` — and it had no coverage at all. `vaapi_cpu_encode_smoke` does not reach it: that drives the swscale/CPU-upload path, which uses `VaapiHw` and never builds a graph. `dmabuf_inner_alloc_drop_cycles` loops construct/drop, which is the whole contract now that every handle releases itself. **It passes on a Radeon 780M**, as do the two pre-existing VAAPI tests, so `VaapiHw` and `DmabufInner` are both hardware-verified rather than compile-only. Also fixes three more owner-only fields the AMD box surfaced: `graph`, `vaapi_device` and `drm_device` are `never read` since the hand-written `Drop` that used to read them is gone. Same call as the decoders and the QSV pair — annotate rather than delete (removing `graph` would free it while `src`/`sink` still point into it) or underscore-rename (which hides what they hold). `drm_frames` is NOT annotated: `submit` genuinely reads it per frame. I had missed these twice: my Linux log greps searched "never constructed|never used", which does not match "never read". The check now includes all three spellings. Two environment notes worth keeping, both diagnosed by testing OUTSIDE our code first (ffmpeg's own CLI reproduced each): * Inside a distrobox on an immutable host, VAAPI needs `LIBVA_DRIVERS_PATH=/run/host/usr/lib64/dri`. The container's mesa (25.3.6) is older than the host's (26.0.4) and every encoder open fails with a bare ENOSYS — "Function not implemented", naming nothing. The test doc says so. * `cargo check --workspace` in that container fails on `glib-sys` (no GTK dev headers). Unrelated to this branch; .21 checks the full workspace clean. Verified: AMD .116 (Radeon 780M, Mesa 26.0.4) full pf-encode suite 33 passed / 0 failed plus all 3 ignored VAAPI hardware tests green. Linux .21 workspace check exit 0 / zero errors, pf-encode 33/0, pf-client-core 34/0, and zero dead-code warnings across all three spellings.	2026-07-28 21:31:42 +02:00
enricobuehler	4241bc0383	fix(encode/windows): enable D3D11 multithread protection before libav sees the device ... libav turns on `ID3D11Multithread::SetMultithreadProtected` in `d3d11va_device_create` — the path where it creates the device itself. We take the other path, `d3d11va_device_init`, because we hand it the capturer's existing `ID3D11Device`, and that path does not. Nothing enabled it on our side either, so it was simply off. Two consequences, one of them shipping since long before this branch: QSV zero-copy could not open at all. `av_hwdevice_ctx_create_derived(QSV <- D3D11VA)` ends in `MFXVideoCORE_SetHandle`, and MFX rejects a device without multithread protection as `MFX_ERR_UNDEFINED_BEHAVIOR (-16)`. libav reports that as "Error setting child device handle", which names neither the cause nor the cure. AMF — the DEFAULT Windows zero-copy path — has been running with a lock that does nothing. We deliberately leave `lock`/`unlock` null so libav installs its `d3d11va_default_lock`, and that lock is `ID3D11Multithread::Enter`/`Leave`, which are documented no-ops while protection is off. The lock libav installs to serialise our capture thread against its encode thread has therefore never actually serialised anything. That is the more serious half of this fix, and it is not QSV-specific. Measured on the Intel VM (UHD 750, FFmpeg 7.1.5 + libvpl), sweeping device flags x adapter x protection: BGRA -> QSV derive FAILED (-16) BGRA +MT -> QSV derive OK BGRA|VIDEO +MT -> QSV derive OK `D3D11_CREATE_DEVICE_VIDEO_SUPPORT` makes no difference in either direction, and the same result holds on both Intel adapters the box enumerates. Protection is the only variable that matters, and it read back `was=false` every time, confirming nothing else had enabled it. The hypothesis came from ffmpeg's own CLI succeeding at the identical derive (`-init_hw_device d3d11va=d3d -init_hw_device qsv=q@d3d`) — the only difference being who created the device. With this, `zerocopy_qsv_alloc_drop_cycles` passes on real Intel silicon, which also makes the QSV arm of the AvBuffer refactor hardware-verified rather than compile-only. Its doc comment now points back here, since a future regression will present as that same opaque "child device handle" line. NOT flipped: `zerocopy_active` still defaults QSV off. The derive works and the handles construct and release cleanly, but that is not the same as a validated streaming session, and the default should move on glass evidence, not on this. Verified on .47 (Intel UHD 750): full pf-encode --features amf-qsv suite 39 passed / 0 failed, d3d11hw_alloc_drop_cycles green, zerocopy_qsv_alloc_drop_cycles green, and the native VPL path (qsv_encode_live_smoke) still green. Linux .21: workspace check exit 0 / zero errors, pf-encode 33/0, pf-client-core 34/0.	2026-07-28 21:31:42 +02:00
enricobuehler	2d78d2a514	test(encode): D3d11Hw verified on real silicon; the QSV derive is broken upstream of us ... Ran the QSV probe on the Intel VM (UHD 750, FFmpeg 8). It fails — and not in the code it was written to cover: [AVHWDeviceContext] Error setting child device handle: -16 ZeroCopyInner::open(QSV) failed on iteration 0: derive QSV device from D3D11VA That is `MFX_ERR_UNDEFINED_BEHAVIOR` out of `MFXVideoCORE_SetHandle`, raised inside `av_hwdevice_ctx_create_derived` — libav's own code, called with the same arguments as before this branch. Confirmed pre-existing by A/B: the same probe, written against unmodified `origin/main` with the raw-pointer struct, fails byte-identically on the same box at the same first iteration. The ownership change is not implicated. It is also not the hardware. `qsv::tests::qsv_encode_live_smoke` — the native VPL backend, untouched by this branch — encodes real H.264 on that box via VPL 2.15 with its own D3D11 zero-copy. So QSV works; libav's QSV-from-D3D11VA derive is what does not. That matches `zerocopy_active` already defaulting QSV **off** pending Intel validation, and is now a measured fact rather than a suspicion. The test stays, `#[ignore]`d, with the finding in its doc comment so the next Intel driver / FFmpeg bump re-checks it instead of the question being quietly dropped. What that leaves is real coverage of the half that IS reachable anywhere: `d3d11hw_alloc_drop_cycles` loops construct/drop on `D3d11Hw`, the hwdevice + frames-pool pair both Windows zero-copy vendors share, so it covers the AMF path's ownership without needing AMD hardware. **It passes on the Intel box: 8 cycles, no abort.** Adapter selection is factored into `test_hw_device`, which prefers a vendor and skips the Microsoft Basic Render Driver — a punktfunk host enumerates our own virtual-display adapter too, so `EnumAdapters1(0)` is not a safe assumption. Verified: QSV VM .47 full `pf-encode --features amf-qsv` suite 39 passed / 0 failed (EXITCODE=0), with `d3d11hw_alloc_drop_cycles` green on real silicon. Linux .21 workspace check exit 0 / zero errors, pf-encode 33/0, pf-client-core 34/0.	2026-07-28 21:31:41 +02:00
enricobuehler	564797a12a	test(encode): a QSV construct/drop smoke test, and AvFilterGraph goes Linux-only ... Two loose ends ahead of running this on real Intel silicon. `zerocopy_qsv_alloc_drop_cycles` covers the one ownership question in the crate that was genuinely ambiguous. `ZeroCopyInner::open` builds a `D3d11Hw` and then DERIVES a QSV device + frames ctx from it, and the tuple it used to return handed those two derived pointers out twice — once as the encoder's args, once as the pair moved into `Self`. Free for raw pointers, two owners for `AvBuffer`. Looping construct/drop is what separates the outcomes: a double-unref aborts in the CRT, a missed one leaks an Intel device per session. Nothing else reaches this code — `zerocopy_enabled` defaults QSV OFF, and the native VPL backend supersedes this whole file unless `PUNKTFUNK_QSV_FFMPEG=1` — so the test calls `open` directly and sidesteps both gates, the same shape as `cuda_hw_alloc_drop_cycles`. `AvFilterGraph` is now `#[cfg(target_os = "linux")]`. The Windows gate had been reporting `struct AvFilterGraph is never constructed` since a960dff8 and I had been filtering it out of my own log greps (searching for "never read", which does not match "never constructed"). It is true: the VAAPI dmabuf path is the only filter-graph user, and the AMF/QSV backends build no graph. Cfg'd out rather than `allow`ed, so it cannot outlive its last caller unnoticed. Verified. Windows .133: `cargo test -p pf-encode --features amf-qsv --no-run` at EXITCODE=0 with the AvFilterGraph warnings gone (107 -> 105), and the test binary lists `ffmpeg_win::tests::zerocopy_qsv_alloc_drop_cycles`. Linux .21: workspace check exit 0 / zero errors, pf-encode 33 passed / 0 failed, pf-client-core 34 passed / 0 failed, and zero dead-code warnings there (AvFilterGraph is live on Linux). NOTE for running it: the test binary needs `C:\Users\Public\ffmpeg\bin` on PATH at RUNTIME. `FFMPEG_DIR` is build-time only, and without the DLLs the harness exits silently with no output at all — which reads exactly like a test that does not exist.	2026-07-28 21:31:41 +02:00
enricobuehler	e60fee7da6	refactor(encode): the QSV derived pair stops being two owners of the same pointer ... `ZeroCopyInner` held the QSV device + frames ctx as nullable raw pointers, where null meant "AMF, which feeds D3D11 frames directly" — a convention documented in a comment and enforced by three `is_null()` checks. `Option<AvBuffer>` says it in the type, so the checks and the hand-written `Drop` both go away. The reason this one was left out of the previous commit is the aliasing. `open` built a five-element tuple whose QSV arm handed the SAME two pointers out twice: once as the encoder's `dev_ref`/`frames_ref`, once as the pair moved into `Self`. For raw pointers that is free; for an owning type it is two owners and a double-unref. Ownership and borrowing are now separated — the pair is owned in `qsv_frames`/`qsv_device`, and the encoder's arguments are `as_ptr()` views taken from whichever owner applies. `open_win_encoder` takes its own refs of what it is handed, so lending transfers nothing. Net: all 13 `av_buffer_unref` calls in this file are gone (the last two hand-written Drops with them), including the encoder-open failure arm, which collapses to `?` now that every handle releases itself. Field order pinned and commented, as with the others: QSV frames, QSV device, then `enc`, then `hw` — reproducing the old `Drop`, which ran ahead of all fields and so released the derived pair before the encoder's AddRef'd copies and the D3D11 refs. `qsv_device` picked up an `#[allow(dead_code)]`: `qsv_frames` is still read by the send path, but the device is now purely an owner (the frames ctx and the encoder each hold their own ref). Same call as the decoders — deleting it would free the device early, an underscore name would hide it. Verified on BOTH: Windows .133 `cargo check -p pf-encode --features amf-qsv --all-targets` EXITCODE=0, no dead-code warnings, and confirmed non-vacuous (log shows `Removed 23 files, 36.2MiB` then a real `Checking pf-encode`). Linux .21 `cargo check --workspace --all-targets` exit 0 / zero errors, pf-encode 33 passed / 0 failed, pf-client-core 34 passed / 0 failed, and `cuda_hw_alloc_drop_cycles` still passing on real CUDA. The QSV path itself still wants Intel silicon to exercise.	2026-07-28 21:31:41 +02:00
enricobuehler	5b142a7e85	refactor(encode): the Windows D3D11VA hwdevice owns its refs ... `D3d11Hw::new` is the third instance of the same shape as `CudaHw` and `VaapiHw` — alloc a hwdevice, deref to fill it, init, alloc a frames ctx, deref, init — with the same hand-written unwind: three `av_buffer_unref` calls spread over the failure branches plus a `Drop` repeating the pair. It gets the same treatment, so all three libav hwdevice wrappers in the crate now share one release path. Field order carries the semantics here as in the other two: frames declared before device, so declaration-order dropping reproduces what the hand-written `Drop` did. `ZeroCopyInner`'s `qsv_device`/`qsv_frames` are deliberately NOT converted in this commit. They are nullable (null for AMF, which feeds D3D11 frames directly), and the QSV branch hands the same two pointers out twice — once as the encoder's `dev_ref`/`frames_ref` and once as the owned pair moved into the struct. Modelling that needs `Option<AvBuffer>` plus a borrow/own split so the aliasing does not become two owners, which is a different change from the mechanical one this commit makes. Verified on the Windows runner .133: `cargo check -p pf-encode --features amf-qsv --all-targets` at EXITCODE=0. Confirmed non-vacuous — the log shows `cargo clean -p pf-encode` removing 23 files / 36.2 MiB followed by a real `Checking pf-encode`, because a fast green on that box can otherwise just be cargo reusing artifacts whose timestamps outrank the freshly-extracted sources.	2026-07-28 21:31:41 +02:00
enricobuehler	eb9c5be20d	refactor(encode): the VAAPI dmabuf path stops unwinding by hand ... `DmabufInner::open` builds four owned objects — a DRM device, a VAAPI device derived from it, a DRM-PRIME frames context, and a filter graph — and every one of its eight failure branches unwound them by hand. The same four-line block (`avfilter_graph_free` + three `av_buffer_unref`s) appeared eight times, once *inside a macro*, plus a ninth copy in `Drop`. Adding a step to that function meant remembering to extend the unwind at exactly the right depth; getting it wrong leaks a device per failed session (the persistent listener accumulates them) or frees one twice. All eight are gone. `AvBuffer` already owned the buffer refs; `AvFilterGraph` now does the same for the graph, so each handle is owned the moment it exists and an early `bail!` releases whatever was built so far. `open` lost ~40 lines of cleanup and gained none. Field order in `DmabufInner` is load-bearing and says so: graph, frames, VAAPI device, DRM device, then `enc` LAST. Fields drop in declaration order, and that sequence reproduces the old hand-written `Drop` exactly — including that it ran ahead of every field, so all four were released before ffmpeg-next dropped the encoder. Everything here holds its own reference, so refcounting makes any order sound; the ordering is pinned so a future reorder cannot quietly change what ships. One subtlety preserved deliberately: the buffersrc parameters take `drm_frames` BORROWED, not ref'd (`av_buffersrc_parameters_set` takes its own ref). That is now `drm_frames.as_ptr()` — same borrow, same single owned ref, no new leak. Verified on .21 (CachyOS, RTX 5070 Ti, FFmpeg 62): `cargo check -p pf-encode --all-targets` clean at exit 0, `cargo test -p pf-encode` 33 passed / 0 failed, and `cuda_hw_alloc_drop_cycles` still passes against real CUDA. vaapi.rs now contains zero `av_buffer_unref` and zero `avfilter_graph_free` calls, down from 40 and 8. The dmabuf path itself still needs AMD/Intel silicon to exercise end to end.	2026-07-28 21:31:41 +02:00
enricobuehler	7adc1db672	refactor(encode): AVBufferRef ownership moves into an RAII handle ... `CudaHw::new` and `VaapiHw::new` are the same shape — alloc a hwdevice, deref it to fill fields, init, alloc a frames ctx, deref, init — and both unwound by hand: `av_buffer_unref` on every failure branch (three in CUDA, two in VAAPI) plus a hand-written `Drop` repeating the pair. That shape has two failure modes and the compiler can see neither: add a branch and forget the cleanup (leak), or let two cleanup paths run (double-unref, an abort inside glibc). `libav::AvBuffer` owns the ref instead. It null-checks on the way in — the check each caller open-coded — and unrefs exactly once on drop, so an early `?` releases whatever was built so far and the failure branches carry no cleanup at all. Both hand-written `Drop` impls are gone, and `linux/mod.rs` goes from seven `av_buffer_unref` calls to zero. The one subtlety, called out at both structs: these two fields must stay declared frames-BEFORE-device. Fields drop in declaration order, and the code being replaced deliberately unref'd frames first (a frames ctx holds its own reference on its device). Refcounting makes either order sound, but a field reorder should not silently change what ships, so the ordering is load-bearing and commented as such. Also adds `cuda_hw_alloc_drop_cycles` — the RAII path had NO test coverage: the NVENC smoke tests take the CPU path and never construct a `CudaHw`, and the VAAPI twin's tests need AMD/Intel silicon. Looping construct/drop is what catches the double-unref (abort) and the leak (allocator growth) this refactor is about. Verified on Nobara (RTX 5070 Ti): `cargo check -p pf-encode --all-targets` clean at exit 0, `cargo test -p pf-encode` 33 passed / 0 failed, and `cuda_hw_alloc_drop_cycles` passes against a real CUDA device — eight construct/drop cycles, no abort. `VaapiHw` is compile-verified only; it is the identical shape but no AMD/Intel box was reachable to run its two ignored tests.	2026-07-28 21:31:41 +02:00
enricobuehlerandClaude Opus 5	ee716d0137	fix(encode): pf-encode did not build on Linux without vulkan-encode ... `vulkan_encode_available_at` and `vulkan_encode_caps` were gated on bare `target_os = "linux"`, but the second returns `vulkan_video::VulkanEncodeCaps` and both reference that module — which only exists under the feature. Every CALL SITE was already correctly gated, so nothing pointed at them; the two definitions alone were enough to fail the build. That is CI's default-feature line (`cargo clippy --workspace --all-targets`), so this was going to be caught — it was caught on a Fedora 44 box first. `cursor_blend_capable`'s `ten_bit` goes unused in the featureless arm for the same reason, which `-D warnings` also rejects. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 18:03:30 +02:00
enricobuehler	3d3ecf1e82	test(encode/nvenc): the NVIDIA HDR leg, verified on an RTX 5070 Ti ... The NVIDIA half of "zero-copy, no host CSC, 10-bit HDR" had never met a GPU. Two `#[ignore]`d smokes now drive it, run on `.41` (Bazzite f43, RTX 5070 Ti, driver 595.58.03): * `nvenc_cuda_hdr10_packed_rgb` — a packed 2:10:10:10 CUDA payload straight into NVENC as `ARGB10`, HEVC **and** AV1. Asserts what would catch a mislabelled stream: the encoder DERIVED 10-bit and HDR from the input format rather than being told, and picked `ARGB10` for `X2Rgb10`. That derivation is what selects Main10 / AV1-at-10 and the BT.2020 PQ signalling. * `nvenc_cuda_hdr10_cursor_blend` — `cursor_blend.comp` MODE 3/4, the 10-bit channel-unpacking twin. Asserts the blend targets `SlotFormat::X2Rgb10` and not the 8-bit layout, which would tint the pointer and shift its channels. Both green, and the dumped bitstreams decode 0-error reporting `Main 10` / AV1 `Main`, `yuv420p10le`, `bt2020nc` / `smpte2084` / `bt2020`. There is no host colour conversion anywhere on this path: the frame arrives as a LINEAR dmabuf, crosses to CUDA through the Vulkan bridge, and NVENC's ASIC does the BT.2020 conversion following the VUI the session configured. The "no CSC" property AMD gets from the EFC, NVIDIA gets from the encoder itself. The whole pre-existing `nvenc_` suite was re-run alongside them — 16/16, no regression from the depth-derivation and buffer-format changes underneath it. Capture half checked too: the patched gamescope binary built on the AMD box runs unmodified on the NVIDIA one (same Fedora 43 base) and its node offers the same four formats with the colorimetry props — so headless gamescope + 10-bit PQ is not AMD-specific.	2026-07-28 18:03:30 +02:00
enricobuehler	576bf7e294	test(encode/vulkan): 10-bit smokes — and they pass on a real AMD GPU ... The Vulkan Video 10-bit path was the least-exercised code on this branch: nothing had ever created a Main10 video session, so the profile query, the `G10X6…3PACK16` picture allocation, the scratch→plane copy, the hand-packed AV1 sequence header and the colour signalling were all first-run-on-glass. Three `#[ignore]`d smokes now drive them, and they were run. `.116` (Bazzite f43, AMD 780M, RADV / Mesa 26.0.4), all three green: * `vulkan_smoke_10bit` — HEVC Main10 through the compute CSC; * `vulkan_smoke_10bit_av1` — AV1 at 10 bits; * `vulkan_smoke_rgb_10bit` — HDR with NO host CSC, the EFC converting BT.2020 off the packed 10-bit source. It did **not** soft-skip, which answers the one capability in this whole feature I had only ever read in a registry: RADV's VCN EFC really does advertise `MODEL_YCBCR_2020` and accept a 10-bit packed-RGB encode source. Every stream decodes 0-error and reports `yuv420p10le` + `bt2020nc` / `smpte2084` / `bt2020`. The AV1 one parsing at all is the load-bearing result there: `high_bitdepth` precedes the CICP bytes in `color_config()`, so a wrong bit would have thrown every later field out of phase rather than merely mislabelling the depth. Round-trip on solid frames, fed (160,160,800) as 10-bit codes: compute CSC -> (159, 158, 796) EFC -> (159, 158, 796) AV1 -> (158, 159, 794) Under 0.5%, all of it limited-range quantisation and lossy encode. The compute and EFC results being IDENTICAL is the strongest check available: two independent BT.2020 NCL implementations — my shader and AMD's fixed-function block — agreeing to within rounding. The smokes deliberately assert structure (submits encode, AU count, the depth the encoder settled on), not colour: a shader writing the 10 bits into the wrong end of the word still produces a decodable stream. Colour is the dump + ffmpeg round-trip above, which is what actually caught nothing this time. Also corrects a comment: I claimed a wrong store factor was a "~1.6% luminance error". It is not. The `<< 6` PLACEMENT is the load-bearing part (dropping it is 64x too dark); `1/1023` vs `64/65535` is ~0.1% and harmless.	2026-07-28 18:03:30 +02:00
enricobuehler	cb4690f216	feat(encode/vulkan): probe the device instead of guessing — AV1 10-bit + zero-CSC HDR ... Three fixes to the same mistake: deciding what the Vulkan Video backend can do from a table in our heads rather than from the driver, and routing everything that didn't fit to libav VAAPI — where a session loses real RFI recovery and the cursor blend for no reason the hardware asked for. **Capability probe, per codec AND depth.** `probe_encode_support`'s "is there an encode queue" boolean becomes `VulkanEncodeCaps { supported, eight_bit, ten_bit }`, answered by `vkGetPhysicalDeviceVideoCapabilitiesKHR` against the very profile chain the session open builds. So the dispatcher's prediction cannot disagree with reality: a capable device keeps the Vulkan path, an incapable one routes to VAAPI BEFORE burning a failed open, and the cursor-blend mirror stays honest for free. This is the shape the direct-SDK NVENC path already uses for its codec GUIDs. **AV1 10-bit.** It was excluded on a guess about driver coverage; now the device answers. `color_config()` carries `high_bitdepth` + the BT.2020/PQ CICP triplet in both the `StdVideoAV1ColorConfig` and the sequence-header OBU we bit-pack ourselves — they must stay identical or the driver's frame OBUs parse against a header we didn't write. `high_bitdepth` sits BEFORE the CICP bytes, so getting it wrong doesn't just mislabel the depth, it puts every following field one bit out of phase; the new test reads the packed bits back. **Zero-CSC RGB-direct in HDR.** The EFC probe assumed BT.709 and BGRA. It now asks for the model this session's colourimetry needs (`MODEL_YCBCR_2020` for 10-bit — the extension has always had it) and for the CAPTURED format as an encode-source format, and the session create-info selects the matching model. An HDR session with no pointer to composite therefore hands the captured buffer straight to the fixed-function front end and runs no host CSC at all. Sessions that DO composite a pointer keep the compute CSC, unchanged: the EFC cannot blend, and that rule outranks everything. Also: `can_encode_10bit` on AMD/Intel now reports the union of VAAPI's and Vulkan Video's answers instead of VAAPI's alone. `open_amd_intel` tries Vulkan first and falls back, so either one being able to encode Main10 makes the session 10-bit-capable — answering `false` because only one of them said yes stranded encodable HDR sessions at 8 bits.	2026-07-28 18:03:30 +02:00
enricobuehler	479f0965ee	feat(encode/vulkan): Vulkan Video encodes 10-bit, so AMD/Intel HDR keeps the good path ... The Vulkan Video backend was 8-bit for no structural reason — the API has `VK_VIDEO_COMPONENT_BIT_DEPTH_10_BIT` and `PROFILE_IDC_MAIN_10` in the very fields this pinned to 8 and MAIN, and AMD VCN and Intel both encode Main10. It was six hardcoded sites, and the cost of leaving them was paid twice over: an HDR session had to take libav VAAPI, losing real RFI loss recovery AND the compute CSC's cursor blend — which on gamescope is the only way the pointer reaches the stream at all, since gamescope has no embedded-cursor mode. An HDR session now opens a Main10 profile with 10-bit component depths, a `G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16` picture + DPB, and an SPS carrying `bit_depth_*_minus8 = 2` with the BT.2020/PQ CICP triplet instead of BT.709. `rgb2yuv10.comp` is the CSC's twin, and the two interesting parts of it are: * it is a PURE 3x3 matrix. The samples arrive already PQ-encoded (gamescope composites into the PQ container), so BT.2020 NCL applies to the code values as they are — there is no transfer function to apply here and applying one would be wrong; * the scratch planes are `R16`/`RG16`, not the picture's plane formats. The 10-bit ycbcr plane formats are not storage-image formats, so the shader writes the value into the HIGH bits by hand (`code10 << 6`, hence the `64/65535` factor and not `1/1023`) into planes that are merely SIZE-compatible with the picture's — which is all `vkCmdCopyImage` requires. Scope and safety: * HEVC only. AV1 10-bit encode has far thinner driver coverage, and a session open is not the place to gamble on it — those stay on VAAPI, as does a device that fails the Main10 profile query inside the open (the pre-existing "failed Vulkan open falls back to VAAPI" net, no new probe needed). * HDR pins the compute-CSC arm over the EFC RGB-direct one, which the EFC could not serve anyway: its fixed-function conversion is 8-bit BT.709 narrow with no knob for BT.2020. * `open_inner` binds `hdr` to the parameter-set HEADER bytes, so the depth flag is `ten_bit` there — the one name collision this change had to route around.	2026-07-28 18:03:30 +02:00
enricobuehler	17f824c3e9	feat(encode/nvenc): an HDR capture stays zero-copy on NVIDIA ... AMD/Intel needed no new encoder code for HDR — the VAAPI path already ingests an XR30 dmabuf into `format=p010:out_color_matrix=bt2020`. NVIDIA did: the 10-bit formats were excluded from the GPU import outright, so an HDR session fell back to a CPU readback plus swscale, which is the one thing the capture path is not allowed to ship. It turns out no CSC kernel is needed. NVENC ingests packed 10-bit RGB natively as `ARGB10`/`ABGR10` and does the conversion itself following the configured VUI matrix — which `apply_low_latency_config` already sets to BT.2020 NCL for an HDR session. So the frame travels LINEAR dmabuf → Vulkan bridge → CUDA → NVENC unconverted: no host CSC pass, no depth loss, no extra work on a contended SM. * invariant 1 is restated rather than dropped: HDR must never take the TILED EGL de-tile blit (it renders into an 8-bit `GL_RGBA8` texture). The HDR pods are LINEAR-only by construction, so the plan may build the importer; the per-frame gate — which sees the negotiated modifier the plan cannot — is what enforces the tiled half, and falls back to the CPU path if a producer ever ignores our offer. * …but only where the encoder can actually take the payload (`linux_hdr_cuda_ok`). libav's HDR route builds a P010 hardware frames context and swscales into it, so on a host without the direct-SDK backend a packed-2:10:10:10 CUDA buffer would land in a P010 surface as garbage. Those keep the CPU path. * `nvenc_cuda` stops pinning 8-bit/SDR. Depth and HDR now follow the INPUT format, like the Windows backend: a 10-bit session whose capture came back 8-bit encodes AND labels 8-bit rather than mislabelling. * the cursor-blend compute shader gains two 10-bit modes, so the pointer gamescope leaves out of its node survives the HDR path. Same display-referred blend the CPU path's `composite_cursor_rgb10` already does — the samples are PQ, and a real sRGB→PQ cursor LUT is polish, not correctness for a pointer.	2026-07-28 18:03:30 +02:00
enricobuehler	28c50d1c5b	fix(encode): every backend signals its colour, so no decoder has to guess ... Three encode paths shipped a bitstream with no colour description at all, leaving primaries/transfer/matrix/range "unspecified": - Vulkan Video HEVC (`vk_build.rs`) built an SPS with no VUI whatsoever. This is the DEFAULT backend for AMD/Intel Linux hosts on HEVC/AV1. - Vulkan Video AV1 packed `color_description_present_flag = 0`. - The openh264 software path wrote nothing (it converts BT.709 limited and relied on decoders defaulting to that). - The libav-NVENC Linux path excluded packed-RGB 4:2:0, on the belief that "NVENC's internal CSC writes its own VUI". It doesn't: libavcodec derives `colourDescriptionPresentFlag` from the AVCodecContext colour fields, so leaving them unspecified emits none. Reachable on a CPU/dmabuf capture, a build without `--features nvenc`, or PUNKTFUNK_NVENC_DIRECT=0. Unsignalled looks fine on every punktfunk client — `csc_rows` falls back to BT.709 on "unspecified" — which is why this survived. Vendor TV decoders do not: they guess colorimetry from RESOLUTION, and an LG webOS panel reads a 4K SDR stream as BT.2020 and renders it visibly washed out. All four now signal BT.709 limited, which is what every host CSC actually produces (`rgb2yuv.comp`, `convert_bt709`, the swscale paths) and what the Welcome's `ColorInfo::SDR_BT709` already advertises out-of-band. NVENC, VAAPI, QSV, AMF and the Windows libav path were already correct. Two tests, both parsing the REAL emitted bitstream rather than re-asserting the constants: an independent bit-walk of the AV1 sequence header (the packed OBU must stay identical to the `StdVideoAV1ColorConfig` handed to the driver), and an H.264 SPS/VUI parse proving openh264 honours the request instead of dropping it. Not yet verified on hardware: the HEVC VUI depends on the driver's SPS writer emitting `vui_parameters()`. PUNKTFUNK_VULKAN_ENCODE=0 falls back to VAAPI if a driver mishandles it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 3c56ff5717b2c9a0871953127da3dadd6a84220d)	2026-07-28 17:01:59 +02:00
enricobuehler	188f55d3b1	fix(encode/nvenc): the host advertises what the driver lists, not a superset ... Every NVIDIA host advertised a static H.264|HEVC|AV1 superset, so a 1st-gen Maxwell (GTX 960M, no HEVC/AV1 encode) offered HEVC — a client that believed it got ~15 s of blank video and a disconnect instead of a stream. Both OSes now ask the driver itself (nvEncGetEncodeGUIDs) on one throwaway direct-SDK session: Linux on the shared CUDA context, Windows on the selected render adapter, wired into host_wire_caps AND the GameStream serverinfo mask (which had been left on the superset for NVIDIA on both OSes). Fails open — an unanswerable probe keeps the historical superset, so it can only ever narrow the advertisement to codecs the GPU really encodes. The HEVC 4:4:4 answer rides the same session on Linux instead of opening a libav hevc_nvenc FREXT probe: that open is the prime suspect for the field bug where one probe wedges NVENC process-wide (NV_ENC_ERR_INVALID_VERSION on every later session until a host restart), and the direct backend re-checks the same caps bit at session open anyway. The ffmpeg probe remains only for hosts that really stream over libav (PUNKTFUNK_NVENC_DIRECT=0 or a build without the nvenc feature), where ffmpeg's NVENC client runs regardless. The 10-bit probe deliberately stays libav — Linux HDR rides the libav P010 path. On-hardware: .136 (RTX 5070 Ti) 14/14 nvenc tests in one process incl. the probe followed by real sessions and dirty teardown; .173 (Windows RTX) probe + 47 release lib tests. The Windows probe test documents the pre-existing MSVC debug-link failure (LNK2019 via the sdk crate's unused lazy loader) — run it with --release, the same reason windows-host.yml gates with clippy. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> (cherry picked from commit 0346ec8090568eb499e8cb7d735305b28471185e)	2026-07-28 17:01:59 +02:00
enricobuehlerandClaude Fable 5	6d1baa0add	fix(pf-encode/pyrowave): the bitrate pin holds on the WIRE, not the raw bitstream ... A datagram-aligned PyroWave session inflates the codec bitstream ×1.2–1.3 on its way to the wire — greedy packing of few-hundred-byte atomic block packets into 1408 B windows zero-pads most window tails, plus the 4-byte prefixes and FRAG chains. The 2026-07 field report's 1440p60 10-bit "Automatic" pin of 407 Mb/s put a measured 550 Mb/s on a 1 GbE link; nothing enforced the pin past the rate controller. New shared WireBudget (pyrowave_wire.rs, both backends): tracks the real per-frame AU/bitstream ratio as a ×1024 fixed-point EMA (prior ×1.25, weight 1/8, clamped ×1.0–×2.0) and deflates the budget handed to pyrowave's rate control by it, so the windowed AU lands on the configured rate. Sealed-datagram framing (+4.5%) and FEC parity stay uncompensated — H.26x sessions carry those on top of the configured bitrate too, and the pin must mean the same thing for every codec. Dense (non-chunked) sessions are untouched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 12:51:11 +02:00
enricobuehlerandClaude Fable 5	dff63b2a29	fix(encode/nvenc): a visible cursor no longer serializes submit — the blend goes stream-ordered ... Report: iPad on a gamescope/NVIDIA 120 fps session capped at ~80 fps with repeat_fps 0, zero loss, capture 0 µs, ASIC 15 µs — and submit p50 at 10.2 ms, ~81 % of the loop period. Under gamescope the host composites the live pointer into EVERY frame, and a cursor-bearing frame forced the CPU-synced submit path: a blocking CUDA copy plus a fence-waited Vulkan blend, both exposed to the running game's GPU load. The "games hide the cursor" assumption the gate relied on does not hold under gamescope. The blend is now stream-ordered end to end. VkSlotBlend exports a timeline semaphore (VK_KHR_timeline_semaphore + external_semaphore_fd) into CUDA (cuImportExternalSemaphore, new dlopen entries): the enqueued copy signals it on the encode thread's copy stream, the blend submission waits for and advances it on the Vulkan queue, and a CUDA-side wait orders the encode after the blend on the session's bound IO stream — no CPU sync anywhere, so cursor frames keep the stream-ordered fast path. Each ring slot gets its own command buffer + descriptor set (written once) so several ordered blends can be in flight; cursor-bitmap uploads and teardown quiesce through the timeline. Drivers without the timeline export keep the previous CPU-synced blend, and any bring-up or per-frame failure still degrades to "no cursor", never a dropped frame. Also: the blocking multi-plane copies (the escalated/pipelined mode and the non-stream-ordered fallback) now enqueue every plane and pay ONE stream sync instead of one per plane (NV12 2→1, YUV444 3→1) — each exposed wait costs scheduling latency under GPU contention, which is what makes the escalation's blocking copies self-reinforcing. Verified on the RTX 5070 Ti box (driver 610.43.03): all 12 nvenc_cuda on-hardware smokes green, including the new nvenc_cuda_cursor_blend_stream_ordered (6 cursor AUs, all ordered, across a bitmap-serial flip); host suite 301/301; clippy --all-targets -D warnings clean; struct layouts of the hand-flattened cuda.h params asserted in tests. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 20:05:27 +02:00
enricobuehlerandClaude Fable 5	751d1de506	fix(encode/windows): a stale PUNKTFUNK_ENCODER pin no longer wedges a conflicting GPU selection ... On a hybrid box, picking a GPU in the web console whose vendor contradicts a host.env PUNKTFUNK_ENCODER pin produced an unrecoverable session: the pin won backend selection while the adapter followed the console, the wrong-vendor encoder failed deterministically at submit, the reset ladder burned its 5 in-place rebuilds on it, and the client reconnected into the identical wall forever (~10 s per cycle, no visible reason). Three legs: - windows_resolved_backend() now reconciles: a hardware pin whose vendor contradicts the selected GPU is overridden by the adapter-derived backend (capture + encode share one adapter, so honoring the pin can only fail); open_video warns loudly when a pin loses. The reconciliation is a pure, unit-tested table (resolve_windows_backend). - the QSV wrong-adapter bind is typed TerminalEncoderError, and the stream loop's reset ladder ends the session immediately on it instead of feeding a deterministic config error 5 futile rebuilds. - the un-pinned path was already correct (verified on-glass: NVIDIA preference + no pin = stable AV1 10-bit HDR on NVENC), so the override simply takes the conflict case onto that path. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 16:53:19 +02:00
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 Fable 5	fc335b39e9	fix(host/encode): negotiate the cursor around what the encoder can blend ... EncoderCaps::blends_cursor's contract said the HOST must fall back to capturer-side compositing when a cursor-as-metadata session lands on an encoder that can't composite — but that host half was never built: open_video warned and the session streamed WITHOUT a pointer (confirmed on the VAAPI dmabuf and libav-NVENC CUDA paths; latent on vulkan RGB-direct/native-NV12). The negotiation is now caps-aware, ahead of capture, on both planes: * pf-encode grows cursor_blend_capable() — the pre-open dispatch mirror (sibling of linux_native_nv12_ok) answering whether the resolved backend composites frame.cursor; its pure core is test-pinned arm by arm. * Native plane: handshake::cursor_forward grants the cursor channel only where the resolved backend can blend (the capture-mouse flip makes the host draw the pointer on demand); denied sessions keep the pre-channel path — the compositor EMBEDS the pointer, never cursorless, never doubled. The Welcome's HOST_CAP_CURSOR bit is computed once and read back at both session-wiring sites instead of recomputed. SessionPlan::output_format additionally keeps every cursor-blend session off producer-native NV12 (the arm with no CSC to fold a cursor into), and vulkan RGB-direct now yields to a cursor-blend session even when pinned (EFC cannot composite; the open logs the override). Windows plans cursor_blend=false via the new shared cursor_blend_for() rule — the IDD capturer composites the pointer itself, and asking the encoder anyway fired the blends-cursor warn spuriously on every cursor-channel session. * GameStream plane: the hardcoded cursor_blend=true is gone. The portal source asks for cursor-as-metadata only when the resolved backend blends, otherwise negotiates an Embedded pointer (choose_cursor_mode's new ladder); the capturer pool now also keys on that mode. The virtual-output source passes false — its capture embeds the pointer where it can. The per-arm warns in vulkan_video (RGB-direct, native-NV12) are now structurally unreachable and removed. open_video's post-open check stays as the single backstop for what planning cannot see: a Vulkan-open falling back to VAAPI mid-session, and the gamescope residual (no embedded mode exists there, so a never-blending backend — H.264-on-AMD VAAPI, software — still streams cursorless; fixing that needs a compositing stage, deliberately not built in this pass). Zero-copy is preserved throughout — every fallback is a capture-negotiation change, never a readback. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 10:50:33 +02:00
enricobuehlerandClaude Fable 5	f495b201e1	fix(encode): delete the write-only EncoderCaps::supports_hdr_metadata ... A caps field nothing reads is a contract nobody honors — and this one shipped write-only: its single reader anywhere in the workspace was a hardware-gated assertion inside pf-encode's own AMF smoke test. Both planes send the static HDR grade out-of-band unconditionally (the native 0xCE datagram per keyframe, the GameStream 0x010e control message), every first-party client reads exclusively that path, and none parse in-band SEI — so the host decision the field was reserved for (suppress out-of-band when the encoder embeds) can never validly exist. The field's doc contract had also rotted in two directions: it claimed set_hdr_meta no-ops when false (native AMF and QSV consume it regardless) and that only Windows direct-NVENC attaches in-band metadata (AMF and QSV do too). The in-band SEI/OBU emission itself is untouched — it stays a bonus for stock decoders, documented at the emit sites; the trait docs now describe the real routing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 10:48:07 +02:00
enricobuehlerandClaude Fable 5	232b6d6be2	test(encode/vaapi): extract the open-time decision logic and pin it with unit tests ... The fallback backend under Vulkan Video — and the only AMD/Intel H.264 and 10-bit/HDR encoder — had 1,300 lines, 26 unsafe blocks, and zero tests. The device-free decisions now live in named functions with their contracts pinned: the entrypoint ladder + LP_MODE latch round-trip (the cross-GPU session-killer and the 8-bit-pins-10-bit under-advertisement are both key'd tests now), the PUNKTFUNK_VAAPI_LOW_POWER / _ASYNC_DEPTH grammars, the VUI ↔ scale_vaapi colour agreement (the Mesa-BT.601 hue-shift pin), the honest-downgrade depth table, the HEVC-Main10-only explicit profile, and the 10-bit probe gate. Probe + CPU-path encode round-trip ride along as #[ignore]d hardware smokes in the house style. No FFI plumbing was chased; no behavior changes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 10:29:31 +02:00
enricobuehlerandClaude Opus 5	cc848479c4	test(pf-encode): re-point the cpu_img size-change smoke at the CSC guard's contract ... vulkan_cpu_img_survives_a_source_size_change drove MISMATCHED source sizes through the then-lenient CSC arm as its vehicle for the staging cache hazard (format-only-keyed cpu_img → OOB copy while submit said Ok). e3354b6d's guard — correctly the equality check every sibling arm always had, against the MODE, not the coded extent, so the padded render-vs-coded tolerance in the direct arms is untouched — makes that scenario unrepresentable through submit and broke the test on main (.25 layers baseline read 13/13 instead of 14/12). Replaced by vulkan_csc_refuses_a_mismatched_source: refusal pinned in BOTH directions, plus the property that actually needs proving — a refused submit does not WEDGE the session (the bail lands after step 1's frame-type bookkeeping; the next well-sized frame must still encode, and an AU must come out). Verified on the 780M under validation layers: 8/8 vulkan tests, full-suite baseline restored to 14/12. The WP4.2 size-keyed staging stays as belt-and-braces; the hazard it fixed is now structurally unreachable through submit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:20:37 +02:00
enricobuehlerandClaude Opus 5	bf9386ecb2	test(pf-encode): pin the typed-EINVAL classifier's chain-survival contract (Phase 8) ... Rides on 25765c53 (the concurrent session landed the same typed-errno fix first — this branch's twin commit was dropped in the rebase; these are its surviving residuals): - Two tests pinning what the ladder's step-down rests on: the typed ffmpeg::Error survives with_context layers as a downcastable source (an eager format! anywhere between open_with and the ladder would silently break it), and the phrase WITHOUT the type no longer classifies. - The CudaHw::new eager-format guard note: those bail!s must NOT be converted to typed errors — a hwdevice/hwframes EINVAL is a config error no bitrate can fix, and enrolling it would burn ~10 doomed opens before surfacing the real failure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:13:49 +02:00
enricobuehlerandClaude Opus 5	bf9fb3fb22	fix(pf-encode): enable VK_EXT_queue_family_foreign for the dmabuf acquires (Phase 8) ... Both Linux Vulkan encode backends named QUEUE_FAMILY_FOREIGN_EXT as the acquire barriers' src family without ever enabling the extension — spec-invalid on every device, tolerated by RADV. The audit filed vulkan_video's three sites; pyrowave's fresh-import acquire had the identical defect on its own device (critic catch). Enable when advertised (a fresh open-time enumerate — the rgb probe's is a probe-local and skipped entirely on native-NV12, so there was nothing to reuse; pf-presenter/dmabuf.rs is the in-repo precedent that already enables this extension). Not advertised → the core-1.1 QUEUE_FAMILY_EXTERNAL conservative substitute, chosen once at open and warn-logged (no fleet hardware takes that arm; such devices were never valid targets before). All four sites are acquire-only (src=FOREIGN, EXCLUSIVE images, oldLayout=UNDEFINED) — the swap is index-only. On-glass: 780M under validation layers — vulkan smokes + pyrowave smokes green, FOREIGN advertised and enabled, no fallback engaged. Shared ext_advertised helper in vk_util (cfg = the union of both consumers) with a unit test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:08:44 +02:00
enricobuehlerandClaude Opus 5	1cefd37603	fix(pf-encode): arbitrate NVENC split-encode vs sub-frame readback (Phase 8) ... Verified against nvEncodeAPI.h's own splitEncodeMode doc (user-prompted — the audit's 'exclusive for HEVC' one-liner deserved checking): - H.264: split 'is not applicable' — hard-DISABLE the mode so the written config, CeilingKey, the split diagnostic log and the rejection-retry stay truthful (the retry used to re-open a byte-identical session after an H.264 'split rejection'). The libav path's operator arm gains the codec gate its auto arm always had. - HEVC: split 'not supported if … subframe mode' — when WE force split (TWO/THREE/AUTO_FORCED, the 4K120 throughput lever), sub-frame yields with a logged escape (PUNKTFUNK_SPLIT_ENCODE=0 chooses sub-frame). ⚠ Keyed on FORCED modes only, never != DISABLE: AUTO(0) is the resolver's fallthrough for every sub-950Mpix session, and the wider key would have disarmed the Phase-3 chunked-poll feature fleet-wide (critic catch). Under AUTO the driver arbitrates — the shipped state. - AV1: untouched — per-tile sub-frame + split are legal together. The arbitration is a pure nvenc_core fn called by each backend BEFORE the ladder, the ceiling key and the chunked-poll latch — all three see the post-arbitration truth. A drop inside build_init_params would have left poll_chunk busy-polling its whole budget every AU (numSlices stays 0 without reportSliceOffsets; both loop exits dead — critic catch). Linux latches subframe_forced beside subframe_on at query_caps (no env re-reads after open); Windows records the arbitrated state so reconfigure presents exactly the params the open had (also closes the pre-existing mid-session env-flip hazard there). Truth-table tests in nvenc_core; PUNKTFUNK_NVENC_SUBFRAME documented (it never was); PUNKTFUNK_SPLIT_ENCODE row updated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 10:08:44 +02:00
enricobuehlerandClaude Fable 5	25765c53ec	fix(encode): classify libav-NVENC open failures by errno, not English strerror text ... The bitrate-probe ladder stepped down on format!("{e:#}").contains( "Invalid argument") — an English substring over the WHOLE context chain, which also fired on any other wrapped EINVAL (e.g. a CUDA-context errno) and gated a ~10-step ladder on strerror wording. The root ffmpeg::Error survives the anyhow chain; downcast and match Error::Other{errno:EINVAL} instead. Same fix for the intra-refresh ENOSYS probe in the open path. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 01:05:24 +02:00
enricobuehlerandClaude Fable 5	e3354b6d5d	fix(encode/vulkan): guard the CSC source dimensions, and bound reset()'s wait ... The CSC path was the only backend arm that took frame.width/height on trust: the shader samples with clamped 1:1 texelFetch, so a mismatched frame silently streamed a cropped/edge-padded picture where every sibling errors into the encoder-rebuild path. The import cache now also carries the extent it imported at (a (st_dev, st_ino) hit alone doesn't prove the allocation still matches) and is dropped on reset(). reset() opened with an untimed device_wait_idle on the one thread whose every other wait is capped at ENCODE_FENCE_TIMEOUT_NS for exactly this reason — reset() runs BECAUSE the GPU looks wedged. Both vulkan-video and pyrowave now bound the wait and report "no in-place rebuild" on timeout instead of parking recovery on the suspect device; Drop keeps the unbounded wait (teardown must stay memory-safe against a wedged device). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 01:05:10 +02:00
enricobuehlerandClaude Opus 5	28f8fc71c4	refactor(pf-encode): split vulkan_video's construction tail into vk_build.rs (WP7.5) ... The ~820-line tail of free builders — make_frame/make_frame_csc/ make_frame_common, make_video_image, probe_rgb_direct, the H.265/AV1 parameter-set writers and the AV1 bit-writer — moves to a #[path] child module, the amf_sys.rs shape: the child sees the parent's private items (Frame and friends), so the split costs zero visibility churn. Six parent-called items went pub(super); five stay child-private (dead_code is per-item and each is used within the child). vulkan_video.rs drops 5,292 → 4,489 lines and the construction unsafe gets its own review surface; steady-state encode logic stays in the parent. ⚠ Trap recorded for future child-module splits: inline `use super::X` statements INSIDE moved fn bodies silently change meaning (super shifts one level) — vk_av1_encode/vk_valve_rgb imports needed crate:: paths. Proven on-glass, not just compiled: all 8 vulkan GPU smokes green under the validation layers on the 780M post-split (H.265 + AV1, RGB-direct, CSC, CPU paths — every moved constructor exercised). nvenc_cuda.rs and qsv.rs are DECLINED the same treatment, with evidence in the handoff doc: no equivalent self-contained seam — their candidate regions are ~150-line loader/accessor clusters interleaved with the encoders' own state types, and a thin-forwarder impl split is exactly the churn a no-defect phase penalizes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	bc5ec5105c	refactor(pf-encode): one Linux backend resolver, consumed by dispatch AND mirrors (WP7.6) ... The Linux backend decision existed as open_video_backend's string match plus five partial hand-copies (the zero-copy-plane gate, the pyro advertisement gate, the software advertisement pin, the vulkan pref ceiling, resolved_backend_is_gpu). Windows solved this long ago — windows_resolved_backend() is consumed by its dispatch AND its mirrors, with labels still stamped at the open sites. Linux now has the twin: resolve_linux_backend (pure, lazy auto probe) + linux_resolved_backend (config wrapper, unknown→auto exactly as every mirror's old `_` arm). ⚠ This deliberately DEVIATES from the audit's shadow-assertion prescription, on both critics' findings: the shadow had no execution venue (open_video had ZERO test call sites; shipped hosts are --release) — unfalsifiable ceremony — and the file's own Windows half proves dispatch-consumes-resolver is safe: the mgmt record is protected by the label-from-the-open-site convention, not by resolver avoidance. One consumed table beats two tables plus an inert cross-check. Preservation riders from the critique, all applied: - pref_ceiling KEEPS its cfg!(vulkan-encode) branch (the resolver is feature-blind; dropping it re-creates advertise-then-die-at-open). - linux_zero_copy_is_vaapi's Vulkan|Software arm preserves the old `_` fallthrough EXACTLY — the vulkan-on-NVIDIA capture-plane mismatch and the software twin are FILED in the design doc, not fixed here. - resolved_backend_is_gpu splits as linux + not(any(windows, linux)) — never a target list, so no exotic target loses the fn. - The auto probe is lazy (impl FnOnce) — explicit prefs stay zero-probe (/serverinfo polls through these mirrors), pinned by a panicking closure in the resolver test. New coverage: the full alias table pinned, and a GPU-free dispatch test through the real open_video_backend (software arm, vendored openh264) — its first test call site anywhere. Config-latch seam guarded loudly. Cross-crate mirrors recorded out of scope in the design doc: session_plan::resolve_encoder, gamestream/serverinfo.rs base_codec_mode_support, capture.rs's "pyrowave" string. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	cb69cd3b8c	refactor(pf-encode): move the AMF C-ABI mirror to its own file (WP7.4) ... The ~410-line hand-mirrored AMF vtable ABI was already isolated in an inline `mod sys` — the remaining value of the audit's 'best split in the crate' is the FILE boundary: amf.rs drops 3379 → 2965 lines and the pure unsafe-FFI surface (25 unsafe fns, zero policy) is reviewable in isolation, which is the crate's stated review goal. Pure move: `#[path = "amf_sys.rs"] mod sys;` keeps the module name and every `sys::` call site byte-identical; the module was self-contained (only `use std::ffi::c_void`, no super:: references). The banner became the file's module docs; contents de-indented one level — rustfmt-clean on the first check, which is what proves the move byte-exact. Gated on .173: all five clippy combos + the amf-qsv,qsv test leg (38 passed — the live AMF matrix on real VCN silicon among them). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	9491cc8759	refactor(pf-encode): extract the range-family RFI recovery policy (WP7.2) ... The two direct-NVENC backends carried hand-copied twins of the same loss-recovery decision: range validity, covering-range dedup, DPB window, clamp — ~30 duplicated lines each. The decision now lives once as nvenc_core::plan_range_recovery (the range half of WP7.2; the slot half is enc/rfi.rs), pure and unit-tested; each backend keeps its session gate, its unsafe per-timestamp driver loop, and its state stores. The step order is load-bearing and now pinned by tests: the covering dedup runs with the UNCLAMPED last and BEFORE the DPB window (a covered re-ask never touches the driver even when the range has since aged out of the DPB), the boundary at next_ts - RFI_DPB is inclusive, and the Invalidate carries the CLAMPED last — which is also what the caller records in last_rfi_range, exactly as the inline code stored it. A driver failure mid-loop still returns false with NO range recorded and no anchor armed. Decline deliberately clears nothing (neither twin touched pending_anchor on decline — same shape as Vulkan's non-clear, opposite of AMF/QSV; do not harmonize). The exact-cover → Covered test records EXISTING behavior including that a covered range survives a forced IDR with zero driver calls — a recorded fact, not an endorsement. RFI_DPB's import leaves both twins: its only per-backend use was the arithmetic that moved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	9f1e648e4e	refactor(pf-encode): extract the slot-family RFI recovery policy (WP7.2) ... AMF (user-LTR bitfield), QSV (mfxExtRefListCtrl) and Vulkan Video (the app-owned DPB slot table) each hand-implemented the same loss-recovery decision: distrust every reference encoded at-or-after the loss start, anchor on the newest one strictly older. Three copies had already diverged once — the fecbec2d taint sweep reached AMF/QSV a commit before the Vulkan backend was carved out, and Vulkan shipped without it. The decision now lives once in enc/rfi.rs, pure and unit-tested (this path had zero coverage and is the loss-recovery path); every mechanism — how a force is applied, how distrust is persisted — stays in its backend. Behavior-preservation notes, each critic-verified against the shipped code: - Callers feed only currently-trusted references; taint (>= loss) and anchor (< loss) predicates are disjoint, so pre-sweep-view pick == post-sweep-table pick on every input. Tie-break preserved (first entry wins == the strict '>' all three used, ascending slot order). - plan_slot_recovery delegates its pick half to pick_anchor, which keeps both items live on every leg (pick_anchor's only external caller is Linux+vulkan-encode; dead_code is an item lint) and makes 'anchor chosen from the taint snapshot' structural. - The decline arms are deliberately NOT uniform and stay put: AMF/QSV clear an un-consumed pending_force; Vulkan leaves pending_loss armed (a stale arm re-resolves at frame-build into the healing IDR) — now pinned in comments on both sides. - Vulkan's frame-build site is a pick-only re-run by design (the arm carries the loss start, not the slot); pick_recovery_slot is deleted and its tests migrated 1:1 into the shared module. Test-count deltas are expected: the rfi tests now run on every Windows combo (amf.rs is featureless there) and on the Linux feature leg. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Opus 5	d28fb1282b	test(pf-encode): guard TrackedEncoder's forwarding completeness (WP7.7, cheap half) ... A defaulted Encoder method that TrackedEncoder doesn't forward silently no-ops through the wrapper — the host loop only ever holds the wrapped box, so the feature dies for every session with nothing in the logs. The trap has bitten three times (set_wire_chunking's §4.4 chunking probe, set_pipelined's LN3 escalation, applied_bitrate_bps's ABR truth), and every Phase 7 consolidation that adds a trait method re-arms it. Source-text parse of the trait and the forwarding impl (both top-level rustfmt items: block ends at the first column-0 brace, method names sit on 'fn '-prefixed lines), then set equality — the reverse direction is already a compile error, so equality == completeness. Mutation-verified: removing set_wire_chunking's forward fails naming exactly that method. 16/16 today. Limit stated in the test doc: name-set equality only — a forward whose body delegates to the WRONG inner method still passes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehlerandClaude Fable 5	ffc7aec91a	feat(encode/pyrowave): log which GPU pyrowave picked — the selection stays put, by decision ... WP4.5's device-selection half, closed as the observability intermediate after TWO selection designs died in adversarial review: - Attempt #1 (d26bcf05, withdrawn): match pf_gpu::selected_gpu(). Its Linux auto arm answers "the NVIDIA GPU" whenever /dev/nvidiactl exists, moving the encoder off the iGPU that can import the compositor's dmabufs on an Intel-compositor + NVIDIA-present laptop — import failures feed the process-wide raw-dmabuf latch, which never un-latches. - Attempt #2 (this session, withdrawn before commit): anchor on the PUNKTFUNK_RENDER_NODE-else-renderD128 node via VK_EXT_physical_device_drm. Render minors are driver-BIND-ORDER artifacts, not display topology: on the common AMD-iGPU + NVIDIA-display desktop, in-tree amdgpu binds before out-of-tree nvidia, so the anchor deterministically picks the idle iGPU while the compositor allocates on NVIDIA — the same latch, opposite polarity, behind a success-looking log. The correct oracle is evidence of which device ALLOCATED the capture buffers — producer identity from the capture negotiation, threaded per session into this open. Until that plumbing exists, selection stays first-usable, both call sites still share one selector (pure over the device list, so capture_modifiers and open_inner cannot diverge — including across an in-place resize's re-open, which does not renegotiate capture), and the open logs ONE greppable line: picked vendor/device, the anchor node and its owner (DRM render major/minor, VK_EXT_pci_bus_info fallback), and the console's selected GPU. A wrong-device session on a multi-GPU host used to be completely invisible; a field report can now show it. No WARN arm on purpose: the wrong-pick direction inverts between the laptop and desktop topologies, so a mismatch is not evidence of a wrong pick, and a warning that fires forever on healthy hosts teaches people to ignore warnings. Decision recorded against the audit's framing: manual console GPU selection stays unhonored by pyrowave on Linux (the Windows twin honors it) — honoring console-mutable state without per-session threading is what made attempt #1 unsafe. Verified on the 780M: the line resolves all three identities (1002:15bf x3, DRM-props match live); full pyrowave on-glass suite green; selection behaviour byte-for-byte unchanged. WP4.5 (device half). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 19:22:28 +02:00
enricobuehlerandClaude Fable 5	46935bf0a5	fix(encode/vulkan): VBR instead of CBR — the driver was stuffing ~98% filler into every calm stream ... Second attempt at WP6.3; the first (ce543668) was withdrawn after its tight CBR window measured as a 36x bandwidth regression (97% filler NALs). The correction that unlocked this one: that measurement's BASELINE row was an 8-frame artifact. Under the shipped 1000ms/500ms CBR window a calm stream overflows the CPB once the initial fill drains (~30 frames at 10Mbps/60fps) and RADV then pads every frame to the exact rate share, forever. Measured on the 780M (1280x720@60, 10Mbps, calm content): 64 frames = 97.5% filler; 300 frames = 5.63MB at 98.5% filler where this commit ships 83KB at 0%. AV1: 99.6% -> 0%. The status quo was ~the full target bitrate of zeros on every idle AMD/Intel Vulkan-encode desktop and Steam Deck — and stuffing to exactly the target permanently satisfied the ABR calm brake (actual >= 3/4 * current), the ratchet WP6.3's withdrawal feared from the tight window, live in the shipped code all along. The fix reads VkVideoEncodeCapabilitiesKHR::rateControlModes (previously ignored — rateControlMode was hardcoded CBR with no capability check) and installs VBR with average == max plus the house ~1-frame window (vbv_window_ms, PUNKTFUNK_VBV_FRAMES-scaled) when the driver advertises VBR. VBR permits underspend, the exact missing degree of freedom: Vulkan exposes no filler-suppression control (AMF's filler_data=false / NVENC's default-off have no VK equivalent), so the MODE is the only lever. CBR-only drivers keep the loose window untouched — tightening it under CBR just starts the stuffing 30 frames earlier. Drivers advertising neither mode (ANV per current Mesa) keep the pre-existing CBR install, now WARN-logged. No pacing claim, deliberately: burst A/B on the 780M is byte-identical between 1000ms CBR and 17ms VBR (max AU 1.19MB in both) — this firmware ignores the window for QP decisions entirely. The payload is filler elimination. PUNKTFUNK_VULKAN_RC=cbr|vbr is the field escape hatch and the on-box A/B control (two withdrawn attempts bought that insurance). Also on the same caps struct: maxBitrate is now read and clamps open + retarget (RADV reports 1 Gbps — within 5% of the 4K120 ABR targets), and applied_bitrate_bps() reports the encoder-side truth (pending-first, so the session loop's read right after reconfigure_bitrate sees the clamp) — without it a binding clamp would feed the ABR a phantom base, the trap the trait doc names. And the one-frame VUID-vkCmdBeginVideoCodingKHR-pBeginInfo-08254 violation found in the withdrawal review: record_submit promoted a pending retarget into self.bitrate BEFORE recording whenever first_frame was set, so after a mid-stream reset() (which preserves the pending rate and rc_installed) the begin-coding declaration named a rate the session had not installed — and the two triggers, ABR retarget and the stall watchdog, correlate. Now the declaration always names the session's current rate and the RESET install carries the pending one via its own struct; promotion stays in post_submit_bookkeeping. The extended validation-layer test reproduces the retarget-then-reset coincidence: exactly one 08254 on the pre-fix build, zero on this one (RADV PHOENIX, on glass). Gates: docker amd64 legs green; Windows .173 seven legs (34 passed); .25 full-suite parity vs origin/main (identical CUDA-only failures) + all 9 vulkan on-glass tests + validation layers clean. WP6.3, plus WP7.1's ms-form half (vbv_window_ms). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 19:22:12 +02:00
enricobuehlerandClaude Opus 5	fdded5b8c3	fix(encode/pyrowave): refuse a frame that isn't the session's mode ... PyroWave never checked frame dimensions against the session, and it applies no alignment — `width`/`height` are the negotiated mode verbatim — so a mismatched frame was encoded edge-smeared or cropped, silently, forever. Every other Linux backend already refuses exactly this, with this shape, in `submit`: libav-NVENC (`linux/mod.rs`), VAAPI (`vaapi.rs`) and openh264 (`sw.rs`) all carry the same `ensure!`. PyroWave was the only one that didn't. That is the justification; an earlier draft cited `vulkan_video.rs` instead, which is the weaker precedent — it bails in its Dmabuf arms only, and its CSC path and CPU arm have no dimension guard at all. Mostly this is a wrong-picture bug and not a memory-safety one: `rgb2yuv.comp` clamps every fetch with `min(p, textureSize - 1)` and the CPU arm uploads `min(len, need)` into a session-sized image. But it also closes a narrow real hazard that was not in the filing: `import_cached` keys on `(st_dev, st_ino)` and returns the cached `VkImage` on a hit WITHOUT rechecking the extent, and unlike the capture side it is never cleared on a renegotiation — so a dmabuf inode recycled across a shrinking renegotiation would hand the encoder an image sized for the old, larger allocation. This check closes that route. ⚠ Recorded at the code because it changes the failure mode, not just the detection: a mismatch is NOT always transient. A compositor-initiated PipeWire renegotiation updates the capturer's size in place and signals nothing the encode loop reads, so it can be a permanent new steady state — and `reset()` reopens at the same dimensions by construction, so the host's five-reset budget cannot recover (~3.1 s of frozen stream, then the session ends) where before it would have streamed on with a wrong picture. For a real mode change that trade is clearly right; for a 16-row KWin mismatch it is not, and the proper fix is for the host to classify this error as a PIPELINE rebuild rather than an encoder reset. Filed, not done here. The device-selection half of WP4.5 was written, reviewed and WITHDRAWN — see the handoff doc. Matching the selected render GPU regresses the hybrid Intel-compositor + NVIDIA-present topology this project has a live field report for, because `selected_gpu()` answers NVIDIA whenever `/dev/nvidiactl` exists regardless of where capture actually runs. WP4.5 (dimension half). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 17:56:38 +02:00
enricobuehlerandClaude Opus 5	9fe9cbbf07	perf(encode/vulkan): build the padded RGB frame in the staging memory, not beside it ... The RGB-direct CPU-upload path allocated and zero-filled a whole padded frame on every submit, filled it row by row, then memcpy'd the whole thing into the mapped staging buffer. The zero-fill was entirely dead: the row loop writes every byte of every row, and rows past the source re-copy the last source row. So the frame paid for an allocation, a page-fault storm over fresh pages, a full zero-fill, and two full-frame copies where one would do. Map first, write the padded rows straight into the mapping. Nothing reads back from the destination — the row source is always the caller's buffer, never the staging memory — so writing into (write-combined) host memory costs nothing extra, and `make_host_buffer` allocates HOST_COHERENT, so the writes need no flush before the transfer reads them. Measured on real RDNA3 780M silicon, release build, `submit` alone, 400 frames x 3 rounds: - **1920x1080** (rows padded to 1088): p50 2315 -> **1725 us** (-25%), p99 2819 -> **1972 us** (-30%), and the spread (p99-min) tightens 739 -> 483 us. - **1366x768 -> 1408x768** (BOTH axes padded, so the column tail loop runs): p50 1013 -> **926 us** (-8%), p99 1303 -> **1110 us** (-15%). This is the one case where the new code could have been slower — 4-byte stores straight into write-combined memory — and it is not. - **CONTROL, 1280x720** (64x16-aligned, so the branch is never entered): p50 692 vs 692 us. No delta, which is what makes the two above attributable to this change rather than to anything else on the branch. The branch is reached by any RGB-direct session at a mode that is not 64x16 aligned, whenever capture delivers CPU frames (the default Linux capture path is dmabuf and never enters it). 1080p qualifies, since 1080 aligns to 1088. ⚠ An earlier draft of this message claimed "33 MB at 4K" — that is wrong: 3840 and 2160 are both already aligned, so 4K UHD never enters this branch at all. The large case is an ultrawide like 3440x1440 -> 3456x1440, ~20 MB. Three things this deliberately does NOT do: - The extent guards stay scoped to the `pad` branch. The CSC path deliberately supports a source SMALLER than the encode extent — its shader clamps at sample time — so a guard hoisted above the branch would break it. - Every fallible step stays above the map. An error raised between `map_memory` and `unmap_memory` would strand the mapping for the life of the slot's staging buffer, and the next frame's `map_memory` on it then violates VUID-vkMapMemory-memory-00678. (The filed "two exits above the map leak Vulkan objects" hazard is separately already gone: `47a23bec` moved that unwind into `make_host_buffer`.) - It adds guards rather than removing them: a zero source axis made `sh - 1` underflow, and "cannot fail after the map" has to be true by construction. Three corrections to an earlier draft, all found by review of that draft: - The `dw*dh*4 == need` precondition was a `debug_assert!` placed BELOW the map. That is wrong twice: it made the only check on the slice length vanish from the builds that ship, and a fired assert would have unwound past `unmap_memory` — the exact failure the bullet above says was designed out. It is now a real checked `?` above the map. - `need` was `(iw * ih * 4) as u64`: a u32 multiply widened after the fact, which agreed with the usize slice length only up to ~32768x32768. The old code's `min(need)` was a hard backstop against exactly that and the rewrite dropped it. Now widened before the multiply, matching `read_slot`'s existing discipline. - The extent guard now runs BEFORE the payload-length guard, so the usize `sw * sh * 4` cannot overflow on a garbage frame header. WP6.2(a). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 17:56:22 +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
enricobuehler	0044649b19	fix(encode/nvenc): codec-gate the HEVC 4:4:4 union write, and stop it eating the 10-bit arm ... `encodeCodecConfig` is a C union, so the `hevcConfig` writes in the 4:4:4 branch are only meaningful on an HEVC session — on H.264 or AV1 they reinterpret that codec's own config bytes. The branch was gated purely on `chroma_444 && full_chroma_input` with no codec test, and stayed non-UB only because `lib.rs` degrades 4:4:4 for non-HEVC codecs: a two-file invariant with nothing asserting it, on the path BOTH direct-NVENC backends take. The audit filed that much. What it did not note is that the same shape hides a second bug: this is an `if`/`else if`, so a non-HEVC session that arrived with `chroma_444` set took the HEVC branch and skipped the per-codec bit-depth arm entirely — ending up with neither HEVC 4:4:4 (wrong for it) nor its own 10-bit configuration (simply absent). AV1 would have lost `pixelBitDepthMinus8`/`inputPixelBitDepthMinus8` silently. Non-HEVC now falls through to the arm that knows what to do with it, and an unexpected request is logged rather than swallowed. Adds two tests that need no GPU — `apply_low_latency_config` is pure config authoring, so an AV1 session can assert it never receives the HEVC FREXT profile GUID (an INVALID_PARAM at open) and that its own depth still lands, with an HEVC case guarding the good path. ⚠ `NV_ENC_CONFIG` must NOT be `mem::zeroed` in those tests: `frameFieldMode`/`mvPrecision` are C enums whose discriminants start at 1, so all-zero is not a valid value and Rust's zero-init check ABORTS the process (SIGABRT, caught by the Linux gate). They seed it from `Default` the same way `build_config` does before overwriting from the driver preset. Worth knowing before writing any further test against these SDK types. Verified: Linux gate L1-L4 green (39 tests, the two new ones among them) and the full Windows gate on .173 — 7 legs. Note the Windows test leg runs `--features qsv`, so these tests only execute on the Linux leg; the Windows legs prove the change compiles in all five feature combinations.	2026-07-25 16:52:40 +02:00
enricobuehler	b3f8803ea3	fix(encode/qsv): stop advertising intra-refresh the driver silently dropped ... `ir_active` was `cfg.intra_refresh && set.co2.is_some()` — i.e. "we asked for it", not "we got it". Both `Query` and `Init` can return MFX_WRN_INCOMPATIBLE_VIDEO_PARAM, a WARNING the open path deliberately accepts, while dropping the intra-refresh wave on the floor. That lie is not cosmetic. `ir_active` feeds `EncoderCaps::intra_refresh`, so the session advertises gradual refresh to the client; the client then stops asking for the IDRs it would otherwise request on packet loss, and a lost frame gets concealed instead of repaired. The stream degrades exactly when recovery matters. Now confirmed against the driver: a best-effort `GetVideoParam` with a CodingOption2 buffer chained on, read back for `IntRefType`. Deliberately a SEPARATE query rather than a buffer attached to the existing `BufferSizeInKB` call (which is what the audit finding suggested) — that value backs every bitstream allocation, and a runtime that disliked the chained buffer would take it down with the readback. A failure here costs only the verdict and resolves conservatively (trust the request), so the worst case is the previous behaviour. Verified on Intel UHD 750 (.42), which is where the Intel on-glass run originally caught this: with PUNKTFUNK_INTRA_REFRESH=1, H.264 now logs "silently dropped intra-refresh (GetVideoParam reports IntRefType=0)" and advertises it OFF, while H.265 on the same GPU stays ON — it is genuinely active there. Per-codec, so it could never have been decided statically. 8 live QSV tests pass. Gated on .173: clippy -D warnings at nvenc,amf-qsv,qsv (host + pf-encode --all-targets), amf-qsv without qsv, qsv alone, no-features, cargo test --features qsv, rustfmt — all green. qsv.rs is Windows-only so the Linux legs do not compile it. Closes WP3.2(c), the last Phase 3 item that was hardware-blocked.	2026-07-25 16:52:40 +02:00
enricobuehlerandClaude Fable 5	47a23bec12	fix(encode/vulkan): unwind every open/import leak, and serve 24-bpp CPU instead of dying on it ... Phase 5's Linux half (audit WP5.1 + WP5.4), each item shaped by the review that rejected the obvious fix: Dmabuf import unwind (vk_util): every failure after create_image leaked the VkImage, and the dup'd dmabuf fd leaked as a raw i32. The sharp edge is that a SUCCESSFUL vkAllocateMemory transfers fd ownership to Vulkan (vkFreeMemory closes it), so the naive close-on-error is a double close that clobbers whatever unrelated descriptor recycled the number. The dup now lives in an OwnedFd released exactly in the allocate-success arm; every other path drops it once, and bind/view failures free image+memory. PyroWave open unwind: open_inner had ~20 fallible steps that each leaked everything before them (instance, device, pyrowave objects, the whole CSC pipeline). Rather than a parallel teardown guard — whose reviewed hazards were a null-unsafe pyrowave_encoder_destroy and a drifting duplicate of Drop — Self is now constructed right after create_device with every later resource null, and the existing Drop (wait-idle first, pw_enc null-guarded, delete-nullptr and VK_NULL_HANDLE destroys are no-ops) is the single unwind path for error and normal teardown alike. The ensure_cpu_rgb staging twins (create/allocate/bind, both backends) and the RGB-direct make_view pair get the same discipline via a shared make_host_buffer. Observed on hardware: 32 forced import failures, zero fd drift (the new import_failure_leaks_no_fds smoke on RADV). 24-bpp CPU service (WP5.4): pixel_to_vk had no mapping for the packed Rgb/Bgr the PipeWire portal negotiates, so a session committed to a path the backend could not serve and died at its first frame. The filed open-gate was rejected as a half-mirror — the dmabuf axis is keyed by fourcc at submit, unknowable at open — so instead the CPU axis is SERVED: a 3-to-4 expand at the staging upload (normalize_cpu_rgb, the CPU twin of WP1.4's swscale expand), order-preserving for the CSC samplers and BGRA-forced for the RGB-direct encode source, whose session pictureFormat is B8G8R8A8 — the on-glass run caught R-first sources violating VUID-vkCmdEncodeVideoKHR-pEncodeInfo-08207, a mismatch that predates this change for plain Rgbx CPU sources. The dmabuf axis feeds pf-zerocopy's raw-dmabuf degrade latch (3efbe416) from both Vulkan import caches — deterministic refusals flip capture to CPU delivery, which now serves every format capture produces; transient OOM and native-NV12 sessions are excluded. RECORDING-state hygiene: the fallible recording prefix (cursor prep, import, staging) now resets the command buffer on error instead of leaving it RECORDING for the next begin to trip VUID-vkBeginCommandBuffer-commandBuffer-00049; PyroWave's submit-level blanket reset is replaced by the same scoped shape, closing its fence-timeout hole where a reset hit a PENDING buffer (VUID-vkResetCommandBuffer-commandBuffer-00045). Verified: docker linux/amd64 4-leg gate green; RADV 780M on-glass under the validation layers at 1920x1080 — all 10 smokes pass (including the new 24-bpp CSC + RGB-direct legs and both channel orders), decoded colour truth checked with ffmpeg, and the only remaining validation messages are the two documented VALVE-extension layer gaps plus a pre-existing pyrowave shader/feature mismatch now filed in the planning doc. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 16:51:27 +02:00
enricobuehlerandClaude Fable 5	e0e845b7df	fix(encode/pyrowave): pin the NT-handle import contract to consume-on-success-only ... import_plane closed the shared NT handle on every pyrowave_image_create failure, believing pyrowave only consumes it on success. The vendored truth was messier: Granite's allocator closed by-reference handles UNCONDITIONALLY after the first vkAllocateMemory — success AND failure — while failures before the allocator (validation, vkCreateImage, no memory type) left the handle open, and both classes surface as the same error code. So the call site could not know whether to close, and an allocate-stage failure double-closed a possibly-recycled handle value (audit WP5.3). The filed fix (DuplicateHandle + close the original unconditionally) traded the double close for a guaranteed leak on every pre-allocate failure and left the ambiguity in place. Patch 0006 fixes the callee instead: the allocator never closes a caller's handle, and pyrowave_image_create consumes it exactly at its success return — which is what pyrowave.h ("take ownership and close the HANDLE on import") documents, and what Granite's semaphore import already did, so import_fence was correct as written and the two paths now share one contract. The close-on-failure in import_plane is thereby correct on EVERY path, including a vkBindImageMemory failure after a successful allocate. Bonus fix recorded in the patch: the allocator's block-recycling retry loop used to re-run vkAllocateMemory with import_info still pointing at the just-closed handle. Both-platform gates green; pyrowave_win_smoke (.173, 34/34) re-validates the live import path against the rebuilt vendored C++. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-25 16:51:00 +02:00