1. 实时通信中的视频传输挑战：带宽波动、延迟约束与丢包问题概述
各位好，我是老周。做实时通信视频编码这块有些年头了。今天咱们开始聊 H.265 在实时通信里的丢包恢复，但得先把底层的挑战说清楚。你想想看，视频在网络上跑，跟你在本地播放完全是两码事。本地播放，文件就在硬盘上，随便读。但实时通信呢？数据要从发送端一路颠簸到接收端，中间要过多少路由器、交换机，谁也说不准。
我个人习惯，在讲具体技术之前，先把问题域画清楚。实时通信的视频传输，说白了就三个大坑：带宽波动、延迟约束、丢包。这三个东西互相纠缠，一个处理不好，视频就卡成幻灯片，或者直接花屏。
1.1 带宽波动：网络不是一根恒定的水管
很多人以为带宽是固定的。其实不是。我在项目中遇到过好几次，明明测试环境带宽跑满 10Mbps，一上公网，瞬间掉到 500Kbps。为什么会这样？因为网络是共享的。你旁边的人在看 4K 视频，你的带宽就被挤了。移动网络更夸张，你从客厅走到阳台，信号弱一格，带宽直接腰斩。
带宽波动对视频编码的影响非常大。编码器得实时调整码率。码率调高了，网络扛不住，丢包；调低了，画面模糊，用户骂娘。H.265 虽然压缩率高，但它的编码单元更大、参考帧更多，一旦码率控制没跟上，后果比 H.264 更严重。
核心矛盾：编码器输出的码率曲线，必须跟网络带宽的实时变化曲线尽量贴合。贴不上，就出问题。
我建议大家在设计系统时，一定要把带宽探测和码率自适应做成闭环。别指望一次探测管一辈子。网络是活的，你的码率控制也得是活的。
1.2 延迟约束：实时通信的命门
实时通信，什么叫实时？你对着手机说一句话，对方 1 秒后听到，这叫实时。如果 5 秒后才听到，那就叫对讲机。视频也一样。延迟是实时通信的命门。
延迟从哪里来？我列一下主要环节：
- 采集延迟：摄像头从感光到输出数据，一般 10-30ms。
- 编码延迟：H.265 编码一帧，尤其是用了 B 帧，延迟可能到 50-100ms。
- 网络传输延迟：数据包从发送端到接收端的物理传播时间，加上路由转发时间。跨洋链路轻松上百毫秒。
- 解码渲染延迟：解码器解码、渲染到屏幕，又是 20-50ms。
- 抖动缓冲延迟：为了对抗网络抖动，接收端得攒几个包再播放。这个延迟是用户能直接感知的。
你看，每个环节都在吃延迟。实时通信的端到端延迟，一般要求控制在 200-400ms 以内。超过 500ms，对话体验就明显变差。超过 1 秒，基本没法用。
注意：H.265 的编码复杂度比 H.264 高 2-3 倍。编码延迟控制不好，实时通信就变成了「延时通信」。我见过有人直接上 H.265 默认配置，结果编码延迟飙到 200ms，加上网络延迟，整个通话延迟超过 600ms。用户反馈说「像在跟外星人通话」。
所以，在实时通信中用 H.265，必须做编码器的延迟优化。比如限制参考帧数量、禁用 B 帧、使用低延迟编码模式。这些后面章节会细讲。
1.3 丢包：视频传输的头号杀手
丢包，是实时通信视频传输里最头疼的问题。没有之一。
为什么会丢包？原因很多：
- 网络拥塞：路由器缓存满了，新来的包直接扔掉。
- 链路质量差：无线信号衰减、干扰，导致数据包在传输过程中损坏，接收端校验失败后丢弃。
- 路由变化：网络拓扑变化，部分数据包走丢了。
- 缓冲区溢出：接收端处理不过来，丢弃后续到达的包。
丢包对视频的影响，跟丢普通数据不一样。你下载一个文件，丢包了可以重传，最多慢一点。但视频是实时流，等你发现丢了包再重传，时间已经来不及了。接收端必须立刻处理，要么隐藏错误，要么恢复数据。
H.265 的丢包影响比 H.264 更严重。为什么？因为 H.265 的帧间预测更复杂，一个参考帧丢了，可能影响后面几十帧的解码。我举个例子：
| 编码标准 | 典型 GOP 大小 | 丢一个 P 帧的影响范围 | 丢一个参考帧的影响范围 |
|---|---|---|---|
| H.264 | 30-60 帧 | 后续 1-2 帧 | 后续 15-30 帧 |
| H.265 | 30-60 帧 | 后续 2-4 帧 | 后续 20-40 帧 |
你看，H.265 的参考帧依赖更深，丢包后的错误传播范围更大。这就是为什么我们需要专门的丢包恢复技术。
我的经验：在实时通信系统中，丢包率超过 1%，视频质量就会明显下降。丢包率超过 5%，基本不可用。所以，丢包恢复不是「锦上添花」，而是「雪中送炭」。没有它，H.265 在实时通信里根本跑不起来。
1.4 三大挑战的相互关系
带宽波动、延迟约束、丢包，这三者不是孤立的。它们互相影响，形成一个三角关系：
你看这个三角关系：
- 带宽波动 → 延迟约束：带宽突然下降，编码器来不及降码率，网络开始拥塞，延迟飙升。
- 带宽波动 → 丢包：带宽不足，数据包在路由器排队超时被丢弃。
- 延迟约束 → 丢包恢复困难：因为延迟要求高，你不能等重传，必须用前向纠错或错误隐藏，但这些方法都有代价。
- 丢包 → 延迟增加：丢包后，接收端可能请求重传，一来一回，延迟就上去了。
所以，设计一个实时通信视频系统，本质上就是在这三个约束之间找平衡。你不能只盯着一个指标优化。我见过有人为了降低延迟，把抖动缓冲调到 0，结果网络一抖，视频直接卡死。也有人为了抗丢包，加了大量冗余数据，结果带宽不够，反而加剧了拥塞。
1.5 为什么选择 H.265？
既然 H.265 在实时通信里挑战这么大，为什么还要用它？说白了，就一个原因：同样的画质，H.265 只需要 H.264 一半的码率。
在带宽受限的场景下，这个优势是致命的。比如移动网络，带宽经常只有几百 Kbps。用 H.264，只能传 360p 的模糊画面。用 H.265，可以传 720p 的清晰画面。用户体验完全不一样。
但代价就是编码复杂度高、延迟控制难、丢包恢复更复杂。这就是我们这门课要解决的问题。后面 29 章，我会把 H.265 在实时通信中的丢包恢复技术，从原理到实践，一个一个讲清楚。
一句话总结本章：实时通信视频传输面临带宽波动、延迟约束、丢包三大挑战，三者互相制约。H.265 虽然压缩率高，但在这三个维度上都比 H.264 更敏感。丢包恢复技术，就是要在不突破延迟底线的前提下，尽可能修复丢包带来的画面损伤。