The measurement unit existed to name which of the six scene elements eats ~140ms per
composite. The creator's Release recording (ty-20261016-1841-559-0002.mp4, 174.5s,
1920x1080@60) names none of them — the whole composite costs ~1ms:
composites 301 per 5s = 60/s, every slot, 0 dropped, 0 stalls after warm-up
avg render 1.0-1.1ms (worst 2.5ms) = ~7% of the 16.67ms budget
parts "#5 HD Pro Webcam C920 0.4ms, #5 ... raster 0.2ms, backdrop 0.2ms"
- the other four elements never reach the 0.1ms print floor
C4 cache 151R/150H: half the ticks were a whole-frame BlockCopy
webcam 30.0/s at the resolver, longest gap 50.0ms (one 60Hz frame of
sampling phase, not a drop)
the FILE 29.6 distinct webcam images/s, 82% of images held exactly 2 frames,
longest hold 267ms (the healthy 30fps-in-60fps signature)
The two stalls are not composite cost: 124ms on the very first render (warm-up) and
53ms entering the "Chat" scene (a rebake).
So the historic slow numbers are not a slow scene but different configurations:
- Oct 9 19:48 (only bad take still on disk) was the VERTICAL tier:
"FramePump started (1080x1920 @ 60 fps) scene='Live' comp=608x1080" - the 607x1080
centre crop upscaled to 2M px, 92 renders/5s, avg render 45.0ms, worst 278ms.
- Oct 5 12:01 (141ms) logged no scene=/comp= at all - the suffix did not exist yet,
so the map's "21:9 -> 1920x803" explanation stays a hypothesis, not a reading.
- Every slow window shows "cache xR/0H" (the whole-frame cache never reusing) while
this take shows 151R/150H, and one Oct 5 take latches mid-take (1.5ms -> 3.0ms ->
45.2ms in 15s, then stays). That latch is the lead for the next take; it is a
hypothesis and the parts line is what will decide it.
Corrections to the map (same commit, stale facts replaced not appended):
- "It was never Debug-vs-Release" is WITHDRAWN: same 1920x1080 tier, Oct 9 = 10.4ms
vs this Release take's 1.0ms, and Build <hash> carries no configuration - every
pre-2026-10-16 render number is config-unknown.
- The "same scene shape" 10:01/12:01 comparison is superseded: it was an eye
comparison of takes whose geometry was never logged.
New: scripts/webcam-cadence.py - the ground-truth probe for what the FILE holds,
beside what the pump says it did. It took three wrong readings to get right (H.264
re-encoding defeats exact-pixel comparison; a round-clip crop's corners leak 60fps
background; a fixed crop across a scene switch reads background), all recorded in
MyMistakes.md as a recipe, including an ffmpeg-native cross-check
(tblend=difference + signalstats.YAVG - the same metric, the technique already in
this repo's A/V-sync recipe) which agreed: 52.2% duplicates / 28.6 distinct/s vs
50.7% / 29.6/s on different windows of the same take.
Next: no fix is allowed yet - the creator makes a Release take in the failing
geometry (vertical 1080p60 tier first), and that take's parts line names the stage.
Docs in the same commit: ai.md (new "What the first instrumented take said" section,
the two corrections, the parts-line denominators, the tool in the inventory),
TASKS.md (reading outcome), HANDOFF.md (rewritten), MyMistakes.md (recipe).
Gates: clean build 0 warnings, full suite 428/428, scope check passed.
Store policy 10.2.2 forbids dynamic code inclusion, and this was the only
third-party binary the app ever downloaded and ran. It had already failed in
production: the pin aged out of BtbN's 14-day retention and the download 404'd
on the creator's first real recording attempt (2026-09-01). Bundling kills
that failure class permanently and deletes the startup network dependency.
- scripts/fetch-ffmpeg.sh populates a gitignored ./ffmpeg from a pinned
month-end BtbN LGPL-shared artifact, SHA-256 verified before extraction,
idempotent, FFMPEG_ZIP= override. 135 MB of DLLs in git would tax every
commit on this 9p tree; the URL + hash are the audit trail LGPL §6 wants.
- ytLive.csproj copies ffmpeg\** to output and publish (Always), and a
GuardBundledFfmpeg target fails the BUILD if the folder is missing, so a
fresh clone finds out before a take rather than during one.
- FfmpegLocator loses the downloader, the zip extraction and the
%APPDATA%\ytLlive\tools cache. Order is now bundle -> PATH, deliberately
inverted: a PATH ffmpeg may be a different major version or a GPL build,
and the bundle is what was pinned, license-vetted and tested. A missing
bundle throws loudly; the old "found something on disk" path could satisfy
a missing bundle with a stale copy, and silent drift is the worst failure
mode for a dependency certification inspects.
- ffplay.exe (18 MB) is not shipped; nothing calls it.
- THIRD-PARTY-NOTICES.txt: "downloads" -> "bundled" throughout, and the stale
build tag autobuild-2026-08-09-13-03 — the tag that 404'd — corrected to
autobuild-2026-08-31-13-27 with the exact artifact name and archive hash.
OpenH264 made precise: compiled INTO avcodec-63.dll, no separate binary.
Checked whether other third-party binaries needed bundling: no. e_sqlite3.dll
and WebView2Loader.dll already ship via NuGet into runtimes\win-x64\native\,
OpenH264 is inside avcodec-63.dll, the rest are managed. Two gaps remain that
bundling cannot fix, recorded in the map: the WebView2 Evergreen runtime is a
machine prerequisite (TASK 48 item 2), and Velopack's updater downloads and
executes, so its teardown is a compliance action.
Tests: 16 locator facts, suite 379/379, 0 warnings. The integration test runs
the bundled ffmpeg -version, which is the only assertion that proves the
sibling libav*.dll resolved — presence checks pass with the DLLs missing and a
shared build then fails to start. TheLocatorCarriesNoNetworkCapability keeps
10.2.2 from rotting back.
Analysis: TASKS/research-store-certification.md §4.
gramps