2. 转码基础

做转码优化，第一件事不是调参数，而是搞清楚——时间到底花在哪了。

很多人一上来就盯着编码器猛调，觉得编码最慢。其实不一定。我见过太多案例，瓶颈根本不在编码，而在某个不起眼的前置环节。今天咱们就把这条流水线拆开，一个一个看。

2.1 标准转码流水线长什么样？

一条典型的转码链路，大致分五步：

1. 解封装（Demux）——从容器里把音视频流拆出来
2. 解码（Decode）——把压缩数据还原成原始图像/音频
3. 滤镜（Filter）——缩放、裁剪、叠加、调色等处理
4. 编码（Encode）——把原始数据重新压缩
5. 封装（Mux）——把编码后的流写回容器

听起来很简单对吧？但实际跑起来，每个环节的耗时差异巨大。

2.2 逐个环节分析：谁在拖后腿？

解封装 —— 几乎不耗时

解封装说白了就是读文件头、解析索引、把数据包分发给对应的解码器。这个过程基本是内存操作，CPU 开销极低。我做过测试，一个 4K 的 MP4 文件，解封装耗时通常不到总时间的 1%。

除非你遇到极端情况——比如网络流反复重连、或者容器格式极其奇葩（某些老旧 AVI），否则解封装不会是瓶颈。

解码 —— 看情况

解码的耗时取决于输入编码格式和硬件。

• H.264 软解：现代 CPU 基本能轻松应付 1080p，但 4K 就吃力了。
• H.265/VP9 软解：计算量翻倍，4K 软解能吃掉 4~6 个核。
• 硬件解码：GPU/ASIC 解码几乎不占 CPU，延迟极低。

我记得有一次优化一个直播转码服务，发现 CPU 跑满但编码器空闲。查了半天，原来是输入流是 4K H.265，软解把资源全吃光了。换成硬解后，整体延迟直接降了 60%。

滤镜 —— 最容易被低估的“时间黑洞”

滤镜这个环节，我愿称之为转码流水线里的“刺客”。它看起来不起眼，但一旦复杂起来，能把整个链路拖垮。

举个例子：

• 单纯缩放（scale）—— 很快，GPU 上一行代码的事。
• 缩放 + 裁剪 + 叠加水印 + 帧率转换 + 色彩空间转换 —— 这就开始吃资源了。
• 如果再加入人脸模糊、动态字幕、多路拼接……嗯，滤镜耗时可能超过编码。

我曾经接手过一个项目，转码一小时的视频要花两小时。排查后发现，滤镜链里有一个 fps=30 的重复帧插入操作，配合一个低效的 lut 滤镜，直接把 CPU 干到 100%。去掉这两个冗余滤镜后，耗时降到 40 分钟。

编码 —— 传统意义上的“老大难”

编码确实是整个流水线里计算量最大的环节。尤其是软编码：

编码器	速度预设	相对耗时（1080p）	典型场景
x264	ultrafast	1x	直播、低延迟
x264	medium	3~4x	点播、平衡
x264	veryslow	10~15x	存档、高压缩
x265	medium	8~12x	4K HDR 点播
NVENC/NVDEC	硬件固定	0.2~0.5x	实时转码

你看，同样是编码，预设不同，耗时差十几倍。所以编码是不是瓶颈，取决于你选了什么预设、用了什么硬件。

封装 —— 几乎可以忽略

封装和解封装一样，主要是写文件头、整理时间戳、生成索引。耗时占比通常 0.5% 以下。除非你写的是极其复杂的容器（比如 MKV 带多字幕多音轨），否则不用操心。

2.3 一张图看懂整条流水线的延迟分布

下面这张图，是我根据大量实测数据总结的典型延迟分布。注意，这是“典型”情况，不是绝对。

2.4 到底哪个环节最拖后腿？

直接给结论：

• 如果滤镜链简单（缩放+裁剪）：编码是最大瓶颈，占比 60%~80%。
• 如果滤镜链复杂（多路叠加、AI 滤镜、逐帧处理）：滤镜反超编码，成为第一瓶颈。
• 如果输入是 4K H.265 且只用软解：解码可能吃掉 40% 以上的 CPU，成为隐性瓶颈。
• 解封装和封装：基本不用管，除非你遇到 IO 瓶颈（比如从极慢的 NAS 读文件）。

2.5 实战建议：如何快速定位瓶颈？

别猜，直接测。我常用的方法：

1. 用 ffmpeg -benchmark 跑一次全链路，看每个阶段的耗时。
2. 分段测试：分别测“解码+滤镜”、“纯编码”、“纯解封装”的耗时。
3. 观察 CPU/GPU 利用率：如果某个核心跑满而其他核心空闲，那就是瓶颈。
4. 用 perf 或 Intel VTune 做更细粒度的热点分析。

嗯，说白了就是——数据说话。别凭感觉猜哪个环节慢，测出来才知道。