3、时间戳同步机制：RTP时间戳的线性增长、时间戳回绕处理、基于时间戳的播放同步

好，咱们进入第三章。这一章要聊的是RTP时间戳的核心玩法——同步机制。

说实话，我在刚接触RTP的时候，觉得时间戳不就是个计数器嘛，有什么好讲的？后来在做一个多路摄像头同步的项目时，被时间戳回绕坑得差点通宵加班。嗯，从那以后我再也不敢小看这个字段了。

3.1 RTP时间戳的线性增长

RTP时间戳的本质，是一个单调递增的计数器。它不代表绝对时间，而是代表采样时刻的“相对位置”。

你想想看，音频每秒钟采样8000次，那时间戳就每125微秒加1。视频如果是30fps，每帧的时间戳增量就是90000/30 = 3000。这个增量是固定的，只要采样率不变，时间戳就线性增长。

关键公式：

时间戳增量 = 时钟频率 / 帧率

例如：视频90000Hz时钟，30fps → 增量 = 90000/30 = 3000

我在项目中见过有人把时间戳写成随机数，结果播放器直接崩溃。记住：时间戳必须线性增长，不能跳跃，不能倒退，除非发生回绕。

媒体类型	典型时钟频率	典型帧率/采样率	每包增量
PCM音频	8000 Hz	8000 采样/秒	160 (20ms包)
H.264视频	90000 Hz	30 fps	3000
Opus音频	48000 Hz	48000 采样/秒	960 (20ms包)

3.2 时间戳回绕处理

RTP时间戳是32位无符号整数。最大值是4294967295。到了这个值再加1，就变成0了。这就是回绕（wrap around）。

为什么会回绕？说白了就是计数器不够长。32位听着挺大，但90000Hz的时钟下，每秒钟跑90000个计数，4294967295 / 90000 ≈ 47721秒 ≈ 13.25小时。也就是说，连续跑13个多小时，时间戳就回绕一次。

我曾经踩过的坑：

有一次做视频录制，跑了12小时，突然播放器开始乱跳。查了半天，发现是时间戳回绕后，播放器用简单的“当前时间戳 > 上一个时间戳”来判断乱序，结果回绕后新时间戳比旧的小，被当成乱序包丢弃了。

正确的回绕处理，需要做模运算比较。我习惯用这个方式：

// 判断 a 是否在 b 之后（考虑回绕）
bool isLater(uint32_t a, uint32_t b) {
    return (int32_t)(a - b) > 0;
}

// 计算差值（考虑回绕）
uint32_t delta(uint32_t a, uint32_t b) {
    return (uint32_t)(a - b);
}

这里的关键是把uint32_t差值转成int32_t。如果差值在-2^31到2^31-1之间，就能正确判断先后顺序。说白了，就是假设两个时间戳的间隔不会超过2^31个计数。

我的建议：

在接收端维护一个“基准时间戳”。每次收到包，用当前时间戳减去基准，得到相对偏移。这样回绕只影响基准更新，不影响播放逻辑。

3.3 基于时间戳的播放同步

播放同步，说白了就是让接收端知道“这个包该什么时候播”。

RTP本身不提供绝对时间，只提供相对位置。接收端需要自己做映射：把RTP时间戳映射到本地时钟上。

我常用的方法是线性回归映射：

收到第一个包时，记录本地时间T0和RTP时间戳R0
后续每个包，用公式计算播放时间：T_play = T0 + (RTP - R0) / 时钟频率
如果发现偏差超过阈值，做微调

但这里有个问题：网络有抖动。包可能延迟到达。如果严格按照公式算，延迟的包一到就立刻播，那音频就会忽快忽慢。

所以需要抖动缓冲区（jitter buffer）。我一般设一个20-50ms的缓冲区，让播放器从缓冲区里匀速取数据，而不是直接从网络取。

同步误差校正的核心思路：

发送端：时间戳线性增长，反映采样时刻
接收端：建立RTP时间戳到本地时钟的映射
缓冲区：吸收网络抖动，平滑播放
回绕处理：用模运算比较，避免误判

下面这张图展示了整个同步流程：

实际项目中，我还会加一个时间戳漂移校正。因为发送端和接收端的时钟可能不同步，时间长了会有累积误差。我一般每30秒做一次重同步，把基准时间戳重新校准一下。

避坑指南：

不要用系统时间直接减RTP时间戳，要用相对偏移
回绕检测要放在所有时间戳比较之前
抖动缓冲区大小要动态调整，网络差时增大，好时减小
音频和视频的时间戳时钟频率不同，同步时要分别处理

嗯，这一章的内容就这些。时间戳同步说难不难，说简单也不简单。关键是把线性增长、回绕处理、播放映射这三个点串起来，形成一个完整的闭环。下次遇到播放不同步的问题，你就知道该从哪里入手了。