LlamaCasty/HANDOFF.md

# HANDOFF — 2026-09-12 (webcam FIXED; audio-silence FIXED; TRUNCATION ROOT-CAUSED + FIXED for static scenes)

## Branch / Commit State

`main` HEAD = `a62a283`. Ahead of origin by 25 commits. **NOT pushing** — user
ruling: no push until web-overlay transparency AND audio-silence are addressed.

Uncommitted (all belong to the current work, none committed yet):

```
M .gitignore
M HANDOFF.md                       (this file)
M MyMistakes.md                    (webcam collateral recipe added)
M Services/Audio/AudioSyncDelay.cs (audio-silence fix)
M Services/Compositor/SceneCompositor.cs (webcam cbW/cbH fix)
M Services/MediaCaptureFrameSource.cs (diagnostics REMOVED — clean)
M ytLive.Tests/AudioSyncDelayTests.cs (silence regression test, proven both ways)
M ytLive.Tests/SceneCompositorTests.cs (webcam regression test, proven both ways)
M Services/Encoder/FramePump.cs (slow-render probe, see TRUNCATION below)
```

Build is green (0 warnings); 295 tests pass (audio + compositor + pump suites).

Audio.SyncOffsetMs changed DB-side to 0 (see AUDIO section) — HANDOFF-only change,
nothing new to compile.

## ✅ TRANSPARENCY — CLOSED (pushed gate #1)

User confirmed transparency is fixed (`efe88b8` era). Push gate #1 clears.

## ✅ WEBCAM GRAY BLOCK — CLOSED

Root cause: `SceneCompositor.BlitContentRaw` defaulted `cbW=cbH=0` when
`src.CropBounds` is null — regression from `ed9d7c1`. Every webcam frame (no crop
bounds) blitted to an empty 0×0 source rect → nothing drawn where the webcam
should be. Fix: default `cbW=src.Width`, `cbH=src.Height`. Regression test
`BlitContentRaw_NoCropBounds_SamplesAcrossFullSource_NotJustOrigin` proven BOTH
ways (fails on old code, passes on new). User confirmed correct webcam render in
the latest recording. All temp diagnostics stripped from
`MediaCaptureFrameSource.cs` and `SceneCompositor.cs`.

## 🟡 AUDIO SILENCE — ROOT-CAUSED AND FIXED, pending final user take

**Symptom:** mic/desktop levels showed real values in preview and in the
per-5s `Audio live:` telemetry, but `peakMix` stayed exactly `0.000` and saved
recordings were digital silence (-91 dB, verified with `ffprobe -af
volumedetect`).

**Root cause:** `AudioMixer.FillAndMix` calls `_syncDelay.Configure(...)` on
EVERY ~10ms tick (it re-reads the live UI setting each mix). The old
`AudioSyncDelay.Configure` unconditionally reallocated and zeroed the delay
buffer AND reset `_writePos=0` on every call — discarding the just-written
audio before the delay offset could ever read it back. With offset 0 the early
passthrough masked it; any non-zero saved offset = total silence. The DB has
`Audio.SyncOffsetMs = 500` (left over from TASK 22 testing) → that's what
triggered it.

**Fix:** `Configure` now early-returns when the delay samples haven't actually
changed (still reallocates/flushes on a *change*, so the live slider still
clicks rather than smearing). Regression test
`RepeatedConfigureWithSameDelay_EveryTick_StillDelivers_TheMarker` mirrors the
mixer's exact calling pattern and was proven BOTH ways (marker lost = silence
on old code; marker survives → expected 960-sample shift on new).

**Telemtery proof the fix works:** latest take (ty-20260912-1135-0000-2.mp4,
recorded WITH the fix, sync offset still 500): `peakMix` = 0.434–0.523 across
all five 5s windows (was 0.000 before). **Audio is NOT silence anymore.**

**Follow-up:** sync offset `Audio.SyncOffsetMs` measured and SET TO **0** (2026-09-12, take ty-...-1358):

Measurement method tri-wins instead of clap deltas: `silencedetect` on the audio
gave the count-word starts (one≈0, two@4.12, three@6.48 — audio PTS, both streams
start at 0, no mux offset), and per-frame video motion (`tblend=difference` +
`signalstats YAVG`) cross-correlated against the audio envelope peaks at shift
**+22 frames → audio LAGS video by ~367ms with the 300ms offset active** → the
pipeline's own lag is only ~70ms. The saved 300ms (TASK 22 leftover) is what made
it read as "one word late" (370ms ≈ a third of the ~2.3s pause ≈ perceptually a
full beat behind). Fix = offset 0. Expected residual ≤~70ms (imperceptible).

## ✅ TRUNCATED VIDEO — ROOT-CAUSED AND FIXED (for baked/static scenes)

**Symptom:** recordings ran ~1s short at first, then HALF-length: 22.8s wall →
10.48s file. Not a mux/`-shortest` cut — the pump simply produces frames slower
than the declared 60fps.

