# 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).

## ✅ 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` is still in the DB — currently
**300** (flipped 500→0→500→300 during lip-sync calibration; user judged 0 worse
than 500, so it was bisected back up). NOT the recording's natural state. When the
user is ready to finalize, measure on the classic method (clap visible in frame;
read delta on the waveform — the auto-correlation approach failed to converge at
~10–14Hz webcam shutter jitter).

## ✅ 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** — DB is at 300 (bisect point). Needs the
  clap/waveform measurement; do NOT rely on the 500 left over from TASK 22.
- **Truncation with DYNAMIC scenes** — proven mechanism; static scenes now
  record full-length. If a widget-heavy take truncates again, read the
  `ProbeRender` path/stage breakdown in startup.log, then optimize composite.
- **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.