1. 音频同步基础：时间戳、PTS/DTS 与三种同步模型

各位好，我是老周。做音视频封装解析这行十几年了，踩过的坑比写过的代码还多。今天咱们聊聊音频同步的基础——说白了，就是怎么让声音和画面“对上嘴”。

你想想看，一个视频文件里，音频和视频是分开存储的。播放器得把它们拉回来，在正确的时间点同时输出。这活儿听着简单，做起来全是细节。我刚开始做播放器的时候，就遇到过声音比画面快了两秒的情况——用户骂街，产品经理拍桌子，那叫一个酸爽。

1.1 时间戳——同步的“锚点”

时间戳（Timestamp）是同步的基础。每个音频帧、每个视频帧，都带着一个时间标签，告诉播放器：“我应该在什么时候被呈现”。

常见的封装格式里，时间戳有两种表示方式：

• PTS（Presentation Time Stamp）——显示时间戳，告诉播放器“什么时候该给我出来”。
• DTS（Decoding Time Stamp）——解码时间戳，告诉解码器“什么时候该解码我”。

对于音频来说，PTS 和 DTS 通常是相等的。为什么？因为音频帧之间没有复杂的依赖关系，不需要像视频那样搞 B 帧预测。但视频就不一样了——B 帧需要参考前后帧，所以 DTS 可能比 PTS 早。

1.2 PTS 与 DTS 的原理

咱们用一张图来理解 PTS 和 DTS 的关系。这张图我当年画在白板上给团队讲过不下十遍。

看到没？音频的 PTS 和 DTS 是一条直线，视频那边就乱了。B 帧的 DTS 比 PTS 晚，因为它得等后面的 P 帧先解码。这就是为什么解复用器（demuxer）必须把 DTS 和 PTS 都传给解码器——不然解码顺序就乱了。

1.3 音视频同步的三种模型

好，时间戳搞清楚了。那怎么让音频和视频“步调一致”呢？业界有三种主流模型。我一个个说。

模型一：音频为主（Audio Master）

这个模型最简单——以音频时钟为基准，视频去追音频。为什么？因为音频是连续流，播放节奏由声卡驱动，很稳定。视频帧率可能有波动，但音频的采样率是固定的。

具体做法：

• 播放器从声卡获取当前音频播放位置（Audio Clock）。
• 视频渲染器根据这个位置，计算当前应该显示哪一帧。
• 如果视频落后了，就丢帧追赶；如果超前了，就等待。

模型二：视频为主（Video Master）

这个模型反过来——以视频时钟为基准，音频去追视频。什么时候用？比如视频会议、远程桌面这类场景，画面的实时性比声音更重要。你想想，开会时画面卡了，大家会喊“你卡了”；声音卡了，大家会喊“你说啥？”——嗯，其实都挺要命的。

但说实话，这个模型用得不多。因为音频是连续流，要“追赶”视频就得做变速处理——要么拉长/缩短音频帧，要么插入/删除静音段。处理不好，声音会变调或者出现爆音。

模型三：外部时钟（External Clock）

这个模型最“公平”——音频和视频都不当老大，而是共同参考一个外部时钟源。这个时钟可以是系统时钟（System Clock），也可以是 NTP 时间（网络时间协议）。

具体流程：

1. 播放器维护一个全局时钟，比如用 clock_gettime() 获取单调时间。
2. 音频和视频各自计算自己的 PTS 与全局时钟的差值。
3. 如果差值超过阈值，就进行微调——音频做重采样，视频做丢帧或插帧。

这个模型的好处是——音频和视频互不干扰，各自独立调整。适合对同步精度要求高的场景，比如广电级的播出系统。

模型	基准源	优点	缺点	适用场景
音频为主	声卡时钟	音频稳定，人耳友好	视频可能丢帧	本地播放、点播
视频为主	显示器刷新率	画面实时性好	音频易失真	视频会议、远程桌面
外部时钟	系统/NTP 时钟	精度高，互不干扰	实现复杂	广电、直播推流

1.4 三种模型的对比与选择

你可能会问：“老周，那我到底该用哪个？”

我的建议是——看场景。做本地播放器，无脑选音频主模型。做直播推流，外部时钟更靠谱。做视频会议，视频主模型虽然坑多，但有时候不得不选。

嗯，这里要注意一点：不管选哪个模型，都要处理“漂移”问题。音频和视频的时钟不可能完全同步，时间长了偏差会越来越大。所以需要定期校准——比如每 100ms 检查一次 PTS 差值，超过 30ms 就触发调整。