**Mechanism (proven):** ffmpeg rawvideo timestamps frames by ARRIVAL at declared
`-r 60`. Pump deadline pacing (OBS libobs pattern) yields each frame when its
~17ms slot lands; if the render stage for that tick takes longer than the slot,
the pump can only do ~1 frame per 35ms → ~27–28fps of *submitted* frames → file
length ≈ submittedFrames/60. So a take that *should* be 22.8s muxes to ~10.5s,
and logs show `avg render 35–38ms` with 136/300 per 5s. FramePump had NO way to
tell which compositor pass ate a slow frame.

**Root cause of the 35ms:** the scene was NOT actually fully static. Any dynamic
element still in the scene — **including hidden ones**, which still count as
Dynamic in `SceneGraph.GetSplitPoint` — forces the per-frame composite path. If
it sits at split 0, `GetBakedBase` returns null and every tick is a FULL render
(no baked base). The 12:59/13:39 takes logged `resolve 1.0ms` per frame — a live
element was still resolving, confirming dynamic content was present.

**The fix that matters (no code changed in the renderer):** a truly static scene
renders in <1ms. New slow-render probe (`ProbeRender` in FramePump.cs) names the
path; the 13:53 take of a 1-element static scene logs
`render=fully-static split=1 dynamic=0 bakeMs=246 totalMs=246` on the FIRST
frame (cold raster of the background at 1080p), then `0.8→0.0ms` avg render,
`301/300` frames per 5s, 0 stalls → **12.46s file from 12.29s wall, 735 frames
@ 60fps. No truncation.**

**Rule for recording:** every scene used for RECORDING should be ≥1 static
element first (background image) with all web/cam/chat widgets AFTER it in
layer order (split ≥ 1 → bake feasible) — a scene whose FIRST layer is dynamic
at recording time will truncate. If a take with widgets comes back truncated
again, the probe now points at whether it took `fully-static` (bake), or
`base+layers` / `full-render` (composite) and how long.

**Probe left in place** (≈0 overhead: one Stopwatch, string built only when a
render ≥20ms): it is the diagnostic that named this bug; keep it until the
dynamic-scene path is proven fast too, then remove.

## 🔴 OPEN — user-reported "video seems truncated ~1s" (unconfirmed)

Recording ty-20260912-1135-0000-2.mp4: format duration 26.370s, video 26.167s
(1570 frames @ 60fps), audio 26.370s. FramePump stats for the whole take show
`dropped 0` and 300/300 frames every 5s window. End-frames (n=1500 vs 1560 vs
1569) differ — not a frozen/repeat-last-frame truncation. Log shows recording
window 11:35:01.386 → 11:35:27.562 = 26.2s of video: matches the file. No
evidence of truncation found in data. Possibly user perceived the 500ms audio
delay (audio trailing video start / leading video end) as truncation — worth
re-checking with offset zeroed. If a real freeze/truncation reappears: pull
last-3-frames diffs and confirm_frame timestamps next.

## Other threads (paused)

- **Audio-silence verification** — the FIXED take has real peakMix; final =
  user re-records with the finalized offset and confirms audible audio in playback.
- **Audio sync offset final value** — set to 0 via DB (measured residual ~70ms).
  NEEDS user re-take to confirm (the running app may still hold 300 in memory —
  if unsynced on the re-take, use the UI slider to 0, or restart the app BEFORE
  recording so the 0 loads).
- **Truncation with DYNAMIC scenes** — proven mechanism; static scenes now
  record full-length. The 13:58 take was a 6-element/4-dynamic scene
  (`split=0 → full-render`, ~34ms, 20 stalls/5s): fully full-length (10.98s)
  but JITTERY (judder from the 34ms hard frames). If a widget-heavy scene reads
  badly again, the ProbeRender log names the stage; the next move is getting a
  baked base by reordering static elements first or optimizing full-render.
- **Webcam MJPG missing** — "MJPG negotiation refused (being used by another
  process)". Queued.
- **Web capture speed** — ~10-14Hz effective. Revisit only on request.
- **Layer order** — SortOrder not persisting on drag. Queued.

## Landmines

- testhost shares startup.log — filter by time.
- `cmd.exe /c "taskkill /F /IM ytLive.exe"` (WSL form double-slashes mangle) before rebuilds.
- Build/tests: Windows dotnet host (`/mnt/c/Program Files/dotnet/dotnet.exe`). 0 warnings.
- ffmpeg/ffprobe: `/mnt/c/Program Files/Krita (x64)/bin/ffmpeg.exe` with Windows paths.
- `Audio.SyncOffsetMs` persisted non-zero WILL re-trigger silence symptoms if
  `Configure` is ever called unconditionally again — the idempotent guard is the
  fix, keep it.
- `MyMistakes.md` has the transparency RESOLVED entry and the new webcam
  collateral recipe — grep before any re-derivation.