3. RTP时间戳机制：时间戳的作用、时钟频率的选择、时间戳与采样率的关系、时间戳的初始值
聊到RTP，时间戳是个绕不开的话题。我刚开始接触流媒体时，总觉得时间戳不就是个序号嘛，后来踩了坑才明白——它其实是整个音画同步的基石。说白了，没有准确的时间戳，接收端根本不知道什么时候该播放这个包，更别提让声音和画面对齐了。
3.1 时间戳到底在干什么？
RTP时间戳的核心作用就一个：告诉接收端，这个数据包里的第一个采样点是在什么时刻生成的。注意，是生成时刻，不是发送时刻，也不是接收时刻。这个区别很重要。
具体来说，时间戳干了几件事：
- 播放时序控制：接收端根据时间戳决定什么时候把数据送给解码器、什么时候渲染出来。
- 音画同步：音频流和视频流各自维护独立的时间戳，接收端通过对比它们的时间轴来实现唇同步。
- 丢包检测与抖动消除：时间戳的跳变能帮你判断是不是丢了包，结合序列号还能算出网络抖动，做jitter buffer补偿。
核心要点：RTP时间戳反映的是媒体采样时刻，而不是网络传输时刻。它和RTCP的NTP时间戳配合使用，才能实现端到端的绝对时间同步。
我记得有一次排查一个视频会议项目，画面总是比声音慢半拍。查了半天发现是发送端把时间戳打在了网络发送时刻，而不是摄像头采集时刻。嗯，这种低级错误，一旦犯过就再也不会忘了。
3.2 时钟频率怎么选？
时钟频率，说白了就是时间戳每秒钟增加多少个单位。这个值选错了，接收端算出来的播放时间就会乱套。
不同的媒体类型，RFC里推荐了不同的默认时钟频率：
| 媒体类型 | 常用时钟频率 (Hz) | 说明 |
|---|---|---|
| PCMU / PCMA (G.711) | 8000 | 采样率就是时钟频率，1:1关系 |
| G.722 | 8000 | 虽然采样率是16kHz，但时钟频率仍用8kHz |
| Opus | 48000 | 与采样率一致，48kHz |
| H.264 / H.265 | 90000 | 视频通用时钟频率，90kHz |
| MPEG-4 Visual | 90000 | 同上，视频流基本都用90kHz |
你可能会问，为什么视频要用90000Hz这么高的频率？音频8000Hz就够了啊。原因很简单：视频的帧率通常是25fps、30fps、60fps，甚至更高。如果时钟频率太低，时间戳的精度就不够区分每一帧。90000能被25、30、50、60这些常见帧率整除，算起来方便，精度也够。
我的习惯：做音频流时，如果Payload Type没有特殊规定，我一般直接用采样率作为时钟频率。视频流则无脑用90000Hz，这是最稳妥的做法。曾经有个项目用了48000Hz做视频时钟，结果帧率一高就出现时间戳回绕计算错误，后来老老实实改回90000Hz。
3.3 时间戳与采样率的关系
这个关系其实很直观：时间戳的增长速率 = 时钟频率。但要注意，时钟频率不一定等于采样率。
举个例子：
- G.711音频，采样率8000Hz，时钟频率也是8000Hz。每采集一个样本，时间戳加1。一个20ms的包包含160个样本，时间戳就增加160。
- Opus音频，采样率48000Hz，时钟频率48000Hz。一个20ms的包包含960个样本，时间戳增加960。
- H.264视频，采样率其实是帧率（比如30fps），但时钟频率是90000Hz。每帧的时间戳增量 = 90000 / 帧率 = 3000。
你想想看，如果视频用30fps，时钟频率90000Hz，那么每帧的时间戳增量就是3000。接收端拿到两个包，时间戳差3000，就知道中间隔了一帧，播放间隔应该是1/30秒。
避坑指南：我曾经在一个项目中，把音频的时钟频率设成了采样率的两倍。结果接收端计算播放时长时，认为每个包的时间跨度翻倍了，声音越播越慢。后来定位到是SDP协商里写错了clockrate。记住，时钟频率是时间戳的刻度，不是数据量。
3.4 时间戳的初始值
时间戳的初始值，RFC 3550里说得清楚：随机初始化。为什么不用0？
原因有两个：
- 安全性：如果每次都是从0开始，攻击者可以预测时间戳模式，做一些恶意操作。随机化能增加破解难度。
- 避免与历史流混淆：如果接收端缓存了之前流的状态，新流从随机值开始，不会和旧流的时间戳范围重叠。
具体做法是：在RTP会话开始时，发送端生成一个随机的32位初始值，作为第一个包的RTP时间戳。之后每个包的时间戳 = 初始值 + 累计的采样点数量。
举个例子：
// 伪代码示例
uint32_t timestamp_base = random(); // 随机初始值
uint32_t samples_per_packet = 160; // G.711, 20ms
uint32_t current_timestamp = timestamp_base;
// 发送第1个包
send_packet(timestamp = current_timestamp);
current_timestamp += samples_per_packet;
// 发送第2个包
send_packet(timestamp = current_timestamp);
current_timestamp += samples_per_packet;这里要注意，时间戳是32位无符号整数，最大值是4294967295。以90000Hz的时钟频率算，大约13.25小时就会回绕一次。接收端需要处理回绕逻辑，不能简单用差值判断先后。
经验之谈：随机初始值虽然好，但调试时很麻烦。我个人的做法是：开发阶段固定一个初始值（比如0或随机但可复现），方便抓包对比。上线前再改成真正的随机值。另外，同一个RTP会话内的所有流（比如音频和视频），它们的初始值应该独立随机，不要有关联性。
3.5 知识体系总览
下面这张图把时间戳的核心逻辑串起来了，你可以对照着理解：
从这张图可以看得很清楚：发送端用采样率采集数据，用时钟频率生成时间戳，然后打包发出去。接收端拿到包后，提取时间戳，结合jitter buffer做播放调度。底部的三个参数——采样率、时钟频率、初始值——是时间戳机制的三大支柱，缺一不可。
3.6 小结
时间戳机制是RTP协议里最基础也最容易出错的部分。我见过太多人把时间戳当成简单的序号来用，结果音画不同步、播放卡顿、回绕处理崩溃，各种问题层出不穷。
记住三条核心原则：
- 时间戳反映的是采样时刻，不是发送时刻
- 时钟频率和采样率可能不同，视频固定用90000Hz最保险
- 初始值一定要随机化，但调试时可以固定方便排查