Better Call CineCrew: Consistent Ultra-Long Narrative-to-Film Generation¶

会议: ECCV2026
Paper: https://eccv.ecva.net/virtual/2026/poster/3661
PDF: https://media.eventhosts.cc/Conferences/ECCV2026/pdfs/2445.pdf
领域: 视频生成
关键词: 长叙事视频生成、FilmDSL、多智能体、跨镜头一致性、人物性格一致性

一句话总结¶

CineCrew 不重训视频模型，而是用 FilmDSL 把叙事、镜头调度、资产和修复反馈组织成可执行的制作流程，在 20 个 MovieBench 叙事输入上改善人物、道具与故事衔接，但并非所有画质和物理指标都领先。

研究背景与动机¶

把剧本拆成短片再拼接，绕开了单次视频生成的时长限制，却没有解决电影中的状态继承问题。同一个人物在下一个镜头可能换脸，道具可能消失，房间布局可能重置；即使脸没有变，一个谨慎的人突然做出不合性格的夸张动作，也会破坏叙事。MovieAgent、AniMaker 等系统已经利用多智能体规划长视频，因此本文面对的不是“是否要拆分任务”，而是拆分后究竟用什么表示来约束这些相互依赖的决定。

自然语言剧本通常只交代发生了什么，并不完整规定镜头大小、机位、道具位置以及角色的微动作。若直接把故事段落变成视频提示词，这些缺口就被每一次生成独立补全。单张人物参考图可以约束外观，却不能完整表达谁应当看向谁、当前情绪如何变化、哪些物品必须延续。更换更强的生成模型能改善短片质量，但无法自动提供可检查、可局部修改的跨镜头生产状态。

本文因而把创新放在剧本与生成器之间：将人类制作中的叙事意图、摄影决定和渲染指令分层保存，并让所有角色共享同一套资产与连续性记录。核心 idea：以 FilmDSL 作为可持久化的制作协议，把跨镜头约束写成明确字段，再用关键帧锚定和结构化诊断反馈局部修复生成失败。

方法详解¶

整体框架¶

输入可以是影视剧情、分集梗概或类剧本文本，输出是按叙事顺序组装的长视频及对应 FilmDSL。系统先划分 narrative beats，即信息揭示、动作完成或情绪变化等故事单元；一个 beat 可以对应多个可执行片段，片段时长也可以不同，因此不能把一个 beat 等同于一个固定时长镜头。

制作前先建立全局设定与资产锚定，再通过分层 FilmDSL 与人物表演约束编译片段计划。制作时采用关键帧优先执行，逐片调用现成生成器；诊断修复与共享规则簿把失败和已接受状态写回，最后由后期模块拼接字幕与声音。这里的“约束”首先是明确的工具条件和检查对象，不是生成器必然满足的数学硬保证。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    Input["叙事文本"] --> Assets["全局设定与资产锚定"]
    Assets --> DSL["分层 FilmDSL<br/>与人物表演约束"]
    DSL --> Execute["关键帧优先执行"]
    Execute --> Review["诊断修复与共享规则簿"]
    Review -->|修改片段字段后重试| Execute
    Review -->|持续状态约束后续片段| DSL
    Review -->|片段定稿| Output["后期组装<br/>视频、字幕与声音"]

关键设计¶

1. 全局设定与资产锚定：让每个片段引用同一组人物和场景

Showrunner 先确定帧率、宽高比、基调、年代、地点和角色名单，这些全局头字段被片段继承，除非明确覆盖。Art Department 再生成 Character Sheets 和 Set Assets：前者提供多视角身份、服装参考和紧凑的人物性格信息，后者提供主要场景的关键图像或描述。这样，片段制作不是重新想象“某个中年男人”，而是引用已经确立的角色与场景。全局格式和资产也被纳入 FilmDSL，而非游离于流程之外的参考附件。

