1. 音画同步基础：RTP时间戳机制与播放时钟模型
做流媒体的人都知道，音画不同步是最容易让用户骂娘的问题。我刚开始接触RTP协议时，总觉得时间戳不就是个计数器嘛，有什么好研究的？直到有一次线上事故，用户反馈直播画面和声音差了将近两秒，我才意识到——时间戳这玩意儿，用对了是神器，用错了就是灾难。
这一章，咱们先把地基打牢。说白了，音画同步的核心就两个东西：RTP时间戳怎么打，以及播放时钟怎么管。搞懂这两个，后面讲丢包场景下的策略才有意义。
1.1 RTP时间戳：不只是个计数器
RTP头里有个32位的时间戳字段，这个字段的值由发送端决定。但你要注意，它不是我们日常说的"2025-01-15 10:30:00"这种绝对时间。它是个相对值，基于一个初始随机偏移量，然后按采样率递增。
举个例子。音频用48kHz采样率，每帧包含960个样本。那么每帧的时间戳增量就是960。视频如果是30fps，每帧的时间戳增量就是90000/30 = 3000。嗯，这里有个坑——视频的时钟频率固定是90kHz，这是RTP规范定的，别问为什么，记住就行。
核心要点：RTP时间戳反映的是媒体数据的采样时刻，不是网络传输时刻。接收端靠这个差值来判断音画是否同步。
我在项目中遇到过一个问题：某个音频编码器输出的时间戳不是均匀递增的，偶尔会跳变。结果播放器那边音画同步逻辑直接崩了，画面一顿一顿的。后来排查发现，是编码器在静音检测时跳过了某些帧，但时间戳没按实际采样数累加。所以啊，发送端打时间戳一定要严谨。
1.2 时间戳的生成规则
不同媒体类型的时间戳生成规则不太一样，我整理了一张表，方便你对照：
| 媒体类型 | 时钟频率 | 典型时间戳增量 | 说明 |
|---|---|---|---|
| 音频（PCMU/PCMA） | 8kHz | 160（20ms包） | 每包固定样本数 |
| 音频（AAC） | 48kHz | 1024（21.3ms包） | 每帧固定样本数 |
| 音频（Opus） | 48kHz | 960（20ms包） | 可变帧长但常用960 |
| 视频（H.264/H.265） | 90kHz | 3000（30fps） | 固定90kHz时钟 |
| 视频（VP8/VP9） | 90kHz | 3000（30fps） | 同上 |
你可能会问：为什么音频和视频的时钟频率不一样？说白了，音频的采样率就是它的时钟，而视频统一用90kHz是为了兼容各种帧率。30fps是3000，60fps是1500，25fps是3600，算起来方便。
1.3 播放时钟模型：接收端怎么用时间戳
发送端打好了时间戳，接收端怎么用？这里就要引入播放时钟模型了。常见的模型有两种：
- 本地时钟参考模型：接收端用自己的系统时钟来驱动播放。RTP时间戳只用来计算相对位置，不直接控制播放速度。
- RTP时间戳驱动模型：接收端直接根据RTP时间戳的差值来决定什么时候播放下一帧。这种模型对网络抖动更敏感。
我个人习惯用本地时钟参考模型。为什么？因为RTP时间戳在丢包场景下可能会乱，你直接用它驱动播放，音画同步反而容易出问题。本地时钟至少是稳定的，你只需要把RTP时间戳映射到本地时钟上就行。
小技巧：映射关系可以用一个简单的线性公式：playout_time = local_clock_base + (rtp_timestamp - rtp_timestamp_base) / clock_rate。其中local_clock_base是收到第一帧时的本地时间，rtp_timestamp_base是第一帧的RTP时间戳。
1.4 音画同步的核心：交叉同步
音频和视频各自有独立的时间戳序列，怎么让它们对齐？这就是交叉同步（Cross-Sync）要做的事。RTP规范里没有强制要求音频和视频的时间戳必须从同一个基准开始，但实际工程中，我们通常让它们共享一个参考时钟。
具体做法是这样的：
- 发送端在编码时，记录每个音频帧和视频帧的采集时间（用同一个时钟源）。
- 把采集时间映射成RTP时间戳，音频用采样率，视频用90kHz。
- 接收端收到后，分别计算音频和视频的播放时间，然后对齐。
我曾经踩过一个坑：某个项目里音频和视频用了不同的NTP服务器来同步时钟，结果两个时钟源之间有几十毫秒的偏差。音画同步怎么调都调不好，最后改成共用同一个时钟源才解决。所以啊，时钟源的一致性是音画同步的第一前提。
注意：如果音频和视频的RTP时间戳来自不同的时钟域（比如一个来自硬件编码器，一个来自软件编码器），接收端必须通过RTCP SR（Sender Report）中的NTP时间戳来建立映射关系。否则，音画同步就是空中楼阁。
1.5 知识体系总览
说了这么多，咱们用一张图把这一章的核心逻辑串起来。这张图展示了从发送端采集到接收端播放的完整链路：
从这张图你能看到，整个链路的关键节点有两个：一是发送端的时间戳生成必须基于共享时钟源，二是接收端必须用本地播放时钟来统一调度音频和视频的播放时刻。这两个节点只要有一个出问题，音画同步就悬了。
1.6 避坑指南
最后，分享几个我这些年积累的经验：
- 时间戳不要用系统绝对时间：RTP时间戳是相对值，用绝对时间反而会导致跨平台兼容性问题。
- 音频和视频的初始时间戳偏移量可以不同：但接收端必须通过RTCP SR来建立映射，不能想当然地认为它们从0开始。
- 播放时钟要容忍抖动：网络延迟不是恒定的，播放时钟需要有一个缓冲区（jitter buffer）来平滑波动。我一般建议音频缓冲区设40-80ms，视频设100-200ms。
- 别在时间戳上做算术溢出：32位时间戳在90kHz时钟下大约13小时会溢出一次。虽然实际场景很少连续播这么久，但做产品时还是要考虑回绕处理。
嗯，这一章的内容就到这里。时间戳机制和播放时钟模型是音画同步的根基，后面讲丢包场景下的策略时，你会反复用到这些概念。记住一句话：时间戳是音画同步的"语言"，播放时钟是"翻译官"。两者配合好了，音画同步才能稳如磐石。