渲染完还要自检：ffprobe、四点抽帧、音量分析与承诺核验

2026-08-09

多数视频工具的流程是这样的：渲染完成，进度条走到 100%，文件躺在输出目录里，剩下的事情归你——自己打开看一遍，发现前三秒是黑的再回去重跑。

OpenMontage 的 README 在 Production Governance 一节里把这一步也写进了流程。它列的五条质量闸中有一条专讲渲染之后：每次渲染后，运行时会跑 ffprobe 校验、在 4 个位置抽帧检查黑帧和坏掉的叠层、分析音量查静音和削波、核验交付承诺是否被兑现、检查字幕是否存在。这一条的收尾原文很硬：评审不通过，视频就不会被呈现。

也就是说，渲染成功不等于交付。文件生成出来之后还要再过一道，过不去，你根本看不到它。

五项自检各自盯着什么

先把这五项摊开，看清它们检查的对象其实分三类。

自检项	检查对象	README 写的关注点
ffprobe 校验	成品文件本身	对文件做探测校验
4 个位置抽帧	成品画面	黑帧、坏掉的叠层
音量分析	成品音轨	静音、削波
交付承诺核验	成品 vs 提案期立下的承诺	承诺是否被兑现
字幕存在性	附带产物	字幕是否存在

前三项是对着渲染出来的那个文件做探测——不看日志说渲染成功了没有，直接去看文件里到底有什么。第四项不一样，它是把成品拿回去对照提案阶段就定下并锁住的那份承诺。第五项最轻，只查在不在。

第五项这里值得多说半句：README 这条列的是「检查字幕是否存在」，字幕内容对不对、时间轴准不准，这条描述里没有涉及，对应的实现代码我们也没有读过。所以别把它当成字幕质量检查，它更接近一个「该有的东西有没有漏掉」的清点动作。

抽帧那一项在仓库里有对应的能力实体。README 的分析工具一组共四项：Frame Sampler（智能抽帧）、Transcriber（WhisperX 语音转文字，带词级时间戳）、Scene Detect（自动场景边界检测）、Video Understand（CLIP/BLIP-2 视觉语言分析）。渲染后自检说的「在 4 个位置抽帧」，对上的正是 Frame Sampler 这一项。另外，README 把后期制作那七件（FFmpeg、Video Stitch、Video Trimmer、Audio Mixer、Audio Enhance、Color Grade、Subtitle Gen）整组标为 always available, always free——一直可用、一直免费。需要说明的是，README 没有明说渲染后自检具体调用了哪几个工具，我们也没有读那部分代码，这里只是把两处名录对上。

渲染前已经拦过一道，为什么还要再查

看到这里很容易问一句：不是有渲染前的校验闸吗，为什么渲染完还要来一遍？

README 列的另一条质量闸是 Pre-compose validation，它在三种情况下阻断渲染：违反交付承诺时（README 举的例子是「动效主导」的视频里 80% 是静图）、幻灯片风险分为 critical 时、渲染器 family 缺失时。这一条的原文理由是在浪费 GPU 时间之前抓住坏掉的计划。

两道闸的差别就在这句话里：渲染前那道查的是计划，渲染后这道查的是文件。计划里写着这一段用生成视频，不代表渲染出来的那一段真的有画面在动；计划里排了字幕轨，不代表 SRT 真的被写出来了。前一道拦的是「方案本身就不成立」，后一道拦的是「方案成立但执行结果不对」。

有意思的是，交付承诺核验在这两道闸上各出现了一次。渲染前对着计划核一次，渲染后对着成品再核一次。这个重复不是冗余——两次核验的输入不是同一个东西。

顺带提一句 README 在源素材检查那条里的一句原文：No hallucinating content from filenames.（不许从文件名幻觉出内容。）那条说的是用户自带素材时要逐个探测文件，而不是靠文件名猜。渲染后自检做的是同一件事的另一头：不靠渲染流程的返回值猜成品好不好，直接探测成品文件。这个对称是我们的读法，README 没有把两条放在一起讲。

承诺核验这一项，落到源码里是什么

五项里最值得深挖的是承诺核验，因为它在 lib/delivery_promise.py 里有可核查的实体。

这个模块的 docstring 把设计意图写得很直接：它要防的最具破坏性的失败模式是——在用户不知情的情况下，从「动效主导」悄悄降级成「静图主导」。交付承诺在提案阶段设定并锁定；compose 阶段兑现不了时，系统必须停下来问，而不是悄悄替换。

承诺一共有八种类型，那张全表本批另有一篇专门拆，这里只引与渲染后核验直接相关的两行。八种里只有 motion_led 和 avatar_presenter 这两种把 still_fallback_allowed 设为 False，也正是这两种把 requires_video_generation 设为 True。motion_led 的 min_motion_ratio 是 0.7，源码那一行还带了条内联注释，说的是至少 70% 的镜头必须是真实动效——视频/动画，不是 Remotion 幻灯片。