FilmDSL 本身不直接装入原始图像，而是保存 ID、URI、哈希或 embedding key 等稳定引用。下游通过 char_id、sheet_ref、set_ref 找到相同资产，减少反复用文字描述导致的漂移。这里应区分资产引用和语义检索：正文说明了如何持久引用及取得资产，没有给出一个单独训练的检索模块或检索排序算法。资产也不仅服务于“长得一样”，角色表中的性格信息会继续参与表演编译。

2. 分层 FilmDSL 与人物表演约束：分清发生什么、怎样拍摄以及怎样调用模型

统一的 JSON-like 对象包含 meta、assets、memory 和 clips。每个片段保留三个层次，而不是把所有要求压成一段提示词。原文式 (3) 的结构为：

\[ d_i=(a_i,s_i,r_i). \]

其中 Narrative Action 对应 \(a_i\)，保存可观察事件、情绪和台词，由 Story Editor 编写；Cinematic Staging 对应 \(s_i\)，由 Cinematographer 规定景别、机位运动、构图、光线、人物与道具；Render Specification 对应 \(r_i\)，由 Technical Director 编译成关键帧提示、视频提示、可选负面提示，以及时长、帧率、宽高比、种子等工具参数。保留这些层次的意义是，失败时能判断应修改叙事意图、摄影选择还是渲染表达，而不必盲目重写整段故事。

Staging 层还承载连续性字段，例如 character_refs、set_ref、required_props、forbidden_props 和 continuity_link。前两个绑定身份与场景，后几个分别规定必须存在、禁止出现的物品，以及与前片状态的关系。相邻片段需要像连续拍摄时，系统可使用上一片尾帧衔接下一片首帧；这不是所有剪辑边界都必须采用的规则。明确区分连续镜头与正常切镜头，有助于避免为追求连续性而抹掉合理的电影剪辑。

外观锚定仍不能保证“演得像这个人”。Persona Schema 因此同时保存长期 trait-to-behavior 映射和当前 beat 的 performance block：前者把谨慎、急躁等特征落实到姿态、目光、反应延迟、人际距离和手势节奏，后者规定当前表演目标、局部情绪弧线、走位意图与微动作。Acting Coach 根据当前 beat 和连续性状态实例化表演块，再由 Technical Director 传入调度约束及可渲染提示。这使抽象性格能够影响可观察动作，但不意味着论文训练了专门的表演模型。

3. 关键帧优先执行：先把人物、布局和道具摆对，再让画面运动

Production Operator 依据片段规格、人物参考、场景资产和已锁定布局先生成 storyboard-like 关键帧。它把文本层面的约束转换成同一张图上的组合关系：人物站在哪里、道具是否出现、整体光线是否正确，随后视频生成器以这张图和片段提示为条件生成动态片段。相比仅给一个身份参考，关键帧同时锚定当前镜头的构图与场面；相比仅继承上一片末帧，它又能支持新机位或新的场景安排。

执行存在有台词和无台词两条路径。有台词时，VO Director 从 FilmDSL 的台词生成语音轨，交给支持音视频条件的生成器；无台词时使用关键帧和视频提示调用视频生成器。正文式 (2) 的文本抽取损坏，但第 3.4 节及算法清楚说明了这两条分支，因此这里只保留可核验的文字机制，不猜补损坏公式。VO 角色还负责声音意图与时序，Post Supervisor 最后组装片段、字幕、拟音及音效，并可混入环境声或音乐；声音链路没有单独定量消融。

4. 诊断修复与共享规则簿：把失败定位到字段，并让后续片段继承修复结果

Dailies Reviewer 检查身份漂移、道具复制或瞬移、布局重置、摄影运动不符等现象，输出结构化 QA 信号。修复优先级先落在连续性和约束字段，如必须或禁止的道具、连续性链接、锁定实体；然后修改关键帧提示，再修改视频提示，必要时回到上游调度字段。这比给整个视频一个笼统低分更可执行：道具凭空出现时，首先补足对应约束，而不是让所有角色重新规划完整叙事。

