11 Commits

Author	SHA1	Message	Date
enricobuehler	fecbec2daf	fix(encode): make LTR-RFI loss recovery sound under sustained loss ... Field report (lid-closed Intel laptop, ~6-19% sustained loss): the stream never healed — permanent macroblock soup. Three stacked bugs: - QSV answered RFI with PreferredRefList only, a reorder HINT per the VPL spec — the recovery frame could keep predicting from tainted short-term refs. Now rejects every other DPB candidate (RejectedRefList) and caps L0 at one active entry (AVC/HEVC), matching AMF's hard ForceLTRReferenceBitfield / NVENC invalidation semantics. - Neither QSV nor AMF taint-swept LTR slots across losses: a slot marked inside the client's corrupt window became the "known-good" anchor of the NEXT loss, propagating corruption through every recovery. Both now drop slots at-or-after the loss start before picking an anchor, and guard a queued force whose slot the sweep emptied (no false recovery_anchor tag). - The native plane re-anchored the FULL IDR cooldown on every successful RFI, so under sustained loss the client's escalating keyframe requests were coalesced away indefinitely (field log: dozens swallowed, one IDR per ~8 s). RFI now anchors a 300 ms echo window with a 2-swallow budget per loss episode; a client still asking past that gets its IDR. Live-validated on Arc (qsv feature): 6/6 including the new qsv_live_ltr_rfi_taint_sweep_declines (a loss covering every live mark declines the RFI and falls back to IDR recovery). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 17:53:48 +02:00
enricobuehler	dc20e4452e	fix(pyrowave): anchor frame-driven pacing to arrival, hold full framerate ... The frame-driven capture loop set its rate-limit floor (`earliest`) relative to `next`, which is re-based to the instant AFTER submit(). For an async encoder (NVENC) submit() returns in ~0, so that anchor is ~frame-arrival and the loop correctly waits for the next vsync — full framerate. But PyroWave's encode is SYNCHRONOUS (~2 ms inline in submit()), so the anchor lands ~2 ms late every frame: the loop misses the next arrival and samples one interval behind, making the period `interval + encode`. That capped a 240 Hz source at ~158 fps (and a 360 Hz request at ~200) with the link and the encoder both idle — no drops. Anchor the floor to this frame's arrival (`t_cap`) instead. The synchronous encode now overlaps the interval rather than stacking onto it; the ≥0.9×interval spacing from the last grab still caps the rate at ~1.11× target. No-op for async NVENC (t_cap ≈ post-submit there), which is why H.26x already held full rate. Measured on-glass (5120x1440@240, RTX 4090 host, macOS client): desktop now holds 240 fps. Also reduces latency (samples fresher frames). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 01:01:59 +02:00
enricobuehler	b89dbfa979	feat(gamescope): end dedicated stream on Steam game exit + auto --steam ... Dedicated single-game sessions now end cleanly when the launched game quits, and Steam launches get gamescope's Steam integration without an operator env knob. End-on-exit: the existing APP_EXITED close only fired when gamescope's PipeWire node vanished, which never happens for Steam — the nested `steam` is the resident singleton client and stays up after a game quits, so gamescope (and its node) never die and the stream sat on a hidden Steam session forever. Add a Steam AppId reaper watcher (pf-vdisplay .../gamescope/discovery.rs): steam_appid_from_launch() parses steam://rungameid/<id>; wait_for_steam_game_exit() waits for the game to start (<=300s grace) then exit (3s confirm); steam_game_running() scans same-uid /proc for Steam's launch reaper matching both the `SteamLaunch` and `AppId=<id>` argv tokens (exact-match; reaper lifetime == game lifetime, so shader precompile can't false-trigger). The host spawns a pf1-gamewatch thread for nested Steam launches that closes the connection with APP_EXITED (launcher clients return to their library) and sets quit/stop; cancelled via stop if the session ends first. Non-Steam nested launches keep the node-death path (gamescope's child IS the game). Flags: auto-enable `--steam` whenever the launch is a Steam launch (was only the global PUNKTFUNK_GAMESCOPE_STEAM knob, default-off) — in-game overlay / Steam+X / gamepad-UI nav for Steam titles with no operator config. New opt-in PUNKTFUNK_GAMESCOPE_GRAB_CURSOR adds `--force-grab-cursor` for a real game launch (FPS mouselook); default OFF because it forces relative mode, which breaks absolute-pointer games/menus. Verified: fmt clean; clippy -D warnings clean on the three crates; pf-vdisplay 64/0 (incl. new steam-appid parse test); punktfunk-host builds + 186/0; reaper /proc detection smoke-tested (detect, exact non-match, gone-after-exit). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 16:24:34 +02:00
enricobuehler	5eb930e71d	feat(pyrowave): negotiation plumbing for 4:4:4 + HDR — thread chroma/depth/ColorInfo end to end ... Phase 1 of design/pyrowave-444-hdr.md. No behavior change yet: the handshake's 4:4:4 gate now admits PyroWave (probe = can_encode_444(codec), capture gate inherently satisfied — the wavelet path always ingests an RGB source and does its own CSC), but can_encode_444 stays false for PyroWave until the per-OS full-res-chroma CSC variants land (Phase 2 Linux, Phase 3 Windows), so every session still resolves 4:2:0/8-bit. - Both host encoders take the negotiated ChromaFormat (bail on 444 for now); the PUNKTFUNK_ENCODER=pyrowave lab override pins 4:2:0. - Bitrate: the automatic ~1.6 bpp pin resolves AFTER depth+chroma and scales x1.625 for 4:4:4 / x1.15 for 10-bit (factors from the Phase-0 fixture matrix); the mid-stream mode-switch re-resolve threads the session's values. - Client: PyroWaveDecoder builds its plane ring (full-res chroma when 444) and creates the upstream decoder from the negotiated chroma, keeps chroma fixed across mid-stream resizes, drops the even-dims requirement for 444, and returns the negotiated Welcome ColorInfo as the frame colour contract instead of hardcoded BT.709 (the wavelet bitstream has no VUI). Verified on .21 (RTX 5070 Ti): clippy -D warnings (host+client+encode), host 186 tests, client + pf-encode tests, fmt, and the pyrowave_smoke GPU round-trip through the patched vendored lib (97cf15e3). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-18 12:37:12 +02:00
enricobuehler	8e75f3d8bf	perf(latency): adaptive IDD pipeline depth — depth-1 default, escalate on contention ... From the 2026-07-17 on-glass finding (.173 RTX 4090): the IDD-push capturer's depth-2 pipeline measured ~13ms of glass-to-glass latency over depth-1 at 60fps (17ms → 4ms) — the AU is ready in µs but depth-2 holds it a whole frame interval unpolled while N+1 is submitted. Depth-2 only earns its keep under GPU contention (it overlaps the convert of N+1 with the encode of N, avoiding the depth-1 ~50fps collapse). So the native encode loop now runs depth-1 by default and escalates to the capturer's max ONLY when it can't hold cadence at depth-1 (a leaky-bucket over 'the frame's work overran its pacing deadline', with a startup warmup skip), then holds there for the session (no oscillation; de-escalation is a v2 item). PUNKTFUNK_IDD_ADAPTIVE=0 pins the capturer's full depth (pre-adaptive behaviour); no effect where the capturer's max is already 1 (every non-IDD backend). GameStream plane untouched. Pairs with the shipped REALTIME auto-gate (1bc156aa): uncontended sessions get the ~13ms latency cut, genuinely GPU-bound ones keep the depth-2 overlap AND the REALTIME priority. Validated: .21 clippy -D warnings (host --features nvenc). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 20:48:55 +02:00
enricobuehler	bbe4380b41	perf(latency): T1.1 frame-driven encode trigger + T1.4 time-based flush thresholds ... design/latency-reduction-2026-07.md tier 1, remaining halves: - T1.1: the native encode loop wakes on the capture's ACTUAL arrival instead of sampling at a free-running tick — deletes the sample-and-hold (~half a frame interval on average, a full one worst-case: ~8ms avg @60fps). New Capturer::supports_arrival_wait/wait_arrival pair (IDD-push waits its frame-ready event against the shared-header token; the PipeWire portal blocks its channel with a pending stash); backends without an arrival signal — and PUNKTFUNK_FRAME_DRIVEN=0 — keep the legacy tick bit-identically. A 0.9x-interval rate floor caps encode at ~1.11x target when the compositor outruns the session; a +0.5x-interval keepalive keeps static desktops re-encoding at 1.5x-interval cadence. Pacing deadlines re-anchor to the actual submit so they can't drift against the arrival clock. GameStream plane untouched. - T1.4: the jump-to-live detectors run on WALL-CLOCK now (STANDING_TIME / FLUSH_AFTER = 250ms) instead of 30-frame counts whose meaning scaled with fps (500ms @60 but 125ms @240 — and stretching further under T1.1's slower static-scene repeats). The queue trip also requires depth still >= high, so a hysteresis-band hover can't fire on elapsed time alone. Validated: .21 Linux 185 core + 177 host + pf-capture tests, clippy -D warnings; .133 Windows cargo check of pf-capture + punktfunk-host green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:31:49 +02:00
enricobuehler	aedee2a4e3	perf(latency): tier-0 attribution + tier-1 send-path levers from the latency plan ... design/latency-reduction-2026-07.md T0.1/T0.2/T1.2/T1.3: - T1.2 rate-capped front-loaded pacing: the paced overflow's budget is now min(0.9x slack, overflow wire time at ~3x the live encoder bitrate) (PUNKTFUNK_PACE_FACTOR, 0 = legacy deadline-only spread). A 300 KB-1 MB frame's tail leaves in ~2-5 ms instead of smearing across ~15 ms at 60 fps; GameStream schedule byte-identical (pins unchanged). - T1.3 data-first wire order: packetize emits every block's data shards before any parity (per-block parity pools keep all blocks' parity alive for the second pass), so lossless completion stops waiting behind the parity tail. EOF = last emitted packet; receiver already order-agnostic. - T0.1 staged 0xCF: HostTiming gains an append-extensible per-stage tail (queue/encode/pace us; seal+channel-wait derived as residual) - no cap bit needed, old peers read the 13-byte prefix. Joined client-side into Stats::host_{queue,encode,xfer,pace}_ms, the OSD detailed tier, and the probe's report. - T0.2 true on-glass present timing: VK_KHR_present_id/present_wait enabled when supported; a PresentTimer waiter thread resolves each present id to real visibility, replacing the submit-time display stamp (which undercounts by up to a refresh and hides a silent-FIFO standing queue). Validated on .21: core 185 + host 185 tests, pf-presenter 19, clippy -D warnings across all five touched crates; loss-harness recovery curve unchanged; C ABI harness round-trips. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:13:08 +02:00
enricobuehler	09849906e9	Merge perf/first-frame-latency: driver proto v4 + first-frame/resize latency (P0-P2) ... Brings the first-frame-latency branch (P0.1 transition tracing, P1.1/P1.2 Welcome-time display prep, P2 in-place resize; pf-driver-proto v3 -> v4 with IOCTL_UPDATE_MODES) onto current main. The branch predates the W6.2/W7 splits, so git's rename detection carried most of it into the moved crates (pf-capture idd_push, pf-vdisplay manager/pf_vdisplay, pf-win-display, pf-driver-proto, the driver workspace) and the punktfunk1.rs remainder was re-homed by hand: - native/handshake.rs: welcome/start trace marks + the Welcome-time display prep spawn (the prep thread BECOMES the stream thread; hand-off via a SyncSender<SessionContext>). negotiate() gains bringup/quit/stop and returns the PrepHandle. - native.rs: bringup/resize_ms creation + the stop/quit flags hoisted BEFORE the handshake (the close watcher splits: flags pre-handshake, lifecycle events post-handshake where `hello` exists); punch_done stamp; the data plane adopts the prep thread's result or builds inline. - native/stream.rs: SessionContext/SendStats carry the trace; send_loop finishes it on the first video packet; the resize path gains the in-place fast path (try_inplace_resize) with the full rebuild as fallback, restructured so both share the post-rebuild bookkeeping; prepare_display/PreparedDisplay/ PrepHandle; build_pipeline(+retry) thread the stage marks. - session_status/mgmt: ttff_ms + last_resize_ms per session (union with the lifecycle-events fields main added to the same spots). - pf-capture: Capturer gains capture_target_id() + resize_output() defaults. - pf-vdisplay manager: perf's faster activation poll (60x50ms) + the settle floor before the PnP sweep, on main's knobs/no-trait shape. Also: packaging/windows/build-gamepad-drivers.ps1 is ASCII again (an em-dash from the pf-mouse work tripped windows-host.yml's locale-safety gate on main). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 16:08:16 +02:00
enricobuehler	b168790e0a	refactor(host/W6.2): extract the shared frame/format vocabulary into the pf-frame leaf crate ... The captured-frame types both capture (producer) and encode (consumer) speak — PixelFormat, OutputFormat, CursorOverlay, CapturedFrame, FramePayload, DmabufFrame, drm_fourcc — move into crates/pf-frame, alongside the small pure helpers that ride the same seam: hdr (HDR static metadata / in-band SEI), metronome (the metronomic-stall detector), thread_qos (per-thread scheduling QoS), session_tuning (Windows process tuning), and the Windows DXGI capture IDENTITY (WinCaptureTarget, D3d11Frame, pack_luid, make_device + the GPU scheduling-priority hardening it applies) (plan §W6). This is the crate that breaks the capture<->encode cycle: FramePayload's GPU variants own their backends from BELOW (Cuda -> pf_zerocopy::DeviceBuffer, D3d11 -> dxgi::D3d11Frame), so encode can speak the vocabulary without a path to capture, and vice versa. The Windows DXGI identity moving here lets capture, encode, and pf-vdisplay share ONE WinCaptureTarget/device factory instead of the old capture<->encode<->vdisplay reach-in. The host keeps thin facades: capture.rs re-exports the vocabulary (crate::capture::{PixelFormat,…} unchanged); capture/windows/dxgi.rs keeps the win32u GPU-preference hook + HDR/video-engine converters + self-test and re-exports the identity; native.rs re-exports boost_thread_priority from pf_frame. crate::hdr/metronome/session_tuning callers rewired to pf_frame::*. metronome's Metronome::new gained a Default impl (new_without_default fires once the type is public across the crate boundary). Verified: Linux clippy -D warnings (pf-frame --all-targets + host nvenc,vulkan-encode,pyrowave --all-targets) + 9/9 pf-frame tests; Windows clippy nvenc,amf-qsv --all-targets Finished exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 10:03:56 +02:00
enricobuehler	3495d189e1	refactor(host/W6.1): extract the config() global into the pf-host-config leaf crate ... Third de-coupling for the host crate carve (plan §W6.1 leaf). HostConfig + the config() OnceLock (config.rs, pure std, zero deps) move to a new pf-host-config leaf so every subsystem crate (pf-encode/pf-capture/pf-vdisplay/pf-gpu) can read process config WITHOUT depending on the orchestrator. 34 crate::config::config() call sites across 19 files repoint to pf_host_config::config(). thread_qos stays in the host for now (it calls session_tuning::on_hot_thread — its own leaf-ification rides the encode carve). Granular-crate decision (supersedes the plan's single pf-media): split capture/encode/ vdisplay into separate crates rather than one broad crate — the capture↔encode cycle is broken by a shared frame-types leaf, and vdisplay→encode (can_open_another_session) is a legal one-way edge since encode never references vdisplay. Verified: Linux (home-worker-5) clippy -p pf-host-config -p punktfunk-host --all-targets -D warnings; Windows (192.168.1.158) clippy --features nvenc,amf-qsv --all-targets green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 08:54:47 +02:00
enricobuehler	68bcfdac3e	refactor(host/W1): split native.rs control task + data plane into submodules ... Continue the W1 native-host restructure (plan §W1, steps 4+5). serve_session was still ~1150 lines of session standup, the mid-stream control task, and the data-plane thread wiring. - native/control.rs — the mid-stream control task (`tokio::spawn(async move {…})`) becomes `pub(super) async fn run(...)`: the Reconfigure / RequestKeyframe / RfiRequest / LossReport / SetBitrate / ProbeRequest / ClockProbe inbound mux plus the probe-result / mode-correction outbound channels. Call site is now `tokio::spawn(control::run(...))`. - native/stream.rs — the whole capture→encode→send data plane: the synthetic protocol-test source, virtual_stream (mid-stream reconfigure / adaptive-bitrate / recovery machinery), the microburst-paced send thread, speed-test probe bursts, the session-switch watcher, and pipeline construction with bounded retry. Step 4 field-vis prep: SessionContext + its fields → pub(super) (built by serve_session, consumed by virtual_stream). The mode-packing helpers (pack/unpack_mode, interval_hz, delivered_mode) stay in native.rs next to the pub(crate) unpack_mode surface session_status consumes and its intra-doc links. native.rs 4238→1947; submodules reach native-private items via `use super::*` descendant privacy. Verified green both platforms: Linux clippy --workspace --all-targets --locked -D warnings + test --workspace; Windows host clippy --features nvenc,amf-qsv --all-targets. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 20:45:22 +02:00