3、H.264 vs H.265：编码效率与同步延迟的初步对比

好，咱们直接进入正题。上一章我们搭好了测试环境，现在该让两个编解码器真刀真枪地干一场了。

H.264 和 H.265，这两个名字你肯定不陌生。但说到它们对同步延迟的具体影响，很多人其实是一笔糊涂账。我见过不少项目，上来就选 H.265，觉得“新标准肯定更好”，结果延迟反而更高了。为什么会这样？咱们今天就把这个账算清楚。

先看一张表，把两个标准的核心参数摆出来：

看到没？H.265 的压缩效率确实高，但代价是编码复杂度翻了 3 到 5 倍。这个数字在同步场景里非常要命。

核心结论：压缩效率越高，编码耗时越长。在实时同步场景中，编码延迟是总延迟的重要组成部分。H.265 省下来的带宽，很可能被增加的编码延迟吃掉了。

我在项目中做过一组实测。用同一台机器（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）但延迟容忍度较高的场景，比如直播推流。

咱们把同步延迟拆开来看。一个完整的同步链路，延迟由这几部分组成：

其中，编码延迟和解码延迟是编解码器直接影响的。H.265 的编码延迟通常是 H.264 的 2-4 倍，解码延迟则是 1.5-2 倍。

我画了一张流程图，帮你直观理解这个延迟链路：

我曾经在一个远程医疗项目中踩过坑。客户要求 1080p 60fps 的实时超声影像同步，我们一开始选了 H.265，觉得画质好、码率低。结果一测，端到端延迟飙到了 120ms，医生反馈操作有“滞后感”。

后来换成 H.264 ultrafast，延迟降到了 45ms，问题解决。说白了，在低延迟场景下，编码效率的优先级要低于编码速度。

避坑清单：

嗯，到这里你应该明白了。H.264 和 H.265 的选择，本质上是在“延迟”和“带宽”之间做权衡。

我个人习惯的做法是：