Production Rulebook 同时保存静态先验和动态状态。静态部分是摄影调度经验、反幻觉与防凭空生成约束、命名约定；动态部分是已接受关键帧、锁定道具与布局、失败标签及定稿提示。规则簿按角色选择性注入约束，供 Story Editor、Cinematographer、Technical Director、Production Operator 和 Dailies Reviewer 共用，并由执行日志持续更新。算法对每个片段设置最多 \(R\) 次尝试，接受则提前结束；正文没有给出 \(R\) 的具体值、接受阈值或耗尽重试后的专门兜底策略。记忆因而是共享生产状态，不是模型参数更新，也没有被证明能无限增长而不出错。

一个完整示例¶

论文展示的 Gene 叙事包含面包店揉面、回到昏暗公寓、播放 VHS 录像等事件。以下按论文机制串联这些事件，用于说明执行过程，不把它当成额外实验轨迹。

全局设定先规定黑白 noir 风格与人物外观，资产库保存 Gene 的角色参考及相关场景。Story Editor 不只是写“他很紧张”，还要确定当前动作和情绪；Persona Schema 再把紧张落到目光与动作表现。Cinematographer 决定镜头如何呈现人物及环境，Technical Director 将这些要求编译成可调用的片段规格。

回到公寓时，系统引用同一角色资产和公寓场景资产，通过关键帧先确立人物、录像设备与房间布局。如果生成视频让设备消失，Reviewer 会反馈道具持久性问题，修订对应字段并重试，而非更改“播放录像”的故事目标。接受后的画面状态和约束进入规则簿，供后续电视画面及人物反应镜头使用。具体失败次数与重试收益正文未报告，不能替这个说明性例子虚构成功率。

损失函数 / 训练策略¶

本文是无需重训底座的编排系统，没有提出新的扩散损失、优化器或可学习的连续性目标。它依靠结构化规划、资产条件、生成器调用和诊断重试改善结果，因此成本应按模型调用与重生成计算，而非只看训练开销。缓存未充分列明完整底座组合、每段推理配置、每条叙事总成本与重试分布，不应补写这些超参。

实验关键数据¶

主实验¶

自动评测从 MovieBench 抽取 20 个叙事，覆盖不同题材、年代、室内外、昼夜、角色人数和动作或对话驱动情节。CineCrewEval 分成电影表达、跨片段一致性和 VBench 通用品质三个维度，VLM 评审使用 Gemini-3-Flash；LTX-Studio 对照使用 LTX-2 Pro。下表摘录原文表 2，不把不同量纲的分数相加。

方法	B.R. 情节可读性	P.A. 性格契合	N.C. 叙事连贯	I.C. 身份一致	P.P. 道具持久	C.L. 电影观感	P.C. 物理合规
MovieAgent	2.50	3.20	3.00	60.09	58.78	4.10	3.35
AniMaker	3.20	3.60	4.10	61.38	65.17	4.20	3.50
LTX-Studio	4.25	4.10	3.80	67.15	73.24	4.90	4.60
CineCrew	4.90	4.75	4.70	75.12	78.59	4.85	4.20

B.R. 判断关键动作、意图和情绪是否清楚，P.A. 判断行为是否符合人物性格和动机，N.C. 判断时间与因果衔接；I.C. 衡量跨片段人物身份，P.P. 衡量道具不应无故出现、消失或复制。C.L. 关注光线、色彩、纹理与风格，P.C. 检查瞬移、凭空生成和不可能运动。正文给出这些语义定义，但将更详细评测规则放在未包含于当前缓存的补充材料，故不能把 I.C. 或 P.P. 擅自解释成精确检测准确率。

消融实验¶

下表摘录原文表 4，所有列均为越高越好。去掉 FilmDSL 指直接将剧本分成可提示生成的片段，而非仅移除 JSON 的文件包装。

配置	B.R.	P.A.	N.C.	I.C.	P.P.	L.C. 布局连续
去掉 Showrunner	4.65	4.05	3.95	67.82	70.15	4.20
去掉 Production Rulebook	4.55	4.70	3.90	73.78	76.85	4.25
去掉 Assets Memory	4.05	3.50	4.05	61.29	72.72	4.05
去掉 Dailies Reviewer	4.75	4.75	4.60	74.08	70.24	3.95
去掉 FilmDSL	3.05	3.40	3.45	65.24	69.15	4.00
完整系统	4.90	4.75	4.70	75.12	78.59	4.50

