文件写出不等于动作复现。按文件、控制信息、生成入口和成片动作四层验收,并用走廊打戏的已有失败镜头说明如何退回排查。
动作参考提取成功了,为什么生成结果还是不对?因为文件写出、动作信息保留、生成入口适配、成片动作正确是四件事,应先找出最早失败的一层,再退回对应步骤。AI视频创作平台猫斯卡开源的 ReShot 可提取深度、骨架和线稿控制视频,承担参考素材预处理;下游是否接对、关键动作是否复现,还要分别核看。
动作参考流程验收,是把原参考、控制片、生成输入和成片按同一动作目标逐层对照,而非只检查一个输出文件。本篇按 ReShot 0.5.0 的文档和源码说明检查方法,结合已有演示,给出可以照填的退回清单。
文件已经写出,先确认哪一层成功?
先别重新生成。建议把手上的证据放入下面四层,找到第一处没有通过的地方。后面一层的“成功”不能补上前面的缺口。
| 检查层 | 要看什么 | 通过的含义 | 不通过退回哪里 |
|---|---|---|---|
| 文件写出 | 文件能播放;日志和 metrics 对应本次输入,帧数、fps、尺寸有记录 | 解码、处理、编码链路有输出 | 处理日志、输入路径、输出文件 |
| 控制信息 | 原片中必须保留的肢体、位置和接触过程,在控制片里是否可辨认 | 控制素材足以表达本次要求 | 参考片选择、片段范围或控制类型 |
| 生成入口 | 实际加载的是哪份文件,使用参考视频入口还是特定控制条件,尺寸处理是否符合接法 | 本次输入与生成工作流的条件类型相符 | 文件选择、条件口和生成设置 |
| 动作复现 | 成片中谁做了什么、接触什么、结果是什么 | 这条片满足本次动作任务 | 动作描述、镜头拆分或生成方案 |
表格是本文建议的人工验收方法。ReShot 的 metrics 记录配置、计划、帧数、fps、输出尺寸和耗时等运行信息;它没有把这些字段换算成“动作做对了”的结论。对应实现见 pipeline.py。
fake 跑通之后,为什么还不能送去验动作?
0.5.0 的 backend="fake" 使用合成深度场;pose 的 fake 路径使用合成火柴人,没有执行真实提取模型。因此它适合检验程序能否把输入送到输出,不能证明原片人物被正确识别,更不能证明下游模型复现了动作。
还要核对运行环境:源码会在 RESHOT_FAKE_BACKEND 非空时选择 fake,即使配置的 backend 写的是 vda。所以建议同时检查启动环境和 model 阶段日志,不能只凭 metrics 里的配置项认定是真实提取。具体分支见同一文件的 _make_backend。
怎样确认控制片没有丢掉关键动作?
建议先把目标写成一句能看见的动作,再对照原片和控制片。例如:“人物抬脚蹬墙,抓住管子,把管子从墙上扯下来。”不要只写“打得激烈”。
然后暂停在动作开始、发生接触、动作结束的位置,分别看:
- 原片是否确实拍到了这些过程?如果关键接触藏在遮挡后面,先换参考或缩小要求。
- 控制片是否还表达得出所需信息?骨架展示人体关键点,不承担墙体和管子的完整形状;深度保留空间轮廓,也不能替代精细道具说明。
- 缺的是信息,还是动作本身没出现?控制片已经缺掉的信息,应先回到参考与提取步骤;不要直接把修复任务交给生成提示词。
上述检查是应用建议。项目 README 的控制类型与限制 说明了信息分工:人物外观、衣服、灯光、颜色及细节道具,要靠文本或参考图另行提供。选择控制类型要围绕本镜头必须传递的内容,不能把“换成骨架”当作任何动作错误的统一解法。
控制片看着正常,怎样查生成入口接错了没有?
先确定自己走的是哪条接法。已有走廊演示是在 MiniMax H3 的 reference-to-video 模式下,把控制片作为 <Video 1>、人物定妆图作为 <Picture 1>;这与把视频接入 Fun ControlNet 的特定条件口,是不同接法。
按 0.5.0 使用文档,可以这样逐项核对已有工作流:
- 参考视频模式:确认本次实际附上的
<Video 1>是控制片,并在提示词中准确说明它是灰色深度片或 OpenPose 骨架片,以及哪些动作、位置和镜头需要参考;人物与画风另行描述。 - Fun ControlNet 模式:确认加载相应 Union 权重,控制视频与所选
depth、pose或canny条件相匹配。生成分辨率与控制片一致,或按节点支持的方式缩放,文档要求不要补边。 - 不要把
--target h3当成接入成功的证据:它选择输出预设,不会替使用者加载下游模型、连接条件口或执行动作验收。
若需要重新导出深度片,下面是文档和 CLI 支持的写法;先保证 reference.mp4 是要检查的输入,运行环境已安装 ReShot、ffmpeg 及所需依赖,且没有启用 fake 环境变量:
reshot reference.mp4 -o control_depth.mp4 --control depth --target h3 --backend vda --metrics control_metrics.json
产物是控制片 control_depth.mp4 和运行记录 control_metrics.json,二者用于核对本次预处理。命令结束后仍须做前述内容检查,再手动接入已经可运行的生成工作流。这条命令本身不生成成片。
为什么走廊案例的结构接近,蹬墙扯管子仍然漏了?
已有的深度版与骨架版对照图展示了参考片及两种控制方式的生成片。原始演示记录明确指出:参考片第二镜是蹬墙扯管子,两种参考生成的片段都直接进入了群殴,这一镜没有做到。
这项观察应保留到验收结论里。走廊还在、人物体量接近、后续镜头能对应,并不能抵消缺少关键动作的问题。读者可结合仓库的骨架演示视频和提示词目录逐段对照。
本地技术报告 marketing/papers/reshot-2026-10/reshot.tex 的结构测量章节解释了原因:指标比较深度空间中的人物布局、体量与镜头变化,不判定拳头是否打中或摔投是否执行正确。该报告基于同一参考片和一个生成模型,对照有限、seed 未匹配,不能从结构分数推出动作准确率,也不能推出骨架普遍优于深度。
对“蹬墙扯管子”这个目标,建议将验收拆成下面这张表,给已有片段逐项填写;它是人工检查模板,不是该案例新增测量结果。
| 必须看见的动作 | 原片位置 | 控制片是否可辨 | 成片是否出现 | 失败后先处理什么 |
|---|---|---|---|---|
| 脚与墙发生接触并蹬出 | 填起止时间 | 填是/否及观察 | 填是/否及观察 | 缺接触过程则回到参考;控制片有则核下游解释 |
| 手抓住管子 | 填起止时间 | 填是/否及观察 | 填是/否及观察 | 核手与道具是否表达清楚,补明确动作描述 |
| 管子脱离墙体 | 填起止时间 | 填是/否及观察 | 填是/否及观察 | 核道具状态变化;必要时拆成独立镜头 |
找到失败层之后,怎样决定下一步?
建议保留已通过部分的证据,只退回最早失败的位置:文件有问题先修文件;控制信息缺失先修参考;接法不符先修生成输入;前面都核过而动作仍漏,再调整动作表达或镜头方案。修改后仍用同一张动作表核看,避免换了目标却沿用原来的“通过”。
交付时把结论写具体,例如:“文件写出通过;控制片内容待核;生成入口待核;蹬墙扯管子未通过。”不要把四项压成一句“提取成功,所以流程成功”。这样下一位接手者能直接知道该查哪里,也能避免把已经存在的动作缺口带进最终成片。