[miguel-heygen]

What was wrong

Compiling a composition probed a media source once per element, not once per file. A source with no content identity (anything the compiler reads in place from a URL) shares only its in-flight probe, and the shared four-slot limiter queues the other probes, so none of them is in flight together and each one starts a new ffprobe. The compile then runs those probes in rounds of four, each over the network, and a long composition with many video elements of the same few files spends its time re-reading headers, so a slow link multiplies the wait by the element count.

Measured on a project of 40 sub-compositions, each with one muted <video> over 3 sources served over HTTP (the new test): 92 ffprobe runs on main, 9 here (two per remote file: one format read, one keyframe scan, plus one for each absent local path the advisory pass tried).

Fix

compileForRender creates one SourceProbes map and hands it to every pass that resolves a media duration (the page, each sub-composition, the audio/video clamp). A unique (tag, resolved source) is probed once behind the existing four-slot limiter; every element reads its own duration from that result, and the per-element checks (media type of the element, the error naming its src) still run per element. The advisory keyframe pass skips a source it already queued. assetMediaType.ts already groups by unique path (byPath), which is the pattern this follows.

Design calls:

• Scope the result to the compile instead of caching it process-wide: a URL's content can change between renders, which is why the engine keeps no result for it.
• The deadline stays per probe: each probe owns its 30 s, started when it gets a slot, so waiting behind others never counts, and a failure carries the element's [src=...].
• No change to the limit of four: a bigger pool would not change how many probes a file needs.

Test

htmlCompiler.probeCount.test.ts builds the 40-element project above and counts the ffprobe processes per source through a logging shim: at most 2 per file. On main it received 24 for one source (expected at most 2); with the fix 3 runs in a row pass. The existing limiter test now uses a distinct source per sub-composition, since it relied on one file being probed eight times. htmlCompiler suites (mediaType, hiddenProbe, scriptOrder, naturalDuration, animatedGif, parity, fontEmbed, moduleScripts, main): all pass.

[heygengenesis]

Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits · head 9d791823

The compiler change is correct: I reran the new test against main's htmlCompiler.ts (24 probes for one source, fails) and at this head (passes), and the mediaType, hiddenProbe and naturalDuration suites pass locally. The one blocker is that the new test runs in the wrong CI lane, so the producer unit tests fail. ↓ inline

Scope

Read all of htmlCompiler.ts diff, its 3 call sites and the advisory pass. The probe map is keyed on the absolute resolved path and scoped to one compile. The probe never rejects, so nothing goes unhandled. withSrcContext still wraps each element separately. No prior reviews. Other CI jobs were still running when I posted this.

— Claude

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 156 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

Unstable (1)

• seqplainkeys-none-pct-r0-root-z100: tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo false, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true / tracking 0.06, pressJump 0, drop 0, reload 0, render 0.03, renderKey -, undo true, teleport true

[heygengenesis]

Verdict: APPROVE — 1 resolved, 0 open, 0 new · 9d79182 → fbac394

[heygengenesis]

Verdict: APPROVE — 0 resolved, 0 open, 0 new · fbac394 → 8979eca (a rebase: the PR patch is the same apart from the re-pinned classification sha256, which I checked against the file; CI is green)

[heygengenesis]

Verdict: APPROVE — 0 resolved, 0 open, 0 new · 8979eca → 2deec47 (a rebase: same patch apart from the re-pinned classification sha256, which matches the file; main's HEIC prep in htmlCompiler.ts runs on images after the duration probes, so the two changes do not interact; CI is green)

[heygengenesis]

Verdict: APPROVE — 0 resolved, 0 open, 0 new · 2deec47 → 532737b (a rebase: the source patch is the same, and the probe-count test is now listed in integration-tests.json. Main has not touched htmlCompiler.ts since the last base. All CI is green.)