客户要一份"母版"，我给了高码率 MP4 被退回来：中间编码与母版格式

有次交付，客户要"一份母版"，我心想"母版就是质量最高的版本呗"，于是出了个 CRF 18 的 H.264 MP4。

对方回复很客气："这个不是母版，我们要 ProRes 422 的 MOV。"

我当时不太理解——CRF 18 的 H.264 画质已经很好了，为什么非要 ProRes？后来搞明白："母版"不是"画质最高的分发版"，它的核心要求是"便于后续再处理"：

• 全帧内编码（每一帧都是关键帧）→ 剪辑软件拖动、切帧、倒放都很快；
• 色彩和位深保留（10bit、4:2:2）→ 留给调色的余地；
• 多代复制不易劣化 → 经过几次转手还能用。

H.264 是长 GOP 编码（每 250 帧才一个关键帧），剪辑软件处理它要解码一大串帧——又慢又容易出问题。所以即使画质再高，它也不是母版。

这篇写清楚这件事，以及 ffmpeg 里怎么做。

TL;DR：编码分三类：采集/相机原始（RAW）、中间/母版（ProRes、DNxHR、CineForm、FFV1）、分发（H.264/H.265/AV1）。中间编码的特点是全帧内（all-intra）+ 10bit + 4:2:2，体积大（1080p ProRes 422 HQ 约 220 Mbps，1 小时 ≈ 100 GB）但剪辑友好。ffmpeg 里：-c:v prores_ks -profile:v 3 -pix_fmt yuv422p10le（3 = 422 HQ）、-c:v dnxhd -profile:v dnxhr_hq -pix_fmt yuv422p10le、无损归档用 -c:v ffv1 -level 3 -g 1（配 MKV）。判断标准很简单：这份文件之后还要不要进剪辑/调色？要 → 中间编码；不要 → 直接出分发版。

目录

• 一、三类编码的分工
• 二、主流中间编码对比
• 三、ProRes 家族
• 四、ffmpeg 做 ProRes
• 五、DNxHR（Avid 生态）
• 六、FFV1：开源无损，长期归档首选
• 七、帧序列：VFX 与调色交接
• 八、什么时候根本不需要母版
• 九、体积与成本
• 十、坑清单

一、三类编码的分工

中间编码的核心特征：全帧内（All-Intra）

分发编码（长 GOP）：
I B B P B B P B B P ... I B B P ...
                                  ↑ 250 帧后才有下一个关键帧

中间编码（全帧内）：
I I I I I I I I I I I I I I ...
                  ↑ 每一帧都是独立可解码的

为什么这对剪辑重要：

剪辑软件要显示第 1000 帧，长 GOP 需要先解码前面的所有帧（因为 P/B 帧依赖参考帧）；全帧内只需要解码那一帧。拖动时间线、渲染预览、导出片段的速度差异是数量级的。

另一个关键点：长 GOP 编码经过多次"解码→再编码"（多代复制）会累积质量损失；全帧内的每一代损失小得多。

二、主流中间编码对比

我的默认选择：

• 给剪辑/调色 → ProRes 422 HQ（最通用）；
• Avid 生态 → DNxHR HQ/HQX；
• 长期归档（自己存） → FFV1 + MKV（开源、无损、不依赖厂商）；
• VFX / 特效交接 → EXR 序列。

三、ProRes 家族

选择建议：

• 普通母版：422 HQ（质量足够，体积可接受）；
• 要做抠像/合成：4444（带 alpha）；
• 只需代理剪辑：Proxy 或 LT；
• 素材量特别大、存储紧张：422（不是 HQ）通常也够。

4:2:2 vs 4:2:0 对母版的意义：

色度采样越高，调色（尤其是抠像、绿幕）的余地越大。4:2:2 是母版的下限——用 4:2:0 做母版，调色时容易出现色度断层。

四、ffmpeg 做 ProRes

ffmpeg -i input.mp4 \
  -c:v prores_ks -profile:v 3 \
  -pix_fmt yuv422p10le \
  -c:a pcm_s16le -ar 48000 \
  -vendor apl0 \
  output.mov

参数说明：

容器用 MOV（ProRes 的标准容器，QuickTime 兼容）。

