1461 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	f06b3d9d04	feat(console): the console answers a mouse and a finger, and host cards get a menu ... Two gaps, both found on the shared Linux/Windows console UI. **The settings tabs only moved for a gamepad.** They were bound to the shoulder buttons and to PgUp/PgDn, and the legend spells PgUp/PgDn out only when NO pad is attached — so with a controller plugged in a keyboard user had nothing to find, and a mouse or a touchscreen could not change section at all. The root cause was wider than the strip: `SkiaOverlay::handle_event` matched only `KeyDown` and `TextInput`, so every mouse button, wheel and touch contact fell past the console into the run loop, which routes pointer input exclusively at `stream.capture` — `None` while you are browsing. Nothing in the console had ever been clickable. Making just the pills answer would not have helped either: the settings screen is opened with X from home, so a mouse could not reach it. So the console gets a real pointer path: - `Overlay::handle_pointer` carries mouse/touch in SWAPCHAIN PIXELS. The run loop converts (it owns the window, hence the display scale, and mouse coordinates are logical while fingers are normalised); the console then hit-tests the very rects it drew last frame. Only DIRECT touch devices are offered — an indirect trackpad already drives the mouse. - Widgets act on the PRESS, not the release. The list and both carousels scroll the focused item toward the centre, so what you pressed has slid out from under your finger by the time it lifts; press-to-act has no such race and there is no drag gesture to compete with. - The hint bar became the pointer's button bar. It is already the console's only on-screen statement of what the face buttons do, and a pointer has none — so its Confirm/Back/Secondary/Tertiary pills are clickable on every screen, which is what puts Settings and Library within reach of a mouse at all. - Tab / Shift+Tab change section; PgUp/PgDn still do, and the keyboard legend now reads "Tab". - Right-click is Back everywhere, EXCEPT at the root: B there quits the launcher and a right-click is far easier to fire by accident. Quitting stays explicit. **Host cards had no menu.** Every other client hangs Wake / Copy link / Edit / Forget off a host card; the console could add a host and connect to one, and that was all — so a renamed machine or a fat-fingered address stayed wrong forever unless you opened a desktop shell. UP on a saved tile now opens that host's menu, the same gesture the Android console uses, on the one direction a horizontal carousel leaves free. - `ConsoleCmd::UpdateHost` edits the stored host IN PLACE. Removing and re-adding would silently drop the fingerprint, the learned MAC, the pinned cards and the profile binding — that is a rename, not a re-pair. - `ConsoleCmd::ForgetHost` drops it; if it is still advertising it returns as a discovered, unpaired row, which is the honest state. - Forget arms on the first press and fires on the second. The other clients forget outright; a console is driven by a thumbstick from across a room. - A pinned profile card offers only Unpin. It is a shortcut, not a second host, and offering to forget the host from it would blur exactly the distinction a pin draws. - "Edit…" REPLACES the menu on the stack rather than stacking over it, so Back from the editor doesn't land on a menu describing the host as it was before the edit. Verified in the pf-lxcheck2 container (this crate compiles to nothing on macOS — a bare `cargo check` there is vacuous): plain build and `clippy --all-targets` clean under `-D warnings`, 72 tests pass. Seven are new, and cover the reported bug directly — a press on a pill selects that tab, and each tab still keeps its own cursor when a pointer is what switched it.	2026-08-07 12:36:22 +02:00
enricobuehler	5aa1ca392e	Merge pull request 'fix(host/encode): the Windows host build stops failing on unused split-encode helpers' (#86) from worktree-fix-winhost-clippy-dead-code into main ... Reviewed-on: #86	2026-08-07 09:22:57 +00:00
enricobuehler	f49f22a292	fix(host/encode): the Windows host build stops failing on unused split-encode helpers ... The Windows host job died in its clippy step: eight items in pf-encode's split-encode policy (`SPLIT_AUTO`..`SPLIT_DISABLE`, `resolve_split_mode`, `max_forced_split_mode`, `clamp_to_engines`) were reported as never used, and `-D warnings` turns that into a build failure. Nothing about the encoder was wrong — the items simply have no reader in one particular build of the crate, and nothing was telling the compiler that. `codec.rs` compiles on every platform, but the split policy only ever has a caller on Linux (the libav NVENC path reads it unconditionally) or on Windows with the `nvenc` feature (the direct-SDK backend). A featureless Windows build of pf-encode has neither, so every item in the cluster is genuinely dead there. Gate them on the union of their callers' cfgs, the way `forced_split_width` next door already is. The step lints pf-encode itself WITH `--features nvenc,amf-qsv,qsv`, where the items are live, which is why this was invisible there; the failure came from the next command in the same step, `clippy -p pf-vdisplay`, which pulls pf-encode in as a plain default-features dependency. Same item-level `dead_code` trap this crate has now hit five times. Verified: default-features pf-encode reproduces all eight errors before the change and none after (macOS default-features exercises the identical "cluster has no caller" arm as featureless Windows — the two remaining errors there, `vbv_frames_env` and a redundant closure call, are pre-existing and macOS-only; both items have real Windows callers). Linux default-features and Linux + nvenc `--all-targets` both stay clean, so the callers still see the policy. `cargo fmt` clean.	2026-08-07 11:11:15 +02:00
enricobuehler	bbbcf321e5	Merge origin/main into worktree-native-decode-m0 ... main moved 93 commits while this branch ran. Two conflicts, both where main's new work sat next to M10's excision: packaging/flatpak/io.unom.Punktfunk.yml — main added the vendored gamescope WSI layer (the only route to HDR on a Deck) and, before it, a vulkan-headers module. Took both: this branch predates them and deletes neither. But the headers module's stated consumer was pf-ffvk's bindgen over FFmpeg's hwcontext_vulkan.h, and M10 deleted pf-ffvk — so it now reads as dead weight to the next person. It is not: the WSI layer IS a Vulkan layer, compiles against those headers, and builds after it, so module order is the dependency. Rewrote the rationale to say so, including why dropping it would be expensive to discover — flatpak.yml has no pull_request: trigger, so a manifest break reaches main invisibly and a tag then ships no Linux flatpak. Also recorded that the native decoder needs nothing from there: pf-vkdecode reaches Vulkan through ash, which is pure Rust bindings, no bindgen, no C headers. crates/pf-console-ui/src/screens/settings.rs — main restructured the gamepad settings into TABS, which removed the per-row section headers; this branch had left Some("Video") untouched from the merge base and added the pre-M10 decoder migration next to it. Git could not tell those apart. Took main's structure (no header, its deliberate change) with this branch's migration layered on: a stored `vulkan`, `vaapi` or `d3d11va` names no preset in the tabbed list and would render as "—", then silently rewrite the user's preference on the next save. Gates on the merged tree, Linux container: fmt clean; cargo check --workspace --all-targets clean; clippy --workspace --all-targets -D warnings clean; tests green across pf-vkdecode (187), pf-client-core (163), pf-console-ui (58) and punktfunk-host (447 of 448 — the one failure is the pre-existing gamestream::stream::tests::sender_delivers_batches, a UDP-loopback EINTR under qemu that fails identically on a pristine HEAD).	2026-08-07 10:50:32 +02:00
enricobuehler	3608de25ed	Merge pull request 'fix(ci): runner hygiene stops eating its own jobs' (#84) from worktree-ci-runner-hygiene into main ... Reviewed-on: #84	2026-08-07 08:37:42 +00:00
enricobuehler	75dfab1d35	fix(host): a reconnecting session inherits its launch instead of starting it again ... Two defects, found while tracing M8's codec-fallback reconnect and recorded verbatim in d5e23146 as out of scope there. A client retry re-sends Hello::launch verbatim, and the host launched unconditionally. Steam and Epic URIs hide it — the launcher focuses the running copy — but a gog:/custom: target really did start a SECOND COPY of the game. The client cannot fix it by dropping the field: on Linux the per-session gamescope is re-adopted through pf-vdisplay's display registry, whose reuse key includes the launch command, so a retry without it orphans the running game. And the retry minted a fresh launch_stamp, so procscan refused to adopt a game started more than 2 s before it — the game was minutes old, so a reconnected session had no game-exit detection for the rest of its life. Both are now answered by a launch registry (launchreg.rs): one record per (client fingerprint, library id), written at launch time and INDEPENDENT OF THE TERMINATION POLICY. That independence is the point. The existing fingerprint-keyed reclaim only exists under GameOnSessionEnd::Always — under the default Keep, arm_grace is never called, so nothing was recorded at all in exactly the configuration the defect was reported in. The design correction that matters: at launch time the host knows NOTHING about the game's processes — that is the premise of the whole lease design. So identity flows BACKWARDS from the watcher, which publishes the concrete ProcRefs it adopted, and the registry's liveness is Scanner::alive over that recorded set, re-verified by (pid, start). Never a re-scan by spec: a later scan would find a copy the player started since, and adopting that is what procscan's rule 1 forbids. The published set is never cleared on exit either — the last thing the watcher saw is what makes a quit game read Gone rather than "no opinion", which is how it becomes relaunchable at once instead of being suppressed for the window. On rule 1: an adopting session inherits the older floor, so its own find() admits what the ORIGINAL session's lease already admitted for its whole life. That is the correct reading of "the same launch, continued" and not a new exposure — rule 1 forbids adopting processes that PREDATE the launch, and these postdate it. The match rule is pure and total (covers()): liveness is authoritative where it has an opinion, and only Unknown falls through to the tie-breakers — a live holder, or a 90 s in-flight window for a re-dial while the launcher is still working. Gone beats both, deliberately: a title that crashed on startup must relaunch at once. Both race orders are handled and neither is relied on. Teardown-first takes the Running arm; handshake-first (a fast re-dial on a half-open connection) takes the holders>0 arm, and the old teardown then sees superseded() and does nothing — without which, under Always, it would arm a grace the new session had already passed its chance to reprieve, and the reaper would kill the new session's game. Two tradeoffs taken deliberately: a custom: command with no detection hints stays Unknown forever, so that reconnect trades game-exit detection for not double-spawning; and IN_FLIGHT_WINDOW is a fixed 90 s rather than sharing disconnect_grace_seconds, because the two have opposite failure costs — grace being wrong leaves a game running, this being wrong silently swallows a launch the player asked for. Gates: fmt clean; clippy -p punktfunk-host --all-targets -D warnings green in the Linux container; 418 passed, +9 exactly the new tests. One failure, gamestream::stream::tests::sender_delivers_batches, is pre-existing and environmental — a UDP-loopback EINTR under qemu at stream.rs:1697, outside every hunk in this change (the last is at +448), and it fails identically on a pristine HEAD. I reproduced both the failure and its location myself rather than taking it on report. ⚠ OWED: the Windows leg is COMPILE-UNVERIFIED. cargo check --target x86_64-pc-windows-msvc dies in ring's C build on macOS and xcheck.sh does not cover punktfunk-host. The Windows edits are small restructures of existing branches plus a bool assignment, reasoned through but seen by no compiler. Run it on .133 before this merges. I narrowed that exposure by inspection afterwards, and it is smaller than the blanket warning suggests. The change presents exactly two things to a Windows compiler that a Linux one did not already see. launchreg gates only alive_count (lines 227/231), whose cfg(any(linux, windows)) arm calls Scanner::system().alive(procs) — the identical call gamelease.rs:563 already makes in code that compiles on Windows today. And the Windows launch arm at native/stream.rs:1666 reads only ungated bindings the Linux arm type-checks thirty lines below it (adopt_launch:1658, spawned_now:1663, launch_claim:1463) and calls only the pre-existing library::launch_title. No new type, no new signature, no Windows-only API. That is an argument, not a compile. The run on .133 is still owed.	2026-08-07 10:14:21 +02:00
enricobuehler	138a1f1b2f	fix(host/windows): the staging-dir SID checks document their unsafe blocks ... clippy's undocumented_unsafe_blocks (deny) flagged the three blocks that 81039581 introduced: the SAFETY comment sat outside the closure, so IsValidSid/EqualSid inside it read as undocumented, and from_raw_parts shared a comment that only covered the GetLengthSid line above it. Windows host clippy is the only leg that lints this cfg(windows) code, red since.	2026-08-07 10:11:04 +02:00
enricobuehler	dee97e893c	fix(vkdecode): the address the driver keeps is now the address we keep ... The AV1 use-after-free fix (cdd1f3ef) stabilised the wrong half. NVIDIA was measured retaining pColorConfig, so StoredParamsAv1 boxed the colour and timing blocks — but OwnedStdAv1SequenceHeader kept the Std struct ITSELF inline, so the pStdSequenceHeader we handed vkCreateVideoSessionParametersKHR was a stack address inside ensure_parameters, dead the moment it returned. The fix worked because of WHICH pointer that driver happened to hold. A driver retaining the outer one instead — no more of a spec violation than retaining pColorConfig was — reproduces the original bug exactly: plausible pictures, wrong content, no error and no counter moved. The same shape was in the shipping codecs, one step further from evidence: the H.264 and H.265 create paths pointed pStdSPSs/pStdPPSs/pStdVPSs at function-local Vecs, and both Add paths handed over the wrapper's inline std field and then moved the wrapper. Those are spec-legal — the object stores copies — and have never misbehaved on the fleet. They are fixed anyway, because that is precisely what was true of H.264/H.265 before the same class of bug was found in them, and a correctness argument that reduces to which vendor we tested is not one. So: the Std struct is boxed inside each owning wrapper (one level out from what _color_backing already did), and the contiguous create-time arrays are now fields of the stored parameters, assembled at their final address. Identical bytes at identical offsets — only where they live changed. The line drawn deliberately, in prose at session.rs:29: Std DATA is pinned; the VkVideoSessionParametersCreateInfoKHR chain itself is not. Retention there would be a different and far more extreme class of driver bug, and pinning it needs a self-referential struct over lifetime-parameterised builders. ⚠ NOT hardware-verified. No GPU has run this — the fleet is unreachable and the 250/250 parity that proved this code bit-exact cannot be re-run. That is why the change is constrained to address stability alone, and why it ships five CPU-only tests instead: three capture the pointer handed to Vulkan, perform the real move, and assert it survives — each verified FAILING first, with genuinely differing addresses, not a tautology. Two more pin the create-array ownership; those fail before the fix as compile errors rather than assertions, because the pre-fix bug there is a dangling pointer and asserting on it is UB. Also: caps.rs claimed the borrow checker pins a profile chain between wire() and its last use. False at exactly one site — decoder.rs took a raw *const, ending the borrow, leaving nothing but inspection to stop a future editor moving the chain before create_query_pool. Correct today, guarded by prose, which is how the first bug shipped. It is now compiler-enforced: the pointer write and the create call live inside one helper that takes the profile by reference, so the borrow is held across both by the signature. An audit cleared the chains otherwise — no entry point we pass one to retains it. Gates: fmt clean; clippy -D warnings over pf-vkdecode AND pf-client-core in the Linux container (its only real consumer, which cannot build on macOS at all — wol.rs uses deps its manifest gates to linux/windows, so workspace clippy has never passed there and does not now); 187 lib tests green on Linux, up from 182.	2026-08-07 09:57:39 +02:00
enricobuehler	93b8528d09	Merge pull request 'fix(encode): NVENC split-frame encode never engaged for HDR — engage it, measured' (#83) from worktree-nvenc-s1-split-reconfigure into main ... Reviewed-on: #83	2026-08-07 07:57:29 +00:00
enricobuehler	b5205fef52	Merge pull request 'fix(client/apple): audio stops crackling on lossy, bunching Wi-Fi' (#82) from worktree-audio-wifi-distortion into main ... Reviewed-on: #82	2026-08-07 07:37:19 +00:00
enricobuehler	515a3c2912	feat(pf-encode): wire split arbitration on Windows too ... The last coverage gap, and only worth building once S1 proved it possible: the Windows backend drives NV_ENC_DEVICE_TYPE_DIRECTX, and an in-place splitEncodeMode change had never been tested there. It works (071358cb), so the arbiter is now ungated from Linux-only to the union of both direct-SDK backends and wired into windows/nvenc.rs: the submit stamp, the feed hook on AU completion, apply_split_mode, split_key, arm_split_arbiter, and set_send_spread_us. Same gates as Linux, and they are correctness conditions rather than preferences: opt-in while it earns trust, an operator PUNKTFUNK_SPLIT_ENCODE pin always wins, a cached verdict short-circuits, >=2 engines, never H.264, and the sub-frame trade is only entered when the host has actually reported a send spread to price it with. The one Windows-specific difference is that `async_rt` is a real possibility here (opt-in two-thread retrieve) and the arbiter refuses it, because under pipelined retrieve the submit->AU span includes queue depth and the comparison would be noise. ⚠ Two more instances of the same item-level dead_code trap, caught by the Windows run and not by reasoning -- that is now 4 and 5: - `clear_split_verdicts` is called only by the Linux on-hw test, so it is dead on Windows; gated to `all(test, target_os = "linux")`. - The arbiter methods first landed inside `impl Encoder` rather than the inherent impl (the anchor I used, supports_chunked_poll, is a trait method), which the compiler caught as "not a member of trait Encoder". Verified .158 (RTX 4090 / Ada, driver 610.88, D3D11): clippy --features nvenc --all-targets -D warnings clean, and 2 on-hardware NVENC tests green including S1 re-run with the arbitration code in place (engines=2 latched, DISABLE->TWO_FORCED accepted, zero IDRs, reverse accepted). Verified .21: clippy clean with AND without the nvenc feature, 65 unit tests, 25/25 NVENC on-hardware. fmt clean.	2026-08-07 09:28:34 +02:00
enricobuehler	81d257c7fa	fix(client/audio): the in-core decoder conceals lost packets like every other client ... A field report: game audio on a MacBook (M1) crackles over Wi-Fi against a host that plays clean to other clients. The Apple client is the one client whose Opus decode lives in core (punktfunk_connection_next_audio_pcm — AudioToolbox has no multistream path), and that decoder only ever decoded packets that ARRIVED. The Linux, Windows and Android decode loops all feed an AudioGapTracker and synthesize libopus packet-loss concealment for every packet the wire lost; the in-core path had the tracker sitting unused in the same crate. So on Apple every lost 5 ms datagram — at ~200 packets/s over Wi-Fi, a steady trickle — landed in the playout ring as a hard time-domain gap: a click per loss, sustained crackle under real loss. The redundant-plane recovery (0xD2) hides single losses when the host grants it, which is exactly why the survivors are the burstier gaps that need concealing most. The decode now runs through the same accounting as everyone else: concealed frames land in front of the arriving frame in one contiguous buffer (the embedder just writes it to its ring), a DTX marker advances the accounting without being decoded, and the output buffer is pre-sized for a full concealment run so the borrow-until-next-call pointer can never dangle. Unit-tested against real libopus: gaps, duplicates, DTX-after-loss, and the 50 ms cap.	2026-08-07 09:23:15 +02:00
enricobuehler	071358cbf7	test(pf-encode): S1 on WINDOWS/D3D11 — passes; Windows arbitration is buildable ... Everything the split-encode programme rests on had been proven only on Linux/CUDA. The Windows backend drives NV_ENC_DEVICE_TYPE_DIRECTX, so none of it transferred by assumption -- and if the driver refused an in-place split change there, Windows arbitration would simply not be buildable. RESULT on the RTX Windows box (RTX 4090 / AD102, driver 610.88, D3D11): engines=2, latched by query_caps (WP1.1's probe, validated on Windows hardware rather than inferred from Linux) DISABLE -> TWO_FORCED via nvEncReconfigureEncoder, resetEncoder=0: ACCEPTED, ZERO IDRs, and the reverse likewise. So the foundation now holds across three platform x arch x driver combinations: Linux/CUDA Blackwell 610.57.04, Linux/CUDA Ada 610.43.03, Windows/D3D11 Ada 610.88. ⭐ UNBLOCKS ALL FUTURE WINDOWS ON-HARDWARE TESTING. pf-encode's nvenc test binaries were believed unlinkable on Windows ("NvEncodeAPICreateInstance unresolved", recorded as pre-existing and worked around by only ever running clippy there). They link fine given the SDK import library: RUSTFLAGS='-L native=C:\Users\Public\nvenc -l nvencodeapi' `-L` alone is not enough -- without a `-l` nothing pulls the archive in, which is why the earlier attempt still failed. ⚠ This is TEST-BINARY-LOCAL and must stay that way: production deliberately dlopens NVENC rather than link-loading it, and an unconditional link-load is the known crash class on non-NVIDIA Windows hosts. ⚠ Box note: the RTX Windows box answers on .158, not the .173 in its memory entry, and `Administrator@` there resets the connection right after SSH2_MSG_SERVICE_ACCEPT in a way that reads like the host being down -- the working login is "Enrico Bühler"@192.168.1.158.	2026-08-07 09:23:05 +02:00
enricobuehler	0430d907bb	fix(pf-encode): gate forced_split_width to Linux — WP4 broke the Windows build ... The verification gap flagged in 01294e3a was real. `.133` came back up and the WP4 commit failed Windows clippy: `forced_split_width` is used only by the libav NVENC path (`enc/linux/mod.rs`), but it was added to `codec.rs`, which compiles everywhere -- so it is dead code on Windows and `-D warnings` rejects it. Third time this crate has hit the same item-level dead_code trap (see `subframe_env_forced`, and the arbiter items in `nvenc_core`), and the third time it was caught by actually running the Windows check rather than by reasoning about it. The comment on the gate says so, since the pattern is clearly not self-evident from the code. Verified .21: clippy -D warnings clean both WITH and WITHOUT the nvenc feature, 65 unit tests. Verified .133: Windows clippy --features nvenc --all-targets -D warnings clean, zero errors, zero dead_code. fmt clean.	2026-08-07 09:01:05 +02:00
enricobuehler	5c05246098	feat: M10 — FFmpeg is gone from the client ... cargo tree -p punktfunk-client-session finds no ffmpeg. The host still does, which is the whole point: pf-encode keeps libavcodec unconditionally and no host workflow, packaging script or licence file was touched. Deleted: crates/pf-ffvk, video_vulkan.rs, video_vaapi.rs, video_libav.rs, the libavcodec half of video_d3d11.rs, the av_log machinery, ffmpeg::codec::Id as the decoder's vocabulary (the quic CODEC_* wire constants now serve, which is why the evidence table was keyed on them), DecodedImage::VkFrame and ::Dmabuf, the presenter's AVVkFrame lane, and the ffmpeg-fallback feature with everything behind it. DrmFrameGuard collapses from an enum to a newtype, which removes an unsafe impl Send. Roughly 25,000 lines. Then the CI, packaging, licensing and docs work the plan's §6 lists: the Windows workflows lose FFMPEG_DIR, PF_FFVK_VULKAN_INCLUDE and their PATH prepend; the MSIX loses its DLL wildcard; the client .deb stops emitting libav sonames on its own because depends come from dpkg-shlibdeps; arch, flatpak and nix drop the dependency; and the README's "FFmpeg 7 or 8" contract narrows to the host. Three defects reached users' machines in the first cut, and none was in the deletion itself. All three desktop Settings UIs offer vulkan, vaapi and d3d11va as stored decoder values, so those strings sit in shipped settings files today. Refusing them by name — which is the correct rule for a stale pin — would have bricked every upgraded client whose owner ever touched that dropdown. They now migrate onto the native rung for the same hardware family, at decoder construction AND at each dialog's lookup, because a legacy value that matches no preset displays as "Automatic" and silently rewrites the user's preference on the next save. M9's evidence filter was deleted on the argument that with no libavcodec twin below, barring an unproven rung removes hardware decode rather than moving down one rung. That is true on Windows and false on Linux for Intel and every unknown vendor id, where prefer_vulkan_first is false and the order is native-vaapi → native-vk: a rung that has decoded nothing anywhere sitting above one that is 250/250 on three drivers. Every Intel Linux desktop would have moved from libavcodec VAAPI, shipping for years, onto pf-vaadec by default — and a rung that constructs and then produces wrong pixels leaves only by the error-streak demotion, which this codebase already documents as not tripping on the B580's strobing. The filter is restored as a narrow, pure, testable rule: an unproven rung yields to a proven one, and to nothing else. Windows deliberately passes no rung below, because that vendor family is the one with a measured wrong-pixel report against Vulkan decode, and trading no evidence for evidence of corruption is the wrong direction. And the notices still said FFmpeg was bundled. The root file is what both desktop clients include_str! and what the MSIX ships, three lines under the new card saying no FFmpeg is bundled; Apple's Acknowledgements said it too, on iOS, tvOS and macOS. The generator now emits four per-client files scoped by transitive closure — 0 FFmpeg mentions in each, verified — while the root file keeps it for the host. That also ends the standing false attribution of ffmpeg-next, GTK4, windows-rs and the NVENC SDK to an iPhone. Windows has no reachable box, so it was compiled instead: a cross clippy at -D warnings on x86_64 and aarch64-pc-windows-msvc with the C toolchain stubbed so build scripts run without linking. That gate immediately caught an include_str! path one directory too deep, which nothing else could have. Gates: container clippy -D warnings, 160 tests, workspace check, both Windows targets clean, client ffmpeg count 0 and host 2. The four decode crates are untouched, so the hardware rungs' 250/250 stands. ⚠ Owed and unrun: no GPU has executed any of this milestone. M8's on-glass software check, M7's D3D11 and VAAPI AV1 hardware legs, and M9's field bake all still want hardware, and the bake window and criteria remain the user's.	2026-08-07 08:58:47 +02:00
enricobuehler	01294e3a53	refactor(pf-encode): WP4 — one split policy, shared with the libav path ... The libav NVENC path carried its own inline copy of the split decision and had already drifted from the direct-SDK selector: it hard-coded a 2-way split regardless of engine count, and had no depth rule at all. That is the drift the shared resolver was extracted to prevent, and the copy quietly reintroduced it. Routing it through `resolve_split_mode` needed the policy to MOVE. `nvenc_core` is gated on `feature = "nvenc"`, but the libav path is precisely the build where that feature is OFF (`PUNKTFUNK_NVENC_DIRECT=0`, and the featureless packages -- the packaging gap this project has been bitten by before). So resolve_split_mode / max_forced_split_mode / clamp_to_engines, plus a new `forced_split_width`, now live in `codec.rs`, which is always compiled and already owned SPLIT_FORCE_PIXEL_RATE. That means the NV_ENC_SPLIT_ENCODE_MODE values had to be hand-written as plain constants, since the SDK enum does not exist without the feature. They are therefore pinned: `nvenc_split_constants_match_the_sdk` (feature-gated, the only place both are visible at once) asserts all five against the real enum, so the copies cannot rot. ⚠ Only the FORCED outcomes are actionable on the libav side -- libavcodec's `split_encode_mode` AVOption is its own vocabulary and our DISABLE is the NVENC enum's 15, which would be meaningless there. DISABLE/AUTO both map to "leave the option unset", which is exactly today's behaviour (unset = the driver's auto). `engines = 0` ("not probed") maps to 2-way, preserving what that site always did; a 3-NVENC part gets the wider split only on the direct-SDK path, which is the one that actually probes. ⚠⚠ VERIFICATION GAP: .133 went down mid-change (no ping), so the WINDOWS leg is UNVERIFIED. This matters more than usual -- the Windows backend imported resolve_split_mode from nvenc_core and that import had to move too, which a grep caught rather than a compiler. Re-run before trusting it: cargo clippy -p pf-encode --features nvenc --all-targets -- -D warnings Verified .21: clippy -D warnings clean BOTH with and without the nvenc feature (the featureless build is the whole point of the move) and with nvenc,vulkan-encode; 65 unit tests incl. the new constant-parity test; 25/25 NVENC on-hardware; punktfunk-host clippy clean. fmt clean.	2026-08-07 08:16:35 +02:00
enricobuehler	38554c1c6e	feat(client): M9's code half — native first, FFmpeg behind an off-by-default feature ... `ffmpeg-fallback` on pf-client-core, default off on the crate. With it off the libavcodec rungs are not compiled, pf-ffvk leaves the dependency graph, and no ladder or demotion arm names them; with it on each sits exactly where it sits today, directly below its native twin. That is the switch which makes M10 a deletion rather than a redesign. The bake window and the regression criteria are the user's, per the plan, and nothing here claims the M9 gate is met. The hard part was not the feature, it was honesty. Two of the four native rungs have never decoded a frame on any hardware — native VAAPI at all, and native D3D11VA's AV1 leg — and making those the default would assert evidence that does not exist. So admission is per rung and per codec: a pair with hardware evidence joins `auto` always; a pair without it joins only when nothing proven is left below it (a build with no FFmpeg twin, where the alternative is not a proven rung but the CPU) or when the user asks with PUNKTFUNK_NATIVE_FIRST=1. Pins bypass it, so a lab run can still reach any rung. The shipping default therefore changes in exactly three ways, all evidence-backed: AV1 `auto` takes native Vulkan (250/250 bit-identical on an RTX 5070 Ti), Windows H.264/H.265 `auto` takes native D3D11VA above its FFmpeg twin (parity on two GPUs plus a 30-minute soak), and a failing Vulkan rung on Windows demotes to native D3D11VA first. Everything unproven is byte-for-byte as it was. The evidence state is written where it cannot rot: a table in video.rs's module docs, the same facts in code as `native_evidence()`, a test asserting them in both feature states, and a per-session log line carrying the rung, the codec, whether hardware has verified that pair and the evidence string — at WARN when it has not. A support engineer reading a log can now tell proven from assumed without asking anyone. Termination needed a new guarantee. With the FFmpeg twins gone, two native rungs in opposite per-vendor orders could hand a session back and forth forever, so a rung once entered is never re-entered and the walk is monotone to software. The never-delivered fall-through still works: with the feature on it is unchanged, and with it off it is redundant, because the next candidate already IS the rung below. ⚠ ffmpeg-next remains a hard dependency of pf-client-core, deliberately. What is left off-feature is three type-level residues — the codec-id vocabulary, the AVVkFrame guard that is pf-presenter's public import, and a pixel-format in one signature — every one of them an M10 §6 line item. Deleting them here would mean deleting the presenter's FFmpeg lane, 55 call sites, in a milestone whose gates cannot run a GPU. No libavcodec decoder is opened in a default build. ⚠ video_d3d11.rs was gated item by item rather than wholesale, and nothing in this tree compiles it — it needs a Windows check before anyone trusts it. Gates: both feature states, container clippy -D warnings and 158/159 tests, workspace check. The four decode crates are untouched, so the hardware rungs' 250/250 stands.	2026-08-07 07:00:29 +02:00
enricobuehler	d5e23146c0	feat(client): M8 — the software rung is openh264 and rav1d, and swscale is gone ... The ladder's last rung no longer runs FFmpeg. H.264 decodes through openh264, AV1 through rav1d, and HEVC is refused outright: no permissively licensed software HEVC decoder exists, so an HEVC session that exhausts its hardware rungs now tears down and re-dials advertising HEVC-less caps, and the host picks H.264. The plan calls that a first-class path; it is one. swscale is deleted, and with it the BT.601 default that its correction code existed to undo. Colour on the H.264 lane now comes from the same pf-bitstream planner every hardware rung submits from — openh264 reports no VUI at all — and AV1's comes per-picture from the sequence header. One colour source, one CSC: the old default is unrepresentable rather than merely fixed. Frames reach the presenter as three tightly-packed planes through the planar CSC pass, which had to be un-gated from the pyrowave feature and its device probe, since the last rung must exist on devices that failed that probe. rav1d rather than the dav1d crate, deliberately and against the plan's literal wording: dav1d-sys is system-deps-only, so it would add a system library and a .pc file to every client package — in the milestone family whose excision checklist exists to delete exactly that. rav1d is the same decoder, same licence, statically linked. The cost is honest: no-asm builds on both decoders, and software throughput is still unmeasured. The colour test is the milestone's exit criterion, so it is built to fail. Three fixtures, and a mutation check: hardcoding the swscale default turns the red bar to [255,24,0], and swapping Cb/Cr turns red to blue — a silent error no metadata assertion could catch. Review then disproved the range half of it numerically: with eight saturated bars, decoding the full-range fixture with the wrong range gives max error ZERO, because a mismatch only pushes values outside [0,1] where the shader clamps. A mid-tone was added; the wrong range now costs 11, well past the tolerance. The exit criterion I set was satisfiable by a test that proved nothing. Two blocking defects, both emergent rather than local. Software AV1 on a 10-bit stream never reached its typed refusal: rav1d is built 8-bit-only and returns ENOPROTOOPT, which the send loop turned into a generic error, so the pump's typed downcast missed and every AU failed identically — a permanent freeze on precisely the shipping case, since AV1 is advertised only where hardware AV1 exists and hardware AV1 plus HDR is Main 10. The shape is now read from the sequence header before any byte reaches the decoder, exactly as the H.264 leg reads the active SPS. And the new Reconnecting phase was the first state that is not streaming, not connecting, and still holding a live stream — which opened all three guards that had made a second launch impossible. Pressing A assigned over `stream` where every other site shuts down first, and StreamState has no Drop, so the old pump was detached: a second live session still submitting to a Vulkan device that gets destroyed underneath it. Nothing about the reconnect was wrong in isolation; the defect lived between a new state and three guards nobody re-examined. Start is now defensive and the retry raises the connecting modal, so the UI matches the state and B can cancel. Also closed: retry_caps was computed, tested and never applied, so a shape refusal could end a session reporting no codec available while a working retry existed; the retry inherited force_software sticky-true, landing an HEVC→H.264 fallback on software H.264 with working hardware H.264; it re-dialled with a stale mode; the CPU present arm had no survivable-failure handling where the pyrowave arm — same pass — has it; HEVC is no longer advertised when the decoder is pinned to software; and the software rung now feeds the recovery-point SEI it already had in hand to the re-anchor gate. ⚠ Two host-side gaps found while tracing, neither in scope here: Hello::launch is NOT idempotent (gog:/custom: targets spawn a second copy on a retry; the field is kept verbatim because dropping it orphans the gamescope display whose reuse key includes the command), and a reconnected session can never adopt a game predating its own launch stamp, so it has no game-exit detection. ⚠ OWED: the on-glass software run. ~200 lines of new Vulkan on a path that only runs because the GPU already failed, and no driver has seen it. The review's minimum check is sync validation enabled, a non-multiple-of-16 mode, a mid-session resize and demotion, and both colour matrices. Gates: container clippy -D warnings over four crates, 236 tests, workspace check. pf-vkdecode and pf-bitstream are byte-for-byte untouched, so the hardware rungs' 250/250 stands.	2026-08-07 06:18:23 +02:00
enricobuehler	a20cd44ed4	feat(client): native VAAPI AV1 — the third rung, and two failure-path defects ... The libva AV1 layouts, the AuPlan conversion and the Linux rung's AV1 arm, completing AV1 across all three hardware backends. Pin-only. Layouts measured, not transcribed: the committed probe grew the AV1 structures and every size and offset it printed against libva 2.23.0 is a compile-time assertion. Three that a hand-count gets wrong — the picture buffer is align 8 because anchor_frames_list is a pointer, inserting seven bytes of padding; seg_info and film_grain_info carry their own padding tails inside the parent; and THREE of AV1's six bit-field unions are narrower than a word (one uint8_t, two uint16_t), so a u32 packer over any of them writes through its neighbour. This is the fifth way this program has had to spell "which pictures does this frame use", and it is unlike the other four: ref_frame_map is indexed by SLOT and holds actual VASurfaceIDs rather than indices into anything, ref_frame_idx is indexed by NAME and holds slots taken from the header — not from the plan's refs, where a lost reference leaves a hole and a hole is not a slot — global motion is picture-level, and there is no per-reference size field at all. Established from va_dec_av1.h and libavcodec's vaapi_av1.c, and stated in the module docs so the next reader does not re-derive it. Review verified the whole happy path — every layout assertion re-measured, every packer width and bit position, the reference convention, the num_elements buffer shape — and found both defects on FAILURE paths, neither reachable on the vendored vector. A conversion refusal permanently desynced the ledger. The mutation block sat after the tile walk, so any tile-shape refusal left the planner holding a picture with no ledger slot — and the resulting UnresolvedReference fires before that block too, so it never repaired. Every later access unit hard-errored until a shown key frame: one lost packet costing a GOP. The arm's own doc already warned that skipping conversion would desynchronise the slot map; the refusal door did exactly what the skip door was written to avoid. The block is hoisted, and a tile-shape refusal on an already-damaged plan is now concealed rather than refused. Fixing that exposed a sharper edge: the conversion can release a slot and reassign it to the refused picture in one call, so the binding would still hold the PREVIOUS picture's surface — a wrong reference rather than a missing one, which nothing downstream could notice. The caller now clears the binding unconditionally on the refusal path. And a damaged frame's surface was never written yet was bound as a reference and left in pending, so a later clean show_existing_frame would claim it with damaged = false and ship uninitialised GPU memory to the presenter — on several drivers another client's framebuffer. The justification quoted half of va_dec_av1.h; its next sentence gives the remedy, which is to point the problematic index at an alternative buffer. Damaged frames now submit as they do on the other two arms, with live surfaces substituted for invalid entries and reported as a bitmask — preferring a reference that really decoded over the decode target, and keeping libavcodec's deliberate all-invalid map on a shown key frame. Film grain is refused rather than decoded wrong: libva wants two surfaces, one ungrained for prediction and one grained for output, and libavcodec allocates a second frame for exactly that. The gate now sits after the mutation block so a grained frame costs itself rather than the GOP, and stays per-AU rather than per-sequence because a stream that merely DECLARES the tool decodes here perfectly. ⚠ Residual, flagged not fixed: a picture decoded from substituted references can still be shown by a later show_existing_frame. It is decoded memory now rather than uninitialised, and it is what the H.264/H.265 arms do, but tracking "this was concealed" through to display needs new session state. Gates: macOS fmt/clippy/125 tests/cargo-doc, container clippy -D warnings over seven crates and 548 tests, workspace check. pf-bitstream's diff is comment-only — verified — so the Vulkan rung's 250/250 stands untouched. Nothing here has decoded a frame: no VAAPI hardware is reachable.	2026-08-07 04:22:23 +02:00
enricobuehler	ef40890c80	feat(client): native D3D11VA AV1 — wired, and four defects it exposed ... The AV1 arm of the native D3D11VA rung, parity-required because today's FFmpeg d3d11va rung already decodes AV1 Profile 0 and the excision must not silently drop it. Pin-only, as that rung is today. decode() walks the temporal unit frame by frame; submit() splits into decode_into and present, because AV1 decodes frames that are never shown. The proven H.264/H.265 body is byte-for-byte unchanged — review diffed it against HEAD mechanically and found only a rename plus one refusal arm — and the VideoProcessorBlt hand-off is untouched. That mattered more than anything else here: those two codecs are hardware-proven, .173 is powered off, and no gate that runs could have caught a regression in them. Every descriptor value comes from libavcodec's dxva2_av1.c read verbatim, not from symmetry with the other codecs: three buffers and no qmatrix (AV1 transmits none), NumMBsInBuffer zero on all three, ConfigBitstreamRaw 1, surface alignment 128, pool +8, and the session sized from the SEQUENCE header's max frame size — sizing from the frame would rebuild the decoder and drop every reference the first time a stream legally resized downward. Two places where following the H.264/HEVC pattern would have been wrong. libav pads the bitstream buffer and grows only its descriptor's DataSize, never a tile's, because a tile's size is exact — charging padding to the last record is corruption, not filler. And the committed tile records were one per tile GROUP spanning the whole OBU, header and frame header included, where libav emits one per TILE addressing the payload past its tile_size_minus_1; the vendored vector is single-tile, so the old tests passed either way. Review then found four more defects in the already-committed conversion, each confirmed against libavcodec AND Chromium's D3D11 AV1 accelerator: Tile widths and heights were the coded minus-1 where the field is a superblock COUNT — every tile declared one superblock short, on every frame, with a comment asserting the opposite of the truth. StatusReportFeedbackNumber must be zero for AV1. Both reference implementations disable it specifically for this codec — libav's note reads "breaks decoding on some drivers (tested on NVIDIA 457.09)", Chromium's "it crashes :|" — while both set it for H.264 and HEVC, which is why this rung's proven codecs never showed it. It would likely have presented as a hang or a rejected submission rather than bad pixels, sending the next session after the tile records instead. frame_refs[].Index is an index INTO RefFrameMapTextureIndex, not a surface index; the neighbouring line already filled that map correctly. Measured: 1636 reference entries on the vendored vector where the two differ. qm_y/u/v need the 0xFF "no matrix" sentinel — 0 is a valid matrix index, and 274 of 274 frames transmit no quantiser matrix, so every one was being dequantized against matrix 0. Also closed: the slot leak the Vulkan rung had already found and documented (a frame refreshing no slot is never reported removed, so nine of them exhaust the ledger); a tile-grid check that could not fire, replaced with libav's own cols*rows guard; per-reference sizes now taken from the reference's own header via RefState rather than the current frame's; and the render size clamped against the decoded picture in both rungs, since AV1 permits a render size larger than the frame. The parity leg was rewired through the real decode path — it previously called the internals directly, so its hidden-frame assertion described the harness's own counter rather than production withholding anything. Gates: macOS fmt/clippy/383 tests, container clippy -D warnings over four crates and 499 tests, and on Windows .133 (.173 is powered off) clean checks plus 97 pf-dxvadec tests. All 8 Vulkan gpu_parity legs re-verified bit-exact on the RTX 5070 Ti after the shared-code change. No AV1 frame has been decoded through this rung anywhere: it needs .173 back.	2026-08-07 03:01:49 +02:00
enricobuehler	185332a866	fix(vkdecode): H.264 and H.265 session parameters own what the driver keeps ... The same use-after-free the AV1 rung was just fixed for, closed in the two rungs that ship. session.rs and session_h265.rs handed their Std parameter sets to vkCreateVideoSessionParametersKHR and dropped the backings when the call returned; NVIDIA 610.57.04 was measured retaining such a pointer to decode-record time, which is what made AV1 diverge on 250 of 250 frames. Nothing was known to be broken here — both rungs are bit-exact on four drivers — but that was luck rather than correctness: the freed blocks happen to still hold the right bytes in that window. The native Vulkan rung sits in the auto ladder above FFmpeg-Vulkan on shipping clients, so this was live code, and its failure mode is silent wrong pixels rather than a crash. StoredParams and StoredParamsH265 hold the parameters object together with every wrapper it points at, so an object whose backing is gone cannot be built. create_parameters_object takes the wrappers by value; the Add arm adopts them only after a successful update, so a failed update drops what it never stored; the Recreate arm replaces, destroys the old object, then drops its backings, written explicitly so the ordering survives later edits. The Add-vs-Recreate decision table and the VPS ledger are untouched — only ownership moved. params.rs still carried the refuted claim as a type-level contract, that Vulkan "copies all parameter data before returning" and keeping the wrapper alive across the call "is the whole obligation". Corrected to the measured truth. The tests are what stop this returning, and each was verified by sabotage: inlining the H.264 PPS box fails at pps pScalingLists, inlining the H.265 SPS DPB box fails at sps pDecPicBufMgr, and making either adopt drop instead of store fails both session tests. Two lessons are recorded in them. Pointer equality cannot be the assertion, because the Std struct carries pointers by value and a stale one compares equal — the read-back is the discriminator, so the tests clobber the dead stack first to make a dangling read deterministic rather than lucky. And the first H.265 draft read six of eight pointers and let the sabotage through, so it now reads every one with a labelled assert. ⚠ One site of this class remains, deliberately: the VkVideoProfileInfoKHR chains, where wire()'s borrow dies with its enclosing block while the object created from it lives on — three session creates, an image, a buffer, and a query pool built from a raw pointer into a stack chain. It spans six modules and all three codecs, and a profile is enums a driver resolves at create time with no per-frame deref, so the risk is materially lower. It wants its own pass with its own hardware verification. Gates: macOS fmt/clippy/196 tests, container clippy -D warnings, pf-vkdecode 182/182 and pf-client-core 140/140. On the RTX 5070 Ti, all 8 gpu_parity legs re-verified green after the change — H.264, H.265, Main 10 and AV1 all still bit-identical to libavcodec.	2026-08-07 01:04:17 +02:00
enricobuehler	cdd1f3efce	fix(vkdecode): AV1 is bit-exact — the bug was a use-after-free, not the driver ... 250/250 frames bit-identical to libavcodec on NVIDIA 610.57.04, and all four other parity legs (H.264, H.265, Main 10, both four-byte-prefix twins) still green. session_av1 built the sequence header, handed pStdSequenceHeader to vkCreateVideoSessionParametersKHR, and dropped the backing the instant the call returned — on the documented assumption that Vulkan copies parameter data before returning. NVIDIA does not. It keeps the pointer and dereferences pColorConfig when a decode is RECORDED. The freed block became our own next allocation, whose bytes read back as mono_chrome = 1, and a monochrome frame skips exactly loop_filter_level[2..3] (AV1 7.14). That is the whole fingerprint two earlier rounds chased: luma bit-exact, chroma off by small amounts, and rewriting the chroma levels in the bitstream changing nothing — the driver read them correctly and then discarded them, because it believed the stream had no chroma. StoredParamsAv1 now holds the parameters object and its Std backing in one value, so an object whose backing is gone is unrepresentable. The road there is worth recording, because two well-evidenced conclusions were wrong before this one was right. A software oracle reproduced the divergence exactly by disabling chroma deblocking, and a GPU probe showed chroma levels [8,12] and [63,63] producing byte-identical output — which looked conclusive and was not. libavcodec's own Vulkan AV1 hwaccel is bit-exact on this same driver, which proved the hardware fine and the defect ours. ffmpeg never hits it: with VK_KHR_video_maintenance2 it uses inline session parameters and never creates a parameters object at all. The proof is direct rather than inferred: a throwaway Vulkan capture layer dumped both submissions and every byte of our AV1 picture info already matched libavcodec's, including the loop filter block; only the session parameters layer differed. Watching the block's address showed correct bytes at create and our next allocation at decode. Ruled out on hardware, so nobody re-tests them: filmGrainSupport, maxCodedExtent, maxDpbSlots/maxActiveReferences, VkVideoDecodeUsageInfoKHR, the tile-start sentinel, the setup slot's SavedOrderHints, a NULL pTimingInfo, and heap luck. Two earlier fixes are confirmed against libavcodec's captured wire bytes and kept: CDEF secondary strengths carry the coded value rather than the spec's in-place fixup, and LoopRestorationSize is log2-based. The refuted driver-ignores-chroma-levels claim is corrected everywhere it was written down, and that probe test now passes and points at the lifetime of everything a submission points at before blaming a vendor. ⚠ Adjacent and NOT fixed: session.rs and session_h265.rs drop their Std backings the same way, and those sets carry embedded pointers too. Both are measured bit-exact on four drivers, so nothing is known to be wrong — but the contract now rests on a driver behaviour measured FALSE for AV1 on a shipping driver. The SAFETY comments asserting it have been corrected; the structure is deliberately untouched pending its own pass. Gates: macOS fmt/clippy/336 tests, container clippy -D warnings, all green; 8/8 gpu_parity and 3/3 gpu_smoke legs verified on the RTX 5070 Ti.	2026-08-07 00:39:34 +02:00
enricobuehler	1062aa780f	test(pf-encode): measure the bits/frame curve — no crossover, split always wins ... WP0's real deliverable, and the hole every previous measurement in this programme had. All prior timings ran against driver-zeroed buffers, so rate control had nothing to code (~300 B/AU against an 833 KB quota) and only the PIXEL-proportional half of the encode cost was ever exercised -- while the 4K60 HDR field report was a BITS/FRAME problem at 6.8 Mbit/frame. Adds `pf_zerocopy::cuda::write_plane_from_host`, the exact mirror of the existing read_plane_to_host. No new loader entry was needed: cuMemcpy2DAsync_v2 was already in the table and CUDA_MEMCPY2D just needed the reverse memory types. Linux-only by construction (pf-zerocopy's `imp` is cfg'd to linux). ⚠ Two harness mistakes found and fixed by looking at bytes/AU rather than trusting the knob: - Pure per-pixel noise is INCOMPRESSIBLE, so a low bitrate target does not produce low bits/frame -- it OVERSHOOTS. At a nominal 50 Mbps the encoder emitted 719 KB/AU against a 104 KB quota, and the three lowest rows of the first sweep all sat at the same ~5.7 Mbit/frame. Sweeping nominal bitrate measures nothing. - So the sweep moves CONTENT DETAIL (block size) instead, and the x-axis is the bits/frame the encoder ACTUALLY produced, never the one requested. 4K60 HEVC 8-bit, real content, single-engine vs forced-2: bits/frame Ada 4090 Blackwell 5070 Ti 0.2-0.3 Mb 4567 -> 2381 1.92x 5549 -> 3552 1.56x ~1.1-1.2 Mb 5060 -> 2626 1.93x 5867 -> 4082 1.44x ~3.3 Mb 8478 -> 4455 1.90x 9286 -> 5862 1.58x ~9.6 Mb 16237 -> 8114 2.00x 16435 -> 9275 1.77x RESULTS. (1) Encode time scales strongly with bits/frame -- 4.6 ms to 16.2 ms across the range on Ada -- confirming the hypothesis' core claim. (2) There is NO CROSSOVER: split wins at every point on both architectures (Ada ~1.9-2.0x and notably flat, Blackwell 1.44-1.77x). So the arbitration's encode-side answer is essentially always "split", which makes the sub-frame handicap the only decision that actually matters -- exactly the part already built and unit-pinned. (3) It corroborates the field capture: at ~6.8 Mbit/frame these curves put single-engine 4K60 around 10-13 ms, and the field report was 10.3 ms on a 4090. That reads as real ASIC time, not the retrieve-queue inflation it might have been. ⚠ Caveat the data itself shows: cost is NOT monotonic in bits/frame alone. The 1px row lands at the HIGHEST bits/frame yet encodes FASTER than the 4px row on both boxes (Ada 10148 vs 16237 us) -- pure noise defeats motion estimation, which gives up early, where semi-structured content makes it search hard. Content structure is a real term, so "bits/frame" is a good axis but not a complete cost model. Verified .21: clippy -D warnings clean (pf-encode + pf-zerocopy), 64 unit tests, 25/25 NVENC on-hardware. Curves run on both Ada and Blackwell. fmt clean.	2026-08-07 00:30:09 +02:00
enricobuehler	50b3fd1012	fix(pf-encode): drop the 10-bit short circuit — measured wrong on Ada, twice ... WP1.3, and the measurement that justifies it. `resolve_split_mode`'s 10-bit rule sat ABOVE the pixel-rate arm and took no codec, so it (D1) vetoed 10-bit 4K120 -- the very case the pixel-rate arm exists for -- and (D2) applied an HEVC-Main10-on- Ada result to AV1 10-bit, which has no such measurement. Both fixed: the pixel-rate arm now comes first, and what remains is codec-scoped to HEVC and only applies BELOW that bar, where a second engine buys nothing anyway. The rule rested on one datapoint: 5120x1440@240 Main10 on Ada, forced-2 7.6 ms vs 2.8 ms single-engine -- split 2.7x SLOWER. Dropping the short circuit flips that exact configuration's behaviour, so it was re-measured on a 4090 (AD102, driver 610.43.03), 400 Mbps, sub-frame pinned off, via a new mode-parameterizable Main10 A/B test (PF_AB_MODE=WxHxFPS reproduces the original operating point). Ada 4090 single forced-2 ratio 3840x2160@60 4483 us 2178 us 2.06x split WINS 5120x1440@240 3689 us 2813 us 1.31x split WINS <- the veto's origin 3840x2160@120 4148 us 2189 us 1.89x split WINS Blackwell 5070 Ti 3840x2160@60 4216 us 2477 us 1.70x split WINS 5120x1440@240 4651 us 3894 us 1.19x split WINS Split wins for Main10 at every mode on BOTH architectures, including the config the veto came from. The original number does not reproduce. ⚠ Caveats, unchanged from the rest of this work: content is trivial (297-300 B/AU against an 833 KB CBR quota -- zeroed VRAM), so this is the pixel-proportional term and the bits/frame regime is still unmeasured; debug build; and the driver differs from whenever the original was taken. Also validated on Ada in the same session -- the whole spike set reproduces on a SECOND architecture and an OLDER driver (610.43.03 vs 610.57.04): S1a in-place split switch accepted with zero IDRs both directions; S1b takes effect (|C-B|=12 vs |C-A|=1921, the cleanest run yet); S1c pair flip passes; D5 confirmed (AUTO+sub-frame 4424 vs DISABLE 4409, 15 us apart -- and AUTO without sub-frame 2310 ~= TWO_FORCED 2314, so the arm stays); engines=2 with THREE_FORCED correctly clamped to mode 2; arbitration converged with exactly 1 keyframe. Verified: .21 clippy -D warnings clean + 64 unit tests; .133 Windows clippy -D warnings clean (the resolver signature grew a `codec` param, so both backends moved); Ada + Blackwell on-hardware as above. fmt clean.	2026-08-06 23:58:24 +02:00
enricobuehler	2366c4fe31	feat(pf-encode,host): price the HEVC sub-frame trade so arbitration can cover it ... The named next step after WP3's first increment. That increment deliberately REFUSED to arbitrate HEVC-with-sub-frame -- the fleet default, and the reported field case -- because engaging split there gives up sub-frame readback, whose whole value is that the send overlaps the encode. An encoder measuring only encode time would see split as ~2x faster, take it, and make end-to-end latency worse while reporting a win. This supplies the missing number. The real comparison is encode_1eng + send_of_last_slice against encode_2eng + send_of_whole_AU, so the challenger owes roughly spread x (slices-1)/slices. Split across the two sides that can each see half: - Host: new `Encoder::set_send_spread_us` (defaulted, forwarded by TrackedEncoder -- same trap class as set_wire_chunking, and unforwarded it would fail SILENTLY IN THE SAFE DIRECTION, which is the hardest kind to notice). The send thread is the only place a paced send is observed and the encode loop the only place the encoder can be touched, so it goes over an AtomicU32 like encoder_ceiling_kbps, EWMA-smoothed 3:1 per completed AU: one content spike must not flip a verdict that then gets cached. - Encoder: turns the raw spread into the handicap, because only it knows `slices`. SplitArbiter::with_handicap charges it to the challenger before the comparison. A unit test runs identical encode numbers with a cheap and an expensive send and asserts the verdict REVERSES -- with an expensive send the arm that looks twice as fast is a loss end to end, and the incumbent must hold. That is precisely the regression an encode-only arbiter ships. Gate now opens for HEVC+sub-frame only when a spread has actually been reported (and slices >= 2); with no hint it still refuses, so behaviour is unchanged until the host feeds it. Two mechanics this needed: - apply_split_mode became a PAIR flip (split + sub-frame), routed through resolve_split_subframe and restoring from `subframe_opened_with` so a session that never had sub-frame can never gain it. It also recomputes `subframe_chunks`, which reconfigure_bitrate does NOT -- spike S1c's finding; leave it stale and supports_chunked_poll keeps saying yes while numSlices never advances, so poll_chunk busy-polls its whole budget every AU. - The arbiter is now fed from BOTH completion points. A sub-frame session finishes through poll_chunk, so the incumbent arm of an HEVC experiment would otherwise never deliver a sample -- only the challenger, with sub-frame dropped, comes through poll. Verified .21: clippy -D warnings clean for pf-encode AND punktfunk-host with nvenc, 63 unit tests (1 new), 23/23 NVENC on-hardware green. Verified .133: Windows clippy -D warnings clean, zero dead_code. fmt clean.	2026-08-06 23:41:40 +02:00
enricobuehler	3b283dc26e	feat(pf-encode): WP3 — live split arbitration, measured on the session, no IDR ... The fix S1 unlocked. Rather than predict the right split mode at open — which cannot work, because the decision depends on bits/frame and an Automatic client's steady-state bitrate is unknown at open (ABR climbs in place afterwards) — the encoder now measures both arms on the live session and keeps the winner. S1 proved nvEncReconfigureEncoder takes a changed splitEncodeMode with resetEncoder=0, emits no IDR, and actually applies it, so the experiment is invisible on the wire. Deliberately measures instead of modelling: hard-coded per-arch constants are exactly how the rule this replaces went wrong (one 5120x1440@240 Ada datapoint generalised into a fleet-wide 10-bit veto). A measurement tracks driver updates for free. `SplitArbiter` (pure state machine, unit-tested without a GPU): measure incumbent -> switch -> SETTLE -> measure challenger -> keep the winner, else switch back. Verdicts cache per (gpu, codec, mode, depth, chroma) so later sessions open straight into the winning arm; the key is CeilingKey minus split_mode, since the split mode is the thing being decided. ⚠ SETTLE_FRAMES=16 is load-bearing, not padding: split-encode does not reach steady state on the first frame (a FRESH TWO_FORCED session measured early-half 3280us vs late-half 1996), so judging an arm right after switching reads the transient — intermittently, which would then be cached. A unit test feeds exactly that transient and asserts the arbiter still sees the steady state. Safety gates, all correctness conditions rather than preferences: opt-in (PUNKTFUNK_NVENC_SPLIT_ARBITRATE=1) while it earns trust; an operator PUNKTFUNK_SPLIT_ENCODE pin always wins; skip if a verdict is already cached; sync depth-1 only (async_rt.is_none(), same gate chunked poll uses — under pipelined retrieve the submit->AU span includes queue depth and the comparison is noise); needs >=2 engines; never H.264. ⚠ And the one that bounds this increment: NO SUB-FRAME TRADE. For HEVC, forcing split gives up sub-frame readback, which costs send/encode overlap the ENCODER CANNOT SEE — it measures encode time only, so it would reliably prefer split and silently make end-to-end latency worse. So arbitration runs only where nothing is traded: sub-frame already off, or AV1 (both features legal). Pricing that trade needs the host's send cost and is the next work package. Challenger choice tests the question worth asking — anything not already the widest forced split is challenged BY the widest ("are we leaving engines idle?"). The naive "challenge whatever we are not" spent the experiment re-proving that splitting beats not-splitting, while parking the session on the slow arm to do it, because 4K60 sits on the fallthrough AUTO. ⚠ Every new nvenc_core item is linux-gated: the arbiter is wired into the Linux backend only for now and nvenc_core compiles on Windows too. Caught by the .133 check, not by reasoning — the first cut failed Windows clippy with 12 dead_code errors, the exact item-level trap this file already carries a scar from. Verified .21: clippy --features nvenc --all-targets -D warnings clean, 62 unit tests (4 new arbiter tests), 23/23 NVENC on-hardware green including a new end-to-end convergence test asserting ZERO extra IDRs and a cached verdict. Verified .133: Windows clippy -D warnings clean, zero dead_code. fmt clean.	2026-08-06 23:26:47 +02:00
enricobuehler	b0ec759fad	fix(brand): capitalize "Punktfunk" in user-facing text ... The docs site's page title read "punktfunk docs". Fixed that and swept the rest of the tree for the same defect, capitalizing the brand wherever it is shown to a human and leaving it lowercase where it is a technical identifier (CLI/package names, `punktfunk://` scheme, PnP enumerator, TLS SNI, logcat tag, config paths, CMS tenant id). User-visible fixes: - docs-site: page title -> "Punktfunk Docs"; API reference title, meta description and the branded bar's aria-label; the BrandMark/Wordmark SVG accessible names (the web console already had these capitalized -- the docs site had drifted from it). - Android: six strings of live UI copy -- the local-network permission dialog (x2), the connect-screen error banner, and the no-controller explainer. - Apple: the "No Hosts" empty-state text and the fallback display name for a host that advertises no instance name. - Windows client: the `--discover` progress line. - KWin fake-input: the application name passed to `authenticate()` (the grant is cached per-exe, so the string is display-only). - THIRD-PARTY-NOTICES: fixed in both generators (about.hbs and gen-third-party-notices.py) and applied to the three checked-in outputs so they match what a regeneration now produces. Every changed line differs from the original only by letter case, so line lengths are unchanged and no formatter width rule is affected. `cargo fmt --all --check` passes.	2026-08-06 23:10:25 +02:00
enricobuehler	96fc3eca10	test(vkdecode): the AV1 rung finally has pixels to answer to ... A parity and smoke harness for AV1, mirroring the H.264 and H.265 legs that proved those rungs bit-identical to libavcodec on four drivers before either ran on glass. This was the milestone's largest test gap: the adversarial review found four blocking defects in the AV1 conversion — flags unset on 274 frames of 274, a units error in LoopRestorationSize, per-reference info describing the wrong picture, film-grain fields left zero — and every one of them would have shown on frame 1 of a parity run, while clippy and 164 green unit tests said nothing at all. The golden is 250 per-frame SHA-256s in DISPLAY order, not 274. The vector carries 274 coded frames in 250 temporal units; the 24 extras are hidden ALTREFs, decoded and referenced but never shown, and the rung delivers what dpb.outputs names. The count is re-derived from the planner rather than assumed. Cross-checked between ffmpeg 8.1.1 on macOS arm64 and 8.0.1 on Linux x86_64, whose raw outputs are byte-identical — and then against a third party neither build knows about: the vendored vector ships upstream's own per-frame MD5s, and re-running those reproduces all 250. The golden agrees with a decode nobody in this program performed. I reproduced both independently before committing. 8-bit NV12, traced from the sequence header rather than presumed (seq_profile 0, high_bitdepth 0, mono_chrome 0), so the P010 scar does not apply here — and the header says which check to make if a Main 10 golden is ever added. film_grain_params_present is 0, which is load-bearing: grain synthesis is part of the Vulkan decode profile, so this golden is only comparable against a grain-less profile key. Anti-vacuity is the point of the exercise, so it is structural. The golden guard asserts the exact count, that every line is a bare digest, and that all entries are DISTINCT — 250 copies of one digest would let a decoder frozen on a single frame pass parity. The parity body asserts the golden set and the access-unit count before it touches hardware, so an IVF reader returning nothing cannot become "0 frames compared, pass". The agent verified the guards fire by mutating the golden three ways. assert_bit_identical now names the FIRST divergent frame, which is what localises a defect; that improves all six legs, not just AV1. AV1 has no four-byte-start-code twin, deliberately: OBUs are length-delimited, so there is no prefix for a driver to mis-skip. Documented where a reader would otherwise see an omission. Nothing here has run on a GPU. The harness exists precisely so the four review defects can be answered by measurement instead of argument.	2026-08-06 22:38:04 +02:00
enricobuehler	9a1d8be4cc	fix(pf-encode): AUTO split is conditional on sub-frame — do NOT retire the arm ... Last change's docs concluded "AUTO never splits, retire the arm" from the sub-frame-ON measurement alone. Measured the missing leg before implementing it, and the conclusion was wrong. On .21 at 4K, plain AUTO (env unset, the resolver's fallthrough): sub-frame ON -> 5023/5157 us/frame ~= DISABLE 4979/5000 (does NOT split) sub-frame OFF -> 2401/2352 us/frame ~= TWO_FORCED 2319/2378 (DOES split) So AUTO is CONDITIONAL, not dead. Retiring it would have silently cost every sub-frame-off session its second engine -- a regression introduced while "cleaning up" an arm that looked inert. Split and sub-frame are mutually unsupported for HEVC, so the driver resolves AUTO to no-split only in that combination. Fix is disclosure, not removal: - resolve_split_subframe debug-logs the inert HEVC + AUTO + sub-frame case, which is the fleet default shape: "split_mode=AUTO" has meant "no split" for every default session and nothing said so. Deliberately NOT rewritten to DISABLE -- the mode we pass is what the driver was actually given, and the ceiling-cache key must keep describing that. - New unit test `auto_survives_the_arbitration_in_both_subframe_states` pins the contract so the arm cannot be simplified away later. - The resolver doc now records both measured legs instead of "AUTO is dead". Also in this change: - WP1.6: `resolve_subframe`'s doc said "Windows passes `false`". Stale since the 2026-07-31 .173 A/B flipped Windows to caps-gated default-on. It mattered: it made the AUTO-plus-sub-frame dead combination look Linux-only when it is fleet-wide. - Windows session-ready log parity: split_mode + engines + subframe. The Windows line had no split_mode at all, so a Windows field report could not answer "did this session actually split?" -- the question that started this whole thread. Verified: fmt clean; .21 clippy -p pf-encode --features nvenc --all-targets -D warnings clean, 58 unit tests (1 new), 22/22 NVENC on-hardware tests green; .133 Windows clippy --features nvenc --all-targets -D warnings clean (15m cold, zero errors or warnings) -- the Windows backend is cfg'd out on both macOS and the Linux box, so that leg needed a real Windows host.	2026-08-06 22:25:10 +02:00
enricobuehler	a404830456	feat(client): wire AV1 into the native Vulkan rung, pin-only ... The third codec arm in video_vk_native, AV1 admitted to native_codec and to native_vulkan_gate by pin only. It stays out of `auto` on the same rule M5's D3D11VA rung follows: `auto` admission is earned with hardware evidence, and this has decoded nothing on a device. is_integrity_warning_av1 did not exist, so the client could not have concealed AV1 damage at all. Added, exhaustive, no wildcard: all three AV1 warnings really are damage, because AV1 has no spec-legal-but-noisy signal to mis-classify — no reorder envelope to announce, no MMCO to rebase — and the exhaustive match is what stops a future variant defaulting to clean. The blocking defect review found was two safety mechanisms cancelling each other. After a failure the decoder skipped to the next key frame answering Ok(None), and because AV1's planner has no flush its store kept planning cleanly, so those AUs carried no warnings and the client read them as proof the rung works — clearing the demotion streak and resetting its clock on every one. The streak could then never reach the threshold, which made the never-delivered fall-through to FFmpeg-Vulkan unreachable, which is the documented backstop for exactly three things: a level above maxLevelIdc, a sequence header disagreeing with the Welcome, and film grain. Film grain is the probe's own admitted assumption, so a grain stream would have frozen the screen for the session while DecodeHealth reported run 0 — recovered. AV1 now answers the wait with an error, as H.264 and H.265 already do through AwaitingIdr, so all three codecs are indistinguishable to the demotion machinery. That matters more than the extra precision of a third state: only the H.26x paths have hardware evidence, and they are proven WITH that behaviour. The obvious form of that fix would have wedged the decoder. A key frame can sit behind a skipped frame inside the same temporal unit — the vendored vector has 24 two-frame units — so erroring out of the per-plan loop would never reach it and the wait would never end. Skips are therefore counted per frame and the error raised only when the whole unit was skipped, with the metadata-only unit staying a clean Ok(None). Also closed: a refused temporal unit left an already-decoded frame in the ready queue, which shipped on the next AU as a clean success — putting a picture from a refused AU on screen, clearing the streak again, and latching delivered so the fall-through was disabled for good. The error arm now drains and releases unshown. MAX_DELIVERABLE is derived rather than picked: HOLD_HEADROOM minus the pipeline's own hold, pinned to pf-vkdecode's constant so a hardcoded depth fails the build. At the previous 8 the queue plus the presenter's 4-7 stood against a headroom of 8, so it capped memory without preventing the exhaustion it named, and a frame waiting 8 AUs burned 16 of the 17 query slots — where a re-armed slot reads as Failed and becomes a fabricated driver-corruption verdict in the very counter the Ally X signal lives in. The trim now runs after this AU's frame is taken, or at the derived depth it would drop a two-output unit's first frame and invert display order inside one AU. Its justification was also wrong: the claim that a temporal unit may carry a show_existing_frame alongside a shown frame is disproved by this repo's own golden — 250 units, 250 shown, zero show_existing. The bound is kept as defence in depth against a non-conformant or multi-operating-point stream, and now says so. Gates: macOS fmt/clippy/392 tests, container clippy -D warnings over six crates, 851 tests, workspace check. No hardware: the rung is pin-only and has still never decoded a frame on a device.	2026-08-06 22:19:22 +02:00
enricobuehler	88f29a9411	feat(pf-encode): use every NVENC engine the GPU has, not a hard-coded two ... WP1.1 plus the engine-count fix. `resolve_split_mode` forced TWO_FORCED at high pixel rate regardless of hardware, so a 3-NVENC part (GB202, AD102 workstation) left a third of its encode silicon idle, and a 1-NVENC part paid a wasted session open to discover it could not split. Probes NV_ENC_CAPS_NUM_ENCODER_ENGINES in both direct-SDK backends' query_caps (the cap is `= 49` in both linux_sys and windows_sys of the vendored SDK 0.4.0 -- the caps enum is cfg-selected per-OS, so that was checked) and latches it on a backend field. NOT on EncoderCaps: nine backends construct that struct as exhaustive literals, so a new field would be a 9-site change of which 7 are unrelated codecs passing a meaningless value, and the only consumer is the resolver. New `max_forced_split_mode(engines)`: 1 -> DISABLE, 2 -> TWO, 3 -> THREE, and >3 -> AUTO_FORCED, because NV_ENC_SPLIT_ENCODE_MODE cannot NAME more than three (NVENCAPI 12.1; values 4..14 are unallocated, so a future API may extend it) and AUTO_FORCED = "split, driver picks how many" is measurably a real split (2.01x vs disabled on .21). 0 = unprobed keeps the historical two-engine assumption. ⚠ WHY THE CLAMP EXISTS, measured on .21 (RTX 5070 Ti, 2 NVENC, 4K HEVC): requesting THREE_FORCED was HONOURED -- session opened in mode 3 -- and ran at 2303 us/frame, identical to TWO_FORCED's 2308. The driver does not reject an over-ask; it silently encodes narrower. So the rejection fallback cannot find the ceiling and PUNKTFUNK_SPLIT_ENCODE=3 on a 2-engine card would have logged a 3-way split over a 2-way encode. Operator overrides are now clamped with a warn. The ordering trap is covered by a test: on a >3-engine part hw_max is AUTO_FORCED (1), which is not "narrower than" TWO_FORCED (2) despite comparing smaller, so a naive min() would collapse a legitimate 3-way request to AUTO. Also adds `engines` and `subframe` to the Linux session-ready log: split_mode alone is ambiguous between "used both engines" and "left a third idle", and since the driver honours an over-wide request the mode cannot be read without the ceiling it was chosen from. This is the line a field report needs. --- and a correction to S1b, in the same change --- Re-running S1b afterwards flipped its verdict to "the driver appears to have IGNORED the in-place split change", contradicting the isolated runs that produced the |C-B|=34 figure already written into the design docs. Investigated rather than re-rolled. The switched leg was landing MIDWAY between the arms (~3600 us against A~5050, B~2300) and the nearest-neighbour verdict flipped on noise. Cause: split-encode does not reach steady state on the first frame -- a FRESH TWO_FORCED session shows it too (early-half 3280 us vs late-half 1996 in one run), so it is split warmup generally, not something specific to reconfiguring in place. A single median over the whole window cannot see that. The test now reports early-half vs late-half and gives a switched leg SETTLE=16 frames before its window opens, every leg the same length. With that, 4/4 runs agree: the switched leg reaches ~2030 us against a fresh-split ~2000 and a single-engine ~4900. ⚠ S1b's CONCLUSION stands (the switch does take effect) but the evidence behind the committed number did not reproduce; the docs are corrected rather than left implying a cleaner result than the harness could support. ⚠⚠ This is a WP3 REQUIREMENT, not just a test fix: a live-session arbitration that switches arms and immediately measures will misjudge the arm it just chose, because the encoder needs ~16 frames to settle. The settle window has to be part of the arbitration, and it is now a measured number rather than a guess. Verified on .21: clippy --features nvenc --all-targets -D warnings clean, 57 unit tests (3 new), all 23 NVENC on-hardware tests green, fmt clean. The 3 failing on-hw tests in a full --ignored run are VAAPI (no AMD/Intel GPU on that box -- their own ignore reason says so), pre-existing and unrelated.	2026-08-06 21:54:00 +02:00
enricobuehler	70b81ac3d7	test(pf-encode): S1c + the D5 confirm — pair flips in place, AUTO really is dead ... S1c `nvenc_cuda_split_subframe_pair_reconfigure`: the leg S1a/S1b excluded. Both pinned sub-frame OFF to isolate the split variable, but a real HEVC arbitration cannot -- split and sub-frame are mutually unsupported there, so engaging split means flipping enableSubFrameWrite in the same breath, a second init param and the one the reconfigure path deliberately pins. RESULT on .21: the PAIR moves in place, accepted, ZERO IDRs, both directions. It also pins the invariant that makes this safe to build on: `subframe_chunks` is latched ONLY in the init path (~line 1625) and is NOT recomputed by reconfigure_bitrate, so a caller flipping sub-frame in place must clear it too or supports_chunked_poll keeps reporting true and poll_chunk busy-polls its whole budget every AU against a numSlices that never advances. The test performs the correct sequence and asserts the state stays coherent, so WP3 has a worked example rather than a warning. `nvenc_cuda_auto_split_with_subframe`: the D5 confirm -- the one claim in the design's defect list that was only ever inferred. The driver reports no "mode I actually chose", so it is settled by timing, at 4K where the gap is ~2x. RESULT: AUTO (env unset) + sub-frame 4904 us/frame, DISABLE + sub-frame 5062, TWO_FORCED without sub-frame 3464. AUTO sits 158 us from DISABLE and 1440 from TWO_FORCED ⇒ D5 CONFIRMED: plain AUTO does not split while sub-frame is on, so the resolver's AUTO fallthrough reads as "let the driver decide" and means "never split". ⚠ TRAP, hit on this test's first run and now documented in it: the env knob CANNOT express plain AUTO. `0` is DISABLE and `1` is AUTO_FORCED, and resolve_split_subframe counts AUTO_FORCED as forced, so passing `1` silently disarms sub-frame and measures a different configuration entirely -- which produced a spurious "D5 REFUTED". Plain AUTO is only reachable as the resolver's fallthrough with the env unset. The leg now asserts sub-frame resolved TRUE, so the test can no longer answer the wrong question quietly. Verified on .21: clippy --features nvenc --all-targets -D warnings clean, all 4 spikes green, the normal 54-test suite unaffected, cargo fmt --all --check clean.	2026-08-06 21:27:18 +02:00
enricobuehler	cab3aa1726	feat(vkdecode): M7's Vulkan AV1 rung — GPU half, and the review that saved it ... caps_av1 / session_av1 / decoder_av1, over the CPU half already committed, sharing the picture pool, bitstream ring, op ring, DPB settling and frame delivery with H.264 and H.265 rather than forking them. AV1 session parameters carry exactly one sequence header — no PPS, no VPS — so the parameters ledger is two-state: current, or recreate. The GPU plumbing came through review clean. The damage was all in the conversion committed two rounds ago, which nothing tested against a reference, and none of it would have failed a gate: clippy was clean, the tests were green, and the rung would have decoded its own conformance vector wrong on essentially every frame on AMD, silently. Four blocking defects, each measured on the vendored vector rather than argued: Nine StdVideoDecodeAV1PictureInfo flags were never set. Four change reconstruction — allow_screen_content_tools on 274 frames of 274, allow_warped_motion on 273, is_filter_switchable on 172, force_integer_mv on 1 — and RADV reads three of them directly. The block already set allow_intrabc, which is only codeable when screen-content tools are on, so it contradicted itself. LoopRestorationSize sent the pixel size where the field is log2(size) - 5. cros-codecs stores 64/128/256; RADV names its destination log2_restoration_size_minus5 and reads 1/2/3. Nothing truncates, nothing errors, and every frame with loop restoration reconstructs against a nonsense unit size. Per-reference Std info answered questions about the wrong picture: every reference carried the CURRENT frame's type, and RefFrameSignBias was never set at all. Sign bias is what tells a decoder a reference lies in the future, and this vector is the hidden-ALTREF one, so all-zero meant every reference was treated as past. Fixed at the source: pf-bitstream now records a RefState when a picture is stored — its own frame type, sign-bias mask, saved order hints — and carries it on the slot, so all three backends get answers about the reference rather than about the frame reading it. Film grain's six chroma-scaling fields were zero, which defeats the profile machinery that exists to refuse devices unable to synthesise grain. The reference-name compaction is fixed in the PLANNER, once. AuPlan::refs is now name-indexed with holes preserved, so a lost reference can no longer renumber every later AV1 reference name — a class that was live in both conversions and armed for the VAAPI rung that does not exist yet. The DXVA twin had a second name-versus-slot confusion: it read global motion by DPB slot from an array the spec indexes by reference name, and slot 0's matrix is all-zero rather than identity, so 273 references were given a zero warp. Also closed: pTileOffsets/pTileSizes were sized to tileCount while RADV reads AV1_MAX_NUM_TILES entries unconditionally — a 4-byte allocation read a kilobyte deep — now fixed 256-entry arrays with zeroed tails. And the test guarding the lost-reference refusal re-implemented the predicate inline, so deleting the guard left it green; both now call one named function. The bitstream layout now matches libavcodec: raw tile payloads only, frameHeaderOffset 0. The review established the spec-literal layout was NOT wrong — AV1 has no start-code scanning, so the 3-versus-4-byte and slices-only scars do not transfer, and no driver in the fleet reads frameHeaderOffset — but matching the validated reference deletes code, uploads 5835 fewer bytes over the vector, and removes the untested-driver tail. Upstream, and the third of its kind: the vendored parser writes ref_frame_sign_bias[i] in the same loop body where it writes order_hints[LAST_FRAME + i], so its array is shifted one down and index 7 is never written. Corrected in RefState::of with the shift documented, the vendored tree untouched, and pinned by a test that recomputes the bias from order_hints through the parser's own get_relative_dist. Gates: macOS fmt/clippy/tests, container clippy -D warnings over six crates, 845 tests, workspace check. No hardware: nothing here has reached a driver.	2026-08-06 21:15:39 +02:00
enricobuehler	4b57d11dd8	test(pf-encode): S1 spike — splitEncodeMode CAN change in place, no IDR ... Two on-hardware spikes answering the gate on the split-encode engagement program (design/nvenc-split-encode-engagement-implementation-plan.md). S1a `nvenc_cuda_split_reconfigure_in_place`: can splitEncodeMode change via nvEncReconfigureEncoder with resetEncoder=0, without an IDR? Our "reconfigure must present the SAME init params as the open" rule (windows/nvenc.rs:620) is our own invariant and had never been tested against a driver. It reports rather than asserts the verdict -- both outcomes are legitimate findings -- and only asserts what would invalidate the measurement (session live, engines >= 2, the arms actually differ). Sub-frame is pinned off so the driver can't reject for the wrong reason (HEVC forced-split and sub-frame are mutually unsupported). S1b `nvenc_cuda_split_reconfigure_takes_effect`: the other half -- a driver that accepts the parameter and quietly ignores it looks identical to one that honours it. Three legs at 4K (fresh DISABLE / fresh TWO_FORCED / DISABLE->TWO in place); if C tracks B and not A, the switch is real. RESULT on .21 (RTX 5070 Ti, GB203 Blackwell, driver 610.57.04): NV_ENC_CAPS_NUM_ENCODER_ENGINES = 2 S1a: accepted, ZERO IDRs, both directions. S1b: A fresh DISABLE 5054 us/frame, B fresh TWO_FORCED 2453, C switched in place 2419 -- |C-B|=34 vs |C-A|=2635. It takes effect, and split is a clean ~2x at 4K. Two limits, both recorded in the test docs rather than the commit only. The frames come out at 427 B/AU against an 833 KB CBR quota: the driver hands back zeroed VRAM, so the rotated buffers are identical and rate control skip-codes everything. So this measures the PIXEL-proportional half of the cost only -- the bits/frame regime the field case lives in is untested here, and the test prints an explicit INCONCLUSIVE-on-content line when it detects that. And this is Blackwell 8-bit; the Ada Main10 question is untouched. Verified on .21: clippy -p pf-encode --features nvenc --all-targets -D warnings clean, both spikes green, cargo fmt --all --check clean.	2026-08-06 21:11:52 +02:00
enricobuehler	eecd04247f	feat(client): AV1 is advertised on hardware, not on a decoder existing ... The standing open item M7 was meant to close. `decodable_codecs` answered the AV1 bit from `ffmpeg::decoder::find(AV1)`, which says yes on every build that links libdav1d — a software decoder. So the client told the host "send me AV1" on machines that would then decode a 4K stream on the CPU, and codec negotiation happens once at Welcome, so there is nothing to fall back to afterwards. A promise the client cannot keep is worse than not making it. `av1_hardware_decodable` answers from device facts only: the presenter's Vulkan device listing DECODE_AV1 among its decode queue family's codec operations, or — on Windows — the D3D11 import path, which is the same gate the D3D11VA rung sits behind and that rung decodes AV1 Profile 0 today. VAAPI is deliberately not consulted: asking libva costs opening a display, and this is called too early and too often for that. The Vulkan bit covers the Mesa devices where VAAPI AV1 exists in practice, and a machine with VAAPI AV1 but no Vulkan AV1 loses the advertisement, not a working path. The test pins what the gate must not accept: a device that decodes H.264 and H.265 but lists no AV1 operation, and a device whose caps word claims AV1 while it has no decode queue at all. Gates: macOS fmt/clippy, container clippy -D warnings over six crates, 805 tests, workspace check.	2026-08-06 19:27:24 +02:00
enricobuehler	b7cd023643	feat(dxvadec): M7's DXVA AV1 conversion — a fourth way to name a reference ... One AuPlan into DXVA_PicParams_AV1, over the layouts the SDK header measured. AV1 on DXVA needs TWO reference arrays that mean different things at once, and this program has now written down four spellings of the same question. `frame_refs[7]` is indexed by reference NAME and each entry carries a SURFACE index — where Vulkan's `referenceNameSlotIndices` carries a SLOT — plus that reference's own global motion. `RefFrameMapTextureIndex[8]` is indexed by SLOT and states the whole reference store, which is what `RefFrameList` is for the other codecs and why a long-term reference no frame names still has to appear in it. The test asserts that difference is exercised rather than assumed: it fails if the run never saw the store hold a picture the frame did not name, which is precisely the distinction the Ally X class of bug lives in. Three transpositions that would each have been silent: Global motion is signalled per reference SLOT in the frame header and stored per reference NAME in DXVA, so the conversion reads by one and writes by the other. Carrying the Vulkan shape across would leave every warped reference at identity. CDEF strengths pack two fields to a byte, primary in the low six bits and secondary in the top two, where the AV1 syntax keeps parallel arrays. DXVA wants log2 of the loop-restoration unit size; the parser records the size. And the superres denominator is the real one here — SUPERRES_NUM when superres is off — where Vulkan's `coded_denom` is the denominator less nine. Film grain rides only where the sequence enables it and the frame applies it, its scaling points transposed into [value, scaling] pairs, and an over-count refused rather than truncated: fewer points than the stream declared is different grain, not less of it. Gates: macOS fmt/clippy/349 tests, container clippy -D warnings over six crates, 804 tests, workspace check.	2026-08-06 19:23:42 +02:00
enricobuehler	e9da37aaf6	feat(host/gamelease): a launcher tile's session stops depending on invisible state ... A launcher entry (design D4) has no "the game exited" moment to detect, but the lease was still deciding its lifetime from whatever happened to be true at launch — and the two outcomes disagree: launcher NOT already running the spawned child stays alive -> `Child` lease -> quitting the launcher ends the session launcher ALREADY running the command forwards to the live instance and exits inside SHIM_WINDOW, with no detect signals behind it -> `Untracked` -> the session persists Same tile, two lifetimes, chosen by something the user cannot see. Steam is the case that settles which one is right: Big Picture is a *mode* of an already-running Steam client, not a process — and on a Deck or SteamOS host Steam is always running — so no process signal can express "the launcher's window closed". Heroic has the same shape for a different reason (single-instance Electron: a second invocation forwards and exits). So a launcher entry is now `LeaseKind::Untracked` unconditionally. The check sits AHEAD of `nested`/`child`/`spec`, and that ordering is the fix rather than an implementation detail: a launcher the host just started leaves a live child behind, and tracking that child is precisely the inconsistency being removed. `Untracked` already meant the right things downstream, so nothing else had to change: no watcher thread, `terminate()` is a no-op ("nothing to end" — closing a session must not kill the user's Steam), and no `GameExited` event, so a client does not bounce back to its library when the launcher closes. Threaded as `LaunchTarget::launcher` -> `LeaseRequest::launcher` from the entry's `role`. Three call sites, one of which was the actual trap: the GameStream path does not build its lease from a `LaunchTarget` at all, it goes through a `GsApp` intermediate that silently dropped the field. An operator-typed `apps.json` command has no library entry behind it and is never a launcher tile, so it passes `false` explicitly. The test pins BOTH cases from the table above, plus the same request without the flag still being `Matched` — so the assertions are the flag's doing and not an artifact of the fixture. Gates: punktfunk-host 439 passed / 0 failed on .21 (+1). Not covered here: nothing publishes launcher tiles until the plugins are released, so there was no live exposure to fix — this is the semantics being made deliberate before the first tile is ever clicked.	2026-08-06 18:35:09 +02:00
enricobuehler	5d1556132e	feat(dxvadec): M7's DXVA AV1 layouts, measured against Microsoft's own header ... The blocker on this rung was never the code — it was that `dxva.rs` is the most safety-critical file in the backend and nothing in it is type-checked against Windows, so M5's layouts only became trustworthy once a libavcodec byte capture had verified them field by field. AV1 turns out not to need that capture: `DXVA_PicParams_AV1` ships in the Windows SDK's OWN `dxva.h` (10.0.26100.0 and 10.0.28000.0 on .173), which is the declaration the driver was compiled against and therefore outranks any mirror. So `layout-probe-av1.c` is committed beside pf-vaadec's probe, compiled with MSVC against that header on .173, and every number below came out of it: DXVA_PicParams_AV1 is 912 bytes with alignment 1, PicEntry 36, Tile 16, and each offset is a compile-time assertion. The nested blocks are asserted through their own types too, so a wrong internal layout cannot hide behind a right outer one. Every assertion passed on the first build, which is the result worth having: the transcription and the compiler agree. The bit-field words are measured, not assumed. C bit-field allocation order is ABI-defined rather than standardised, so the probe sets one member at a time and prints the word, and the tests check each packer against what MSVC produced — tx_mode at bits 22-23, reference_frame_update at 26, film grain's sixteen-bit word with matrix_coeff_is_identity at 12, and so on. Two places AV1 puts things where the other two codecs would not, both now written down where a conversion will read them: Global motion is per REFERENCE, inside DXVA_PicEntry_AV1 — where Vulkan hangs one global-motion block off the picture info. A conversion carrying the Vulkan shape across would leave every warped reference at identity. CDEF strengths are packed two-to-a-byte, primary in the low six bits and secondary in the top two, where both the AV1 syntax and Vulkan's Std block keep parallel arrays. A zeroed block names NO reference: 0 is a valid surface index, so a memset-style default would quietly point every unused reference at surface 0, which decodes, and decodes wrong. Gates: macOS fmt/clippy/347 tests, container clippy -D warnings over six crates, 802 tests, workspace check.	2026-08-06 18:26:02 +02:00
enricobuehler	83cfabda89	feat(vkdecode): M7's Vulkan CPU half — AV1 into the Std structures ... The sequence header and the picture info, converted for VK_KHR_video_decode_av1. Same shape as the H.264 and H.265 conversions, and the same ownership contract: boxed backing beside the Std struct that points at it, movable wrapper, no mutation, not Clone. AV1 puts almost the whole frame header in the PICTURE info rather than in a parameter set, so StdVideoDecodeAV1PictureInfo carries eight pointers to per-frame blocks — tile info, quantisation, segmentation, loop filter, CDEF, loop restoration, global motion, film grain — and the tile info carries four more arrays of its own. Session parameters, by contrast, hold exactly one sequence header. That asymmetry is why params_av1 is the small module here and pic_av1 the large one. The plan now carries the parsed frame header whole. The client needs a digest — size, depth, colour, keyframe — but a backend needs nearly all of the header, so AuPlan carries it the way its H.264 and H.265 siblings carry their activated parameter sets: a backend builds from exactly what was parsed, never by re-reading the access unit. referenceNameSlotIndices holds DPB SLOT indices, not positions in the reference list, and that is the HEVC RPS defect's exact shape in a narrower place. Measured rather than argued: over the vendored vector the two readings disagree 566 times across 274 frames, and the test fails if they ever stop disagreeing, because then it would no longer be able to tell the conventions apart. Two places where transcription would have been wrong, both caught by the types and then by asking the spec: The parser's film-grain point arrays are 16 entries where the Std ones are 14 (luma) and 10 (chroma) — the spec's own maxima. The counts are validated against the Std capacity and the copy is bounded by them; a stream declaring more is refused, because a decoder handed fewer scaling points than the stream declared synthesises different grain. `coded_denom` is the superres denominator less SUPERRES_DENOM_MIN and only meaningful where superres is in use, and `UsesLr` is derived — no frame header codes it — from whether any plane's restoration type is not NONE. Film grain rides only where the sequence enables it AND the frame applies it, with the apply_grain flag set from whether a block is attached, so the flag and the pointer cannot disagree. Gates: macOS fmt/clippy/345 tests, container clippy -D warnings over six crates, 800 tests, workspace check.	2026-08-06 18:00:59 +02:00
enricobuehler	7f83ec6c2f	feat(bitstream): M7 begins — the AV1 planner, and it plans frames the stream hides ... The third planner in this crate, and the foundation every AV1 rung will consume. Same contract as its H.264 and H.265 siblings: an access unit in, a plan out, with the vendored cros-codecs parser reading the bitstream and this module owning the reference ledger, the output bookkeeping and the concealment posture. AV1's reference model is simpler than H.264's and entirely explicit — eight numbered slots, `ref_frame_idx` naming what a frame reads and `refresh_frame_flags` naming what it writes — so the planner is bookkeeping rather than derivation, and a frame naming an empty slot is a lost reference with no spec process that might legitimately have emptied it. Two things measurement changed, both before a line of backend code depends on them. `plan_au` returns a VECTOR. An AV1 temporal unit may carry several frames, and the vendored vector does: 250 units, 274 frames, 24 units carrying two. Measured, those 24 extras are not `show_existing_frame` (there are none in this vector) but HIDDEN frames — decoded, never displayed, referenced later. A planner that took the last header in each unit would have decoded 250 frames and silently dropped 24 REFERENCES, and the damage would have surfaced as missing-reference concealment on frames that were never damaged. A picture is not removed until its LAST slot goes. One picture routinely occupies several slots at once — a key frame refreshes all eight — so a slot being overwritten does not mean its picture is gone. Reporting it removed would free a surface under a live reference, which is precisely the shape this program exists to catch. Tested directly, and asserted to report once rather than once per slot. What this does not cover is written down rather than left to be assumed: the vector uses `show_existing_frame` zero times, so the display-only path and its key-frame slot reset are exercised by no test here, and the test asserts that count is zero so the day it changes the claim gets revisited. Per-backend conversions are deliberately absent. Vulkan, DXVA and libva disagree about what a reference list indexes — the disagreement that made HEVC unplayable on every driver — so each belongs beside its siblings in pf-vkdecode / pf-dxvadec / pf-vaadec, where its own convention is written down and tested. Gates: macOS fmt/clippy/344 tests, container clippy -D warnings over six crates, 799 tests, workspace check.	2026-08-06 17:18:34 +02:00
enricobuehler	a6e51215fd	feat(client): M6's rung is wired — libva, dlopen'd, no libavcodec ... The native VAAPI decoder now runs end to end: pf-vaadec's plans go into libva's buffers, the surface comes back as DRM-PRIME dmabufs, and the presenter imports them exactly as it does the FFmpeg rung's. Pin-only — `PUNKTFUNK_DECODER=native-vaapi` — for the reason M5's D3D11VA rung was: `auto` admission is earned with hardware parity and a soak, and this rung has decoded nothing yet. libva is dlopen'd rather than linked, so the pf-lxcheck2 container compiles and clippies the whole thing without libva-dev, and a machine without a VAAPI runtime gets a clean refusal instead of a packaging dependency. The surface pool is not the slot map. `SlotMap::assign` hands out the lowest free slot, and a slot freed by an access unit's own removals is free by the time that unit's picture takes it — measured at 225 of the vendored vector's 250 access units. A surface bound by slot index would therefore decode, on nine frames in ten, into the surface still holding the picture on screen. So `plan_to_va` now takes the decode target as a parameter, bound by the caller at activation time the way pf-vkdecode binds a pool image, and a surface is free only when no live picture is bound to it, no output is owed for it, and no consumer holds it. Measured rather than transcribed, as everywhere else here: layout-probe.c grew the export descriptor (312 bytes, objects[4]/layers[4]), the buffer-type enumerators — VASliceParameterBufferType is 4 and VASliceDataBufferType is 5, not the 3 and 4 that counting off the header suggests — and the config, attribute and generic-value layouts. All pinned as compile-time assertions, which is how the 12-byte VAGenericValue in the first draft was caught: the C union holds a pointer, so it is 8-aligned and 16 bytes. The plane walk lives in pf-vaadec, pure and unit-tested on macOS, because it is the one structure the DRIVER writes and we read: SEPARATE_LAYERS returns NV12 as two layers, and taking layers[0] is the green screen this project has already paid for. It also refuses what it cannot express rather than guessing — a bogus object count, a plane naming an object that is not there, objects disagreeing on tiling. Own DecodedImage variant, same payload type. The physical hand-off is identical to the FFmpeg rung's, so the presenter keeps ONE arm and one demotion streak; the variant exists so the compiler asks which rung decoded wherever that matters. Both D3D11VA rungs share a variant and `1573a987` had to fix the consequence afterwards — a "native" soak that could silently have been an FFmpeg soak. Here the four uncovered matches were compile errors. Buffers are destroyed by us, not by vaEndPicture: va.h is explicit that the user must call vaDestroyBuffer, and the libva 0.x behaviour is long gone. Leaking two per picture at 60 fps exhausts the driver's store in minutes. pf-vaadec's presenter headroom was 4, written against no consumer. The Vulkan rung had already measured the client pipeline at four to seven held frames; it is 8 now, pinned to that crate's constant so a re-measurement moves both. Gates: macOS fmt/clippy/341 tests/cargo doc, and in the container clippy -D warnings over six crates, 795 tests, workspace check. Hardware legs are still owed — no AMD/Mesa or Intel box was reachable.	2026-08-06 16:56:38 +02:00
enricobuehler	453b9850fa	Merge pull request 'Gamepad UI: multi-tone palettes, and a UI that takes its colours from them' (#74) from worktree-gamepad-ui-polish into main ... Reviewed-on: #74	2026-08-06 14:48:24 +00:00
enricobuehler	4a9a1c3ed4	feat(clients/gamepad-ui): multi-tone palettes, and a UI that takes its colours from them ... The first pass built each palette by rotating ONE colour field's hue, and it showed: every option was a single tone at several brightnesses, which reads flat next to any real gradient. A palette is now an ordered ramp of DISTINCT hues. The 4×4 mesh samples that ramp along the diagonal with a fixed per-cell offset table, so neighbouring cells land on different parts of it and the colours pool and swirl instead of banding; the control points' existing drift then moves the pools around. Violet keeps its explicit sixteen colours, so the default is untouched. Twelve of them now, dark first then pale: Violet, Nebula, Abyss, Ember, Moss, Graphite, then Holo, Sunset, Bloom, Dawn, Mint, Opal. Holo and Sunset are straight takes on the two reference gradients — foil and poster. `every_palette_is_multi_tone` measures the hue spread across all sixteen cells and fails under 45° (20° for Graphite and Opal, which are meant to be restrained). It caught Ember at 35°, all reds and oranges — the very flatness this rework exists to remove — and Graphite at 3° despite a comment claiming it drifted cool to warm. Both were rebuilt until the numbers matched the prose. The UI follows the palette now, rather than wearing brand violet over whatever happens to be behind it. Each palette carries an accent and a light flag, and an Ink derived from those (foreground, accent, on-accent, glass, scrim and its strength) is published to the whole tree — a thread-local in the console, an environment value on Apple, a CompositionLocal on Android. Pale palettes flip the ink: dark text on white frost, with the materials, tray scrims and every wash that sits under text following suit. Three things only the renders could have told us: - Additive blending blows out over a pale ground. Android's blobs and Apple's legacy field composite with Plus/plusLighter, which over near-white saturates every blob to white — Holo rendered as a grey wash. Pale palettes blend normally. - A white scrim at the dark field's strength BLEACHES the gradient. Mixing toward black at 0.4 reads as depth; toward white at 0.4 destroys the chroma it is drawn over. The scrim now carries a per-palette strength. - White glass over a bright field has far less separating it from its backdrop than dark glass over a dark one, and needed more body. Verified: console build + clippy -D warnings + 173 tests, Apple build + 200 tests + an iOS-triple typecheck, Android compile + 62 tests, and eyeball passes on real renders of both the vivid and the pale ends (console CPU rasters; a new Roborazzi light-palette scene, which is what exposed the blend-mode bug).	2026-08-06 15:55:26 +02:00
enricobuehler	166e158afe	feat(host/library): an xbox launch kind a de-privileged plugin can publish ... The xbox scanner resolves each package's PackageFamilyName by enumerating %ProgramData%\Microsoft\Windows\AppRepository\Packages. Probed on .173 (design doc S1), that directory is: NT AUTHORITY\LocalService UnauthorizedAccessException <- the plugin runner LocalSystem count=348 <- the host service So an extracted xbox plugin cannot build an AUMID, and `aumid` — which takes a complete `<PFN>!<AppId>` — is unpublishable by one. The design doc offered two fallbacks: entries without `aumid` (they would list but not launch), or a one-shot elevated PFN resolve at install time. This is neither. The plugin sends `<Identity>!<AppId>`, both read straight out of MicrosoftGame.config — which IS readable de-privileged — and the host resolves the publisher hash at LAUNCH time, where it already owns command construction. That keeps D1 intact (the plugin supplies a validated value, the host builds the command), it is the same shape as the `playnite` kind, and resolving late means a package update that changes the publisher hash cannot leave a stale unlaunchable tile behind — which the install-time cache would have. `xbox_pfn` therefore moves from the scan path to the launch path rather than being deleted, and its doc records the privilege asymmetry so the next reader doesn't re-derive it. The charset guard is factored out (`aumid_part` / `valid_aumid`) and shared with the `aumid` kind. On `aumid` it was belt-and-braces — every value was host-derived. On `xbox` it is load-bearing: the Identity arrives over the wire from a plugin, and it is interpolated into a `shell:AppsFolder\…` argument. Validated inbound at reconcile too, so a malformed value is a 400 the plugin author can act on rather than a tile that fails on click. Gates: punktfunk-host 438 passed / 0 failed on .21, and 55/0 for the library tests on .173 (where these arms actually compile). Both counts +1 for the new guard test.	2026-08-06 15:43:26 +02:00
enricobuehler	65996621d8	Merge pull request 'fix(encode/pyrowave): stop stamping GPU scheduling priority over pf-frame's auto gate' (#72) from worktree-pyrowave-gpu-priority into main ... Reviewed-on: #72	2026-08-06 13:15:06 +00:00
enricobuehler	61b96c3837	feat(client): M6's HEVC conversion — the CPU half is complete ... The H.265 twin of plan_to_va, and with it pf-vaadec covers both codecs end to end from an AuPlan to the buffers a vaRenderPicture call carries. What remains for the rung is the Linux-only plumbing. HEVC differs from H.264 in four ways that each had to be got right rather than assumed, and they are why this is a separate module instead of a parameter: ReferenceFrames is 15 entries, not 16. The reference sets are FLAGS, not arrays. There is no RefPicSetStCurrBefore here: membership is ORed into each DPB entry's own flags. Vulkan wants slot indices in identically named arrays, DXVA wants list positions in them, and VAAPI wants neither — three spellings of one idea, and confusing the first two is what made HEVC unplayable on every driver. The per-slice lists are INDICES into ReferenceFrames, not pictures and not surfaces. So the DPB array is built first and every list entry resolved through it; a picture a slice names that is not in the marked DPB is a refusal rather than something to paper over, because there is nothing to fall back to. The offset is in BYTES. slice_data() is byte-aligned by byte_alignment(), so header_bit_size / 8 is exact — and a header that is not a whole number of bytes is an error rather than a rounded offset, which would decode garbage from the first inter picture. Two conversions that are NOT copies, and would have been silently wrong as copies: libva takes the derived ChromaOffsetLX (equation 7-56) where the parser stores the coded delta, so putting the delta there would tint every weighted-predicted block; and only 32x32 matrixIds 0 and 3 exist, where the parser keeps six slots. The IQ matrix is Optional and gated on scaling_list_enabled_flag for the reason review round 13 found on the DXVA side — a driver MUST apply what it is handed, so a table of parser defaults dequantises every residual to zero. The weight table is only filled where 7.3.6.1 says one is coded, and the chroma denominator is clamped into a legal shift so a malformed stream cannot panic a decode thread. Tests walk both HEVC vectors — the 250-frame 8-bit one and the 50-frame Main 10 one, so a depth field wired to a constant would show — asserting per slice that the start code was trimmed, the byte offset is inside the slice, and every used list index points at a DPB entry that is actually valid. Per picture it asserts that exactly the three current sets carry RPS flags and nothing else does, and the walk fails if it never saw an RPS flag or a reference at all, so it cannot pass vacuously.	2026-08-06 15:15:04 +02:00
enricobuehler	c48e60fbb7	Merge pull request 'Two July fixes that were never merged: rpm FFmpeg modules + the released-pointer double cursor' (#71) from worktree-july-rpm-and-cursor into main ... Reviewed-on: #71	2026-08-06 13:13:33 +00:00
enricobuehler	6c379f8fef	feat(client): M6's HEVC layouts, and a third way to spell a reference set ... The HEVC twin of pf-vaadec's H.264 buffer layouts, measured the same way: the committed probe extended to cover va_dec_hevc.h, every size and offset read off real libva 2.23.0 headers and pinned as const assertions — VAPictureHEVC 28, VAPictureParameterBufferHEVC 604, VASliceParameterBufferHEVC 264, VAIQMatrixBufferHEVC 1016 — and every bit-field position read back out of a real header rather than counted by eye. The finding worth carrying: HEVC's reference plumbing is a THIRD convention, and this program has now been bitten by confusing two of them. Vulkan takes DPB SLOT indices in RefPicSetStCurrBefore/After/LtCurr. Writing reference-list positions there is what made HEVC unplayable on every driver until it was root-caused. DXVA takes positions into RefPicList[] in identically named arrays. VAAPI takes neither. It marks set membership as FLAGS on the DPB entries themselves — VA_PICTURE_HEVC_RPS_ST_CURR_BEFORE / _AFTER / _LT_CURR — and its per-slice RefPicList[2][15] holds INDICES INTO ReferenceFrames, not pictures and not surfaces. Three spellings of one idea, identical names on two of them, and different referents on all three. The conversion will say which it is writing, every time, and the docs now hold all three side by side. Two more asymmetries with the H.264 side, recorded where they will be read: ReferenceFrames is 15 entries here, not 16; and the offset is slice_data_byte_offset — BYTES, where H.264 wants bits — over the same definition. slice_data() is byte-aligned by byte_alignment(), so the parser's header_bit_size / 8 is exact rather than rounded, which the conversion will assert rather than assume. Tests cover the probe's measured bit patterns plus a disjointness sweep over every field of pic_fields and slice_parsing_fields — two probe vectors per word would not catch a shift typo that overlapped two neighbours, and these words are 20 and 14 fields wide.	2026-08-06 15:09:07 +02:00
enricobuehler	70684e5079	fix(encode/pyrowave): stop stamping GPU scheduling priority over pf-frame's auto gate ... `windows/pyrowave.rs` raised the process's WDDM scheduling class to HIGH itself, once per process, at every session open. `pf-frame::dxgi::auto_priority_gate` already owns that policy for the whole process and runs from `create_device` — the call the Windows capture path always makes before any PyroWave texture exists. Two owners of one process-wide setting. The audit filed this as "downgrades REALTIME to HIGH", which undersells it. pf-frame's default `auto` mode starts at HIGH and then UPGRADES to REALTIME once it has established that is safe — HAGS off, or HAGS on with VRAM headroom — and leaves a monitor running that drops back when VRAM tightens, because REALTIME + NVIDIA + HAGS + near-full VRAM is a documented NVENC hang. Opening a PyroWave session after that upgrade stamped HIGH back over the class AND orphaned the monitor's decision, losing the ceiling-raise on exactly the GPU-saturated workload PyroWave exists to survive: it encodes on the shader cores a game saturates, where the measured spike is ~2 ms to 15-18 ms. Removed rather than reconciled. `PyroWaveEncoder::open` takes no device, so there was nothing session-specific to preserve, and the surviving owner is strictly better informed — it knows the adapter, HAGS state and VRAM headroom, none of which this call site had. The duplicated knob goes with it: `PUNKTFUNK_GPU_PRIORITY` is retired in favour of `PUNKTFUNK_GPU_PRIORITY_CLASS` (`off|normal|high|realtime|auto`, default `auto`), which is a superset — the removed knob could not express the auto gate at all. No other reference to it exists in the tree. Verified 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 (34 passed), rustfmt — 7 legs green. Windows-only file, so the Linux legs do not compile it.	2026-08-06 15:06:49 +02:00
enricobuehler	2a67c02f7e	fix(clients/cursor): the host must not composite a pointer under a released client's own cursor ... Streaming a KDE desktop showed two cursors: the one the user was moving, and a second one sitting underneath it that never moved. It was not KDE's — KWin 6.7.3 in cursor-as-metadata mode calls `setRenderCursor(false)` on every recorded buffer and hands the cursor item to an exclusive `ItemTreeView`, so `shouldRenderItem()` skips it and no pointer is ever painted into that stream. It was ours. Both clients declared the render model as `captured && desktop`, so ANY released pointer handed compositing back to the host. But releasing does not remove the local cursor — it restores the ordinary window arrow over the video. The host then blends its own pointer in underneath, and since a released client forwards no motion, nothing drives it: it stays frozen wherever the host pointer was last left. Caught live on the host with the render-model diag: cursor diag: client_draws=false blended=true live=Some((-1, 622, true)) x = -1 — parked on the streamed output's left edge, unchanged sample after sample, while the user moved their own cursor around freely. Engaging capture flipped it to `client_draws=true blended=false` and the duplicate vanished, which is why it only looked "stuck when not dragging": dragging means engaged, and engaged was the one state that behaved. The host may composite ONLY while the client holds a grabbed, hidden pointer — the capture model, engaged — which is the single state with no local cursor on screen. Released now counts as "the client draws it": the host stops compositing and keeps forwarding shape/state over the channel (the forwarder ticks on this side of the flip), so re-engaging is seamless and the client's cached shape stays warm.	2026-08-06 15:03:11 +02:00