docs: the 4:4:4 story catches up with the code that ships it #87

Merged

enricobuehler merged 2 commits from worktree-docs-support-matrix-444 into main 2026-08-07 09:27:35 +00:00

Conversation 0 Commits 2 Files Changed 3

+61 -28

2 Commits

Author	SHA1	Message	Date
enricobuehler	3a35773b70	Merge origin/main; 4:4:4 has no software floor, and the ABI is 17 ... Reconciling with #85 (FFmpeg is gone from the client). Two of my claims were true against the pre-merge tree and false against this one. Note 4 said the desktop clients need no 4:4:4 decode probe "because every rung can display full chroma — swscale converts for the software rung". There is no swscale any more. The CPU floor is openh264 + rav1d, it is 4:2:0 8-bit by contract and has no HEVC at all, so it refuses a 4:4:4 stream rather than converting one. The client still advertises the bit unprobed, which was the point of the original fix, but the honest reason is different: full chroma is a hardware path (Vulkan RExt, NVIDIA today), and what catches a box whose hardware 4:4:4 fails is note 2's codec reconnect, not a downgraded picture. Note 13 repeated the same wrong premise and now names both halves of its warning. The C ABI is 17, not the 14 I read before the merge. Textual side of the conflict: #85 rewrote the Codecs column and notes 1-3 of the same table while leaving note 4's stale 4:4:4 text alone. Theirs kept in full; only the 4:4:4 column and note 4 are mine.	2026-08-07 11:25:17 +02:00
enricobuehler	f1e7ec3535	docs: the 4:4:4 story catches up with the code that ships it ... The support matrix said the desktop clients' Full chroma switch "has no effect today" and that only the Apple client asks for 4:4:4. Both stopped being true in July: `clients/session/src/main.rs` advertises VIDEO_CAP_444 whenever the setting is on, deliberately with no client-side probe, because every desktop decode rung can display full chroma — the Vulkan presenter samples the 2-plane 4:4:4 pool formats and swscale converts for the software rung. So Linux, Windows and Apple all ask; Android is the one that genuinely doesn't implement it. The other half was HDR. `9f72a3b6` gave the Windows IDD-push capturer a packed 10-bit BT.2020 PQ RGB output, so NVENC encodes HEVC Main 4:4:4 10 and the two compose — the matrix still said "4:4:4 and HDR together is refused", and hdr.md still called PyroWave the only exception. Linux is the side that keeps the trade: handshake.rs resolves the depth back to 8 for a 4:4:4 session, so full chroma wins and the stream is SDR. Three cells move ❌ → ⚠️ rather than ✅ on purpose. The client half is unconditional, but the host half is not: HEVC 4:4:4 means an NVIDIA host, or PyroWave on any vendor. The notes say which, and point at the stats overlay's `4:4:4→4:2:0` tag — this negotiation is the one that fails loudly. Also: C ABI version 13 → 14; PyroWave's ≈8K 4:4:4 block-index ceiling now has a note; and the roadmap no longer calls Intel 4:4:4 a hardware limit, which the matrix and vaapi.rs both contradict — VCN can't, VAAPI hasn't. Spot-checked and left alone as still accurate: the Linux client clipboard stub, VAAPI declining 4:4:4, Android having no 4:4:4 at all, and the wire / driver / gamepad-channel versions.	2026-08-07 10:58:58 +02:00