LlamaCasty/HANDOFF.md

HANDOFF — 2026-09-14 (composition capture DEVICE-VERIFIED ✓; slice-15 pacing fix committed locally — A/V re-measure next)

Branch / Commit State

main HEAD = slice-15 commit (FramePump duplicate-on-lag pacing — committed LOCALLY, NOT pushed; web/A/V work stays commit-local until greenlight). Before it: c01206f (composition capture redesign, also local/unpushed), before that b22d08e (signed audio-sync, pushed). Working tree clean.

⚠️ Branding (2026-09-14, creator-corrected): product = llamacasty, internals = ytLive

The product is llamacasty; repo path, csproj AssemblyName/RootNamespace, DB/log paths (%APPDATA%\ytLlive\...), and most code names are the legacy ytLive/ytLlive. User-facing language says "llamacasty"; code/assembly/repo names stay ytLive. See ai.md → Brand.

✅ DEVICE-VERIFIED — composition capture looks good; then the A/V defect surfaced

The creator ran real takes off the c01206f build and reports the video looks very good — the Windows.Graphics.Capture web path is confirmed on device (open item closed). BUT the same takes showed the A/V defect we have seen before: both desktop and webcam playback are accelerated, the audio "gets speedier", then cuts off at the end.

🔬 Sliced and measured (evidence)

With the A/V recipe (MyMistakes.md → "Measuring audio-video A/V sync" + /tmp/opencode/avsync.py):

• ty-20260914-1723-0000-2.mp4: 697 video frames @60fps = 11.62s vs audio 11.84s.
• ty-20260914-1726-0000-2.mp4 (clap take): 163 frames = 2.72s vs 2.93s audio. Video ends 0.21–0.24s before audio → the cut-off. Clap: audio env peak 1.655s vs video motion 0.75–1.03s; cross-correlation lag +0.667s (audio late).
• startup.log: FramePump stall: iteration 33-46ms (> 2× the 17ms interval): worst render 33ms … dropped 0.

Root cause (slice 15): slice 10's freshness choice skipped the overrun's missed slots — one fresh frame per ~35ms stall authored into a 60fps container = accelerated playback. OBS's answer is duplicate-on-lag (libobs/video-io.c, docs.obsproject.com/backend-design): fill each missed slot by repeating the newest frame — duration == wall, judder never fast-forward.

🔬 Committed locally — slice 15: one frame per deadline slot (duplicate-on-lag)

What: Services/Encoder/FramePump.cs submit is now a bounded catch-up — while (now >= nextTick) { submit latest composite; nextTick += intervalTicks; } clamped to a deadlineNow captured once per iteration. First missed slot gets the fresh composite, the rest get repeats of it (OBS duplication) — recording duration == wall time under any render load, no acceleration, no audio tail cut. The burned _outputIndex moved inside the submit loop (every emitted slot gets its own +1; also fixes the old unconditional bump that gapped the judge sequence on non-submitting fast-render iterations).

Good Dog test: ytLive.Tests/FramePumpTests.cs → Pump_Overrun_Renders_EmitsEverySlot_NotSkipped (60fps, 35ms render cost, asserts ≥0.65 of the wall slots emitted — the old skip-pump wrote ~1/35ms). 294/294 green, app build 0 warnings. Files: Services/Encoder/FramePump.cs, ytLive.Tests/FramePumpTests.cs. Docs in same commit: ai.md Slice 15, MyMistakes (supersedes the slice-10 "no burst re-write" clause + latest numbers), this HANDOFF.

⚠️ Open items (before PUSHABLE)

• Device re-verify: a take on the slice-15 build must play at REAL time (no acceleration, no cut-off audio tail). Confirm via ffprobe: video stream duration ≈ audio ≈ container.
• Re-measure the true A/V offset with a clap take now that video pacing is honest (/tmp/opencode/avsync.py). The +0.6s reading on 1726 was confounded by the 1.1x acceleration. If a real residual remains after the pacing fix, the backlog is the AUDIO pipeline (mixer ring / advance), not video.
• No push yet — commit-locally-until-greenlight for web/A/V work.

Open threads (carried)

• Audio-silence verification — fixed (724af14); creator heard real audio.
• Webcam MJPG missing / ~10–14Hz, layer SortOrder, truncation-with-dynamic-scenes — queued.
• Sync control user-doc tutorial — REQUIRED before 1.0 (creator directive; TASK 22).
• Signed A/V sync: verify the negative (advance) direction on device.

Landmines

• testhost shares startup.log — filter by time.
• cmd.exe /c "taskkill /F /IM ytLive.exe" (WSL double-slashes mangle) before rebuilds — a live app process locks ytLive.exe and the apphost copy fails (MSB3021, seen today).
• Build/tests: Windows dotnet host (/mnt/c/Program Files/dotnet/dotnet.exe). 0 warnings — only ./scripts/verify.sh "<files>"'s clean build counts. Building ytLive.csproj alone does NOT rebuild ytLive.Tests.dll — run the Tests csproj before vstest.
• ffmpeg/ffprobe: /mnt/c/Program Files/Krita (x64)/bin/ with Windows paths.
• MyMistakes.md has the A/V sync measurement recipe, the deadline-pacing lessons (item 1 + slice 15), and the CoreMessaging DQ recipe — grep before re-deriving.
• sqlite3 at /home/gramps/android-sdk/platform-tools/sqlite3 for /mnt/c/Users/gramp/AppData/Roaming/ytLlive/ytLlive.db.

Next step

Have the creator record a clap take on the slice-15 build → ffprobe durations (video == audio == wall) + /tmp/opencode/avsync.py for the honest offset. If durations match, the acceleration defect is closed; then decide push with the user, and attack any true audio-latency residual as its own work unit.