4. RTP 时间戳分析：深入理解 RTP 时间戳的生成、传递与解析机制
RTP 时间戳，说白了就是音视频同步的「心跳」。我做了这么多年 WebRTC 开发，见过太多因为时间戳没搞对导致的音画不同步问题。有的视频比音频快了半秒，有的干脆卡死不动。嗯，今天我们就把它彻底讲透。
4.1 时间戳的本质：它到底在记录什么？
很多人以为 RTP 时间戳记录的是「当前几点几分」。其实不是。它记录的是采样时刻——也就是音频或视频帧被采集设备捕获的那个瞬间。
举个例子。你对着摄像头说话，摄像头在 t=0 时刻拍下一帧画面，编码器把它压缩成视频包，这个包的 RTP 时间戳就是 0。下一帧在 t=1/30 秒后采集，时间戳就是 90000/30 = 3000（假设 90kHz 时钟）。
核心要点：RTP 时间戳是一个单调递增的计数器，单位是采样时钟的 tick，不是毫秒或微秒。
4.2 不同媒体类型的时间戳时钟
这里有个坑：音频和视频用的时钟频率不一样。我刚开始做的时候，直接把音频时间戳当视频用，结果画面和声音完全对不上。
| 媒体类型 | 标准时钟频率 | 常见采样率 | 1 秒对应的 tick 数 |
|---|---|---|---|
| 音频（PCMU/PCMA） | 8,000 Hz | 8 kHz | 8,000 |
| 音频（Opus） | 48,000 Hz | 48 kHz | 48,000 |
| 视频（H.264/VP8） | 90,000 Hz | N/A | 90,000 |
我的经验：视频用 90kHz 是因为它能精确表示常见的帧率（如 29.97fps、30fps、60fps）。90000 能被 30、60、29.97 整除，不会产生小数误差。
4.3 时间戳的生成：发送端怎么做？
生成时间戳看起来简单，但细节很多。我们分音频和视频来看。
4.3.1 音频时间戳生成
音频是连续流，每个包包含固定数量的采样点。比如 Opus 每帧 20ms，采样率 48kHz，那一帧就有 960 个采样点。时间戳增量就是 960。
// 伪代码：音频时间戳生成
uint32_t audio_timestamp = 0;
const int samples_per_frame = 960; // 20ms @ 48kHz
while (capturing) {
audio_timestamp += samples_per_frame;
send_rtp_packet(audio_timestamp);
}你想想看，如果网络抖动导致丢包，接收端可以根据时间戳差值判断丢失了多少采样点，然后做 PLC（丢包隐藏）。
4.3.2 视频时间戳生成
视频就复杂一些。因为视频帧不是均匀产生的——编码器可能因为场景复杂度不同，导致帧间隔不稳定。
// 伪代码：视频时间戳生成
uint32_t video_timestamp = 0;
const int clock_rate = 90000;
while (capturing) {
// 获取当前帧的采集时间（单位：微秒）
uint64_t capture_time_us = get_capture_time();
// 转换为 RTP 时间戳
video_timestamp = (uint32_t)(capture_time_us * clock_rate / 1000000);
send_rtp_packet(video_timestamp);
}注意：视频时间戳必须基于采集时间，而不是编码时间或发送时间。我曾经见过有人用发送时间戳代替采集时间戳，结果在低帧率场景下（如 5fps），音画同步误差直接飙到 200ms 以上。
4.4 时间戳的传递：RTP 头部结构
时间戳放在 RTP 固定头部的第 4-7 字节。我们来看一下完整的 RTP 头部结构：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+时间戳字段占 32 位，这意味着它最大能表示 2^32 个 tick。以视频 90kHz 为例，大约 13 小时会回绕一次。嗯，这个问题我们后面会讲。
4.5 时间戳的解析：接收端如何还原？
接收端拿到 RTP 包后，需要把时间戳转换成播放时间。这个过程涉及两个关键步骤：
- 提取时间戳：从 RTP 头部第 4-7 字节读取 32 位无符号整数。
- 转换为播放时间：用公式
playout_time_ms = (timestamp - base_timestamp) * 1000 / clock_rate。
// 接收端时间戳解析
uint32_t rtp_timestamp = extract_from_rtp_header(packet);
uint32_t base_timestamp = get_base_timestamp(ssrc);
int clock_rate = get_clock_rate(payload_type);
// 计算相对时间（毫秒）
int64_t relative_time_ms = (int64_t)(rtp_timestamp - base_timestamp) * 1000 / clock_rate;
// 计算绝对播放时间
int64_t playout_time_ms = first_packet_time_ms + relative_time_ms;我的习惯：在接收端维护一个 TimestampUnwrapper 类，专门处理时间戳回绕和乱序。不要直接在业务代码里做时间戳运算，容易出 bug。
4.6 时间戳回绕：32 位溢出的处理
32 位时间戳迟早会溢出。视频 90kHz 大约 13 小时回绕一次，音频 48kHz 大约 24 小时。对于长时间通话的场景，必须处理回绕。
WebRTC 的做法是维护一个「扩展时间戳」——用一个 64 位整数来跟踪实际的时间戳值。每次收到新包时，判断时间戳是否发生了回绕：
// 时间戳回绕检测
uint32_t new_ts = packet->timestamp();
uint32_t last_ts = last_timestamp_;
// 如果新时间戳比上一个还小，且差值很大，说明发生了回绕
if (new_ts < last_ts && (last_ts - new_ts) > 0x7FFFFFFF) {
// 回绕了一次
wrap_count_++;
}
// 扩展时间戳 = wrap_count_ * 2^32 + new_ts
uint64_t extended_ts = (uint64_t)wrap_count_ << 32 | new_ts;避坑指南：我曾经在实现回绕检测时，直接用 new_ts < last_ts 判断回绕。结果在乱序场景下（比如网络重传导致旧包晚到），误判了大量回绕，导致音画同步彻底崩溃。正确的做法是结合序列号和时间戳一起判断。
4.7 时间戳与 NTP 时间的映射
真正实现音画同步，光靠 RTP 时间戳还不够。因为音频和视频的时钟频率不同，它们的 RTP 时间戳不能直接比较。这时候就需要 RTCP SR（Sender Report）包里的 NTP 时间戳来做映射。
RTCP SR 包包含两个关键字段：
- NTP 时间戳：64 位，表示当前绝对时间（1900 年 1 月 1 日以来的秒数 + 小数部分）。
- RTP 时间戳：32 位，与 NTP 时间戳对应的 RTP 时间戳值。
接收端收到 SR 包后，可以建立 NTP 和 RTP 的映射关系：
// 从 SR 包中提取映射关系
uint64_t ntp_ts = sr_packet->ntp_timestamp();
uint32_t rtp_ts = sr_packet->rtp_timestamp();
// 计算 RTP 时间戳对应的 NTP 时间
// ntp_time = ntp_ts + (rtp - rtp_ts) * 1000 / clock_rate
int64_t ntp_time_ms = ntp_ts_to_ms(ntp_ts) +
(int64_t)(rtp_timestamp - rtp_ts) * 1000 / clock_rate;有了这个映射，音频和视频的时间戳就可以统一到 NTP 时间轴上进行比较了。
4.8 知识体系总览
下面这张图总结了 RTP 时间戳从生成到解析的完整流程：
4.9 实战中的常见问题
最后，我总结几个实际项目中容易踩的坑：
- 时间戳起始值不为 0：有些采集设备的时间戳起始值是随机的。接收端必须记录第一个包的 baseline，不能假设从 0 开始。
- 多路流的时间戳对齐：如果同时接收多路视频流，它们的 SSRC 不同，时间戳基线也不同。需要分别维护映射关系。
- 时间戳跳跃：编码器可能因为 B 帧重排导致时间戳不连续。接收端要做抖动缓冲，不能直接按时间戳顺序播放。
一句话总结：RTP 时间戳是音视频同步的基石。搞懂它的生成、传递和解析机制，你就掌握了 WebRTC 同步的 80%。剩下的 20% 是抖动缓冲和时钟漂移补偿，我们后面会讲。