HANDOFF — 2026-09-10

Branch / Commit State

main HEAD = c45cbc9 (slice 10 committed), ahead of origin by 15, NOT pushing — user ruling (2026-09-10): do not push until the web-overlay transparency AND audio silence issues are addressed. Both are open (see Still Open). Working tree clean.

The timing saga — where it stands

slice 9 (committed bd396e4) fixed the DURATION (count-based CFR, deadline never rebased, -re removed): file length == wall time by frame-count construction.
But the CONTENT still hiccuped — the creator read "1...23...4...56..." in the recording, and the aggregates (301/300, uniform PTS, 15.6s wall vs 15.74s file) could NOT see it. Root cause finally measured in FfmpegEncoder.SubmitFrameAsync: it BLOCKED on WriteAsync(8.3MB)+FlushAsync when ffmpeg lagged the pipe, and slice 9's burst while loop then re-wrote that SAME composite for every crossed slot — frozen runs.
slice 10 (current, uncommitted) — the OBS obs-encoder.c shape:
1. FfmpegEncoder.SubmitFrameAsync is an ENQUEUE into a bounded Channel<byte[]> (cap 120) drained by its own task; the pump NEVER blocks on the pipe.
2. Queue full → drop the NEWEST frame + count (IFfmpegEncoder.DroppedFrames). Stop flushes the whole queue, then EOF.
3. Pump: ONE fresh composite per iteration (burst loop deleted) — no stale re-write.
4. Burned-in frame counter (the new judge, replaces the WSL ticker): 6-digit dot-matrix strip, white box, bottom-right of every composite. Decoding the file reads +1/frame; jumps = counted drops. Clock-independent.
5. Stats: worst submit, dropped N, stalls K; stall log names iterations > 2× interval.

NEXT STEP (ONE user run required — the take that closes timing)

Record ~20s (WSL ticker visible in the preview is optional now — the burned counter is the judge), then check:

decode the recording and read the bottom-right frame counter (probe a few frames widely spaced + the same region across a densely-sampled range): the number advances exactly +1 per frame, jumping only where drops are countable
%APPDATA%\ytLlive\startup.log: FramePump stats: ≈ n/n per 5s (n=300 @60fps), dropped 0, stalls 0, worst submit ≈ 1-3ms
NO "FramePump stall:" lines, NO frozen-content runs in the playback
Extract a few frames around any suspicious moment and correlation-check the strip.

Committed so far this session (before slice 10)

d212d5a — tools: WSL ticker (tools/ticker.c + binary)
bd396e4 — fix(rec): CFR emission + -re removal + docs (ai.md slice 9, MyMistakes, HANDOFF). Cites libobs video-io.c.
Do NOT push until the user says (multi-commit local only).

Still Open

Web overlay: pre-parse transparency injection NOT yet proven — recorded diagnostic PNGs (%TEMP%\ytLive-web-<id>.png) were 100% alpha=0 AND RGB=0 (an EMPTY capture). Frozen pending the timing verification.
Audio silence: silent audio (full-length, -91dB) in the take-15 file — the named-pipe audio delivers ~nothing. Separate from timing; queued follow-up, NOT this change.
WSL-ticker-under-heavy-load reliability check: informational (burned counter is judge).
Pre-existing: Composite_FullScene_MasterPixels line 109 pixel (1380,700) — verbose cyan-vs-magenta; fails with slice-9 stashed; untouched by both slices. Separate compositor investigation. DO NOT fix in the timing work.

Landmines

testhost shares startup.log with app — filter by time when triaging
testhost/exe lock DLLs: taskkill /F /IM testhost.exe /IM ytLive.exe before rebuild
Build via the Windows dotnet host: /mnt/c/Program Files/dotnet/dotnet.exe build "C:\Users\gramp\Documents\Code\projects\ytLive\ytLive.csproj"
No Linux ffmpeg / no sudo on this box — probing uses /mnt/c/Program Files/Krita (x64)/bin/ffmpeg.exe
tools/ticker: constant ~+982ms offset on the FIRST line is cosmetic (t0 a beat late)

3.9 KiB Raw Blame History Unescape Escape