3、RTCP协议与同步：SR报告、NTP时间戳、RTP时间戳与NTP的映射关系、CNAME机制
聊到音视频同步，很多人第一反应是算时间差、调PTS。但真正干过流媒体的人都知道——同步的根基在RTCP。没有RTCP的SR报告，你连发端和收端的时钟关系都搞不清楚，同步根本无从谈起。
这一节，我们就来拆解RTCP里跟同步最核心的几个东西：SR报告、NTP时间戳、RTP时间戳的映射，还有那个容易被忽略的CNAME。嗯，都是实战中绕不开的硬骨头。
3.1 SR报告：同步的“锚点”
SR（Sender Report）是RTCP里最重要的报文类型之一。它由发送端定期发出，告诉接收端：“我这边的时间基准是这样的，你看着办。”
一个标准的SR报文包含以下关键字段：
| 字段 | 长度 | 说明 |
|---|---|---|
| SSRC | 32 bit | 发送端的同步源标识符 |
| NTP timestamp | 64 bit | 绝对时间，高32位秒，低32位小数秒 |
| RTP timestamp | 32 bit | 与NTP对应的RTP时间戳 |
| sender's packet count | 32 bit | 自开始发送以来的总包数 |
| sender's octet count | 32 bit | 自开始发送以来的总字节数 |
这里最核心的就是NTP时间戳 + RTP时间戳这对组合。它们共同构成了一个“时间锚点”，告诉接收端：在某个绝对时间点，RTP时间戳的值是多少。
核心理解：SR报告的本质，是发送端在时间轴上打了一个“桩”。接收端拿到这个桩，就能把自己的本地时钟和发送端的时钟关联起来。
3.2 NTP时间戳与RTP时间戳：两个时钟域
很多初学者会混淆NTP和RTP时间戳。我刚开始做RTP开发时也犯过这个错——以为它们是一回事。其实完全不是。
- NTP时间戳：绝对时间，基于UTC。64位，精度高到纳秒级。它代表的是“墙上时间”。
- RTP时间戳：相对时间，基于采样时钟。32位，单位取决于媒体类型（音频通常是采样周期，视频通常是90kHz时钟周期）。它代表的是“媒体播放进度”。
举个例子：
- 音频：采样率48kHz，RTP时间戳每增加480，代表过去了10ms。
- 视频：时钟频率90kHz，RTP时间戳每增加9000，代表过去了100ms。
你看，RTP时间戳本身不携带绝对时间信息。它只告诉你“这是第几个采样点”，而不是“现在是几点几分”。
我的经验：曾经有个项目，视频流RTP时间戳的时钟频率写错了，写成了48kHz。结果播放器算出来的时间全乱套，画面一顿一顿的。排查了两天才发现是这里的问题。所以，时钟频率一定要跟编码器对齐，别想当然。
3.3 NTP与RTP时间戳的映射关系
SR报告里最关键的就是这个映射。它告诉接收端：
在NTP时间 = T_ntp 时，RTP时间戳 = T_rtp有了这个锚点，接收端就可以做两件事：
- 计算RTP时间戳对应的绝对时间：根据SR中的映射关系，把RTP时间戳换算成NTP时间。
- 跨流同步：音频流和视频流各自有独立的RTP时间戳，但通过SR报告，它们都能映射到同一个NTP时间轴上。这样就能对齐了。
映射公式其实很简单：
NTP_time = NTP_base + (RTP_timestamp - RTP_base) / clock_rate其中：
NTP_base和RTP_base来自最近的SR报告clock_rate是媒体时钟频率
注意：RTP时间戳是32位无符号整数，会循环回绕。如果SR报告间隔太长，中间可能已经回绕了好几次。接收端必须处理回绕，否则映射出来的时间会差一大截。我见过有人因为这个bug，同步误差直接飙到几分钟。
3.4 CNAME机制：跨流关联的“身份证”
CNAME（Canonical Name）是RTCP SDES（Source Description）报文中的一个字段。它的作用很简单——把同一个源发出的多个RTP流关联起来。
举个例子：
- 一个视频会议终端，同时发送音频流（SSRC=100）和视频流（SSRC=200）。
- 这两个流的CNAME都设为
user@host。 - 接收端看到两个流，发现CNAME相同，就知道它们是同一个源的，可以一起做同步。
CNAME的格式通常是 user@host 或UUID，保证全局唯一即可。
| 特性 | 说明 |
|---|---|
| 作用 | 关联同一源的不同RTP流 |
| 位置 | RTCP SDES报文 |
| 唯一性 | 全局唯一，通常用 user@host 或 UUID |
| 同步意义 | 告诉接收端“这两个流是一家的，一起同步” |
避坑指南：我曾经遇到一个情况，音频流和视频流的CNAME不一致，结果播放器死活不把它们当成一对，同步逻辑根本跑不起来。排查了半天才发现是CNAME拼写错了。所以，CNAME一定要在发送端统一配置，别手抖。
3.5 整体同步流程
把上面这些串起来，一个典型的RTP音视频同步流程是这样的：
- 发送端定期发送SR报告，包含NTP和RTP时间戳的映射。
- 接收端收到SR后，记录映射关系。
- 接收端收到RTP数据包，提取RTP时间戳。
- 接收端根据最近的SR映射，把RTP时间戳换算成NTP时间。
- 音频流和视频流各自换算后，都在同一个NTP时间轴上，直接比较就能对齐。
- CNAME确保接收端知道哪些流属于同一个源，避免跨源混淆。
说白了，就是通过SR报告把两个独立的时钟域（音频时钟、视频时钟）统一到一个绝对时间轴上。CNAME负责“认亲”，SR负责“对表”。
我的习惯：在实际项目中，我会在接收端维护一个“SR映射表”，缓存最近几个SR报告。这样即使网络抖动导致SR丢失，也能用上一个SR继续同步。当然，如果SR间隔太长，映射精度会下降，需要根据实际情况调整RTCP发送间隔。
3.6 知识体系图
下面这张图把RTCP同步的核心逻辑串起来了。建议你仔细看看，理解每个模块之间的关系。
这张图把整个流程分成了三层：发送端、传输层、接收端。SR报告和CNAME在中间搭桥，接收端通过映射表完成最终的同步计算。你想想看，如果没有SR，接收端连发送端的时钟都不知道，同步就是空中楼阁。
再次提醒：SR报告不是发一次就完事了。RTP时间戳会回绕，NTP时间会漂移，所以SR需要定期发送。RTCP的默认间隔是5秒，但在高精度同步场景下，我建议缩短到1-2秒。当然，也要考虑带宽开销，别把RTCP发成了RTP。