带 Alpha 通道：

ffmpeg -i rgba_source.mov \
  -c:v prores_ks -profile:v 4 -pix_fmt yuva444p10le \
  output_alpha.mov

检查输出：

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,profile,pix_fmt,bit_rate -of default=noprint_wrappers=1 \
  output.mov
# codec_name=prores
# profile=422 HQ          ← (ffmpeg 可能显示 High/Standard 等，看版本)
# pix_fmt=yuv422p10le
# bit_rate=220000000

注意：ffmpeg 的 ProRes 实现是逆向工程 + 社区实现，编码质量与 Apple 官方编码器"几乎一致"但非完全相同。对绝大多数流程没问题，但如果客户是严格的广播交付（要过 QC），最好用官方工具（比如 Apple 的 Compressor 或者在 macOS 上用 ffmpeg 的 prores_aw? 实际上更推荐用 Resolve 导出）。

五、DNxHR（Avid 生态）

ffmpeg -i input.mp4 \
  -c:v dnxhd -profile:v dnxhr_hq \
  -pix_fmt yuv422p10le \
  -c:a pcm_s16le \
  output.mov

DNxHR 的 profile：

DNxHD vs DNxHR：DNxHD 是老版本（只支持特定分辨率/帧率），DNxHR 是新版本（支持任意分辨率，含 4K）。现在都用 DNxHR。

（老）DNxHD 的限制：只对特定的"分辨率+帧率+码率"组合有效，不在列表里会报：

ERROR: video parameters incompatible with DNxHD

DNxHR 也有分辨率要求：有最小分辨率限制（我记得 LB/SQ 有最小宽度要求），4K 以上要用 HQX/444。如果报错，试试换 profile。

六、FFV1：开源无损，长期归档首选

FFV1（FF Video Codec 1） 是 FFmpeg 社区开发的数学无损编码器，被很多图书馆、档案馆采用（因为它是开放标准、无专利、有完整文档）。

ffmpeg -i input.mov \
  -c:v ffv1 -level 3 -coder 1 -context 1 -g 1 -slices 4 -slicecrc 1 \
  -c:a flac \
  output.mkv

容器用 MKV（FFV1 的推荐容器，Matroska 对 FFV1 支持最完善）。

为什么归档用它：

1. 数学无损——解出来跟原始像素完全一致，不存在"画质损失"；
2. 开放标准——不依赖任何厂商，20 年后还能解码（这是档案馆最看重的）；
3. 有 CRC——能检测数据损坏（配合定期校验）；
4. 无专利风险。

代价：体积非常大（1080p 大约 300~600 Mbps，1 小时 150~270 GB）。所以它只适合"珍贵内容的长期保存"，不适合日常。

我们的用法：客户的珍贵母版（老录像数字化成果）存一份 FFV1 + MKV 进冷存储，日常用的是 ProRes（剪辑）和 H.264（分发）。

七、帧序列：VFX 与调色交接

什么时候用帧序列（DPX / EXR / PNG / TIFF）：

• VFX 合成（每帧要单独处理）；
• 调色交接（某些流程）；
• 需要最大灵活性的场合。

# 导出 DPX 序列
ffmpeg -i input.mov -pix_fmt rgb48le -start_number 1001 out_%06d.dpx

# 导出 EXR（需要编译支持）
ffmpeg -i input.mov -c:v exr -pix_fmt rgb48le out_%06d.exr

# 序列导入
ffmpeg -framerate 25 -start_number 1001 -i out_%06d.dpx -c:v prores_ks -profile:v 3 out.mov

-start_number 1001：帧序列的起始编号通常用 1001（行业习惯，给前面留空间）。

帧序列的缺点：

• 文件数量巨大（1 小时视频 = 90000 个文件）——文件系统压力很大；
• 没有音频（要单独存）；
• 管理麻烦。

所以除非流程要求，一般不用。

八、什么时候根本不需要母版

这是最容易被忽略的判断：不是所有项目都需要母版。

需要母版：

• ✅ 后续还要剪辑、调色、加特效；
• ✅ 要出多个分发版本（不同平台、不同语言）；
• ✅ 珍贵内容要长期归档；
• ✅ 客户明确要求（要进他们的媒资系统）。

