2755 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	fa2bcd9dbb	docs(release): the last three PRs — FFmpeg 9, the Arch soname trap, and the Linux buffer ceiling that was defeating A/V sync	2026-08-08 02:43:46 +02:00
enricobuehler	353091270d	Merge remote-tracking branch 'origin/main' into worktree-release-0250	2026-08-08 02:42:00 +02:00
enricobuehler	86bb09e2cf	Merge pull request 'Arch could upgrade FFmpeg out from under the host and brick it — and the host now builds against FFmpeg 9' (#108) from worktree-ffmpeg9-support into main ... Reviewed-on: #108	2026-08-08 00:41:33 +00:00
enricobuehler	deeb8b6700	feat(pf-encode): build against FFmpeg 9 ... ffmpeg-next 8.1.0 could not accept FFmpeg 9 at all: ffmpeg-sys-next's version probe covered avcodec majors 56..62 (the range is exclusive of its end), so libavcodec 63 fell outside what it knew how to bind. 9.0.0 widens that to 56..63, which is what actually unblocks Arch. Bump both pins — the unconditional Linux dep and the optional Windows amf-qsv one — and the lock with them. No API drift to fix. The crate major is a CEILING, not a target: one source tree still spans FFmpeg 7.x/libavcodec 61, 8.x/62 and 9.x/63 via per-version cfgs, and every wrapper symbol the NVENC-libav, VAAPI and amf-qsv backends name survives 8.1.0 -> 9.0.0 unchanged. The three hand-written #[repr(C)] hwcontext mirrors are the parts no compiler checks, so they were re-read against the real headers rather than trusted: AVCUDADeviceContext and AVD3D11VAFramesContext are byte-identical across 7.1/8/9, and AVD3D11VADeviceContext gained two trailing UINTs in 8 that 7.1 lacks — which is why that mirror deliberately stops at the common prefix, and why its assertions now say what they do and do not buy you. They pin our layout, not libav's; a green build is not evidence. The CI image is the step that makes this reach users. arch.yml deliberately runs no -Syu ("the image's snapshot IS the build environment"), so the builder stayed frozen on ffmpeg 8 no matter what Arch shipped, and a canary built from that snapshot could not satisfy the soname dep the PKGBUILD now derives. Re-keying ci/ rebuilds it against ffmpeg 9. Ubuntu and Windows deliberately stay put: the noble .deb bundles its own FFmpeg 8 behind an rpath and strips the libav sonames from its Depends, and Windows bundles BtbN DLLs into the signed installer — neither is exposed to the break, BtbN publishes no FFmpeg 9 build, and moving either would re-qualify an encode stack to buy nothing. Verified end to end on 192.168.1.21 (CachyOS, system ffmpeg 2:9.0-5, RTX 5070 Ti): host builds clean and links libavcodec.so.63/libavutil.so.61/libavfilter.so.12/libswscale.so.10 with no unresolved sonames; the ffmpeg-8 compat shim is gone and the service runs with NRestarts=0 and answers 401 on :47990; pf-encode's 67 tests pass; and a live synthetic encode drives real NVENC hardware through FFmpeg 9's libavcodec to a decodable 1080p HEVC stream (180/180 frames, FEC loopback 0 mismatches) with libavcodec.so.63 and libnvidia-encode both mapped into the encoding process.	2026-08-08 02:35:20 +02:00
enricobuehler	b1e0525872	fix(packaging/arch): pacman could upgrade FFmpeg out from under the host and brick it ... `depends=('ffmpeg' ...)` carried no version bound, and pacman is the only one of our packaging formats that does not derive dependencies from ELF DT_NEEDED — rpm auto-generates `libavcodec.so.62()(64bit)`, dpkg-shlibdeps emits `libavcodec62`, nix pins the closure. So when Arch shipped ffmpeg 2:9.0-5 on 2026-08-08 and every soname moved (libavutil .60->.61, libavcodec .62->.63, libavfilter .11->.12, libavdevice .62->.63, libswscale .9->.10), a plain `pacman -Syu` walked every Arch/CachyOS install straight across the break. The result is not a crash we can log: the dynamic loader cannot start the binary at all, so it is exit 127 *before* main() in a systemd restart loop, and because punktfunk-web is a separate bun service with no libav linkage it keeps serving happily while :47990 has nothing listening — which reads as "the mgmt API is broken" rather than "the host is not running". `ldd /usr/bin/punktfunk-host | grep "not found"` is the one-line diagnosis. Depend on the sonames instead of the package. Arch's ffmpeg declares the matching `provides=(libavcodec.so=63-64 ...)`, and makepkg rewrites each bare `libfoo.so` listed in depends into `libfoo.so=<soname>-<arch>` by reading the built binary's DT_NEEDED, so the bound tracks whatever FFmpeg the builder linked against with nothing to hand-maintain across the next bump. pacman now refuses the ffmpeg upgrade rather than bricking the install. A hand-written `ffmpeg<2:9` would have gone stale on the very next major; not bundling FFmpeg the way the .deb does, because that exists only because Ubuntu 24.04 LTS is frozen on 6.1 and can never satisfy the dep, while rolling Arch always ships a current one. Verified on a real ffmpeg-9 box (192.168.1.21): the built package records libavcodec.so=63-64, libavutil.so=61-64, libavfilter.so=12-64, libavdevice.so=63-64 and libswscale.so=10-64, exactly matching DT_NEEDED, with the two libs --as-needed drops left bare and satisfied by any ffmpeg. The new arch.yml step asserts that expansion actually happened. If it ever stops — Arch dropping the soname provides, someone tidying the entries out of depends — the dep silently degrades to an unversioned name that any ffmpeg satisfies, which is exactly the state that caused this, and it is invisible in a green build until a box bricks weeks later.	2026-08-08 02:34:59 +02:00
enricobuehler	4adea10557	Merge pull request 'fix(plugin-kit): regSubKeys could never return a subkey, and adopt biome' (#107) from worktree-kit-regsubkeys into main ... Reviewed-on: #107	2026-08-08 00:23:46 +00:00
enricobuehler	4edb662b63	fix(plugin-kit): regSubKeys could never return a subkey ... Found on hardware by the GOG plugin's own parity gate, on a box with exactly one GOG game installed: HKLM\SOFTWARE\WOW6432Node\GOG.com\Games -> 1 subkey (IRON NEST ...) host's built-in scanner: 1 entry plugin: detect: absent, 0 games parity FAILED - 1 missing, exit 1 `reg.exe` ALWAYS echoes the full hive name in its output rows, never the abbreviation it was given: query `HKLM\SOFTWARE\...` and every line comes back `HKEY_LOCAL_MACHINE\SOFTWARE\...`. regSubKeys built its match prefix from the `HKLM\...` string it was handed, so no line ever matched and it returned `[]` — on every machine, for every key, always. Measured verbatim on .173: reg.exe: [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\GOG.com\Games\2013434102] regSubKeys: [] Its only consumer is the GOG plugin, so the symptom was "GOG reports no games installed" rather than an error — the same shape as the SQLite reader in 0.3.1: a total failure that every layer degrades into an empty library. The contract was wrong too, and the hive bug hid it. regSubKeys returned whole key PATHS while the GOG plugin uses each result as a bare NAME (`const key = \`${GAMES_KEY}\\${id}\``, and the subkey name IS the product id that becomes `external_id`). Even with the prefix fixed, paths would have composed nonsense keys. It now returns names, which is what the sole consumer and its own comment always assumed. Parsing is split into an exported `parseRegSubKeys(stdout, key)` for the same reason `parseRegQuery` is exported — this is a text format that breaks quietly, and it had NO test coverage at all. Six added, using the verbatim .173 output: names not paths, multiple subkeys, grandchildren ignored, the queried key is not its own subkey, case-insensitivity, and empty/error input. Four of the six FAIL against the old behaviour. 0.3.1 -> 0.3.2. Gates: biome clean, tsc clean, 67/67 tests, build clean.	2026-08-08 02:19:30 +02:00
enricobuehler	10a0ef3283	style(plugin-kit): adopt the biome config its own plugins already use ... The kit had NO biome config and no lint script, while every plugin repo that consumes it has both. So its source quietly drifted — unused imports, unsorted imports, formatting — with nothing to catch any of it. Running biome here for the first time reported 20 findings across 8 files. Adds `plugin-kit/biome.json` mirroring the plugin repos' (tab indent, double quotes, recommended lint preset, organizeImports), a `check` script, and `@biomejs/biome` pinned to the same `^2.5.2` the plugins pin — without that pin `bunx biome` resolved 2.4.6, which rejects the 2.5 `rules.preset` key. Two deliberate differences from the plugin repos' copy: * no `vcs.useIgnoreFile` — those are standalone repos with a .gitignore beside the config; plugin-kit is a directory inside this one, and biome errors with "couldn't find an ignore file". The `files.includes` exclusions cover it. * `!examples/**/dist` instead of `!ui/dist` — the kit has examples, not a UI. `css.parser.tailwindDirectives` is carried over and is load-bearing: without it biome cannot parse `@theme` in src/theme.css and reports three parse errors on CSS that is perfectly valid Tailwind v4. Everything here is formatter/import churn except two real findings, both fixed: * `Layer` (library/define.ts) and `Cause` (sync-engine.ts) were imported and never used; * test/spike-httpapi.test.ts read `(reg?.body as …).ui.secret` one line after `expect(reg).toBeDefined()`. The optional chain undoes the assertion: had `reg` been undefined the `.ui` access would throw a TypeError instead of failing the test readably. Now asserted to the type system too. Wired into plugin-kit-publish.yml as a `Lint & format` step ahead of Typecheck, so this cannot rot again. Gates after: biome clean (42 files), tsc clean, 67/67 tests, build clean.	2026-08-08 02:19:06 +02:00
enricobuehler	cabd011f1d	Merge pull request 'The 272 ms audio buffer was legal: the PipeWire callback filled the buffer ceiling, not the graph's request' (#106) from fix/pw-playback-requested into main ... Reviewed-on: #106	2026-08-08 00:12:02 +00:00
enricobuehler	d939c7c14e	Merge pull request 'fix(pf-inject): the DualShock 4 Windows backend never imported OFF_INPUT' (#105) from worktree-ds4-off-input into main ... Reviewed-on: #105	2026-08-08 00:10:18 +00:00
enricobuehler	be86cfcdc0	fix(client/audio): the PipeWire callback stops filling the buffer ceiling every cycle ... The playback process callback sized its writes from the mapped buffer's capacity — PipeWire's quantum-limit, 8192 frames ≈ 170 ms — instead of the graph's per-cycle ask (pw_buffer.requested). Every cycle therefore queued up to 170 ms of PCM downstream of the ring, and, worse, taught JitterPolicy that the device drains 170 ms per callback: the underrun floor (want + one frame) rose above any depth the A/V sync loop may request, so sync measured audio ~280 ms late and was forbidden — by its own continuity rule — from draining it. The first on-glass run of the latency overhaul showed exactly that: audio buffer 272 ms, a/v +284 ms, stable. Honor requested (capacity remains both the ceiling and the fallback for requested == 0), and log requested-vs-capacity once per stream in the shape of the host's per-capture-open quantum line, so the next on-glass report can say which one is sizing the writes. Needs libpipewire >= 0.3.49 (2022-03) for the requested field; every ship target clears that. Verified on .21: cargo clippy -p pf-client-core --all-targets -D warnings clean, 167 tests pass, fmt clean.	2026-08-08 02:04:15 +02:00
enricobuehler	e9e1ec7dc5	fix(pf-inject): the DualShock 4 Windows backend never imported OFF_INPUT ... The Windows host does not build: error[E0425]: cannot find value `OFF_INPUT` in this scope --> crates\pf-inject\src\inject\windows\dualshock4_windows.rs:65:48 error: could not compile `pf-inject` (lib) due to 1 previous error `dualshock4_windows.rs` writes the neutral report straight to `OFF_INPUT` in its bootstrap path — correctly, and exactly as the DualSense and Steam Deck backends do: the devnode does not exist yet at that point, so there is no reader to race and no seqlock to take. Its steady-state path already goes through `publish_input`, which is the v2.3 seqlock. But the import list only names `publish_input`. `steam_deck_windows.rs` imports `OFF_INPUT` explicitly for the same bootstrap write; this one was missed when the list was edited to add `publish_input`. One word in a `use`. No behaviour. WHY CI DID NOT CATCH IT: `pf-inject`'s Windows backends compile only for `*-pc-windows-msvc`, and the crate is host-side, so the client Windows workflow never touches it. A cargo check from a Mac cannot stand in either — pf-inject pulls punktfunk-core and therefore ring, whose C build wants MSVC headers, so the cross-check dies in cc-rs long before it reaches this file. FOUND BY: running windows-host.yml's own build line on the CI runner (.133) against the v0.25.0 release tree before tagging — `cargo build --release -p punktfunk-host --features nvenc,amf-qsv,qsv`. It fails at `pf-inject`, which is step 1 of the host job, so a v0.25.0 tag would have produced no Windows host binary, no installer, and no host asset on the release.	2026-08-08 01:43:11 +02:00
enricobuehler	cacfe04a93	docs(release): the commit count catches up with main (327 -> 395)	2026-08-08 01:41:09 +02:00
enricobuehler	5fda4d4805	Merge remote-tracking branch 'origin/main' into worktree-release-0250	2026-08-08 01:40:04 +02:00
enricobuehler	959d3eb604	docs(release): A/V sync takes a TL;DR slot, and the old audio claim was wrong ... main moved another 62 commits (a8a4b11f -> fca9f42c), taking 0.25.0 to 391 since v0.24.0. Five PRs: decode aliasing (#102), A/V sync (#101), gyro correctness (#99), web console sweep (#100), Apple ATS (#103). THE CORRECTION THAT MATTERED. The notes carried "Audio that falls behind the picture pulls itself back … Android was worst, with no correction at all", describing the jitter ring's buffer-shedding as if it were sync. It never was. The host has stamped `pts_ns` on every audio datagram since long before v0.24.0 and EVERY CLIENT DECODED IT AND NEVER READ IT — verified in the v0.24.0 tree (`crates/punktfunk-host/src/native/audio.rs:162` stamps it; the client audio paths ignore it). Lip-sync was an emergent property of buffer depth, and it got WORSE as video got faster, which is why shaving milliseconds off the audio budget had never helped. That bullet is rewritten to say what is actually true, and A/V sync takes a TL;DR slot. It displaces the settings-BOM bullet, which was the weakest of the six as a HEADLINE: conditional (only if the file was ever saved by PowerShell), partly duplicated by the Windows non-C: entry, and it survives verbatim in Fixed. A/V sync affects every user, every session, every client, with sound on — and unlike most of this release it shipped broken in EVERY release we have ever made. GYRO NEEDS AN UPGRADE NOTE, so it got one. The pipeline was wrong end to end and is now measured against a real controller, which MOVES AIM SENSITIVITY: a pad presented as a DualShock 4 reported gyro 40x fast (host-side), and a PlayStation pad on Android reported ~30% short (client-side). At 40x nobody could have compensated — gyro aim was unusable, not miscalibrated — but the Android ~1.4x change is exactly the size a real person tunes around, so `## Before you update` names it specifically. DELIBERATELY NOT PROMOTED. The decode-aliasing program (#102) reads like a catastrophe — H.264 decoding into a surface it predicted from on 297 of every 300 access units of every stream we emit, on both rungs — but it NEVER SHIPPED: `git ls-tree v0.24.0 crates/` has no pf-vkdecode/pf-dxvadec/pf-vaadec/pf-bitstream. It is a ship-blocker that was cleared, and writing "your picture was subtly wrong" would be false for every reader. It contributes one clause to the decode entry (every path is now checked frame-by-frame against a reference decoder; Windows + Intel AV1 routes through Direct3D) and a full section in the changelog. Same reasoning already applied to #96 and the rav1d abort. Changelog gains the A/V sync mechanism (including that video is the master and continuity outranks sync — the ring refuses a sync request that would break audio on a jittery link) and the aliasing section, with the four independent reasons four gates missed it: a structurally-blind conformance vector, a test that had encoded the bug AS CORRECT, a vacuous assertion that could not fail, and the fact that it streamed clean on glass. gpu_parity is 11 legs, not the 9 an earlier note claimed. Verified after the merge: lock diff versions-only 35/35, `cargo metadata --locked` resolves (39 members), `cargo fmt --all --check` clean in both workspaces, notes body 0 internal-vocabulary hits, Play notes 497/500 by android.yml's own gate. Wire 2, C ABI 17, no new capability bits in this range.	2026-08-08 01:36:53 +02:00
enricobuehler	b2f08b1a73	Merge pull request 'fix(pf-dxvadec): a wrapped sentence turned "6." into an ordered list' (#104) from worktree-dxva-doclint into main ... Reviewed-on: #104	2026-08-07 23:26:52 +00:00
enricobuehler	7f82bca9c0	fix(pf-dxvadec): a wrapped sentence turned "6." into an ordered list ... A doc paragraph in `pic_av1.rs` wrapped so that "first at frame / 6. Releasing…" put `6.` at the start of a line. rustdoc reads that as an ordered-list item starting at 6, which makes the following unindented `///` line a lazy continuation — `clippy::doc_lazy_continuation`, denied by `-D warnings`. Reflowed so the number cannot begin a line. Prose is byte-identical in content; only the wrap points move. No code, no behaviour. WHY THIS MATTERS FOR THE TAG. `pf-dxvadec` is Windows-only, and no Windows leg runs on a push to main — so main being green proves nothing about this. The failure surfaces for the first time in a release tag's fan-out, which is exactly what happened to the FIRST v0.23.0 tag: it went red on Windows clippy for this same lint, and the cure was a tag re-point. Caught pre-tag by re-running the lazy-continuation scanner over the tree while preparing v0.25.0 (0 hits before this commit's parent merged the new decode crates, 1 after). Cannot be verified by compiling here — the crate does not build on macOS — so the evidence is the scanner plus the lint's own rule, not a clippy run.	2026-08-08 01:25:59 +02:00
enricobuehler	9043332002	Merge remote-tracking branch 'origin/main' into worktree-release-0250	2026-08-08 01:24:23 +02:00
enricobuehler	fca9f42c44	Merge pull request 'Worktree apple mgmt ats bypass' (#103) from worktree-apple-mgmt-ats-bypass into main ... Reviewed-on: #103	2026-08-07 23:20:19 +00:00
enricobuehler	3d20f2c0e5	Merge pull request 'Three decode rungs were decoding into a surface they were predicting from' (#102) from integration/decode-aliasing-program into main ... Reviewed-on: #102	2026-08-07 23:11:28 +00:00
enricobuehler	7798401f06	perf(apple): cache posters on disk and pool the mgmt connections ... Moving the management API onto Network.framework left one request per connection, so a library grid paid a TLS handshake per poster where the pooled URLSession had shared one. And the Apple client -- unlike Windows -- never cached art at all, so it re-fetched every poster on every visit. ArtCache: a size- and age-bounded blob cache in the CACHES directory (every byte is re-derivable from the host, so the system is welcome to evict it). Keyed by the SHA-256 of the absolute URL, so host-proxy paths and store CDN URLs share one cache without colliding. Reads touch the entry, so eviction is by last USE, not last write. Empty bodies and data: URLs are refused -- neither is worth a file. Defaults: 128 MB, 30 days. Connection pooling: MgmtConnectionPool keeps up to four keep-alive connections per host and makes further callers wait rather than opening more, which is the part that matters -- a grid can ask for dozens of posters at once. A connection the host dropped since we last used it is indistinguishable from a live one until we write, so a REUSED connection that fails is retried once on a fresh one; a fresh failure is a real failure. Keep-alive means a response can no longer be delimited by the peer hanging up, so HTTPResponseParser.messageLength finds the end from the framing itself -- Content-Length or the chunked terminal chunk plus trailers. Getting that wrong would truncate a response or bleed one into the next, silently, so it carries the bulk of the new tests. A connection with bytes left over after a response is dropped rather than reused: we never pipeline, so anything trailing means we are out of sync. LibraryView closes the loader's pooled connections on disappear instead of leaving sockets open on a screen the user has left. 16 new tests: message framing (both encodings, partial reads, back-to-back responses, close detection) and the cache (binary round trip, key separation, refusals, expiry, LRU eviction).	2026-08-08 01:09:25 +02:00
enricobuehler	244cafe005	refactor(apple): move the mgmt API off URLSession so ATS can stay on ... The previous commit bought the library back on VPN/remote hosts by declaring NSAllowsArbitraryLoads, which works but is blunt: it drops ATS for ALL of the app's URLSession traffic, and the only other traffic is third-party cover-art CDN fetches -- the one surface we never wanted to open. It cost the TLS-version floor, forward secrecy, and the cleartext-HTTP block on URLs the host supplies at runtime (custom entries and scanner plugins carry arbitrary ones). So take the host out of the URL loading system instead. MgmtTransport speaks HTTPS over Network.framework, which ATS does not govern, and states the trust rule we actually mean in a verify block: the leaf must hash to the fingerprint pinned during PIN pairing. That is the same rule punktfunk-core has always applied on the QUIC stream plane -- which is exactly why streaming kept working over Tailscale while the library did not. With that, the ATS dict is gone and ATS is fully enforced again. Cover-art CDN fetches keep ordinary URLSession with full system trust evaluation and no client certificate. LibraryTLSDelegate is deleted; nothing pins through URLSession now. Also here: - HTTPResponse: just enough HTTP/1.1 to read one GET -- status, headers, Content-Length and chunked framing (hyper streams the art proxy chunked). A body shorter than Content-Length throws instead of returning partial JSON, which would otherwise read as "this host has no games". - LibraryError.pinMismatch, so a re-keyed host says "pair again" rather than sending someone to debug their network. - 403 joins 401 as "unauthorized": both are the host declining the certificate. - baseURL brackets IPv6 literals; the old string interpolation did not. - 11 tests covering the framings hyper emits and the failure modes that would otherwise be silent. Known trade-off: no connection reuse yet, so each poster costs its own handshake where the pooled URLSession shared one. Fine on a LAN, worth revisiting for large libraries over a high-latency link.	2026-08-08 01:09:04 +02:00
enricobuehler	bae8742e48	fix(apple): the library's unreachable message pointed at the wrong layer ... It led with `--mgmt-bind 127.0.0.1`, a rare cause, and never mentioned the one fact that actually explains the symptom: the library rides the management API on a different port (47990) than the QUIC stream plane (9777), so it can fail while streaming to the same host works. Field triage of exactly that case spent hours on the stream path before anyone questioned the port. Leads with that now, and names browser-testing the port as the fast split between "unreachable" and anything client-side.	2026-08-08 01:07:26 +02:00
enricobuehler	78a02bc994	fix(apple): ATS blocked the library on every non-RFC1918 host ... The game library rides the management REST API over HTTPS (TCP 47990) through URLSession, authenticated by mTLS and pinned by SHA-256 fingerprint. The app declared no App Transport Security policy at all, so it ran under default ATS -- which exempts only "local" destinations (.local, unqualified names, RFC1918 and link-local literals) and applies the full policy everywhere else. The host certificate is self-signed (and carries no SubjectAltName), so it cannot satisfy that policy: the library loaded at 192.168.x and failed at the TLS layer on any other address. Field-reported against a Tailscale host. 100.64.0.0/10 is CGNAT, not RFC1918, so the library failed there while streaming to the very same address worked -- the QUIC stream plane is raw UDP and never enters the URL loading system. A WireGuard peer or a public-IP host breaks identically. Declares NSAllowsArbitraryLoads, which must stay the dict's only key: iOS 10+ and macOS 10.12+ ignore it whenever a more granular ATS key sits alongside it. Trust is unchanged -- LibraryTLSDelegate still pins the host by fingerprint and hands every other origin (cover-art CDNs) to full system trust evaluation.	2026-08-08 01:07:26 +02:00
enricobuehler	2b167595aa	docs(client): the VAAPI rung has parity now — say what is actually left ... Its rows still read "never frame-hash parity-checked: the rung exports a tiled dmabuf with no CPU-readable image, so parity needs a readback path that does not exist yet". That readback now exists, and all SEVEN legs came back bit-identical to libavcodec on RDNA3: vendored H.264 250/250, our host's low-delay H.264 120/120, vendored H.265 250/250, host low-delay H.265 120/120, HEVC Main 10 50/50 as P010, vendored AV1 250/250 of 274 decoded, and host low-delay 4K two-tile AV1 60/60. The two arms collapse into one, because the thing that split them — AV1 having evidence the other legs lacked — is gone. Every leg now has the same evidence. It stays `verified = false`, and the note says why in the words the unproven-rung test requires: it has NEVER run on a second vendor and has never been soaked. That is a real limit rather than a formality — every other verified pair in this table earned it on more than one part, and the D3D11VA AV1 row two entries up is a rung that passed on one vendor's driver while failing on another's. The second reason is not about evidence at all, and it belongs in the record rather than in a commit nobody reads later: flipping this flag is a ROUTING change. `native_rung_admitted` is `verified || !below.verified`, so a verified VAAPI outranks Vulkan Video on every Linux AMD and Intel client — the Steam Deck included. The parity result justifies that change; it should still be made on purpose, by someone who wants it, rather than arriving as a side effect of writing down a test result.	2026-08-08 01:00:06 +02:00
enricobuehler	a9e7c033c3	test(client/vaapi): the last rung of the ladder, finally checked in pixels — 7 legs, all bit-identical ... Every other decode rung earns `verified` with frame-hash parity against libavcodec. VAAPI could not: it hands out a DRM-PRIME dmabuf whose memory the driver tiles, so nothing could read its decoded pixels back, and all four of its legs sat at "never frame-hash parity-checked". That was never bookkeeping. The D3D11VA AV1 rung decoded 250 frames, streamed 4K60 through a clean five-minute soak, and produced WRONG PIXELS for 186 of 250 frames on NVIDIA and 245 of 250 on Intel. It looked perfect on glass; only the goldens caught it, and the same defect turned out to be in H.264 on two other rungs. VAAPI was the one rung where that class of bug could still be sitting with nothing able to see it. It is not. Measured on .25 (Radeon 780M, RDNA3, radeonsi, Mesa 26.0.3, VA-API 1.23) on 2026-08-08, against the SAME golden files the Vulkan and D3D11VA rungs are held to, read across the crate boundary rather than copied: H.264 vendored vector 250/250 bit-identical (7 from the flush) H.264 our host, low-delay 640x480 120/120 bit-identical (3 from the flush) H.265 vendored vector 250/250 bit-identical (2 from the flush) H.265 our host, low-delay 640x480 120/120 bit-identical (0 from the flush) HEVC Main 10, P010 50/50 bit-identical (2 from the flush) AV1 vendored vector 250/250 delivered of 274 decoded, and display frame 0 byte-identical to libavcodec's own PIXELS AV1 our host, 4K two-tile 60/60 bit-identical ⚠ ONE vendor. AMD/radeonsi only; no Intel iHD box has run these legs. The readback that made it possible: * `pf-vaadec`'s `va` module gains `VAImage` and `VAImageFormat`, hand-declared with every size and offset measured off libva 2.23.0's real headers by `layout-probe.c` and pinned as compile-time assertions — the same discipline the decode buffers already keep. The trap: `VAImage::width`/`height` are 16-bit, so `data_size` sits at 60 and not at the 64 counting 32-bit fields gives, and every field after them is two bytes earlier than it looks. * `pack_two_plane` is the pure geometry — the crop to the picture, the padding columns dropped per row, and the chroma plane taken from the driver's OWN `offsets[1]` rather than from `pitch * display_height`, which is the 1088-row smear this program has already paid for once. It needs no device, so ten CPU tests cover it on macOS and in the container. * `video_vaapi_native::parity` drives the seven streams above through the production entry point and hashes what the rung DELIVERS, in delivery order, tail included — so the delivery path is under test as well as the decode, and a frame's surface comes from its own release token rather than from an inference about which pool entry holds which picture. THE READBACK CANNOT REACH THE PRODUCTION PATH, and that is structural rather than a promise. `vaDeriveImage`, `vaCreateImage`, `vaGetImage`, `vaMapBuffer` and the rest are resolved by a `#[cfg(test)]` type that dlopens libva itself; the production `Libva` gains no field; `sha2` is a dev dependency. A CPU test scans this file's own source and fails if any of those symbols is dlsym'd outside the harness, so a refactor cannot quietly undo it. Derive is not guaranteed, so both routes are implemented and neither is optional: `vaDeriveImage` first, `vaCreateImage` + `vaGetImage` as the fallback (which also detiles), and if neither yields the pool's own fourcc the leg FAILS naming what the driver gave it. There is no skip path — a parity test that passes because it could not read anything is the failure mode this program has been bitten by three times. Both answer on radeonsi, the first frame of every leg is read through BOTH and they must agree, and `PF_VAAPI_READBACK=getimage` reproduces the H.264 leg's 250/250 through the copying route alone, so the fallback is exercised rather than merely written. And it can fail — proven, not asserted. Planting the real geometry defect this driver's layout makes visible (rows read contiguously, ignoring the 512-byte pitch behind a 320-wide picture) fails at display frame 0 with the full localisation: 68312 luma and 14998 chroma samples differing, max |delta| 255, luma bounding box (0,1)..(319,239) — and with the goldens forced through one route, 250/250 diverging with "suspect the readback geometry". `compare` and `localise` also have CPU counterfactuals, and a hardware leg proves the readback reads real and DISTINCT pixels and localises a one-byte flip to the exact pixel. ⚠ One thing the hardware legs do NOT cover, found by planting the other defect and watching it do nothing: radeonsi's decode surfaces for every fixture here have no VERTICAL padding — `offsets[1]` is exactly `pitch * height` — so the chroma-plane trap is untested on this driver, and `pf-vaadec`'s `reading_chroma_at_the_display_height_would_have_been_caught` is the only place it is checked at all. `probe_this_machines_readback_routes` now prints the derived layout and says which of the two it is, so the next driver answers for itself instead of being assumed.	2026-08-08 00:55:03 +02:00
enricobuehler	167e35f720	Merge pull request 'Audio was late because nothing ever placed it against the picture' (#101) from audio/latency-overhaul into main ... Reviewed-on: #101	2026-08-07 22:32:08 +00:00
enricobuehler	bfed711921	Merge remote-tracking branch 'origin/main' into audio/latency-overhaul	2026-08-08 00:16:02 +02:00
enricobuehler	c43769282a	fix(apple): place audio with the picture instead of wherever the ring settles ... The Apple half of the A/V sync overhaul; the Rust half is 12a53183 and this mirrors its policy rather than re-deriving one. The host stamps `pts_ns` on every audio datagram and the client decoded it into `AudioPCM` — and then never read it. Video's `pts_ns` is used end to end (the end-to-end meter computes a true glass-to-glass `displayed + clockOffset − pts` per presented frame), so audio free-ran at whatever depth its jitter ring happened to reach, video was presented on an independent path, and nothing ever compared them. The A/V offset was an accident of buffer depths: it moved whenever the ring ratcheted under underrun pressure, and it got WORSE every time video got faster, because a quicker decoder lowers the video leg and leaves audio's exactly where it was. Video is the master: audio_e2e = (now + buffered_ahead + clock_offset) − pts_ns av_offset = audio_e2e − video_e2e (> 0 ⇒ audio behind the picture) `AvSync` smooths that with an EWMA, ignores what sits inside a deadband no listener can detect, refuses the implausible outright rather than clamping it (a wall-clock step must not steer the ring), and proposes a depth. Swift refuses one thing Rust does not have to: the arithmetic itself. The Rust controller works in i128, while Swift has no Int128 at this tools version, so the terms are combined with overflow-REPORTING arithmetic instead of the `&-` the latency meters use. That is not defensive padding — `ptsNs = 1 << 63` reads as `Int64.min`, the difference lands on exactly `Int64.min`, and `abs()` of that has no representable result, so checking the overflow flags AFTER the sanity limit does not mis-measure the stream, it aborts the process from the audio drain thread. The guard's short-circuit ordering is what makes the sanity check safe to run at all. Continuity outranks sync, always. `AudioRing.setSyncTarget` only ever takes a REQUEST, clamped between the existing underrun-driven floor and the hard cap. A link whose jitter genuinely needs more buffer than the picture is away keeps its buffer and the residual is reported. `nil` is the default and reproduces the previous behaviour exactly. The clamp raises its ceiling to the floor rather than using it as-is: a device whose callback quantum alone exceeds the hard cap makes floor > cap, and a plain `min(max(s, floor), cap)` would then hand back the CAP — quietly below the continuity floor, inverting the exact ordering this exists to guarantee, on the awkward hardware it exists to survive. (Rust's `Ord::clamp` announces that condition by panicking; Swift would just get it wrong, which is worse.) The reference is the other half, and without it the loop is inert — which is why this was split out rather than shipped alongside the Rust side. `LatencyMeter` now publishes its most recent sample as a LEVEL, so the end-to-end meter the presenter already writes per presented frame becomes the video figure the audio plane reads. Both present paths (arrival and deadline) feed it without either knowing audio exists, and the stage-1 fallback presenter — which stamps no present at all — offers nothing, so the loop correctly declines to correct. The level EXPIRES, unlike the Rust atomic: this client has a backgrounded keep-alive that keeps audio playing and drops video decode entirely, and a reference with no expiry would go on steering the ring against a figure minutes old and frozen. And the reason none of this was visible: `bufferedMS`/`targetMS` existed only in a periodic log line, absent from anything a surface could render. The HUD's detailed tier now carries `audio buffer N ms · a/v ±N ms` and the 1 Hz stats log gains the same pair, appended last so existing parsers are unaffected — both numbers, because a deep ring on a jittery link is correct and only the offset separates that from audio held late. `PUNKTFUNK_NO_AV_SYNC=1` disarms the loop without a rebuild, as on the Rust clients. Verified: swift build + 225 tests (5 skipped) green. Every new gate was proven non-vacuous by planting its own defect and confirming the gate caught it — the continuity invariant, the clamp inversion, the deadband, both refusal paths, the evidence threshold, the sync-pressure relax, the reference's staleness and its survival of a drain, and `setSyncTarget` being live at all rather than dead code, which is how the previous pass in this area shipped a correction that was structurally unreachable with a green test. Two gates came back VACUOUS on the first sweep and are the reason their inputs look so specific: the overflow test was being caught by the sanity limit instead of the overflow guard, and the refused-reference test was being caught by `latestSample`'s own `> 0` check rather than by where the publish sits.	2026-08-08 00:10:48 +02:00
enricobuehler	f926bab9f7	fix(client): the native VAAPI rung stopped dropping decoded frames on the floor ... `finish` showed `outputs.last()` and retired every other picture an access unit bumped out of the DPB without ever displaying it, and nothing flushed the DPB at end of stream. Measured on .25 against the vendored vectors: 225 of 250 frames for H.264, 204 of 250 for H.265, 45 of 50 for HEVC Main 10. D3D11VA and Vulkan deliver every frame, so this was the rung's alone. All four legs now deliver 250 / 250 / 50 / 250. The same function carried a second defect. `DmabufFrame::keyframe` was stamped with the CURRENT access unit's `is_idr`, not the flag of the picture it was about to display, and on a reordering stream those are different pictures: the IDR is bumped out several units after it decodes and arrived flagged `false` on all three legs' first frame, while a later AU draining the DPB flagged some old trailing picture as a keyframe. That field is `DecodedImage::is_keyframe`, the pump's post-loss re-anchor signal, so a mislabel re-anchors on the wrong frame. Three changes, all inside this rung: * **A deliverable queue**, the same shape as `video_vk_native`'s — extend, ship the front, trim the oldest past the bound, count and rate-limit the drops into `DecodeHealth::dropped`. Its DEPTH is derived differently and the divergence is documented: the Vulkan rung's bound is `HOLD_HEADROOM - PIPELINE_HOLD` = 1 because a queued frame there counts against the pool ON TOP of the DPB's own residency. Here the three claims are disjoint and a bumped picture MOVES from `pending`/slot to `held`, so the queue inherits the claim rather than adding one. The bound is the DPB's depth — the deepest carry-over a bump can leave — and the measured cost is at most one surface (zero on H.264, whose three seven-picture IDR drains are the deepest bursts these vectors have). A bound of 1 would have left 235 of 250 on H.264, most of the defect still in place. * **An end-of-stream flush.** This rung has no EOS signal and cannot have one: the pump feeds access units until the session ends and then drops the decoder. So `flush` has the two honest callers — `Drop`, where nothing can be presented and the job is to release the queue's surfaces and the DPB's before the pool goes, and a caller that KNOWS the stream ended, which today is the conformance harness. One walk, not a production path and an untested teardown path. AV1 needs none: it shows at most one frame per temporal unit and buffers nothing, which its 250/250 says out loud. * **`PictureFacts` recorded when a picture decodes**, and read back when it is displayed. `keyframe` was the defect; `color` and `display` are the same mistake one field along — an in-band HDR switch changes the VUI mid-stream and AV1's render region is per-frame, so a queued frame shown two units later would have been drawn with the newest picture's signalling. Concealment answers `Ok(None)` and deliberately does NOT drain the queue, which is the Vulkan rung's order and is load-bearing: `clears_demotion_streak` is `delivered || !concealed`, so shipping a queued frame on a concealed AU would zero the streak and take away the escape hatch that stops a rung concealing forever from holding a frozen picture. The three delivered-count assertions moved with the fix, and so did the CPU derivation that reproduces them without a GPU — it now simulates the whole delivery model (ledger, queue, one-per-AU hand-off, flush) in the order `decode` does it, and carries the old behaviour beside the new one as a counterfactual: a queue bound of 0 with no flush still reproduces 225/204/45 exactly, and the test fails if it ever stops being SHORT. `settle` was split out as the pure half of `finish` so the claim walk, the display ordering and the picture facts are all assertable with no device; `the_queue_never_needs_a_surface_the_pool_does_not_have` runs the surface-lifetime arithmetic over the real vectors and pins the peak claims (9 of a 16-surface pool on H.264, 8 of 14 on both HEVC vectors), with an unbounded queue as the counterfactual that shows the bound doing its job. Gates run: `cargo fmt --all -- --check`, `cargo clippy -p pf-client-core -p pf-vaadec --all-targets --features sdl3/build-from-source -- -D warnings`, `cargo test -p pf-client-core --lib --features sdl3/build-from-source` (176 pass), the same filtered to `video_vaapi_native -- --include-ignored` (23 pass, 0 ignored) and `cargo test -p pf-vaadec` (48 pass) — all on .25 (Radeon 780M, RDNA3, radeonsi, Mesa 26.0.3, VA-API 1.23); plus `cargo fmt --all -- --check` and `cargo clippy --workspace --all-targets -- -D warnings` in pf-lxcheck2.	2026-08-08 00:10:35 +02:00
enricobuehler	74270109dd	ci(android): lint the Android target, which nothing had ever done ... `ci.yml` runs `cargo clippy --workspace` on the HOST, where `clients/android/native` and every `#[cfg(target_os = "android")]` module elsewhere compile out, and `android.yml` only ever built. So the Android target was never linted at all — not once. Five lints were sitting in clients/android/native when this was noticed, in code no gate had ever read. The gate is a Gradle task rather than a YAML step because cargo-ndk needs a specific discovery environment (NDK sysroot, SDK cmake 3.22.1 for libopus, `LIBOPUS_STATIC`, Ninja) and duplicating it into the workflow would let the lint drift from the build — a lint that ran against a different toolchain is a lint about a different program. `registerCargoNdkClippy` reuses the build task's environment verbatim via the extracted `cargoNdkEnvironment`, so local and CI runs are the same invocation. It lints BOTH pointer widths, and that is load-bearing rather than thorough: arm64-v8a is 64-bit and armeabi-v7a is 32-bit, so a cast that is redundant on one can be required on the other. Linting only the primary ABI would license "fixes" that break the 32-bit build — the shipping ABI for the many 32-bit Google TV / Android TV boxes this client targets. x86_64 is skipped: it is emulator-only and shares its width with arm64, so it costs lint time for no signal the other two do not already carry. The five resident lints: * `audio.rs` / `mic.rs` `type_complexity` — the open-attempt closures now return named `OpenedPlayback` / `OpenedCapture` aliases. The two tuples are mirror images of each other (playback sends, capture receives), which the aliases now say out loud. * `vsync.rs` ×2 `unnecessary_cast` — **not** taken. `timespec`'s fields are 32-bit on armv7 and 64-bit on arm64, so the casts are REQUIRED on one shipping ABI and redundant on the other; following the suggestion would break the 32-bit build. `i64::from`/`.into()` do not escape it either, they trade `unnecessary_cast` for `useless_conversion` on the 64-bit side. Answered with a documented `#[allow]` at the expression instead of in whichever build breaks first. * `pad_audio.rs` `needless_range_loop` — iterator form, preserving the `channels < 2` no-op the range had. Verified: `:kit:cargoNdkClippy` green on both ABIs, host-lane clippy for the crate still clean, `cargo fmt --all --check` clean. The gate was proven non-vacuous by planting `1i32 as i32` in an android-only module and confirming it fails the task, then reverting.	2026-08-08 00:01:39 +02:00
enricobuehler	70e6b80200	fix(client/android): place audio with the picture on Android too ... The core, Linux, Windows and host halves of the audio latency overhaul landed with Android deliberately left inert: `JitterPolicy`'s sync target defaults to `None`, so this ring kept behaving exactly as it always had. What was missing was not the loop but its REFERENCE — nothing here published where a frame actually reached glass, and a controller with no reference is the mechanism you can prove is present but that cannot act. This wires both halves. The decode thread now reads the host capture `pts_ns` that every `AudioPacket` has always carried and that this client, like every other, dropped on the floor. Against the ring depth (published by the AAudio callback through the shared `AudioSyncCell`) and the video plane's end-to-end figure it computes audio_e2e = (now + buffered_ahead + clock_offset) − pts_ns av_offset = audio_e2e − video_e2e (> 0 ⇒ audio behind the picture) and asks the ring for a depth that closes it. Only ASKS: `set_sync_target` is clamped between the underrun-driven adaptive floor and the hard cap, so a link whose jitter genuinely needs more buffer than the picture is away keeps its buffer and the residual is reported instead of being taken out of the listener's stream. Continuity outranks sync, on this ring as on the others. The reference comes from `DisplayTracker`'s `OnFrameRendered` callback — the one place in the client that knows a frame truly latched — and it is computed ABOVE the HUD gate now. A sync loop that only ran while the overlay was up would be off on exactly the devices that report latency; the stats LOCK stays gated, which is what that early-return was really protecting. Both decode loops feed it, so sync works with "Low-latency mode" off as well. Two deliberate refusals: * The figure is published RAW. The HUD shaves the OS present floor off its shown display/end-to-end numbers — metrics report what Punktfunk controls — but sound has to reach the ear when the light reaches the eye, and a floor-shaved reference would place audio a whole latch period early on every device. * Below API 33 there is no render callback, so there is no confirmed present and the loop stays inert (target `None` ⇒ today's behaviour exactly). The release instant is NOT substituted for it: a release targets a FUTURE vsync and runs a whole latch period (8-21 ms measured) ahead of glass, well outside the loop's deadband — it would place audio early on every frame while looking like it was working. The plane is also no longer invisible. Ring depth and the smoothed offset ride the stats array at 33/34 and the Detailed HUD carries `audio buffer N ms · a/v ±N ms`, the same wording the desktop HUD uses — both numbers, because a deep ring on a jittery link is correct behaviour and only the offset separates that from audio simply held late. The 1 Hz logcat line gains `av_ms` beside its depth, and the depth itself now has ONE publisher: the counter copy is gone in favour of the sync cell both readers already share. The escape hatch is two levers. `PUNKTFUNK_NO_AV_SYNC=1` keeps the contract the desktop clients document, but an app launched from the launcher inherits no environment, so the one a field tester can actually reach is `adb shell setprop debug.punktfunk.no_av_sync 1` — no rebuild, exactly like `debug.punktfunk.presenter`. A loop that steers playback has to be bisectable on the device that reports the regression. Verified: `cargo ndk -t arm64-v8a check` clean; `cargo clippy -p punktfunk-client-android --all-targets -- -D warnings` clean on the host lane CI lints, and the Android target introduces no new findings (5 pre-existing lints in audio/mic/pad_audio/vsync are unchanged — the android-gated modules are never linted by the host workspace); `cargo fmt --all --check` clean; `./gradlew :app:testDebugUnitTest` green. The new HUD test was proven non-vacuous by planting the defect first — dropping the render call fails its three positive assertions and leaves the three absence assertions passing, which is the shape a test that "passes for the wrong reason" would not have. design/audio-latency-overhaul.md W4. Apple (W6) still keeps today's behaviour.	2026-08-07 23:51:15 +02:00
enricobuehler	12a5318397	fix(audio): place audio with the picture instead of wherever the ring settles ... The host stamps `pts_ns` on every audio datagram and the client decoded it into `AudioPacket` — and then never read it. Video's `pts_ns` is used end to end (the presenter computes a true glass-to-glass `displayed + clock_offset − pts`), so audio free-ran at whatever depth its jitter ring happened to reach, video was presented on an independent path, and nothing ever compared them. The A/V offset was an accident of buffer depths: it moved whenever the ring ratcheted under underrun pressure, and it got WORSE every time video got faster, because a quicker decoder lowers the video leg and leaves audio's exactly where it was. That is what a field report on the Steam Deck heard as "the audio delay is way too high", and it is why shaving milliseconds off the audio budget had not helped. Video is the master. In a game streamer the video leg is the input-feel budget and must never be inflated to satisfy the audio clock, while audio tolerates small crossfaded corrections that are inaudible — and `crossfade_drop` already applies them. So audio moves: audio_e2e = (now + buffered_ahead + clock_offset) − pts_ns av_offset = audio_e2e − video_e2e (> 0 ⇒ audio behind the picture) `AvSync` smooths that with an EWMA, ignores what sits inside a deadband no listener can detect, refuses the implausible outright rather than clamping it (a wall-clock step must not steer the ring), and proposes a depth. Continuity outranks sync, always. `JitterPolicy::set_sync_target` only ever takes a REQUEST, clamped between the existing underrun-driven floor and the hard cap. A link whose jitter genuinely needs more buffer than the picture is away keeps its buffer and the residual is reported — sync can never starve the ring into dropouts. `None` is the default and reproduces the previous behaviour exactly, so the four client rings can adopt this one at a time without diverging. Two upstream defects found on the way, both prerequisites: * The host stamped `pts_ns` at ENCODE time, inside the loop draining an already-accumulated chunk, so every frame of a chunk carried near-identical timestamps describing when we got round to encoding. Harmless while nothing consumed it; a sync loop regulating against it would regulate against a fiction. It now comes off the capture clock. * The host did not pace. One capture callback hands over a whole quantum — 5 ms when the graph honours our ask, 21.3 ms on a VM, where stock PipeWire raises `min-quantum` to 1024 — and the loop drained all of it into back-to-back `send_datagram` calls. The wire carried a 4-5 frame burst then ~21 ms of nothing, and a ring can only absorb that by standing a burst period deep. Frames now leave on the audio clock, which costs no average latency. And the reason none of this was visible: `buffer_ms`/`target_ms` existed only as a `tracing::debug!` line, absent from `Stats`. On a Deck the client runs under Steam's `reaper` with stdout on a pipe nobody can read, so the one number identifying a deep ring was unobtainable on the device reporting the latency. The HUD now carries `audio buffer N ms · a/v ±N ms` — both, because a deep ring on a jittery link is correct and only the offset separates that from audio held late. The host also reports its negotiated quantum against the one it asked for, per capture open rather than once per process. Verified: 364 core + 40 presenter tests on Linux, clippy -D warnings clean on punktfunk-{core,host} + pf-{client-core,presenter}, fmt clean. New tests pin the safety invariant (sync cannot pull the target below the continuity floor on any preset), that `None` leaves the policy bit-identical, and that a device quantum exceeding the hard cap does not panic `Ord::clamp` inside a realtime callback. Android and Apple keep today's behaviour (the `None` default) until their presenters publish a video figure to align against; design/audio-latency- overhaul.md carries the plan.	2026-08-07 23:33:45 +02:00
enricobuehler	1482e6b373	docs(client): all four VAAPI legs have decoded — the evidence table said two never had ... The H.264 and H.265 rows still read "NEVER decoded a frame on any hardware". That stopped being true on 2026-08-07, in the same session that proved AV1: every access unit of the vendored H.264 (250), H.265 (250) and HEVC Main 10 (50) vectors was accepted on .25 (Radeon 780M, RDNA3, Mesa 26.0.3) with no decode error — NV12 for the 8-bit legs, P010 for Main 10, all on the same tiled AMD modifier — and probe_this_machines_libva reports VLD decode for all three profiles. The row records the delivered counts honestly rather than rounding them up: 225/204/45 against 250/250/50 access units, because `finish` shows `outputs.last()` and drops the other pictures an AU bumps, and nothing flushes the DPB at end of stream. That is this rung's own behaviour — D3D11VA delivers all 250 — and it is invisible on punktfunk's zero-reorder host output. It is recorded and asserted rather than fixed: changing the one-frame-per-AU contract touches the pump's deliverable queue, an end-of-stream flush, and the `keyframe`-labels-the-access-unit defect in the same function, so it belongs in a commit that moves all three. Still `verified = false` for all four, and the note says why in the words the unproven-rung test requires: never frame-hash parity-checked. That is not pedantry — the D3D11VA AV1 row two lines above is a rung that decoded 250 frames and produced wrong pixels for every one of them. Parity is what distinguishes them, and this rung exports a tiled dmabuf with no CPU-readable image, so it needs a readback path nothing has written yet.	2026-08-07 23:13:17 +02:00
enricobuehler	79afa9ce79	Merge branch 'fix/hevc-lowdelay-parity-gate' into integration/decode-aliasing-program	2026-08-07 23:12:22 +02:00
enricobuehler	bb9f482b2c	Merge branch 'fix/vaapi-decode-target-aliasing' into integration/decode-aliasing-program	2026-08-07 23:12:06 +02:00
enricobuehler	dc116d28ca	Merge branch 'fix/vaapi-h264-h265-hardware-proof' into integration/decode-aliasing-program	2026-08-07 23:12:02 +02:00
enricobuehler	d25a20a233	feat(vkdecode): the AV1 rungs meet a second tile for the first time ... Every AV1 frame either decode rung has ever been measured against is `tile_cols = tile_rows = 1`. The vendored vector is single-tile on all 274 of its frames, so every tile array the conversions fill — `tiles.widths`, `tiles.heights`, the per-tile records — had only ever been written at index 0, and a conversion that wrote tile 0 and left the rest zero would pass the whole suite. Our encoder splits 4K into TWO TILE ROWS. **The fixture.** `lowdelay-3840x2160.ivf.av1`, 261 KB, 60 frames — `punktfunk-host spike --source synthetic --codec av1 --width 3840 --height 2160 --fps 60 --seconds 1 --bitrate 1` on .21 (NVENC, RTX 5070 Ti), wrapped to IVF with `ffmpeg -f obu … -c copy` so `common::split_av1_aus` (the vendored parser's own `IvfIterator`) frames it exactly as it frames the vector, with no second splitter that could disagree. **4K is not a size choice, it is the only shape with the property.** Measured on the same box with the same command: 1280x720, 1920x1080 and 2560x1440 all give `tile_cols = tile_rows = 1`; 3840x2160 gives `tile_cols = 1, tile_rows = 2` with `width_in_sbs_minus_1 = [59]`, `height_in_sbs_minus_1 = [16, 16]`, and both tiles in ONE Tile Group OBU. 60 frames instead of 120 pays for the resolution: 261 KB, under both the 282 KB H.264 and 270 KB H.265 low-delay fixtures. Goldens are libavcodec's software decode, cross-checked between ffmpeg n8.1.2 (Arch x86_64, libdav1d) and 8.1.1 (Homebrew, macOS arm64, libdav1d) whose 746,496,000-byte raw outputs are BYTE-IDENTICAL, not merely equal per frame. 60 of 60 digests distinct. **AV1's frame accounting is asserted, never derived.** The vendored vector is 250 temporal units carrying 274 coded frames of which 24 are hidden; this stream is 60 units, 60 coded, 60 shown, 0 hidden, 0 `show_existing_frame`, 1 key frame. Neither is the general case, so both parity harnesses now take units / decoded / shown as three independent parameters instead of computing one from another, and the CPU guard states all six numbers. **A CPU gate that needed no hardware at all.** `pic_av1`'s new `a_two_tile_frame_fills_both_row_entries_and_leaves_the_rest_zero` pins the second row entry against its OWN `height_in_sbs_minus_1`, requires the two rows to tile the frame exactly, and requires TWO tile RECORDS out of ONE tile group with rows (0,0) and (1,0) — the transposition a square grid could never reveal — each spanning real bytes. The existing one-tile test asserts index 0 is right and `1..` are zero, which a broken multi-tile conversion also satisfies. ⚠⚠ **This is a file, and on AV1 that distinction has already cost a release.** "250/250 delivered frames bit-identical to libavcodec" was true for the entire period the host was shipping only the FIRST TILE of every 4K frame: the verification ran against a vendored file while the truncation lived in packetisation, and the suite stayed green throughout. This fixture closes the multi-tile gap on the DECODE rungs and closes nothing about fragmentation, reassembly, loss or AU boundaries — the golden header, both module docs and the leg docs all say so, at length, so the next reader does not inherit the same false confidence. Legs: `low_delay_host_av1_every_frame_hashes_bit_identical_to_libavcodec` on the Vulkan rung (11 ignored legs now) and on the D3D11VA rung, plus two non-ignored CPU tests. Verified: 11/11 Vulkan parity legs on .21 (RTX 5070 Ti, 610.57.04), the new one 60/60 bit-identical; workspace clippy `-D warnings` and `cargo fmt --all --check` clean on .21.	2026-08-07 23:09:12 +02:00
enricobuehler	de1bfdc0c5	Merge pull request 'The console stops borrowing the browser's controls — and its preset tiles stop landing all at once' (#100) from worktree-web-console-sweep into main ... Reviewed-on: #100	2026-08-07 21:08:42 +00:00
enricobuehler	3be7d1d4f8	feat(web): the console asks its own questions ... Follow-up to a85e8452, closing the three items that sweep flagged and left. SIXTEEN BROWSER DIALOGS, GONE. Every destructive action in an otherwise fully branded console handed off to `window.confirm` — a grey OS box with the page's URL in it, no brand, no red on a delete, and untouchable by any story or screenshot, which is part of why it survived this long. They are replaced by one promise-based surface (components/dialogs.tsx) rather than a dialog per call site. The native calls were EXPRESSIONS — `if (!confirm(…)) return;` — threaded through mutation handlers; rewriting each into "hold the pending action in state, render a dialog, run it from onConfirm" would have put dialog machinery in every section file and turned each linear handler inside out. Returning a promise keeps them the shape they already were, and it is what let the navigation guard come along too: TanStack's `shouldBlockFn` accepts `Promise<boolean>`. `beforeunload` necessarily stays native — a reload is the browser's dialog to draw, and it will not wait on ours. No warning copy was rewritten. Each message was SPLIT at its existing sentence boundary: the question becomes the dialog's title, the consequence its body, and "Continue?" is dropped where the affirmative button now carries the verb ("Delete", "Uninstall", "Unpair", "Stop every session"). 16 new keys, en and de in parity at 629. Verified by driving the real dialogs in a headless browser — all seven contract checks pass, including the two that would be invisible until they bit: Escape SETTLES the promise (an unsettled one would hang a mutation handler forever with no error), and a cancelled prompt resolves null rather than "", so a caller can still tell "backed out" from "cleared the field". FOUR OF THE SEVEN NUMERIC FIELDS became InputNumber; three deliberately did not, and now say why in place. The layout X/Y pair had a real defect: a screen left of the origin has a negative coordinate, and `Number("-") || 0` rewrote the lone minus sign to "0" before the digits could be typed. Measured on the built page: the field can now be emptied to retype instead of snapping to its floor, and 900 in a 1..=16 field clamps to 16. The three left alone cannot take it — the grace seconds field writes to the HOST on blur (InputNumber commits while typing, so its clamp would race the apply), and the library's year/players are OPTIONAL, where `value: number` has no way to say "unset" and would invent a year for every entry without one. The select's highlighted row moves off @unom/ui's neutral grey onto the brand wash the nav and the preset cards already use. The Displays story earned its keep immediately: adding `useDialogs` to that page broke it in Storybook, because the provider was mounted in __root and nowhere else. It belongs beside the other app-level providers in .storybook/preview.	2026-08-07 22:56:46 +02:00
enricobuehler	e8a7a1e6af	fix(client/vaapi): the third rung does NOT alias — and now it cannot start to ... The D3D11VA and Vulkan rungs both decoded into a surface they were predicting from, on 117 of 120 access units of our own host's low-delay H.264 (`1c54d099` for AV1, `834b2443` for H.264). `pf-vaadec` feeds `reference_frames` from the same `plan.dpb_refs` snapshot, releases its whole `removed` list inline exactly as the two broken conversions did, and neither fix commit touched it. It is still exempt — this is the evidence, and the thing that keeps it true. **Measured on the CPU, no GPU needed.** `walk_for_aliasing` drives the planner and `plan_to_va` over both streams and counts four shapes. On `lowdelay-640x480.h264` the aliasing PRECONDITION is fully present: 117 of 120 access units remove a picture their own `dpb_refs` still names, and on the same 117 the setup picture is handed the slot of a picture that access unit READS — the D3D11VA/Vulkan defect verbatim, in this conversion, today. On the vendored conformance vector both counts are 0, which is why that vector proved nothing on two other backends for two milestones. Aliased submissions: **0 on both**. **Why.** A slot is not a surface here. `plan_to_va` never invents one — every reference it can name is read out of the `surfaces` table it is handed — and the decode target is a separate parameter the caller takes from OUTSIDE that table. `setup_surface` reaches the submission at exactly one field per codec (H.264/H.265 `curr_pic.picture_id`, AV1 `current_frame` and `current_display_picture`); HEVC is doubly safe, because its per-slice `RefPicList` stores an INDEX into `reference_frames` rather than a surface. AV1's documented substitution fallback is the one place the target can be named as a reference, and only where the store resolved nothing at all to prefer. **The exemption was incidental; it is structural now.** It needs the reference table and the decode target to come from ONE snapshot of the bindings, and the rung had that only by writing `free_surface()` and `surface_table()` adjacently at three call sites. Split them and this rung acquires the defect exactly: the table must be the PRE-removal one (that is where the references are), while a free list consulted after the removals offers precisely the displaced picture's surface. `Session::acquire_target` now returns the index, the surface and the table together from `&self`, so a later edit cannot move one call and not the other. No behaviour change: same order, same values, same refusal message. Tests. `no_submission_names_its_decode_target_as_one_of_its_own_references` (both streams, 0) with `taking_the_decode_target_from_the_slot_table_aliases_on_the_low_delay_stream` as the counterfactual that reproduces the defect on 117 of 120 — so the walk demonstrably CAN see it when it is there. `the_low_delay_stream_reassigns_slots_whose_pictures_it_still_reads` pins 0/250 and 117/120 so neither can drift silently. `the_decode_target_can_never_be_a_surface_the_reference_table_names` sweeps every binding state a 4-surface/3-slot pool can hold, and `taking_the_free_surface_after_the_removals_would_hand_out_a_referenced_surface` is the ordering counterfactual. ⚠ One existing test lost a VACUOUS half. `the_setup_picture_routinely_inherits_a_just_freed_slot` asserted the decode target was never also a reference while handing every picture its own never-reused surface id — distinct integers cannot collide, so that assertion could not fail whatever the conversion did. Its real measurement (225 of 250 access units reuse a just-freed slot, which is why the target is a parameter) is kept; the collision half is gone, and the doc says where the question is actually answered and why a recycling pool is what it takes to answer it. Gates, run on `.25` (Radeon 780M, radeonsi, Mesa 26.0.3, VA-API 1.23), this rung being Linux-only: `cargo fmt --all -- --check`; `cargo clippy -p pf-client-core -p pf-vaadec --all-targets --features sdl3/build-from-source -- -D warnings`; `cargo test -p pf-client-core --lib --features sdl3/build-from-source` (171 passed); the same filtered to `video_vaapi_native` with `--include-ignored` (18 passed); `cargo test -p pf-vaadec` (48 passed). Plus the pf-lxcheck2 container for the cross-platform half — fmt, clippy and `cargo test -p pf-vaadec`, all clean. All four VAAPI legs still decode with the refactor in place, not one access unit refused: H.264 225 of 250 access units delivering a frame, H.265 204 of 250, HEVC Main 10 45 of 50 (P010), AV1 250 of 250 — the same counts and the same tiled modifier 0x200000010401b04 those legs recorded before it. ⚠ The H.26x legs live on `fix/vaapi-h264-h265-hardware-proof`, not on this branch, so they were run by overlaying that commit's test module onto the scratch tree; only the AV1 leg and the libva probe are reachable from here. This is a decode measurement, not frame-hash parity — the rung exports a driver-tiled DRM-PRIME dmabuf, so there is no CPU-readable image to hash. The alias assertions above are the real evidence and they need no device. ⚠ NOT taken: `finish`'s `outputs.last()`, which ships one frame per access unit and drops the rest of what a bump displaces (225/204/45 against 250/250/50), with no end-of-stream flush. It cannot bite punktfunk — hosts emit zero-reorder output, so `outputs` never holds more than one picture — and fixing it changes `decode()`'s one-frame-per-access-unit contract with the pump (it wants a deliverable queue, which `video_vk_native` already keeps) plus an end-of-stream flush and the `keyframe`-labels-the-access-unit defect in the same function. It is recorded and asserted on that other branch, whose three delivered-count assertions any fix has to move in the same commit; doing that from here, blind to them, would be worse than leaving it.	2026-08-07 22:55:25 +02:00
enricobuehler	f0702f3e06	feat(vkdecode): HEVC's exemption stops being an argument and becomes a vendored stream ... `fd6241a2` made HEVC's freedom from the release-ordering defect falsifiable on CPU and recorded what was still missing: no low-delay HEVC stream was vendored, so the exemption rested on a structural argument plus one throwaway measurement. This vendors the stream, and the exemption HELD. **The fixture.** `lowdelay-640x480.h265`, 270 KB, 120 pictures — `punktfunk-host spike --source synthetic --codec h265 --width 640 --height 480 --fps 60 --seconds 2 --bitrate 1` on .21 (NVENC, RTX 5070 Ti, driver 610.57.04). Deliberately the H.264 sibling's resolution and frame count: the two are then directly comparable, 640 and 480 are both multiples of MinCbSizeY so there is no conformance window and a hash mismatch can only be decode rather than readback geometry, and 270 KB sits alongside the 282 KB already accepted for H.264. Goldens are libavcodec's software decode, cross-checked BIT-IDENTICAL across ffmpeg n8.1.2 (Arch, x86_64) and 8.1.1 (Homebrew, macOS arm64), 120 of 120 digests distinct. **The exemption held, measured rather than argued.** `sps_max_dec_pic_buffering_minus1 = 4` against the four pictures 8.3.2 keeps marked in steady state, `sps_max_num_reorder_pics = 0`, `numRefL0 = 1` — a five-picture DPB filled exactly by four references plus the current picture. 115 of the 120 access units retire a picture, and `removed ∩ dpb_refs` is **0 of 120**. A 300-picture 1080p stream from the same host reports the same shape: 295 retirements, 0 intersections. It is the encoder and not the resolution, exactly as for H.264. **A zero proves nothing on its own, so the fixture is pinned by its counterfactual.** `test-25fps.h264` reported zero for two milestones while every stream we ship aliased on 99% of its frames. So the guarantee here is not "we looked and it was fine": hand `plan_to_dxva_h265` the marked DPB as it stood BEFORE `decode_rps` — the mutation a snapshot move would cause, reconstructed exactly as `dpb_refs(N-1) ∪ {stored(N-1)}` — and the alias appears on **115 of 120** access units, driven through the real conversion rather than through planner arithmetic. If a regeneration ever produced a stream that reordered, or a DPB deeper than its reference count, that 115 collapses to 0 and the tests say so instead of continuing to pass. **The two rungs are exempt for different reasons, and the asymmetry is now a gate.** DXVA binds the whole marked DPB — `RefPicList` is spec-defined that way, and an RFI long-term anchor has to survive in it — so its exemption really is `H265Planner`'s snapshot ordering, one call away from being untrue. `plan_to_vk_h265` never reads `dpb_refs` at all: `pReferenceSlots` is the slots the operation uses, so it binds the current RPS sets, which `decode_rps` itself derives and which therefore cannot name a picture that same RPS just dropped. A new test feeds that conversion the identical widened snapshot and asserts nothing changes, so a future change making the Vulkan rung bind the marked DPB — a legitimate thing to want, since a *Foll* anchor invisible to the hardware is the RFI failure shape — fails loudly instead of silently acquiring the defect. What the Vulkan pixel leg adds is therefore NOT aliasing coverage, and its docs say so: it is the first HEVC frame either rung has decoded from our own encoder, under a DPB that retires and reissues a slot on 115 of 120 access units back to back, where the vendored vector's reordering keeps that eviction slack. Legs: `low_delay_host_h265_every_frame_hashes_bit_identical_to_libavcodec` on the Vulkan rung (10 ignored legs now, up from 9) and on the D3D11VA rung, plus three non-ignored CPU guards that run in ordinary CI. Verified: 10/10 Vulkan parity legs on .21 (RTX 5070 Ti, 610.57.04), the new one 120/120 bit-identical; workspace clippy `-D warnings` and `cargo fmt --all --check` clean on .21.	2026-08-07 22:53:22 +02:00
enricobuehler	a85e845255	fix(web): the console stops falling out of its own design system ... A pre-release sweep of the management console for two things that no type check and no diff can catch: primitives that were never @unom/ui's, and animation that a nested motion parent quietly cancelled. THE PRESET TILES ALL LANDED ON THE SAME FRAME. @unom/ui's <Section> sets `delayChildren: stagger(...)`, so a page whose cards are direct descendants of it staggers for free — which is why every page but one looked right. An <AnimatedCard> is ALSO a motion element and sets no `delayChildren`, and the Virtual displays preset tiles are cards nested INSIDE that page's config card, so that card became their timing group. Measured in a headless browser: the opacity spread between the first and last tile was 0.00 across the whole animation (six tiles in lockstep), and is 0.98 now — a ~100 ms cascade matching the rest of the console. The four hand-rolled copies of the stagger container collapse into one `<Stagger>` that carries the explanation. FIVE FILES IMPORTED THE WRONG BUTTON. `@unom/ui/button` exports both a plain `Button` and the `AnimatedButton` that this console's wrapper re-exports under the same name — so `import { Button } from "@unom/ui/button"` compiles, renders, and silently opts out of the mount animation and the hover/tap response. Displays, SessionGame, GPU, Update and PendingDevices had dead buttons sitting next to live ones. THREE PRIMITIVES HAD NO WRAPPER, SO NOBODY REACHED FOR THEM. @unom/ui ships form/select, form/textarea and form/checkbox; components/ui did not, and the gap was filled with browser-chrome `<select>`, `<textarea>` and `<input type="checkbox">` in the add-hook modal and both library forms. Select needs the same token correction Tabs needed — upstream `text-secondary` is a text colour, but here `--secondary` is a SURFACE, so the trigger's chevron and placeholder rendered at near-zero contrast on the card behind them. The hook timeout also stops accepting a value the host rejects: `min`/`max` on a controlled `<input type="number">` are decoration (no form validation ever runs), so 900 went into a field capped at 600 and failed later, at run time. @unom/ui's InputNumber clamps on blur and lets the field be empty while you retype instead of snapping to the fallback. Storybook gains the page that had no story at all — the console's largest config surface, and the reason this shipped unseen. Its <Card> wrapper is load bearing: it reproduces the motion nesting that IS the bug.	2026-08-07 22:34:24 +02:00
enricobuehler	fd6241a24f	fix(dxvadec): the review round — a doc that had become false, a warn-storm on renegotiation, and HEVC's exemption made falsifiable ... Four findings, all real. **`SlotMap`'s own docs had become false.** "feed it every `DpbUpdate` in decode order (via `Self::apply` or `plan_to_vk`, which applies internally)" — `plan_to_vk` no longer applies internally, which is the entire point of the change, and `release`'s docs named it as one of the two things that may free a slot. A reader following those docs would build the next caller wrong in exactly the way this commit's parent fixed. Both now say which conversions defer, which one does not, and why H.265 is the one that does not. **The deferred release warned on a legitimate event.** `release_deferred` warned per id when a deferred release found no slot — but a renegotiation replaces the whole `Session`, and with it the slot map, INSIDE `plan`, while the planner's own drain reports every drained picture in that same access unit's `removed`. Every one of those ids then misses, and nothing is wrong. `debug!`, with the legitimate cause named so the illegitimate one stays diagnosable. **HEVC's exemption was asserted only in its consequence.** `the_current_picture_is_ named_by_curr_pic_and_never_aliases_a_reference` checked that no reference shares the decode target's slot — which on the vendored vector holds whether or not the reasoning behind it does. That is precisely how the H.264 leg passed for two milestones. The test now also asserts the PLANNER property the exemption rests on (`removed ∩ dpb_refs = ∅`, falsified by moving `dpb_snapshot()` above `decode_rps`), and records that the low-delay measurement was 0 of 300 against H.264's 297 of 300 from the same host and the same run. It also records what is still missing: no low-delay HEVC stream is vendored, so HEVC's freedom is a re-derivable argument plus one measurement, not a standing hardware leg. **Two stale cross-references.** Both AV1 conversions told the reader the H.264/H.265 zero was "measured on reordering vectors and not a proof" — the open question this commit's parent closed. They now say what the answer was.	2026-08-07 22:19:12 +02:00
enricobuehler	834b244301	fix(client): the H.264 twin was real — every low-delay picture decoded into a surface it predicted from ... The AV1 review round flagged the H.264 leg as "plausibly the same defect, traced in source, not reproduced" and deliberately did not touch it. It is reproduced now, and it is worse than the AV1 one: it fires on 297 of 300 access units of every stream a punktfunk host emits, at 720p, 1080p and 2160p alike, on BOTH the DXVA rung and the Vulkan one. **Decided on the CPU, no GPU needed.** `H264Planner` snapshots `dpb_refs` in `begin_picture`, BEFORE `finish_picture` runs 8.2.5's marking and C.4.5.3's bump, so a picture the sliding window unmarks and the bump then evicts lands in both `dpb_refs` (which `RefFrameList` is built from) and `dpb.removed`. The conversion released the whole `removed` list and then assigned the decode target a slot; `SlotMap::assign` takes the lowest free slot, which is the one just vacated. `CurrPic = N` and `RefFrameList[k] = N`, in one submission. The two conditions have to coincide in ONE access unit, and low-delay H.264 is exactly what makes them: `max_num_reorder_frames = 0` means the evicted picture has already been output, which is what makes it evictable at all. NVENC seals it by writing `max_num_ref_frames = 3` ALONGSIDE `max_dec_frame_buffering = 3` — a DPB exactly as deep as its reference count — so the window unmarks the oldest reference in the very unit whose bump drops it. The aliased picture is `ref_idx 2` of a three-entry `num_ref_idx_l0_active` list: addressable by any macroblock, not a spare. **Why two hardware-proven codecs and four GPUs never saw it.** `test-25fps.h264` is level 1.3 with no VUI `bitstream_restriction`, so `dpb_limit` falls back to A.3.1's level ceiling and gives a 7-frame DPB against 2 reference frames — the window unmarks two units before the bump can evict — and it REORDERS, which keeps an unmarked picture alive past the unit that unmarked it. Two independent reasons, both properties of that vector rather than of H.264. It measured zero and passed 250/250 throughout. `data/lowdelay-640x480.h264` is vendored to close exactly that: our own host's output, 120 pictures, goldens from libavcodec cross-checked bit-identical across two ffmpeg builds on two architectures. **The fix is the AV1 fix.** `DecodePlanDxva` and `DecodePlanVk` grow `release_after_decode`, the conversions hand the removals back instead of applying them, and the callers release them once the decode op is issued. It costs no slot the map does not have: `SlotMap::new` allocates `max_dpb_frames + 1` and the DPB never exceeds `max_dpb_frames`, so a free slot always exists with the whole `removed` list still held — measured, peak 4 of 4 on the stream that defers on 117 of 120 units. The Vulkan rung breaks on it in both DPB modes and neither loudly: DISTINCT hands the aliased reference the same array layer the setup writes; COINCIDE clears `slot_image[setup]` in the binding sync and the reference then resolves to no bound image, dropping out of `pReferenceSlots` with a `trace!`. Its deferred release runs on the FAILURE paths too — the fallible region's Result is held rather than `?`-ed, because seven exits sat between the conversion and the release and each would have leaked a slot. `a_full_dpb_bump_reuses_the_slot_but_the_pool_model_binds_a_fresh_image` asserted the aliasing as "the planner's normal behaviour": an authored depth-1 stream whose AU1 references the picture it evicts. It now asserts the opposite, which is the defect in two lines. New evidence, all of it runnable: the CPU proof pins BOTH numbers (0 on the vector, 117 of 120 on the low-delay stream) so neither can drift silently; the ledger-pressure test measures the peak; and a low-delay parity leg is added to `pf-vkdecode`'s `gpu_parity` and `pf-client-core`'s `video_d3d11_native::parity` so both rungs are held to what they stream rather than only to what they conform to.	2026-08-07 22:09:44 +02:00
enricobuehler	42e4d47743	Merge pull request 'Gyro: the pipeline was wrong end to end — measured against a real controller, and fixed' (#99) from worktree-gyro-p0-correctness into main ... Reviewed-on: #99	2026-08-07 19:51:17 +00:00
enricobuehler	5aeb8d2552	fix(client): a failed AV1 decode left the surface's facts saying it holds the last picture ... The `damaged` path has cleared `Session::held[setup_slot]` since M7, for a reason that now applies to the failure path too: the slot map says the surface holds THIS picture while the surface still carries whatever the previous occupant decoded, so a later `show_existing_frame` naming it blits the old picture's pixels with the old picture's geometry and colour. The failure path never reached that far before — `decode_into`'s error returned straight out of `frame_av1` — and the previous commit made it continue so the slot releases could run.	2026-08-07 21:36:16 +02:00
enricobuehler	3a4c94ad79	fix(dxvadec): the review round — a vacuous predicate, an overstated claim, and the H.264 twin of this defect ... Five findings from the adversarial pass, all real. **The deferral predicate was vacuous.** `plan.dpb.removed` is ALWAYS a subset of `plan.dpb_refs`: `Av1Planner::plan_frame` snapshots `dpb_refs` before any mutation and `refresh_slots` can only report a picture that was in `self.slots` at that moment. So `filter(|id| dpb_refs.contains(id))` was a condition that is never false, the eager-release loop beside it could never release anything, and the test assertion "only a picture the submission points at earns the reprieve" could never fire. Now: defer every removal, say why in terms of the planner, and assert the PLANNER's property (`removed ⊆ dpb_refs`) — which is falsifiable, and whose failure would mean the conversion is releasing a surface `ref_frame_map` points at. **The failure-path claim was overstated.** Holding the decode's `Result` closes this frame's leak, not the unit's: `decode_av1` returns on the first failing frame and abandons the rest of the temporal unit's plans, so their removals are never released. 24 of 250 units carry a second frame. Named rather than fixed — what to do with the frames after a failure is the pump's question. **⚠⚠ The H.264 leg plausibly has the same defect, and the comment this change added said it could not.** `pic.rs` builds `RefFrameList` from `plan.dpb_refs`, and `H264Planner` snapshots that in `begin_picture` — BEFORE 8.2.5 marking and the DPB bump. The vendored bump drops a picture the sliding window just unmarked once it has been output, so a picture can land in both `RefFrameList` and `dpb.removed`: the AV1 aliasing shape exactly. Measured zero on the vendored vector — but that vector REORDERS, which is precisely what keeps an unmarked picture alive past the AU that unmarked it. A punktfunk host emits LOW-DELAY H.264, where output happens as each picture is decoded, which is the condition that makes eviction and unmarking land in the same access unit. Traced end to end in source, not reproduced (no low-delay vector). NOT fixed: changing a hardware-proven codec on an unreproduced suspicion is the worse risk two commits before a release. Instead `no_au_removes_a_picture_its_own_reference_list_names` makes the assumption falsifiable, and its message says what to do when it fires. HEVC is structurally safe and now says why: `H265Planner` snapshots `dpb_refs` AFTER `decode_rps`. **Four more stale promotion sites**, past the four already fixed: `Backend:: NativeD3d11va`'s variant doc, `Decoder::new`'s Windows rung comment, `lib.rs`'s module note and `clients/session/README.md`. Two sites that used the AV1 leg as the live EXAMPLE of an unproven rung are marked as expired rather than deleted — the reasoning is what the next bad-evidence leg will need. **The AV1 dump was missing.** `PF_DXVA_DUMP` wrote h264 and hevc only, for the one codec whose libavcodec capture has never been taken and where the dump is therefore the only tool.	2026-08-07 21:34:59 +02:00
enricobuehler	ee61e8c9ba	fix(clients/pads): the phone mirror never needed the controller path's frame change ... Reverts half of 1eab4b66 and closes G10's open frame question, both settled by the same measurement. 1eab4b66 made two corrections to the Apple phone-gyro mirror. The negation was right and stays: Apple reports the gravity VECTOR, pointing down, while an accelerometer measures proper acceleration, pointing up at rest, and the wire carries the latter. The frame change was wrong, and this removes it. The mistake was a name collision. Two different frames are both called "the controller frame". GCMotion reports a CONTROLLER in (Right, Forward, Up) — measured on a real DualSense — which is not the wire's frame, which is why `GamepadCapture.forwardMotion` converts. The mirror's orientation remap resolves THIS DEVICE into the frame its header describes, x right, y up, z out of the screen. For the pose that mirror exists to serve — a phone clipped upright with the screen facing the player — "out of the screen" points at the player, so that frame is (Right, Up, Backward), which IS the wire's. It was already correct. Applying the controller path's conversion on top rotated it out of true: a phone sitting still would have reported gravity as −1 g on the roll axis rather than +1 g up, i.e. claimed to be lying on its edge. Reasoning by analogy is what produced it — "the mirror says controller frame, the capture path says controller frame, so the same fix applies". Both files say it; they mean different things. What caught it was measuring the Android twin, which does the same thing straight through. On glass: a DualSense on Bluetooth to a phone, streaming to a Linux host, reads +1 g on the up axis end to end. Had the Apple mirror needed a conversion, the Android one would have needed the same one and would have been visibly wrong. It is not. The same run settles G10's frame, which shipped straight-through and explicitly unverified because nobody had put a Bluetooth pad in front of the platform sensor framework. Now somebody has. `PadSensors`' own first-sample log read `accel 0, 10000, 0` — exactly 1 g on slot 1 — and at the far end hid-playstation published gravity as +0.991 g on ABS_Y, with every rotation driving its correctly-named axis and the signs agreeing with gravity's independent witness on 95 of 100 rotating samples. Android hands a controller's sensors over in the pad's own frame, as documented. No remap, and the comment now says measured instead of assumed. Worth recording why the earlier suspicion was wrong, since it is the same trap in the other direction: Android's DEVICE sensor frame really does put +z out of the screen, so a flat phone puts gravity on z — but a CONTROLLER's sensors are reported in the controller's frame, not the phone's. One platform, two conventions, chosen by what the sensor is attached to. Gate: Apple macOS `swift build` + full suite (215 tests, 5 skipped, 0 failures) and the iOS-triple typecheck, which is what actually compiles `DeviceGyro.swift`; Android `:kit:compileDebugKotlin`, `:kit:testDebugUnitTest`, `:app:compileDebugKotlin`. Green. Still owed: `DeviceGyroRemap`'s four orientation matrices remain derived — this run used a controller's own sensors, not the mirror, so it says nothing about them. They need a gyro-less pad on wire index 0 and a phone turned through all four orientations.	2026-08-07 21:28:13 +02:00
enricobuehler	af4d265168	fix(client): the fourth site that swore the DXVA AV1 leg fails parity, and a clippy lint ... `the_evidence_table_says_exactly_which_rungs_have_run_on_hardware` asserts the same fact a third way — a proven list and a NOT-proven list, both spelled out — so promoting the rung in the three places the handoff named still left a test saying "the DXVA AV1 leg FAILS parity on two GPUs — claiming otherwise is the dishonesty this program must not ship". It was right to fail; the pair moves lists here. Three prose sites that still described the leg as decoding wrong pixels move with it: `native_supports_av1`'s device-facts note, `log_rung`'s honesty-surface docs, and the OPEN question in the Windows Intel arm of `pick_native` — that last one is marked CLOSED rather than deleted, because the question it raised (the evidence filter asks "any evidence", and has no answer for BAD evidence) is a real gap in the rule that outlived this particular leg.	2026-08-07 21:10:03 +02:00