fix(video): black flash / black-on-connect at the canvas→sink handoff

[rmounce]

The full-frame H.264 presenters hide the main canvas the moment the first frame is written to the takeover sink (<video> track generator, or the worker's OffscreenCanvas). At that point the sink usually hasn't rendered anything yet: a track frame written before the <video> starts playing isn't shown until the next frame arrives, and the worker draws its first transferred frame asynchronously. On Firefox (worker canvas) this is a brief black flash a few seconds after connecting, when the first screen update lands; on Chromium — where frames go to the main-thread MediaStreamTrackGenerator from the very first frame, so the canvas never has content — the stream is black from connect until the next screen update, which on a static desktop can be indefinitely.

Fix: gate the canvas hide on the sink provably rendering — requestVideoFrameCallback for the <video> sinks, and a one-time presented message from the worker after its first drawImage. Until then the main-thread MSTG path also keeps painting incoming frames onto the canvas, so a fresh connection shows content immediately. Browsers without requestVideoFrameCallback keep the old behavior.

Reproduced both symptoms and verified the fix on an lsio-based image (Firefox and Chrome clients, Intel laptop, software x264).

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request introduces a handoff gate mechanism to prevent a black flash when transitioning from the main canvas to a takeover sink (such as a

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[ehfd]

Fixes incorporated in de77558, linuxserver/pixelflux@b32a178, linuxserver/pcmflux@0cbadcb.