为什么单挑这两行？因为渲染后自检里「承诺是否被兑现」这句话，在这两种承诺上才有牙齿。其余六种承诺允许静图回退，其中 data_explainer、teacher_explainer、screen_demo、localization 四种的 min_motion_ratio 干脆是 0.0——在规则层面完全允许零动效。你选了这四种之一，成品里全是静图也不构成违约。反过来，你在提案阶段选了 motion_led，那 0.7 就是一条写死在表里的数字，成品对不上它就是没兑现。

DeliveryPromise 这个数据类里还有几个默认值值得记住。from_dict() 的反序列化默认值是：tone_mode 默认 "corporate"（五个取值是 cinematic、educational、corporate、playful、raw），quality_floor 默认 "presentable"（三档是 draft、presentable、broadcast），approved_fallback 默认 None。

quality_floor 默认落在中间档而不是 broadcast，这一条对理解自检的性质挺关键：这道闸的合格线本来就不是「播出级」，而是配置里那个值。你想要更高的门槛，得自己在承诺里写清楚。

approved_fallback 那个字段更说明问题。它只有两个具名取值——"animatic"（动态分镜）和 "still_led"（静图主导）——否则就是 None。这就是「降级必须被显式批准」的实现方式：没有被批准的 fallback 就是 None。成品发生了降级、而 approved_fallback 仍停在 None，对应的正是 docstring 点名的那个失败模式。至于这两者在代码里由哪一步、哪个函数去对上，我们没有读到那段实现，这里不做描述。

模块里另有 get_rules() 和 validate_cuts(cuts) 两个方法，后者的 docstring 说它返回一个含 'valid'、'violations'、'motion_ratio' 三个键的 dict。它内部怎么算 motion_ratio、怎么判定一个 cut 算不算真实动效，我们没有读完那段代码，不做描述。

自检的结果去了哪里

自检跑完总要有产物。仓库 schemas/ 目录下我们实读数出 24 个 .json，其中 20 个是 artifact schema，名字里就有 render_report（渲染报告）、review 与 final_review（评审与终审）、decision_log（决策日志）。渲染与评审这条链上产生的结构化产物，在契约层面是有位置的。

必须把边界说死：这些 schema 的内部字段我们一个都没有读过，只能按文件名说明「存在这样一个 artifact 契约」，不能描述任何字段、必填项或校验规则。

与之呼应的是 README 的决策审计链路那节：provider 选择、风格选择、音乐曲目、音色选择、渲染器 family、任何回退或降级，都会连同考虑过的备选项、置信度分数和理由一起被记录，累积的决策日志跨所有阶段持久化。降级被记录，这件事和上面 approved_fallback 的设计是一条线上的。

还有一处细节可以佐证「为审计而保留冗余」这个取向。lib/slideshow_risk.py 里 render_runtime 参数的 docstring 明写：评分逻辑当前对运行时是中立的——文字很重的 HyperFrames 合成和文字很重的 Remotion 合成一样幻灯片化；但这个参数仍然是契约的一部分，好让调用方把 runtime 和 family 一起记录下来。一个当前不影响计算结果的参数被保留下来，理由是记录。

这道闸不替你保证什么

最后把话说回来。

上面所有内容都来自 README 文本和 lib/ 下几个模块的源码，我们没有安装或运行过这个系统，没有渲染过任何一条视频，也没有调用过任何一个 provider API。「评审不通过就不呈现」是仓库文档写的行为约定，不是我们验证过的运行结果。

同样地，README 里那些 “High quality”、“State-of-the-art quality”、“Cost-effective” 之类的描述，是 README 自己的措辞，不是我们的评价，也不构成选型建议。

再有几处边界：lib/slideshow_risk.py 内部那六个 _score_* 私有函数的打分逻辑我们没读过，所以「它怎么判定重复」这类问题这里给不出答案；幻灯片风险的 6 维、0-5 分与 2.0 / 3.0 / 4.0 四档判定本批另有一篇专讲。仓库里有流水线在 manifest 里自标 stability: beta，README 也把本地 LLM（Ollama / LM Studio）支持写作 “Coming soon”——那就是计划，不是现有功能。

有一件事倒是可以放心说：渲染后自检这套设计的价值，不在于它能保证成片好看，而在于它把「渲染成功」和「可以交付」这两件事拆开了。 前者是进程退出码，后者要过 ffprobe、四个抽帧点、音量、承诺和字幕这五关。你自己搭流水线的时候，就算不用这个项目，这个拆法也值得抄。

本文依据 OpenMontage 官方仓库（github.com/calesthio/OpenMontage）的 README、 AGENT_GUIDE.md、config.yaml、pipeline_defs/ 与 lib/ 下的治理模块整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装或运行过该系统，也没有调用过其中任何一个 provider API，文中出现的成本数字均为项目方在 README 中自行标注的金额，非我们的实测结果。该项目以 AGPL-3.0 发布，部分流水线在 manifest 中自标 stability: beta，请以仓库最新内容为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。安全相关做法请结合自身环境评估，本文不构成安全方案建议。