1、音画同步基础：音画不同步的成因、PTS/DTS 时间戳概念、音画同步的数学模型

做多媒体系统这么多年，我见过最多的线上问题就是音画不同步。用户抱怨「嘴型对不上」「声音超前画面半秒」，说白了就是播放体验直接崩了。今天咱们就从根上把这个问题拆清楚。

为什么会不同步？我总结下来，核心原因就三个字：时间差。音频和视频在采集、编码、传输、解码、渲染这条链路上，走的路径不一样，处理时间也不一样。

主要成因清单：

采集端时钟不同源：摄像头和麦克风各自有自己的时钟晶振，频率漂移会导致采样点错位。我在项目中遇到过，两个设备用不同晶振，跑半小时就差了 40ms。
编码/解码延迟不对称：视频编码通常比音频复杂得多，H.264 编码一帧可能耗时 10-30ms，而 AAC 编码一帧只要 2-3ms。解码端同理。
网络抖动与缓冲策略：网络传输中，视频帧可能比音频帧晚到，或者丢包重传导致乱序。播放器如果没做好缓冲对齐，画面就追不上声音。
渲染管线差异：音频渲染是连续的流式输出，视频渲染是离散的帧刷新。显示器的刷新率（60Hz/120Hz）和音频输出设备的缓冲区大小（比如 512 样本）都会引入额外延迟。

你想想看，这些因素叠加在一起，哪怕每个环节只差几毫秒，累积下来就是肉眼可见的「口型对不上」。我早期做直播项目时，就因为没处理好采集端时钟漂移，被用户骂了整整一周。

要解决不同步，首先得给每一帧数据打上「时间标签」。这就是 PTS 和 DTS 的由来。

缩写	全称	含义	我的理解
PTS	Presentation Time Stamp	该帧应该被显示的时间	观众看到这帧的时刻
DTS	Decoding Time Stamp	该帧应该被解码的时间	解码器开始干活的时间

为什么需要两个时间戳？因为视频编码里存在 B 帧（双向预测帧）。B 帧需要参考前后的帧才能解码，所以解码顺序和显示顺序不一样。

举个例子：

假设一个 GOP（图像组）的帧顺序是：I1 - B2 - B3 - P4。

解码顺序（DTS）：I1 → P4 → B2 → B3

显示顺序（PTS）：I1 → B2 → B3 → P4

看到了吗？P4 必须先解码，B2 和 B3 才能显示。所以 DTS 和 PTS 是两套时间轴。

我个人习惯在代码里把 PTS 和 DTS 当作两个独立变量来维护，绝不混用。曾经有个同事把 PTS 当 DTS 用，结果 B 帧全部花屏，排查了三天才找到原因。

有了时间戳，接下来就是对齐。音画同步本质上是一个时间轴对齐问题。我把它抽象成下面这个模型：

同步条件：

| PTS_audio - PTS_video | < 阈值

通常阈值取 ±20ms（人耳/人眼能感知的极限）。超过这个范围，用户就会觉得不同步。

实际工程中，我们用一个 主时钟（Master Clock） 来统一调度。音频和视频各自维护一个缓冲区，播放器根据主时钟的时间戳决定「现在该播哪一帧」。

我常用的同步策略是：

以音频为基准：音频输出是连续的，一旦中断用户立刻能感知。所以让视频去追音频。
计算差值：当前音频 PTS 减去当前视频 PTS，得到偏移量 Δ。
调整策略：
- 如果 Δ > 40ms（视频落后）：丢弃视频帧，追赶上音频。
- 如果 Δ < -40ms（视频超前）：重复显示上一帧，等待音频。
- 如果 |Δ| ≤ 20ms：正常播放，不做调整。

注意： 调整策略不能太激进。我曾经在项目里把阈值设成 10ms，结果视频频繁丢帧和重复，画面反而更卡。后来改成 20ms 才稳定下来。这个值跟内容类型有关——电影可以松一点，直播要严一点。

下面这张图展示了音画同步的核心流程，我画了张 SVG 方便你理解：

这个模型看起来简单，但实际落地时坑很多。比如主时钟的选择——我习惯用音频的 PTS 做主时钟，因为音频输出是连续的，一旦中断用户立刻能感知。视频是离散帧，丢一帧或者重复一帧，用户不一定能察觉。

避坑指南：

我曾经在 Android 平台上遇到过一个坑：音频设备的时钟和系统时钟不同步，导致音频 PTS 一直在漂移。后来我改用 系统单调时钟（CLOCK_MONOTONIC） 作为主时钟，音频和视频的 PTS 都换算成这个时钟域，才彻底解决。