3. 编解码器入门
好，咱们直接进入正题。上一章我们搭好了测试环境，现在该让两个编解码器真刀真枪地干一场了。
H.264 和 H.265，这两个名字你肯定不陌生。但说到它们对同步延迟的具体影响，很多人其实是一笔糊涂账。我见过不少项目，上来就选 H.265，觉得“新标准肯定更好”，结果延迟反而更高了。为什么会这样？咱们今天就把这个账算清楚。
3.1 核心差异：压缩效率的代价
先看一张表，把两个标准的核心参数摆出来：
| 对比维度 | H.264 (AVC) | H.265 (HEVC) |
|---|---|---|
| 编码标准发布时间 | 2003年 | 2013年 |
| 核心编码工具 | 16x16宏块、运动估计 | 64x64 CTU、帧内预测35种模式 |
| 同等画质下码率节省 | 基准 | 约30%-50% |
| 编码复杂度（相对） | 1x | 3x-5x |
| 解码复杂度（相对） | 1x | 1.5x-2x |
| 硬件加速普及度 | 极高（几乎所有设备） | 中高（近5年设备为主） |
看到没？H.265 的压缩效率确实高，但代价是编码复杂度翻了 3 到 5 倍。这个数字在同步场景里非常要命。
核心结论：压缩效率越高，编码耗时越长。在实时同步场景中，编码延迟是总延迟的重要组成部分。H.265 省下来的带宽，很可能被增加的编码延迟吃掉了。
3.2 编码延迟实测对比
我在项目中做过一组实测。用同一台机器（i7-12700 + NVIDIA RTX 3060），同样的 1080p 30fps 源视频，分别用 x264 和 x265 的 ultrafast preset 编码，记录单帧编码耗时。
结果是这样的：
| 编码器 | Preset | 平均单帧编码耗时 | 码率（同等画质） | 理论端到端延迟 |
|---|---|---|---|---|
| x264 | ultrafast | 2.1ms | 4.5 Mbps | 约 35ms |
| x265 | ultrafast | 8.7ms | 2.8 Mbps | 约 55ms |
| x264 | medium | 5.3ms | 3.2 Mbps | 约 45ms |
| x265 | medium | 22.4ms | 1.9 Mbps | 约 80ms |
注意看，同样是 ultrafast preset，H.265 的单帧编码耗时是 H.264 的 4 倍多。这意味着什么？
你想想看，如果一帧画面要花 8.7ms 才能编完，再加上网络传输、解码、渲染，端到端延迟很容易就超过 50ms。对于实时互动场景（比如视频会议、远程操控），50ms 已经是临界点了。
我的经验：在带宽充足（>5Mbps）的情况下，H.264 的延迟优势非常明显。H.265 更适合带宽受限（<2Mbps）但延迟容忍度较高的场景，比如直播推流。
3.3 同步延迟的构成分析
咱们把同步延迟拆开来看。一个完整的同步链路，延迟由这几部分组成：
- 采集延迟：摄像头/屏幕捕获，通常 5-15ms
- 编码延迟：帧内编码 + 帧间参考，这是变量最大的部分
- 网络传输延迟：RTT/2，取决于网络质量
- 解码延迟：解码器处理时间
- 渲染延迟：显示刷新、缓冲
其中，编码延迟和解码延迟是编解码器直接影响的。H.265 的编码延迟通常是 H.264 的 2-4 倍，解码延迟则是 1.5-2 倍。
我画了一张流程图，帮你直观理解这个延迟链路：
3.4 避坑指南：什么时候别用 H.265
我曾经在一个远程医疗项目中踩过坑。客户要求 1080p 60fps 的实时超声影像同步，我们一开始选了 H.265，觉得画质好、码率低。结果一测，端到端延迟飙到了 120ms，医生反馈操作有“滞后感”。
后来换成 H.264 ultrafast，延迟降到了 45ms，问题解决。说白了，在低延迟场景下，编码效率的优先级要低于编码速度。
避坑清单：
- 场景一：视频会议/远程操控 —— 优先 H.264，延迟敏感度 > 带宽敏感度
- 场景二：直播推流（非互动） —— 可以上 H.265，延迟容忍度较高
- 场景三：移动端弱网环境 —— H.265 有优势，但要注意解码兼容性
- 场景四：多路同步（如监控墙） —— H.264 更稳妥，解码负载更低
3.5 初步结论：选型不是非黑即白
嗯，到这里你应该明白了。H.264 和 H.265 的选择，本质上是在“延迟”和“带宽”之间做权衡。
我个人习惯的做法是：
- 先测网络带宽。如果上行带宽 > 5Mbps，无脑选 H.264。
- 如果带宽 < 2Mbps，再考虑 H.265，但必须用 ultrafast preset，并且接受 50ms 以上的延迟。
- 如果带宽在 2-5Mbps 之间，我会做 A/B 测试，看哪个延迟更符合业务要求。