H.264 10 Mbps YouTube stream coincides with ~20-second operator stall #597

Owner-visible incident

During a 10 Mbps H.264 stream to YouTube on the installed beta, the whole CoreVideo Pro app appeared to stop working for about 20 seconds. Treat this as a show-survival incident. The owner reported a stall, not an app exit.

Captured example (2026-09-22, America/New_York)

Installed process path identifies beta-2026-09-22-58d4fab; WinUI, native core, FFmpeg, and Zoom engine were still running when inspected after the event. Local copies of launch.log, media-core.log, and perf.log were preserved under artifacts/incident-20260922-h264-10mb-stall/ on the owner machine (not committed because raw logs may contain private meeting or streaming data).

• 21:07:30.532 — operator starts RTMP at 10.0 Mbps, codec=h264, encoder=nvenc after stopping a prior H.265 attempt at 21:07:22.
• 21:07:30.929 — native log confirms GPU-direct hardware H.264 at 1920x1080@60, 10,000 kbps, with a first keyframe.
• 21:07:50, 21:08:15, 21:08:50 — output supervisor logs repeated RTMP restarts: Destination never accepted output within 15s of starting.
• 21:09:09.305 — compressed-video queue overflow (queuedChunks=60, queuedBytes=1,355,782), and supervisor reports the stream transport could not drain encoded video fast enough. More overflows and encoder restarts follow through 21:09:28.
• 21:09:12.058 to 21:09:33.068 — the app's periodic Zoom transport telemetry has a 21.009-second gap where adjacent 30-sample reports normally arrive about every 5–6 seconds. This matches the scale of the reported stall, but does not alone identify the blocked thread or prove every media output stopped.
• 21:09:29.553 — operator requests stream stop. No process crash was observed.

The earlier FFmpeg progress reported about 60 fps / 10.2 Mbps before the transport stopped draining. A successful encoder cadence is not proof that YouTube accepted playable output.

Investigation / done when

• Reproduce or isolate this specific H.264 10 Mbps YouTube failure with instrumented UI input/dispatcher latency, core Program frame cadence, encoder queue depth, FFmpeg pipe/write latency, output-supervisor transitions, and receiver state.
• Determine whether the 20-second operator stall comes from retry teardown/startup, blocked IPC, UI scheduling, or another shared resource. Preserve the distinction between an unresponsive UI, a Program freeze, and a receiver outage.
• A backpressured or non-accepting destination must fail clearly and recover with bounded retries without making the app controls unresponsive or starving Program, audio, recording, or sibling outputs. No silent codec or quality downgrade.
• Validate an installed beta under the same workload, including recovery/stop controls and independent receiver playback. Record the exact result and frame gaps.

Related: #524 (bitstream write isolation/backpressure), #521 (GPU streaming), #569 (receiver acceptance). This is a new whole-app responsiveness report, not proof that any one of those issues is its root cause.