不需要母版：

• ❌ 一次性的交付（比如活动快剪，交了就完事）；
• ❌ 源本身质量就一般（低分辨率的老素材，做母版没有意义）；
• ❌ 存储预算有限且没有后续处理需求；
• ❌ 客户只是要"能在微信里发的版本"。

我的判断问题："这个文件交出去之后，还会有第二次处理吗？"

• 有 → 母版（ProRes/DNxHR，或者至少保留一份高码率的中间文件）；
• 没有 → 直接出分发版。

成本意识：一个 1 小时的 ProRes 422 HQ 母版是 100 GB。如果客户的项目有 50 小时素材，就是 5 TB——这个成本要在报价里体现，而不是默默承担。

九、体积与成本

实测（1080p25，1 小时内容）：

4K 内容乘 4 倍。

所以"母版"的成本主要是存储。我们的策略：

1. 母版只在项目进行期间保留（热存储）；
2. 项目结束后归档到冷存储（对象存储低频层，成本 1/5）；
3. 或者只保留分发版 + 一份 ProRes 422（不是 HQ）。

给客户的话术："母版 ProRes 422 HQ，1 小时约 100 GB。如果您只需要 1080p 分发版，我们可以只保留分发版和一份 422（66 GB/小时），需要时再出高清版本。"

十、坑清单

1. 用高码率 H.264 当母版 → 长 GOP，剪辑软件处理慢且容易出问题。用全帧内编码。
2. 母版用 4:2:0 → 调色时色度不足。至少 4:2:2。
3. 母版音轨用 AAC → 有损。用 PCM（pcm_s16le）或 FLAC。
4. profile 编号记错 → ProRes 的 0~5 对应不同质量，选错了要么太大要么质量不够。422 HQ = 3。
5. 像素格式没指定 → ProRes 422 需要 yuv422p10le，不指定的话 ffmpeg 可能选错或者报错。
6. DNxHR 分辨率/帧率不支持 → 报错，换 profile（老 DNxHD 限制更多）。
7. 带 alpha 却用了不支持的 profile → 4444 才支持 alpha，且 pix_fmt 要 yuva444p10le。
8. 容器用 MP4 装 ProRes → 虽然技术上可以，但行业惯例是 MOV，很多软件只认 MOV。用 MOV。
9. FFV1 用 MP4 容器 → 支持不好。用 MKV。
10. 没算存储成本 → 100 GB/小时，50 小时就是 5 TB。报价前先算。
11. 所有项目都做母版 → 浪费。先问"后续还要处理吗"。
12. 母版和分发版混淆 → 交付时文件名要区分（_master.mov / _web.mp4）。
13. 母版没保留原始时间码 → 回批时对不上。用 -timecode 保留。
14. 跨代复制损失 → 即使是全帧内，多次解码再编码也会累积损失。保留一份"最初的母版"不动。
15. 归档格式没有校验 → FFV1 的 -slicecrc 1 能检测损坏，配合定期校验（前面备份那篇讲过演练）。
16. 以为 ProRes 是"无损" → 它是视觉无损的有损压缩。真无损要 FFV1 或帧序列。

最后说说这次被"退回来"的收获。

技术上的收获当然是懂得了中间编码的存在和用途。但更有价值的是理解了"交付物的定义权在需求方"这件事。

我当时以为"母版 = 质量最高的版本"，这是一个纯粹从技术参数出发的理解。但对方要母版不是为了"看"，是为了"再加工"——这个用途决定了它必须是全帧内、必须是 10bit 4:2:2、必须用 MOV 容器。

一个交付物的正确形态，由"它接下来要经历什么"决定，而不是由"它的质量指标有多高"决定。

这个教训在其他地方也适用：

• 给印刷的图片要 CMYK + 300dpi，不是"看起来清楚就行"；
• 给开发的数据要 JSON/CSV 结构清晰，不是"人能看懂就行"；
• 给剪辑的素材要全帧内，不是"画质高就行"。

所以现在遇到交付需求，我的第一个问题总是："这份文件交出去之后，对方要拿它做什么？" 答案决定了格式、参数、容器、甚至文件命名——比任何"最佳实践"都更准确。