4、RTP/RTCP协议：RTP头部格式、RTCP SR/RR报告、NTP时间戳映射
聊到多媒体流同步，RTP/RTCP 这对协议组合是绕不开的基石。很多人觉得它们就是单纯的“打包发送”和“质量反馈”，其实不然。我个人习惯把 RTP 看作运货的卡车，而 RTCP 则是调度中心发回来的路况报告——两者配合，才能让音视频数据在复杂的网络里准时到达、步调一致。
这一节，我们重点拆解三个核心：RTP 头部到底长什么样、RTCP 的发送端报告（SR）和接收端报告（RR）怎么读，以及NTP 时间戳如何与 RTP 时间戳映射。嗯，这些是同步机制的“硬通货”，搞懂了它们，你才算真正入了门。
4.1 RTP 头部格式：12 字节的“身份证”
RTP 头部固定 12 字节，不长，但每个字段都有讲究。我刚开始接触时，总觉得它跟 UDP 头部差不多，后来踩了坑才发现——序列号和时间戳这两个字段，是同步的灵魂。
| 字段 | 长度（bit） | 说明 |
|---|---|---|
| V（版本） | 2 | 当前为 2 |
| P（填充） | 1 | 1 表示尾部有填充字节 |
| X（扩展） | 1 | 1 表示头部后有扩展头 |
| CC（CSRC 计数） | 4 | 表示 CSRC 标识符数量 |
| M（标记） | 1 | 视频帧边界或音频 talkspurt 起始 |
| PT（负载类型） | 7 | 标识编码格式，如 H.264=96 |
| 序列号 | 16 | 每发一个包递增 1，用于检测丢包和排序 |
| 时间戳 | 32 | 媒体采样时刻，单位取决于采样率 |
| SSRC | 32 | 同步源标识符，唯一标识一个流 |
| CSRC 列表 | 0~15×32 | 仅当 CC>0 时存在，标识贡献源 |
关键点：序列号用于检测丢包和乱序，时间戳用于播放同步。两者缺一不可。我曾经在项目中遇到一个问题：视频流时间戳正确但序列号跳跃，结果解码器直接崩溃——因为解码器依赖序列号判断帧顺序。
你可能会问：为什么时间戳不用 NTP 格式？嗯，这里有个设计考量——RTP 时间戳是相对于媒体采样时钟的，单位是采样周期（比如音频 8kHz 采样，每 tick 是 125μs）。这样设计的好处是，解码器可以直接用时间戳计算播放间隔，不需要跟系统时钟打交道。但坏处也很明显：不同媒体流的时间戳基准不同，没法直接比较。这就是为什么需要 RTCP 和 NTP 映射。
4.2 RTCP SR/RR 报告：谁在发，谁在收
RTCP 包有很多类型，但做同步最核心的是两种：发送端报告（SR）和接收端报告（RR）。说白了，SR 是“我发了多少”，RR 是“我收到了多少”。
4.2.1 发送端报告（SR）
SR 由媒体发送端周期性发出。它的结构分为三部分：头部、发送者信息块、以及零个或多个接收报告块。
发送者信息块里，有两个字段对同步至关重要：
- NTP 时间戳：64 位，高 32 位是秒数（从 1900 年 1 月 1 日开始），低 32 位是小数部分。精度极高，用于跨流对齐。
- RTP 时间戳：32 位，对应同一时刻的 RTP 时间戳值。
我的经验：SR 包里的 NTP 和 RTP 时间戳是“配对”的。接收端拿到这个配对，就能建立一条映射关系：RTP_ts = (NTP_ts - NTP_base) × 采样率 + RTP_base。这样，不同媒体流就能用同一个 NTP 时钟对齐了。
4.2.2 接收端报告（RR）
RR 由接收端发出，不包含 NTP 时间戳，但包含重要的统计信息：
| 字段 | 说明 |
|---|---|
| 丢包率 | 从上一个 RR 到现在的丢包比例 |
| 累计丢包数 | 会话开始以来的总丢包数 |
| 到达时间抖动 | 包到达间隔的统计方差，单位是 RTP 时间戳 tick |
| LSR（最后 SR 时间） | 最近收到的 SR 中的 NTP 时间戳中间 32 位 |
| DLSR（从收到 SR 到发送 RR 的延迟） | 单位是 1/65536 秒 |
避坑指南：我曾经在调试一个视频会议系统时，发现接收端画面频繁卡顿。查了半天，原来是 RR 报告里的 DLSR 字段填错了——发送端用它计算 RTT，算出来是负数，导致拥塞控制逻辑直接崩溃。记住：DLSR 必须精确反映从收到 SR 到发出 RR 的时间差，否则 RTT 计算全错。
4.3 NTP 时间戳映射：跨流同步的“翻译官”
现在我们来解决那个核心问题：如何让音频流和视频流在同一个时间轴上对齐？
答案就在 SR 报告里的 NTP-RTP 映射对。接收端收到音频流的 SR 和视频流的 SR 后，可以分别建立两条映射关系。然后，把两个流的 RTP 时间戳都转换成 NTP 时间，就能直接比较了。
举个例子：
- 音频流 SR：NTP = 1000s，RTP_audio = 80000（采样率 8kHz）
- 视频流 SR：NTP = 1000s，RTP_video = 30000（采样率 90kHz）
那么，音频 RTP 时间戳 80000 对应 NTP 1000s，视频 RTP 时间戳 30000 也对应 NTP 1000s。如果音频包的时间戳是 88000，视频包的时间戳是 33000，分别换算：
- 音频 NTP = 1000 + (88000 - 80000) / 8000 = 1001s
- 视频 NTP = 1000 + (33000 - 30000) / 90000 ≈ 1000.033s
你看，音频比视频晚了约 0.967 秒。接收端就可以据此调整播放缓冲区，让唇音同步。
核心公式：
NTP_corresponding = NTP_SR + (RTP_current - RTP_SR) / sampling_rate
其中 NTP_SR 和 RTP_SR 来自同一个 SR 报告。
4.4 同步流程全景图
下面这张图展示了从发送端到接收端的完整同步链路。我习惯用这种图来跟团队对齐思路——你一看就明白数据是怎么流动的。
4.5 实践中的几个坑
理论说完了，聊聊实际中容易出问题的地方。我这些年调试过的同步问题，十有八九都跟下面几个点有关：
- NTP 时钟不同步：发送端和接收端如果 NTP 时钟偏差太大，映射出来的时间全是错的。我曾经在跨机房部署时遇到过，两个机房的 NTP 服务器差了 2 秒，结果音视频始终对不上。解决方案是：所有设备统一使用同一个 NTP 服务器，或者用 PTP 做高精度同步。
- RTP 时间戳回绕：32 位时间戳，在 90kHz 采样率下大约 13 小时回绕一次。如果接收端不做回绕检测，映射出来的 NTP 时间会突然跳变。我建议在代码里维护一个 时间戳回绕计数器，把 32 位扩展到 64 位再计算。
- SR 报告间隔太长：RTCP 的默认报告间隔是 5 秒。如果网络抖动频繁，5 秒前的映射关系可能已经不准了。我习惯把间隔缩短到 1~2 秒，代价是带宽占用增加一点，但同步精度提升明显。
一个小技巧：如果你在做 WebRTC 相关的开发，可以看看它的 RTCRtpReceiver 接口——里面直接提供了 getStats() 方法，能拿到当前流的 RTP 时间戳和 NTP 时间戳映射。省去了手动解析 SR 包的麻烦。
4.6 小结
这一节我们拆解了 RTP 头部、RTCP SR/RR 报告，以及 NTP 时间戳映射。说白了，同步的核心就是一句话：用 NTP 做统一时钟，用 RTP 时间戳做媒体内定位，用 SR 报告搭桥。搞懂了这三者的关系，你就能在接收端精确计算出不同媒体流之间的时间差，从而实现唇音同步。