用户研究另招募 24 名参与者，使用 10 个叙事，每个至少包含 5 个连续片段；结果匿名、随机排序，论文声明采用匹配的生成预算。表中是原文表 3 的部分指标，评分范围 1–5。

方法	CS 电影调度	BC 情节清晰	CC 跨片段连续	OP 总体偏好
MovieAgent	2.67	3.35	2.17	3.67
AniMaker	3.33	2.83	4.33	3.00
LTX-Studio	4.00	3.67	3.83	3.17
CineCrew	3.67	4.50	4.83	4.25

关键发现¶

对比 LTX-Studio，I.C. 高 7.97 分、P.P. 高 5.35 分，说明主要优势落在跨片段状态维持；这里是分数差，不是相对百分比或统计显著性结论。
去掉 FilmDSL 后 B.R. 下降 1.85 分，N.C. 下降 1.25 分，两项均为表中最大降幅，符合“显式保留故事意图”的解释；去掉 Production Rulebook 也使 N.C. 降到 3.90，显示共享状态同样影响叙事连贯性。
去掉 Assets Memory 的 I.C. 下降 13.83 分，是表中身份指标损失最大的消融；去掉 Reviewer 的 P.P. 下降 8.35 分，说明视觉锚定与失败修复承担不同职责。
不是全面胜出：LTX-Studio 的 C.L. 为 4.90、P.C. 为 4.60，均高于本文的 4.85 和 4.20；用户研究的 CS 也以 LTX-Studio 的 4.00 高于本文的 3.67。均值趋势应与没有置信区间的限制一起读。

亮点与洞察¶

FilmDSL 的价值不在 JSON 格式本身，而在错误能够被追溯到叙事、调度或渲染层。类似的分层接口可迁移到图文故事和广告视频制作，让人工导演只修改失败的表达环节。
人物一致性被拆成“外观相同”和“行为符合角色”两件事。将长期性格映射为可观察动作，再结合当前 beat 的表演要求，比在提示词中反复添加性格形容词更可检查。
资产库保存“应该是什么”，规则簿保存“目前已经发生了什么以及哪些尝试失败”。两者结合能够支撑跨片段生产状态，但消融只支持当前设置下的作用，不能外推成无限长记忆能力。

局限与展望¶

当前缓存正文没有独立的局限章节；以下是基于报告范围的评读。标题强调 ultra-long，但没有清晰汇总总生成时长、最大片段数量或随序列长度变化的性能曲线，不能据此认定已经量化验证小时级电影生成。
自动评测只有 20 个叙事，用户研究是 24 人与 10 个叙事，未提供置信区间或显著性检验。电影表达主要依赖单一 VLM，当前缓存缺少详细评分提示、身份及道具指标公式，评测可复核性仍有限。
不同系统可能采用不同生成底座；用户研究虽声明匹配预算，正文没有充分列出统一调用成本与具体执行配置。主表优势不能完全归因于编排机制，受控消融更接近这个问题，但也缺少重复实验方差。
Persona Schema、语音分支和各类修复优先级没有各自独立消融；重试上限、接受阈值及记忆增长成本也未充分报告。后续应同时测量收益、调用费用、延迟及修复传播到后续片段的影响。
明确写入约束并不能消除生成器的物理错误。更强的空间状态检查与人工干预接口值得尝试，但属于延伸建议，并非本文已经实现和验证的能力。

评分¶

新颖性: 4/5。将可执行电影中间表示、人物行为约束和持久修复状态整合得较完整，但总体仍建立在现有多智能体与生成器工具链上。
实验充分度: 3/5。具备多方法比较、组件消融和用户研究，但长时程尺度、成本、方差与评测复现细节不足。
写作质量: 4/5。三层表示和制作闭环清晰；部分实现细节留在补充材料，且需要以表格纠正过强的概括性结论。
价值: 4/5。对可控多镜头制作有实际参考意义，但不宜把系统级改进等同于解决任意长度的电影生成。