4. RTP时间戳机制：时间戳的作用、时间戳频率与采样率的关系、时间戳增量计算、时间戳回绕处理、时间戳与NTP时间对齐。
各位同学，咱们今天聊聊RTP里一个特别容易让人栽跟头的东西——时间戳。
说实话，我当年刚接触RTP的时候，觉得时间戳不就是个序号嘛，跟序列号差不多。结果第一次做音视频同步，画面和声音对不上，排查了整整两天。最后发现，问题就出在我对时间戳的理解太肤浅了。
时间戳这东西，说白了就是给每个RTP包打上一个“时间标签”。但它不是简单的计数器，它承载着播放时序、抖动消除、音视频同步这些核心功能。你想想看，如果没有时间戳，接收端怎么知道这个包该什么时候播放？
核心认知：RTP时间戳反映的是媒体数据的采样时刻，而不是网络传输时刻。这个区别非常重要。
4.1 时间戳的作用
时间戳在RTP里干三件事：
- 播放时序控制：告诉接收端，这个包里的数据应该在什么时间点被播放出来。
- 抖动消除：网络有延迟抖动，接收端靠时间戳把乱序的包重新排好，恢复出原始的播放节奏。
- 音视频同步：音频流和视频流各自有独立的时间戳，接收端通过它们之间的时间关系，实现唇音同步。
我记得有一次做视频会议系统，用户反馈声音和画面不同步。我抓包一看，音频时间戳和视频时间戳的基准点没对齐。嗯，这就是典型的同步问题。
4.2 时间戳频率与采样率的关系
这里有个容易混淆的概念：时间戳频率不等于采样率，但两者密切相关。
RTP时间戳的单位是“tick”，每个tick代表的时间长度由时间戳频率决定。公式很简单：
时间戳频率 = 采样率（对于音频）
时间戳频率 = 90000 Hz（对于视频，固定值）为什么视频要用90000？我刚开始也觉得奇怪。后来查了标准才知道，这是为了兼容MPEG的90kHz系统时钟。说白了，历史原因。
| 媒体类型 | 采样率 | 时间戳频率 | 说明 |
|---|---|---|---|
| PCM音频 | 8000 Hz | 8000 Hz | 每个采样点对应一个tick |
| AAC音频 | 44100 Hz | 44100 Hz | 同上 |
| H.264视频 | 不适用 | 90000 Hz | 固定值，兼容MPEG系统时钟 |
| Opus音频 | 48000 Hz | 48000 Hz | 同上 |
我的习惯：在代码里，我一般把时间戳频率定义成常量，比如 VIDEO_CLOCK_RATE = 90000，避免到处写死数字。
4.3 时间戳增量计算
时间戳增量，就是相邻两个RTP包之间的时间戳差值。它取决于两个因素：采样率和每个包包含的采样点数。
计算公式：
时间戳增量 = (采样点数 / 采样率) × 时间戳频率举个例子，20ms的PCM音频包，采样率8000Hz：
采样点数 = 0.02 × 8000 = 160
时间戳增量 = (160 / 8000) × 8000 = 160你看，对于音频，时间戳增量恰好等于采样点数。但视频就不一样了。
视频的帧率是变化的，比如30fps的视频：
每帧时间间隔 = 1/30 ≈ 33.33ms
时间戳增量 = 0.03333 × 90000 = 3000所以H.264视频在30fps下，时间戳增量通常是3000。如果是60fps，就是1500。
我曾经踩过的坑：有一次我写视频推流，帧率从30fps切换到15fps，忘了更新时间戳增量。结果接收端播放速度直接翻倍。排查了半天才发现，增量没跟着帧率变。
4.4 时间戳回绕处理
RTP时间戳是32位无符号整数，最大值是4294967295。如果一直累加，总会溢出回零。这就是回绕（wrap around）。
回绕带来的问题：接收端无法直接比较两个时间戳的大小，因为回绕后的小数值可能实际上代表更晚的时间。
怎么处理？标准做法是用“模比较”：
// 判断a是否晚于b（考虑回绕）
bool isLater(uint32_t a, uint32_t b) {
return ((a - b) & 0xFFFFFFFF) < 0x80000000;
}这个技巧的原理：32位无符号数相减，结果取模，如果差值小于2^31，说明a在b之后。
我建议在接收端维护一个“扩展时间戳”，用64位来记录，每次收到包时判断是否回绕，然后累加：
uint64_t extended_ts = 0;
uint32_t last_ts = 0;
void onRtpPacket(uint32_t ts) {
if (ts < last_ts && (last_ts - ts) > 0x80000000) {
// 检测到回绕
extended_ts += 0x100000000ULL;
}
extended_ts = (extended_ts & 0xFFFFFFFF00000000ULL) | ts;
last_ts = ts;
}避坑指南：我曾经在嵌入式设备上遇到过回绕处理bug，因为那个平台的int是16位的。记得用 uint32_t 显式声明，别依赖默认类型。
4.5 时间戳与NTP时间对齐
RTP时间戳是相对值，它从会话开始时的某个随机偏移量开始计数。但接收端需要知道这个时间戳对应的绝对时间，才能做音视频同步。
这时候就需要NTP时间了。RTCP的发送者报告（SR）里，同时包含了NTP时间戳和RTP时间戳。两者的关系：
NTP时间 = 基准时间 + (RTP时间戳 - 基准RTP时间戳) / 时间戳频率举个例子，SR报告里说：
- NTP时间戳 = 1000秒（相对于某个参考点）
- 对应的RTP时间戳 = 90000
那么，收到一个RTP包，时间戳是180000，它的绝对时间就是：
绝对时间 = 1000 + (180000 - 90000) / 90000 = 1001秒这样，音频流和视频流就可以用同一个NTP时间轴来对齐了。
关键点：RTP时间戳是媒体采样时刻的映射，NTP时间戳是绝对时间参考。两者配合，才能实现精确的跨流同步。
我个人习惯在接收端维护一个映射表，记录每次SR里的NTP-RTP对应关系，然后用线性插值计算任意RTP时间戳对应的NTP时间。这样即使SR丢失，也能保持同步精度。
嗯，时间戳这块内容不少，但核心就几条：频率决定精度，增量决定节奏，回绕要防坑，NTP对齐才能同步。你在实际项目中遇到时间戳问题，多半是这几个环节没处理好。