AV1 decoded on the D3D11VA rung because 31 is not a level, and two host warnings that named the wrong subsystem #205

Merged

enricobuehler merged 3 commits from worktree-av1-level-sentinel into main 2026-08-13 19:35:41 +00:00

Conversation 0 Commits 3 Files Changed 8

+256 -41

3 Commits

Author	SHA1	Message	Date
enricobuehler	8216f1d92d	fix(host): a 2 s keyframe cadence is the client's flush cooldown, not display churn ... The host's recovery-cadence detector warns that "client keyframe recoveries are METRONOMIC — a periodic host/display disturbance (display-topology churn, display-poller software, virtual-display timing) is the likely cause, not random network loss". In a 2026-08-13 field log it fired at period_s=2.0 and sent the investigation at three innocent host subsystems. 2.0 s is `punktfunk_core::client::FLUSH_COOLDOWN`. The client's receive-backlog guard sheds a standing queue with a flush plus a keyframe request and is rate-limited to one per cooldown, so a client that cannot sustain the stream asks for a keyframe at EXACTLY that spacing for as long as it stays behind — the constant's own doc says it "degrades into a periodic skip + a logged warning", which is the behaviour the detector then read as physical. Perfect periodicity argues FOR a fixed software cooldown, not against it. In the field case the host was blameless and the chain ran the other way: the client refused the negotiated codec on its Vulkan rung, demoted to a slower decode path, could not hold 4K120 there, and built the standing queue. Three layers between the symptom the host reported and the cause. So the detector now routes: a period on the client's cooldown names the client and says where to look in ITS log (`receive backlog stopped draining`, and a demoted decode rung); anything else keeps the display-disturbance wording it had. The comparison reads FLUSH_COOLDOWN itself — now `pub` for exactly this, documented as such — rather than a copy of the number, so the two cannot drift. ±10 % absorbs scheduling jitter and the request's trip without being wide enough to swallow the disturbance cadences the other branch exists to report. Verified: 18/18 native::stream::tests on linux/amd64 (container), including the new case, which derives its inputs from FLUSH_COOLDOWN so it survives a retune; clippy --all-targets -D warnings clean; cargo check clean on the Windows CI runner.	2026-08-13 21:00:48 +02:00
enricobuehler	1677d1c0c2	fix(host/audio): stop warning that "the stream will click" when there is no stream ... A 2026-08-13 field host log carried ten "the audio encode thread could not keep up — captured audio was DROPPED" warnings, the worst reading dropped_chunks=11251. That reads like catastrophic audio loss. It was not: not one sample anybody wanted was lost. PipeWire negotiated a 128-frame quantum, so the plane produces 48000/128 = 375 chunks/s and a 30 s stats window holds exactly 11250 — those windows were a 100 % drop rate, at peak_db=-120.0 (digital silence). Every one of the ten straddled a session boundary, and across all of them dropped_chunks/375 matches the seconds with NO live session in that window to within a fraction of a second (3890/375 = 10.4 s against a 10.5 s gap; 3616/375 = 9.6 s against 9.8 s). The capturer is host-lifetime: the native and gamestream planes PARK it between sessions (`AudioCapturer::idle`) rather than dropping it, but the consumer is the per-session encode thread. The hand-off channel is a bounded sync_channel(64), so ~170 ms after a session ends it is full and every try_send fails for as long as the host sits idle — counted as the encode thread falling behind, and reported with a sentence about a stream that does not exist. It is the worst kind of false alarm: it names a real failure mode, in a subsystem with real open audio work, at a volume that demands attention. So the drop counter now only counts while a session is actually reading, via an `active` flag shared with the capture thread and toggled by the same open/drain/idle/Drop transitions that already own the routing claim. A full channel under a live consumer still means exactly what it used to. Both backends: the parking call sites are platform-independent, so the WASAPI half had the identical defect (it had no `idle` at all, and gains one). Only the Linux half has field evidence. Verified: punktfunk-host clippy --all-targets -D warnings clean on linux/amd64 (container) and cargo check clean on the Windows CI runner.	2026-08-13 21:00:26 +02:00
enricobuehler	3f738a9989	fix(pf-vkdecode): AV1's "maximum parameters" level is not a level above the ceiling ... A 2026-08-13 field report from the same RTX 5060 client as a02014ec: every AV1 session demoted to D3D11VA with "outside device caps: stream level (seq_level_idx 31) above the device's maxLevel (AV1 Std level 23)" — 4K120, NVIDIA, the hardware decoding the stream trivially on the D3D11VA rung it fell through to. a02014ec fixed the H.264/H.265 half of exactly this and left AV1 alone on the premise that "no over-declaration has been seen in the field"; the reporter's own log from that same day already showed otherwise. seq_level_idx is a 5-bit field. Annex A defines 0…23 (levels 2.0…7.3), reserves 24…30, and makes 31 the "maximum parameters" level — the spec's own way of saying the bitstream is NOT constrained to a level. StdVideoAV1Level stops at 7.3 = 23, so 31 has no Std code point and the index-coded comparison that holds across 0…23 says nothing here: 31 > 23 is true even of a device that decodes everything AV1 can name, which is what makes it useless as a capability test. We write no AV1 level on any host encode path, so whichever sentinel the vendor's encoder defaults to is what the client must accept. So the gate warns once and proceeds, like its H.265 sibling. Unlike H.265 there is nothing to clamp: StdVideoAV1SequenceHeader carries no level field, so the declaration never reaches the driver and cannot be invalid usage. The stream's real demands stay enforced where they are physical facts — coded extent and DPB depth, both checked at session build. Not verified on glass: no RTX 5060 here, and the reporter's box is the only one that has produced a seq_level_idx 31 stream. The unit test pins the arithmetic that made the refusal look reasonable.	2026-08-13 20:05:41 +02:00