7 Commits

Author	SHA1	Message	Date
enricobuehler	1d587a259e	fix(client/d3d11va): green bar at the bottom — clamp the blit to the frame ... The decode surface is DXVA-aligned (height rounded up to the profile's alignment, 128 for HEVC/AV1), so it is taller than the frame: a 2400-line stream decodes into a 2432-line texture. VideoProcessorBlt was called with no stream source rect, so it blitted the WHOLE surface — the uninitialized padding rows (NV12 Y=0,U=V=0, which converts to vivid green) landed at the bottom of the output and the picture was squashed to fit. Set the source rect to the real frame. Pre-existing on this backend, but 40030e90 made D3D11VA auto's first choice on Intel, so it went from a corner case to what every Intel user sees — a ~32 px green bar at 3840x2400, reported on glass within the hour. Also dedupe the Settings GPU picker by description: that string IS the identity downstream (persisted as Settings::adapter, matched by name as PUNKTFUNK_VK_ADAPTER), so repeated enumerations of one adapter offered the user the same choice twice — live on an Intel Arc laptop, whose Vulkan ICD also enumerates the single physical iGPU twice. Both paths now log their raw enumeration (decode texture dims; DXGI name/LUID/ids) for the next report. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 14:44:05 +02:00
enricobuehler	fb8deb31a5	feat(client): HDR pass-through on the D3D11VA path ... A PQ stream on the D3D11VA backend was always tone-mapped to sRGB by the VideoProcessor — with D3D11VA now auto's first choice on Intel (40030e90), Intel Windows users would have lost HDR entirely. When the presenter can import an RGB10A2 D3D11 texture AND offers an HDR10 swapchain (the new VulkanDecodeDevice::d3d11_hdr10 probe), the hand-off ring switches to RGB10A2 and the VideoProcessor does a pure colorspace conversion (YCbCr G2084 -> RGB G2084, no tone mapping); the emitted frame carries PQ/BT.2020 color, so the presenter flips its HDR10 swapchain and video image exactly as it does for Vulkan Video PQ frames, and the blit passes the PQ values through untouched. SDR-only paths keep the tonemap-to-sRGB BGRA8 ring; in-band PQ flips rebuild the ring like a resize (generation-bumped). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 14:19:35 +02:00
enricobuehler	40030e90c8	fix(client): vendor-aware Windows decode order — D3D11VA first on Intel ... Intel's Windows driver advertises Vulkan Video (Arc drivers since 2023), so the capability gate alone no longer keeps Intel off FFmpeg-Vulkan — and that combination is broken in the field (B580 report: strobing + 7.2 ms p50 decodes at 4K120) and on glass (Arc Pro iGPU: 29-33 ms p50 decodes at 4K60 where D3D11VA does 2.5 ms on the SAME GPU). Mirror the Linux vendor order on Windows: NVIDIA/AMD keep Vulkan Video first, Intel/unknown take D3D11VA first; vulkan stays reachable by explicit preference and as auto's fallback. Also: - Vulkan→D3D11VA mid-session demotion rung (the Windows analog of Linux's Vulkan→VAAPI rung) — a failing Vulkan backend lands on hardware, not on software, which cannot survive 4K120. - The demotion streak now needs 1 s of age as well as 3 consecutive errors: a startup loss burst produced 3 errors in 20 ms and stranded the session on software decode (one-way) before the IDR requested on the first error could possibly arrive — live-hit on the Intel iGPU leg. - Stale "Intel's Windows driver has no Vulkan Video" comments corrected, docs updated to the per-vendor order, vendor-order test extended with discrete/iGPU Arc cases. Verified on an Arc Pro iGPU + RTX 3500 Ada laptop against a CachyOS/NVENC host: auto now picks d3d11va on Intel (60 fps, 2.5-2.8 ms decode, e2e 26 ms vs 50 ms before) and still picks vulkan on NVIDIA. 27/27 pf-client-core tests, clippy clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 14:04:32 +02:00
enricobuehler	e55ff1bb28	feat(recovery): clean mid-stream loss recovery — freeze-until-reanchor + AMD LTR-RFI ... Removes the "gray frames with motion" artifact on Vulkan-Video clients and lets AMD/NVENC hosts re-anchor after loss WITHOUT a 20-40x IDR spike. Client (pf-client-core): after a reference loss the hardware decoder conceals the missing-reference deltas (on RADV, a gray plate with new motion painted over) and returns Ok. The pump now freezes on the last good picture until a clean re-anchor instead of showing the concealment — lifting on a real IDR, an intra-refresh recovery mark (2nd wave boundary), or an LTR-RFI recovery anchor (1st). The frame_index gap is the early, precise loss signal and drives an RFI request. Host recovery signals (inert unless the backend supports them): - USER_FLAG_RECOVERY_POINT — intra-refresh wave boundary (NVENC constrained GDR). - USER_FLAG_RECOVERY_ANCHOR — AMD LTR reference-frame-invalidation recovery frame. AMD LTR-RFI (encode/windows/amf.rs) — the AMD twin of NVENC RFI. AMF's AVC/HEVC API has no constrained-intra property (intra-refresh cannot heal; PSNR-proven), so the only clean-recovery lever is user LTR: mark frames as long-term references, and on loss force the next frame to re-reference the newest known-good one — a clean P-frame, not an IDR. Two rotating LTR slots, ~0.5s mark cadence, on by default for AVC/HEVC (PUNKTFUNK_NO_AMF_LTR disables). invalidate_ref_frames picks the newest LTR before the loss; a range older than the live slots falls back to a keyframe. Protocol (punktfunk-core): RfiRequest control message + NativeClient::request_rfi(). Host: RfiRequest dispatch -> invalidate_ref_frames (IDR fallback); an RFI success anchors the keyframe cooldown so the client's frames_dropped echo of the same loss is coalesced away rather than emitting a redundant IDR. Spike: synthetic NV12 GPU source for headless AMF encoder testing. Validated: core rfi_request_roundtrip; pf-client-core 31 unit tests (incl. an_rfi_anchor_lifts_immediately); punktfunk-host builds + 271 tests on Linux; punktfunk-host builds clean on Windows; real AMD iGPU spike (invalidate at frame 90 forced re-reference to LTR frame 60 — 180 frames, keyframes=1, no recovery IDR). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-11 17:31:17 +02:00
enricobuehler	1fcf9e11ec	fix(video): honor the signaled CSC matrix end-to-end + tvOS HDR presentation ... Clients derive Y'CbCr->RGB from the stream's SIGNALED matrix x range x depth via shared csc rows (Rust csc_rows + Swift CscRows) instead of hardcoded 709/2020 - a BT.601-signaled stream (a Linux host's RGB-input NVENC) no longer renders with a constant hue error. Host-side signaling made honest across NVENC/VAAPI/openh264/GameStream and the session plan's chroma/bit-depth. Decoded color-bar fixtures (601/709 x limited/full) pin the math in tests on both cores. Same presenter, tvOS HDR: tvOS has no Metal EDR API and a bare PQ colorspace tag composites UNTONE-MAPPED (the "overblown" Apple TV report), so HDR now splits on the display's live EDR headroom - PQ passthrough when the per-session AVDisplayManager mode switch landed (a real HDR10 output tone-maps itself), else an in-shader PQ->SDR tone-map (203-nit reference white, extended-Reinhard 1000-nit knee, 2020->709) into the proven SDR layer config. The 10-bit stream keeps its full decode depth either way. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-10 16:59:01 +02:00
enricobuehler	4839c0e6f6	fix(ci): windows clippy + rustfmt debt from the D3D11VA push ... The windows workflow has been red since a69a83b5: clippy 1.96 rejects the two field-reassign-with-default view-desc initializers in video_d3d11.rs (now struct literals), and with clippy failing first, the rustfmt step never ran — cargo fmt --all had genuine misses queued up in video_d3d11.rs / pf-presenter d3d11.rs + vk.rs / core abr.rs + client.rs (plus this session's config.rs). Formatting only beyond the two initializers; no behaviour change. Verified: clippy -p pf-client-core --all-targets -D warnings clean on the RTX Windows box, cargo fmt --all --check clean, core lib tests green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-09 11:47:06 +02:00
enricobuehler	a69a83b545	feat(clients/windows): D3D11VA hardware decode in the session client — Vulkan chain becomes vulkan → d3d11va → software ... The vendor-agnostic DXVA path for GPUs without Vulkan Video (Intel's Windows driver foremost, which previously landed on CPU decode). Ported from the retired WinUI presenter's decoder with its Intel-safe discipline intact (decode pool stays libavcodec-derived — a hand-built pool broke Intel at the first SubmitDecoderBuffers), on a decode device LUID-matched to the presenter's adapter. Hand-off is a ring of shareable BGRA8 textures (SHARED_NTHANDLE | SHARED_KEYEDMUTEX) filled by the fixed-function ID3D11VideoProcessor (NV12/P010 → BGRA8, colour spaces from the per-frame CICP; PQ is tone-mapped to SDR by the processor — HDR-first boxes take Vulkan Video). BGRA is deliberate: importing a multiplanar NV12 D3D11 texture device-losts on NVIDIA however it is consumed (plane-view sampling and DMA copy both validation-clean, both TDR — bisected), while single-plane RGBA D3D11↔Vulkan interop is the path Chromium/ANGLE exercise on every driver. The presenter imports a slot's NT handle per frame (VK_KHR_external_memory_win32, gated on the spec-required external-format probe) and blits it into the video image — no CSC pass; the DXGI keyed mutex (key 0 both sides, drop-tolerant) is the cross-API lock and visibility barrier. Verified live vs a real host at 5120x1440@240 HEVC on an RTX 4090: 240 fps, e2e 2.7/3.0 ms p50/p95 under the Khronos validation layer — parity with Vulkan Video (2.6 ms); auto still resolves vulkan on NVIDIA. PUNKTFUNK_DECODER=d3d11va forces it; import/present failures demote to software on the existing streak contract. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-09 10:57:41 +02:00