一条 AI 短片改过几个镜头后，目录里往往同时出现 final_v9.mp4、final_v10.mp4、若干 shot02 候选和一份字幕。过几天有人问："v10 究竟用了哪六段？字幕跟的是哪版？现在能不能重新导出相同成片？"仅凭文件名和一条最终 MP4，通常答不完整。知道成片能播放 、知道选了哪些输入 、能重新执行并验收，是三个不同层次。
本文使用同一条六镜头短片的 v9/v10 拼接清单、v10 字幕和最终 MP4 做一次实际对账。v10 六个源镜头合计 622 帧 ，成片实际解码 623 帧 ，字幕最后结束于 25.916 秒 。我们记录源文件顺序、完整 SHA-256、逐文件帧数与输出身份，同时明确：当时完整导出命令、编码参数和执行日志未留存，因此这份历史成片可以复盘输入与输出，不能声称已经按字节复建成功。
这里公开的是脱敏的镜头编号和核对方法，不包含内部服务地址、完整工程路径、模型权重或提示词。示例环境为 Python 3、OpenCV 与 24 帧/秒的固定帧率 MP4；可变帧率、多音轨或跨机器构建须额外记录时间基和流映射。
目录
- "可追溯"和"可复建"差在哪里
- 先锁定六个输入，不能只相信文件名
- 把字幕、源片和最终成片做时间线对账
- 用代码生成可核验的交付记录
- 缺了导出日志，就不要宣称完全复建
- 失败路径和发布前验收
- 怎样把这次经验变成下一版的交付规范
一、"可追溯"和"可复建"差在哪里
假设今天只收到 final_v10.mp4。播放器能打开，最多证明当前文件可读；它不告诉我们源镜头的版本、是否后来被覆盖、字幕是否与本版同步。如果还保留一份拼接清单，就能知道计划选用的镜头顺序；但如果清单里的同名文件曾经被替换，光有路径仍不足以识别当时的字节内容。
因此交付至少应区分四种证据：
| 证据 | 回答什么 | 缺失后的后果 |
|---|---|---|
| 有序输入清单 | 六段分别选哪个候选、按什么顺序 | 找不到版本差异，接缝也难回查 |
| 文件完整哈希和媒体信息 | 现在的源文件是否仍是那份字节内容，帧数/尺寸/帧率如何 | 同名覆盖不易发现，无法做输入身份校验 |
| 字幕版本与时间线 | 这六条字幕从哪一刻到哪一刻，是否越过成片结尾 | 镜头缩短后字幕可能仍沿用旧时间码 |
| 导出命令、环境和日志 | 当时如何解码、拼接、编码、映射音轨，是否成功退出 | 只能复盘部分事实，不能宣称可复建 |
这四类材料也不能代替内容审片。哈希相同能说明文件字节相同，不能说明兔子的动作已经合理；帧数一致能说明结构接近，不能说明字幕压住人物或旁白提前没有发生。本文把文件身份 、技术验收 和观看验收分开记。
图1：源镜头、字幕、导出过程与最终文件要分别留证；只保存 final.mp4 无法回答后续复盘问题。
二、先锁定六个输入，不能只相信文件名
把 v9、v10 两份六段拼接清单按镜头编号比较，第 02、05、06 段换了候选 ，第 01、03、04 段清单中的候选名称未变。这里说的是"清单名称未变"，不是断言它们的历史文件字节绝对没变；要证明后者，需要 v9 当时保存的完整哈希。现有素材只足够核对当前 v10 所指向的六个文件。
| 镜头 | v10 源片实际解码帧数 | 当前文件 SHA-256 前 12 位 | v9→v10 清单变化 |
|---|---|---|---|
| 01 | 54 | aadf5d754477 |
候选名称未变 |
| 02 | 72 | 7abe469de87b |
长尾候选换成短版 |
| 03 | 124 | 30d3ac6b6dc6 |
候选名称未变 |
| 04 | 124 | c8e16825409f |
候选名称未变 |
| 05 | 124 | d031a79c8f91 |
换成荒田候选 |
| 06 | 124 | c5243425b62b |
换成荒田候选 |
图里把六个实际选用文件的首帧 放在一起，方便人工核对选片。缩略图和哈希前缀只是便于阅读；程序校验必须比对完整 SHA-256。文件名可以改、也可以被覆盖，哈希是当前字节内容的标识。若记录中只留了"镜头 05 选荒田版"，没有完整哈希，就无法防止日后同名文件被悄悄替换。Python hashlib 文档给出了文件摘要的标准做法。
案例图1：六段源镜头的首帧、实际帧数和哈希前缀。图不包含完整路径；完整哈希保留在机器核对记录中。
"把清单直接存一份"还要注意一个技术细节：FFmpeg concat 文本中的 file 行是有顺序 的，后一个文件的时间戳接在前一个文件之后。FFmpeg concat demuxer 文档还要求输入流兼容，并说明文件时长不准会影响后续时间戳。因此清单不仅是资产目录，也是时间线输入；编辑、导出和后续审计必须引用同一版冻结清单。
图2：v10 清单更换 02、05、06 三段；"候选名没变"不能替代对历史文件内容的哈希证明。
三、把字幕、源片和最终成片做时间线对账
v10 六个源文件都是 448×768、24 帧/秒；实际解码帧数依次为 54、72、124、124、124、124，合计 622 帧 。按固定帧率计算，源片累计时间界点依次为 2.250、5.250、10.417、15.583、20.750、25.917 秒 。六条 SRT 的结束时间依次是 2.249、5.249、10.416、15.583、20.749、25.916 秒 。可见这份字幕在计划源片时间线上基本贴着每段末尾安排，最后也没有超出成片。
但最终 MP4 实际解码 623 帧 ，比六段源片之和多一帧。不能据此武断地说"第 06 段多了一帧"或"FFmpeg 一定重复了尾帧"。多出的帧可能与拼接、时间戳或编码处理有关；要查具体位置，应回到历史导出命令、日志与最终文件逐帧时间戳。现有材料只证明总数差 +1，不足以定位原因。
案例图2：源片帧区间从 0 开始计数，字幕结束时间与源片累计边界相邻。最终导出多一帧，图中的源片边界不能冒充成片精确切点。
这种对账有实际用途：换短第 02 段时，后面所有字幕的绝对时间都要重新计算；但只看字幕最后一条没有越界，也不能保证每条旁白在对应动作上。技术检查应该输出"字幕区间合法、未超出成片"，观看检查则要回放每段首尾和旁白接点。
图3：源片帧数之和、SRT 时间线与最终解码帧数是三种口径；一帧差异必须保留为待定位事实。
四、用代码生成可核验的交付记录
检查器需要做的不是"猜这个 MP4 是怎么来的"，而是把当前能直接观测到的东西 固定下来。下面保留核心逻辑：解析有序拼接清单，对每个源文件计算完整 SHA-256 并逐帧解码，最后单独核对字幕和输出。使用 shlex.split 是为了正确处理带空格或引号的 file 行；这份示例清单只用 file 指令，遇到 inpoint、duration 等其他 concat 指令要显式扩展解析，不能悄悄忽略。
python
import hashlib
import shlex
from pathlib import Path
import cv2
def selected_files(concat_text):
files = []
for raw in concat_text.splitlines():
line = raw.strip()
if not line or line.startswith("#"):
continue
parts = shlex.split(line)
if len(parts) != 2 or parts[0] != "file":
raise ValueError(f"不支持的清单指令: {line}")
files.append(Path(parts[1]))
if not files:
raise ValueError("没有选用文件")
return files
def file_sha256(path):
with path.open("rb") as stream:
return hashlib.file_digest(stream, "sha256").hexdigest()
def decoded_frames(path):
cap = cv2.VideoCapture(str(path))
if not cap.isOpened():
raise ValueError(f"文件无法打开: {path.name}")
count = 0
try:
while True:
ok, _frame = cap.read()
if not ok:
break
count += 1
finally:
cap.release()
if count == 0:
raise ValueError(f"视频没有可解码帧: {path.name}")
return count
def input_records(concat_text):
return [
{"shot": f"{index:02d}", "frames": decoded_frames(path),
"sha256": file_sha256(path)}
for index, path in enumerate(selected_files(concat_text), start=1)
]
records = input_records(Path("selected_v10.txt").read_text(encoding="utf-8"))
assert [r["frames"] for r in records] == [54, 72, 124, 124, 124, 124]
assert sum(r["frames"] for r in records) == 622上面的 selected_v10.txt 是示例文件名，运行时要指向自己的本地清单。生产脚本还应把文件尺寸、帧率、像素尺寸、字幕完整哈希和最终 MP4 完整哈希一起写入 JSON；公开文章可以只展示哈希前缀，真正比较时绝不能截断哈希 。本例最终 MP4 的 SHA-256 前 12 位是 9e68044563be，完整值在本地核对报告中。一个文件即使名字没变，只要内容改了，摘要就会不同。
用机器可读记录还有一个好处：下次谁说"只改了字幕"，可以把新旧两份记录逐项比较。若镜头哈希也变了，那就不是"只改字幕"；若输入哈希没变而输出不同，应继续查导出参数、工具版本和编码器。这种对比比人工盯着 final_最新版_最终.mp4 的名字可靠得多。
保存上一版核对 JSON 后，下次发布前逐项比对完整摘要。相同文件名而内容变化，应被视为新版本输入，不能沿用旧版验收结论：
python
def require_same_inputs(previous, current):
old, new = previous["inputs"], current["inputs"]
if len(old) != len(new):
raise ValueError("镜头数量变化")
for before, after in zip(old, new):
if before["shot"] != after["shot"] or before["sha256"] != after["sha256"]:
raise ValueError(f"镜头 {after['shot']} 的内容或顺序已变化")
old = {"inputs": [{"shot": "01", "sha256": "old-full-hash"}]}
changed = {"inputs": [{"shot": "01", "sha256": "new-full-hash"}]}
try:
require_same_inputs(old, changed)
except ValueError:
print("拒绝沿用旧版验收")上面两个哈希字符串只是测试占位；真实报告里应是完整 64 位 SHA-256，而不是图中的 12 位预览。输入确实发生变更时，正确做法是生成新版本记录、重跑时间线与内容验收，不是把变化视作脚本错误后强行放行。
五、缺了导出日志，就不要宣称完全复建
当前核对能回答："现在的 v10 清单指向哪六个文件、它们的哈希是什么、源帧数之和多少、字幕区间如何、现有成片身份是什么。"它不能回答："当时用的精确导出命令、编码器选项、流映射、滤镜顺序、工具版本是什么。"尤其短片中可能还经过字幕烧录、音轨合成与最终编码；源文件清单只是其中一步。
建议以后把交付记录分两部分：
json
{
"version": "v10",
"inputs": "有序的镜头编号、完整 SHA-256 和媒体信息",
"subtitles": "字幕文件完整 SHA-256 和时间范围",
"build": {
"command": null,
"tool_versions": null,
"encoder_options": null,
"exit_code": null
},
"output": "最终 MP4 的完整 SHA-256 和验收结果",
"historical_rebuild_proven": false
}这里的 null 不是待填的漂亮模板，而是本案例历史记录确实缺失 的过程字段。未来版本应在任务执行时自动记录实值，包括命令参数、使用的软件/模型版本、输入哈希、日志和返回码；若生成环节依赖随机性，还要记录种子与模型权重身份。即便这些齐全，不同机器、GPU 或编码器版本也未必得到逐字节相同的 MP4；此时应分开定义"字节复建"和"画面内容、时序、音轨等价验收"，不要用一个模糊的"可复现"掩盖差异。
六、失败路径和发布前验收
核对脚本不能只对一套成功文件打印 JSON。至少要有以下拒绝路径：源文件丢失、同名文件被覆盖导致完整哈希不符、字幕编号或区间错误、字幕尾部越过成片、输出无法解码、导出进程失败但临时 MP4 仍留在目录。测试要验证这些情况下不会把任务标成"已交付"。
字幕检查可从最小的一条断言做起：时间码先转毫秒，再拒绝倒序和重叠。下面两个输入分别应通过、失败；换成自己的视频还要核对最后一条结束时间是否在实际成片时长之内。
python
def check_cues(cues):
previous_end = -1
for start_ms, end_ms in cues:
if start_ms < previous_end or start_ms >= end_ms:
raise ValueError("字幕重叠或区间倒置")
previous_end = end_ms
return previous_end
assert check_cues([(0, 2249), (2250, 5249)]) == 5249
try:
check_cues([(0, 2249), (2200, 5249)])
except ValueError:
pass
else:
raise AssertionError("重叠字幕必须被拒绝")完整核对还要把以下四类结果分开记录，而不是笼统返回 pass=true：
| 检查项 | v10 这次的实测或状态 | 能否直接通过 |
|---|---|---|
| 六个源文件可读、帧率和尺寸一致 | 均为 24 fps、448×768；合计 622 帧 | 当前文件结构可核对 |
| SRT 六条时间区间 | 首条从 0 开始，末条结束于 25.916 秒 | 时间范围合法；仍需试听 |
| 最终 MP4 | 实际解码 623 帧，SHA-256 已记录 | 文件身份可核对；+1 帧待定位 |
| 历史导出命令与日志 | 未完整保存 | 不能宣称历史成片已复建 |
对 v10 源文件从第 01 到第 06 段逐个抽首尾帧，再回放每个接缝和字幕/声音的相邻几秒，才能补上观看验收。生成模型的输出可以作为素材，最终交付仍是一条带时间轴、声音、字幕和版本身份的媒体文件；"技术上文件有效"和"观众看得明白"不能合成一项勾选。
图4：缺源文件、哈希不符、字幕越界或导出失败都必须阻止交付登记；内容审片另行记录。
七、怎样把这次经验变成下一版的交付规范
这次复盘得到一个明确结论：v10 当前输入和输出可追溯，历史导出过程不可完整复建。一帧差异也应如实留在问题单，而不是因为只有约 42 毫秒就删掉记录。以后每次替换镜头，可以按以下顺序形成交付包：先冻结有序选片清单和字幕，记录每份完整哈希；执行时保存命令、参数、版本、日志和退出码；写临时输出，检查解码帧数、时长、音轨、字幕范围；人工抽查接缝与动作；全部通过后再登记正式成片及其哈希。
这样做的收益不是"让所有 AI 视频永远零错误"，而是下次发生问题时，能分清是源素材被换、字幕沿用旧版、拼接时间戳变了、编码失败，还是镜头本身就没讲清故事。每一层都有对应证据，返工才有方向。
图5：本例已有输入和输出身份，但没有完整历史导出过程；下一版要在任务运行时自动留下这些字段。
参考资料：FFmpeg concat demuxer 文档、FFprobe 逐流/逐帧检查说明、Python hashlib 文件摘要。