2. RTP 时间戳机制：时钟频率与采样率的秘密

聊完音画同步的整体框架，咱们得先啃一块硬骨头——RTP 时间戳。说实话，我早年刚接触 WebRTC 时，觉得时间戳不就是个计数器嘛，有啥好研究的？结果第一次做音画同步优化，就被它狠狠上了一课。

RTP 时间戳，说白了就是告诉接收端：这个包里的数据，应该在哪个时刻被播放。但它不是我们日常用的那种绝对时间，而是一个相对值。嗯，这里要注意，它跟 NTP 时间戳完全是两码事。

2.1 RTP Header 中的时间戳字段

先看 RTP 包头的结构。我习惯把 RTP 固定头画成一张图，这样更直观：

看到那个绿色的 Timestamp 字段没？32 位，占 4 个字节。它记录的是采样时刻，而不是网络传输时刻。这个区别很重要——我见过不少新手把 RTP 时间戳跟系统时间混为一谈，结果音画同步做得一塌糊涂。

2.2 时钟频率与采样率的关系

好，现在问题来了：时间戳的单位是什么？是毫秒吗？微秒吗？

都不是。时间戳的单位是时钟周期。每个媒体流都有自己的时钟频率（clock rate），时间戳每增加 1，代表过去了 1/clock_rate 秒。

举个例子：

• 音频用 48kHz 采样率，时钟频率就是 48000 Hz。时间戳每跳 1，代表 1/48000 ≈ 20.8 微秒。
• 视频用 90kHz 时钟频率（这是标准，别问为什么，历史原因）。时间戳每跳 1，代表 1/90000 ≈ 11.1 微秒。

你想想看，为什么视频要用 90kHz？我早年也纳闷，后来查了资料才知道——90kHz 能被 24、25、30、50、60 这些常见帧率整除，算起来方便。嗯，老前辈们留下的智慧。

媒体类型	常见采样率	RTP 时钟频率	时间戳精度
PCMU/PCMA 音频	8 kHz	8000 Hz	125 μs
Opus 音频	48 kHz	48000 Hz	20.8 μs
H.264 视频	N/A	90000 Hz	11.1 μs
VP8/VP9 视频	N/A	90000 Hz	11.1 μs

2.3 时间戳增量怎么算？

假设你有一帧 20ms 的 Opus 音频包，采样率 48kHz。那么：

时间戳增量 = 采样率 × 时长（秒）
           = 48000 × 0.02
           = 960

也就是说，相邻两个音频包的时间戳相差 960。这个值在通话过程中是固定的（除非你动态调整了采样率）。

视频呢？假设你采集了 30fps 的视频：

时间戳增量 = 时钟频率 / 帧率
           = 90000 / 30
           = 3000

每帧视频的时间戳比上一帧多 3000。但注意——视频的时间戳增量不是固定的。为什么？因为视频编码是变码率的，I 帧、P 帧、B 帧的复杂度不同，编码耗时也不同。再加上网络抖动，实际发送间隔会有波动。

2.4 时间戳的随机初始值

RFC 3550 规定，RTP 时间戳的初始值必须是随机数。为什么？

我个人的理解是：为了防止攻击者预测时间戳，也为了避免多个流的时间戳恰好对齐导致混淆。实际开发中，WebRTC 内部会用随机数生成器来初始化。

举个例子：

// 伪代码：WebRTC 中时间戳初始化
uint32_t timestamp_offset = random();  // 随机初始值
uint32_t rtp_timestamp = timestamp_offset + sample_count;

接收端收到第一个包时，并不知道初始值是多少。但它也不需要知道——它只关心相对差值。比如收到两个包，时间戳分别是 123456 和 124416，差值 960，就知道这两个包之间隔了 20ms 的音频。

2.5 时间戳与 NTP 的映射

这里要引出另一个概念：NTP 时间戳。RTP 时间戳是相对值，NTP 是绝对时间（从 1900 年 1 月 1 日开始的秒数）。

在 RTCP Sender Report（发送端报告）中，会把 RTP 时间戳和 NTP 时间戳配对发送。接收端拿到这个配对，就能算出 RTP 时间戳对应的真实时间。

我画个图帮你理解：

有了这个映射，接收端就能把 RTP 时间戳换算成真实时间，然后跟本地时钟做对比，判断音画是否同步。

2.6 实际开发中的常见坑

最后，我总结几个我在项目中踩过的坑：

1. 时钟频率搞错：视频固定用 90000 Hz，别自作聪明改成别的。音频要根据编码类型查表。
2. 时间戳回绕：32 位无符号整数，最大值 4294967295。以 90kHz 算，大约 13 小时回绕一次。WebRTC 内部用无符号减法处理回绕，你写代码时也要注意。
3. 音频时间戳不连续：如果音频有丢包补偿（PLC），补偿后的包时间戳要连续，不能跳变。
4. 视频时间戳抖动：编码器输出时间戳可能不是严格等间隔的，接收端要做平滑处理。