1. 音画同步基础：理解PTS与DTS，音视频时间戳的本质与关系
做WebRTC开发这些年，我遇到过最头疼的问题之一就是音画不同步。用户那边嘴巴在动，声音却慢了一拍——这种体验真的很糟糕。要解决这个问题，首先得搞懂两个核心概念：PTS和DTS。
说白了，时间戳就是音视频数据的"身份证"。没有它，播放器根本不知道什么时候该显示哪一帧、什么时候该播放哪一段声音。
1.1 时间戳的本质：为什么需要它？
想象一下，你手里有一堆视频帧和一堆音频样本。如果没有时间戳，播放器只能按顺序一股脑往外丢。结果就是：视频帧可能比音频快，也可能比音频慢，完全乱套。
时间戳的作用，就是告诉播放器："这一帧应该在哪个时刻呈现"。
核心要点：时间戳是音视频同步的基石。没有精确的时间戳，任何同步算法都是空中楼阁。
在WebRTC中，时间戳的单位通常是毫秒(ms)。但要注意，视频和音频的时间戳基准可能不同——视频用90kHz时钟，音频用采样率。这就引出了第一个坑：
我曾经踩过的坑：视频时间戳是90kHz的tick，音频时间戳是采样率(如48000Hz)的tick。直接拿这两个数值做比较？结果就是同步完全错乱。必须统一换算成毫秒再比较。
1.2 PTS与DTS：一对孪生兄弟
很多初学者搞不清PTS和DTS的区别。我刚开始做音视频开发时也迷糊过。其实很简单：
- PTS (Presentation Time Stamp)：显示时间戳。告诉播放器"什么时候把这一帧显示出来"。
- DTS (Decoding Time Stamp)：解码时间戳。告诉解码器"什么时候开始解码这一帧"。
你可能会问：为什么需要两个？解码完直接显示不就行了？
嗯，问题出在B帧上。
1.3 B帧带来的麻烦
在视频编码中，帧有三种类型：
| 帧类型 | 全称 | 特点 |
|---|---|---|
| I帧 | 关键帧 | 完整图像，不依赖其他帧 |
| P帧 | 前向预测帧 | 依赖前面的I帧或P帧 |
| B帧 | 双向预测帧 | 依赖前后帧，需要先解码前后帧 |
B帧的问题在于：它需要参考后面的帧才能解码。所以解码顺序和显示顺序是不一致的。
举个例子：
显示顺序： I1 B2 B3 P4 B5 B6 P7
解码顺序： I1 P4 B2 B3 P7 B5 B6看到没？P4虽然显示在B2、B3后面，但解码时必须先解P4，因为B2、B3依赖它。这就是DTS和PTS不同的原因。
个人习惯：我在做WebRTC编码器配置时，通常会禁用B帧。虽然压缩率会降低一点，但能彻底避免DTS/PTS不一致的问题，同步逻辑简单很多。实时通信场景下，延迟比压缩率更重要。
1.4 时间戳的换算与对齐
WebRTC中，视频时间戳用90kHz时钟，音频时间戳用采样率时钟。换算公式很简单：
// 视频时间戳转毫秒
video_ms = video_timestamp / 90
// 音频时间戳转毫秒
audio_ms = audio_timestamp / sample_rate * 1000举个例子：
视频时间戳 = 90000 tick → 90000 / 90 = 1000 ms
音频时间戳 = 48000 tick (48kHz采样率) → 48000 / 48000 * 1000 = 1000 ms两者都表示第1秒的时刻，这才是正确的对齐方式。
注意：WebRTC的音频时间戳是累积的采样数，不是直接的时间值。比如48kHz采样率下，第1秒的音频时间戳就是48000。千万别把它当成毫秒数去比较！
1.5 音视频时间戳的关系图
下面这张图展示了音视频时间戳在采集、编码、传输、解码、渲染全流程中的关系：
1.6 实际项目中的常见问题
我在做WebRTC音画同步调优时，遇到过几个典型问题：
- 时间戳回绕：32位时间戳最大只能表示约13小时(90kHz时钟下)。长时间通话会溢出回绕，导致同步逻辑崩溃。
- 时间戳跳跃：网络抖动或丢包重传可能导致时间戳不连续，播放器需要做平滑处理。
- 音视频时间戳基准不一致：摄像头和麦克风可能使用不同的时钟源，导致时间戳漂移。
我的经验：处理时间戳回绕时，不要直接用差值比较。用带模运算的差值函数：int32_t diff = (int32_t)(ts1 - ts2)。这样即使回绕也能正确判断先后顺序。
1.7 小结
PTS和DTS是音视频同步的基础。记住三点：
- PTS决定"什么时候显示"，DTS决定"什么时候解码"
- B帧会导致DTS和PTS不一致，实时通信中建议禁用B帧
- 音视频时间戳单位不同，必须统一换算成毫秒再比较
搞懂了这些，后面讲WebRTC的NTP时间同步、RTP时间戳扩展、音画同步算法时，你就能轻松跟上节奏了。