28 lines
1.7 KiB
Markdown
28 lines
1.7 KiB
Markdown
## Context
|
||
现有批量生成按镜头顺序执行，主要是为了将上一段尾帧传给下一段首帧。新的产品判断是尾帧传递收益不明显，用户更需要整体生成速度。
|
||
|
||
## Goals
|
||
- 两套工作流保持一致：爆款 MV 与爆款视频都使用同一类并行批量生成语义。
|
||
- 每个镜头独立生成首帧，再基于该首帧生成视频。
|
||
- 保留现有角色参考图、全局参考图、知识库上下文、模型参数、尺寸参数和自动插入画布行为。
|
||
- 停止按钮应尽量阻止后续提交，并让已提交任务自然完成或由现有任务队列处理。
|
||
|
||
## Non-Goals
|
||
- 不新增新的记录实体或持久化大文件。
|
||
- 不引入上一段尾帧到下一段首帧的兼容模式。
|
||
- 不改变单镜头“生成首帧/生成视频”的交互语义。
|
||
|
||
## Approach
|
||
`handleGenerateAllVideos` 改为为每个需要生成的镜头启动一个独立 async pipeline：
|
||
|
||
1. 若镜头缺少可用首帧，则调用现有首帧生成任务，参考图包含全局参考图与该镜头角色参考图。
|
||
2. 首帧 URL 写回当前镜头。
|
||
3. 使用该首帧作为本镜头视频任务的 `referenceImages`，提交视频生成。
|
||
4. 视频 URL 写回当前镜头，并按现有设置选择是否插入画布。
|
||
|
||
所有镜头 pipeline 使用 `Promise.allSettled` 并行等待。失败和重试在单个镜头内部处理，不阻塞其他镜头。
|
||
|
||
## Risks
|
||
- 并行提交可能触发供应商限流。实现优先复用现有任务队列和轻量 URL 引用，不读取/缓存大二进制；若后续实测限流严重，再加并发上限配置。
|
||
- 停止无法取消已经提交给供应商的任务；本次保持现有队列语义，只停止未进入下一阶段的 pipeline。
|