render: parallel worker's first frame still captures pre-seek state — #2477 fix never landed (0.8.72)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- html, typescript
调研方向
Start in frameCapture.ts and trace the parallel worker path that calls captureFrame; inspect how discardWarmupCapture is intended to participate, along with its re-export in engine/src/index.ts. Reproduce with the provided multi-worker HTML composition and alpha scan. Done means non-zero worker shards capture their seeked state without transparent first frames, while single-worker behavior remains unchanged.
由索引模型根据 Issue 内容生成。
描述
Describe the bug
Re-opening the #2477 symptom on 0.8.72: parallel capture emits a fully transparent frame at each worker shard's first frame. The fix PR #2489 was closed unmerged, and discardWarmupCapture still has zero call sites on current main (a3d7736) — only its definition in frameCapture.ts and the re-export in engine/src/index.ts.
Observed with a transparent ProRes 4444 render of a canvas/DOM overlay composition (120 frames @ 24fps, --workers auto → 4 workers, screenshot capture mode): frames 30, 60, 90 decode fully transparent — exactly shardStart = w * (totalFrames / workers) for workers 1–3. Worker 0's first frame is naturally identical to t=0 so it's invisible in the alpha scan. --workers 1 produces zero blank frames; the anomaly is deterministic in position across parallel runs but intermittent (some runs clean), matching the paint-settle race described in #2477.
Notable difference from the original report's setup: our composition registers a non-GSAP duck-typed RuntimeTimelineLike on window.__timelines ({duration, time, seek, totalTime, pause, paused, play, add, set} — pure seek→redraw, no GSAP). If the post-#2477 warm-up logic engages only for GSAP timelines or on a code path duck timelines don't reach, that would explain why the regression survives for this comp shape.
Steps to reproduce
The race is timing-sensitive — a heavier page (custom fonts, canvas setup, larger script payload) widens the window. Composition shape that fails for us ~half the time at 4 workers:
<div id="root" data-composition-id="repro" data-duration="4"
data-width="1920" data-height="1080">
<div id="box"></div>
</div>
<script>
var t = 0;
window.__timelines = window.__timelines || {};
window.__timelines["repro"] = {
duration: function(){ return 4; },
time: function(){ return t; },
seek: function(s){ // pure seek->redraw contract
t = Math.max(0, Number(s) || 0);
// visible whenever t>0; only t=0 state is blank
document.getElementById("box").style.opacity = t > 0.02 ? "1" : "0";
},
totalTime: function(s){ this.seek(s); },
pause: function(){}, paused: function(){ return true; },
play: function(){}, add: function(){}, set: function(){}
};
</script>
Detection (alpha scan, same method as #2477):
ffmpeg -i out.mov -vf "alphaextract,signalstats,metadata=mode=print" -f null -
# frames at w * ceil(totalFrames/workers) show alpha mean ~0 between normal neighbors
Expected behavior
Every worker's first captured frame contains the seeked state — e.g. wire discardWarmupCapture into the parallel worker path (it already exists and is exported), or gate the first captureFrame on a post-seek paint commit rather than the seek alone.
Actual behavior
First frame of each non-zero worker shard captures the pre-seek page state (t=0). For fade-in/transparent overlays that state is fully transparent, producing visible flicker in the baked output.
Environment
[email protected](managed npm install)- macOS arm64, chrome-headless-shell 152.0.7977.30 (CLI-managed cache)
screenshotcapture mode (drawelement not engaged for this comp)- Output:
--format mov(ProRes 4444, yuva444p12le),--fps 24
Additional context
Workaround confirmed on our side: --workers 1 removes the anomaly entirely (verified across a 37-template regression suite with per-frame RGBA diffing). Filing mainly so the #2477 fix can land — the reporter there already wrote it.
- 主要语言
- TypeScript
- 星标
- 54.1k
- 派生
- 4.9k
- 平均合并
- 7 小时 2 分钟
- 30 天内合并 PR
- 782
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
heygen-com/hyperframes 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 84/100
heygen-com/hyperframes#5117 ·
维护者通常 1 天内回复
-
Docs: clarify that "Enable auto-update" is only available in the Claude Code terminal (CLI) /plugin UI可能已有人在做 @rumi7911 于 1 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 85/100
heygen-com/hyperframes#5027 ·
维护者通常 1 天内回复
-
fix(producer): propagate useGpu to HDR layered streaming encoder可能已有人在做 @Monster-GM 于 3 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 87/100
heygen-com/hyperframes#5002 ·
维护者通常 1 天内回复
-
skills: remoteHeadSha() can open a Git Credential Manager dialog on Windows (GIT_TERMINAL_PROMPT does not cover GUI helpers; slug unvalidated)可能重新可做 @RaphaelFakhri 于 7 天前认领,目前没有进行中的 PR。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
heygen-com/hyperframes#4702 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
Studio catalog prompt editor has no accessible name可能已有人在做 @lorenzozanee 于 14 天前认领。 未关闭bug difficulty/easy triage/ready
难度 2/5 1-3 小时 新手友好度 78/100
heygen-com/hyperframes#4384 ·
维护者通常 1 天内回复
查看 heygen-com/hyperframes 的全部 Issue
相似的 Issue
-
Bump Firebase JS SDK (12.19.0 → 13.0.0)可能已有人在做 @SelaseKay 今天认领。 未关闭Needs Attention type: enhancement
难度 2/5 1-3 小时 新手友好度 75/100
invertase/react-native-firebase#9364 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 4 天内回复
-
e2e-failure ready-to-code
难度 2/5 1-3 小时 新手友好度 78/100
redhat-developer/rhdh-plugin-export-overlays#4261 · 1 条评论 ·
维护者通常 1 天内回复
-
[Bug] 官网文档的图片挂了未关闭bug
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
area:cli bug triage:in-progress
难度 1/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复