[vanceingalls]

What was wrong

With blur on and data-motion-blur-events="on", a render worker that starts mid-film could show the wrong one-off state until the next callback. In spacex-launch, the first caption showed the second caption's text for up to 74 frames.

The mover scan walks the film with callbacks live and finishes at the end. Each tier's discover() then seeks straight back to the worker's first frame. GSAP fires tl.add(fn) calls in both directions, so that backward seek re-runs only the calls ahead of the worker, and the latest state wins.

Why it went unnoticed

Most local renders interleave frames, so every worker starts near frame 0 and the backward seek crosses every call. Workers get contiguous blocks when capture can't encode at the same time: non-H.264, chunked encode, PNG capture, or as many workers as CPUs. Distributed chunks are contiguous too, but they force blur off today.

The fix

scanMovers now ends by rewinding through 0 with callbacks live, so the seek to the start frame goes forward. Every worker then lands on what the frame-0 worker already had. Both tiers go through scanMovers, including the rescan after a tier handoff. A silent seek to 0 is not enough: it leaves onUpdate state from the scan, and the counter in the same film then read $1.0T instead of $0.0T.

Evidence

spacex-launch, Subtle, PSNR against an interleaved whole render:

• Contiguous local render, before: frames 891-956 wrong, min 31.2 dB. After: no frame below 40 dB.

• Distributed chunks (blur force-off removed in a scratch build), before: frames 883-956 wrong. After: mean 66.0 dB, min 49.9 dB on Mac; min 48.8 dB on Linux with Chrome 156.

• spacex-launch forced to the filter tier, after: the caption is right on chunks and on a contiguous local render. Chunked vs whole still differs at frames 541-581, 680-750 and 1112, and those same frames differ with blur off, so they are not blur's.

New test leaves a worker starting mid-film the state of the calls behind it, in the capture and filter suites, fails without the fix on both: expected 'second' to be 'first'.

Not fixed here

Worker scans can still disagree by one mover (76 vs 77 in spacex-launch, 27 vs 28 in HF-heygen-stripe), because the scan starts from the worker's own state. No visible difference in spacex-launch, and HF-heygen-stripe stays within its Off noise floor.

🤖 Generated with Claude Code

[heygengenesis]

Verdict: REQUEST CHANGES · 1 blocker · 0 important · 0 nits · head a5e397a

The capture-tier fix is right: going through 0 replays the frame-0 worker's path. But the filter tier still has the bug.

• blocker packages/core/src/runtime/captureMotionBlur/filterTier.ts:133: discover() runs the same scanMovers and then calls seek(restoreTo) directly from the end of the film. A worker starting mid-film on the filter tier still keeps the state of the call ahead of it. That covers data-motion-blur-tier="filter", Chrome without html-in-canvas, and every settleTier() handoff (translation-only on auto, root-opacity defects, and so on). The handoff case also undoes this fix: the filter tier rescans at the worker's first frame and seeks backward from the end again. I copied the new test into describe("filter fallback") with no html-in-canvas installed, and it fails at this head with expected 'second' to be 'first'. Adding seek(0); before filterTier.ts:133 makes it pass, and the whole captureMotionBlur/ suite passes (188/188). Please make that change and add the filter-tier test.

Scope

Read the full diff, index.ts discover/blockedByScan/settleTier, filterTier.ts discover, and discover.ts scanMovers (when events are on it ends on a quiet pass at the end, so the loud seek through 0 crosses every call). With events off, the extra seek(0) is quiet and costs nothing. The frame-0 worker's path doesn't change. I ran the new test locally and it passes. CI was still running when I reviewed, so this verdict doesn't depend on CI.

— Genesis

[github-actions]

Edit accuracy: accurate 271 (base branch 271), smooth 128 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-center-r0-nested-z100: 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 / 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 · a5e397a → 8829228

✅ The filter-tier blocker is fixed in 8829228. scanMovers now rewinds through 0, so both tiers and the handoff rescan get it. Both new tests fail without that line (expected 'second' to be 'first'), and captureMotionBlur/ passes 188/188. CI is green at this head.

— Genesis