mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-10-30 17:27:09 +00:00
miga-heygenandMiguel Ángel
77a45f6080
A render on the layered HDR route accepted `motionBlur` and returned frames with no blur in them. The HDR compositor runs its own capture loop, seeking and blitting each layer itself, so a frame never reaches the sub-frame accumulation branch. The engine's own guard cannot catch it, because from inside the session everything looks supported: screenshot capture mode, PNG frames, and no video injector on a composition with no video. This is the third time the question "does this route support motion blur" has been answered implicitly by whichever code path happened to run, and the third time it came out wrong and silent. `assertMotionBlurSupported` gives that question one owner and one answer. The route it takes is the capture plan's own `kind`, already the single value the capture stages consume, so it cannot drift from the route that actually runs, and a new plan kind with no entry in its table fails the typecheck rather than inheriting silence. It sits inside `syncCapturePlan`, which runs on the initial plan and after every replan, so a route a render falls back into is checked too. Distributed renders are out of scope on purpose and recorded as such: `DistributedRenderConfig` has no `motionBlur` field and is not built from `RenderConfig`, so motion blur cannot be requested on one. There is nothing to reject and no dead call site. The explicit unsupported-mode error for layered HDR is the design in #4013 by Dante-dan. Co-authored-by: Miguel Ángel <miguel.sierra@heygen.com>