2. 同步原理剖析：音频时钟与视频时钟的关系，PTS/DTS 时间戳机制
做音视频开发，绕不开一个核心问题——时钟。说白了，音频有音频的节奏，视频有视频的帧率，它们各自独立运行。想让它们步调一致，就得靠一套精准的时钟同步机制。我刚开始接触这块时，也以为只要把数据丢给解码器就行，结果画面和声音总是对不上。后来才明白，时钟才是音画同步的基石。
2.1 音频时钟与视频时钟：两个独立的“心跳”
音频时钟和视频时钟，本质上是两个独立的计时器。音频时钟通常由声卡的采样率驱动，比如 44100Hz 或 48000Hz。视频时钟则由显示器的刷新率或视频帧率驱动，比如 24fps、30fps 或 60fps。
你想想看，这两个时钟的“滴答”速度完全不同。音频时钟每秒钟跳几万次，视频时钟每秒钟跳几十次。要让它们对齐，就需要一个共同的参考系。
核心概念：系统时钟（STC, System Time Clock）是音视频同步的基准。音频时钟和视频时钟都需要以 STC 为参考，进行校准。
我在项目中遇到过一个问题：播放器在播放某些 MP4 文件时，声音正常，但画面越来越卡。排查后发现，是视频解码器没有正确参考音频时钟，导致视频帧堆积。嗯，这里要注意，视频时钟不能独立于音频时钟运行，尤其是在直播场景中。
2.2 PTS 与 DTS：时间戳的“身份证”
每个音频帧和视频帧，都带着两个重要的时间戳：PTS（Presentation Time Stamp，显示时间戳）和 DTS（Decoding Time Stamp，解码时间戳）。
PTS 告诉播放器：这一帧应该在什么时候显示。DTS 告诉解码器：这一帧应该在什么时候解码。对于大多数音频帧来说，PTS 和 DTS 是相同的，因为音频帧通常按顺序解码、按顺序播放。但视频帧就不一样了。
为什么？因为视频编码中使用了 B 帧（双向预测帧）。B 帧需要参考前后的帧才能解码，所以解码顺序和显示顺序可能不一致。举个例子：
| 帧类型 | 解码顺序（DTS） | 显示顺序（PTS） |
|---|---|---|
| I 帧 | 1 | 1 |
| P 帧 | 2 | 4 |
| B 帧 | 3 | 2 |
| B 帧 | 4 | 3 |
你看，B 帧的解码顺序是 3 和 4，但显示顺序却是 2 和 3。如果播放器按照 DTS 来显示画面，那画面顺序就全乱了。所以，播放器必须根据 PTS 来决定何时渲染画面。
避坑指南：我曾经在开发一个播放器时，直接用了 DTS 来驱动视频渲染，结果画面跳跃严重。后来才意识到，必须用 PTS 来对齐显示时间。记住：解码用 DTS，显示用 PTS。
2.3 音画同步的核心逻辑：谁追谁？
音画同步的策略，说白了就是“谁慢等谁，谁快追谁”。但具体怎么实现？通常有两种主流方案：
- 音频为主，视频为辅：以音频时钟为基准，视频帧根据音频时钟的 PTS 来调整显示时间。这是最常见的方案，因为人耳对声音的抖动更敏感。
- 视频为主，音频为辅：以视频时钟为基准，音频帧根据视频时钟的 PTS 来调整播放速度。这种方案在视频编辑或特效合成中比较常见。
我个人习惯用第一种方案。原因很简单：人耳对声音的延迟或超前非常敏感，稍微有点偏差就能察觉。而人眼对画面的轻微抖动容忍度更高。所以，让视频去追音频，用户体验更好。
具体实现时，播放器会维护一个主时钟（通常是音频时钟），然后不断比较当前视频帧的 PTS 与主时钟的差值：
- 如果视频帧的 PTS 比主时钟早太多（比如超过 100ms），说明视频落后了，需要丢帧或加速渲染。
- 如果视频帧的 PTS 比主时钟晚太多（比如超过 100ms），说明视频超前了，需要等待或减速渲染。
- 如果差值在可接受范围内（比如 ±20ms），则正常渲染。
注意：丢帧和重复帧是最后的手段。频繁丢帧会导致画面卡顿，频繁重复帧会导致画面抖动。我建议优先调整渲染速度，而不是直接丢帧。
2.4 时间戳的生成与传递：从编码到解码
时间戳不是在播放时才生成的，而是在编码阶段就确定了。编码器在封装媒体文件时，会根据帧率或采样率为每个帧打上 PTS 和 DTS。这些时间戳会写入容器格式（如 MP4、TS、FLV）的元数据中。
解码器读取这些时间戳后，会按照 DTS 顺序解码，然后按照 PTS 顺序输出。播放器拿到解码后的帧，再根据 PTS 和主时钟进行同步。
这里有一个常见的坑：时间戳的基值（time_base）不一致。不同的容器格式或编码器可能使用不同的时间基，比如 1/1000 秒（毫秒）或 1/90000 秒（MPEG-TS 标准）。如果播放器没有正确转换时间基，PTS 和 DTS 就会算错，导致音画不同步。
// 示例：时间基转换（FFmpeg 风格）
// 假设原始时间基是 1/90000，PTS 值为 180000
// 目标时间基是 1/1000（毫秒）
int64_t pts_original = 180000;
AVRational time_base_original = {1, 90000};
AVRational time_base_target = {1, 1000};
// 转换公式：pts_target = pts_original * time_base_original / time_base_target
int64_t pts_target = pts_original * time_base_original.num * time_base_target.den /
(time_base_original.den * time_base_target.num);
// 结果：pts_target = 180000 * 1 * 1000 / (90000 * 1) = 2000 毫秒
你看，如果不做这个转换，直接拿 180000 当毫秒用，那画面就差了 180 秒。嗯，这个坑我踩过，后来在代码里加了一层时间基校验，才彻底解决。
2.5 知识体系总览
下面这张图，把音频时钟、视频时钟、PTS/DTS 的关系梳理清楚了。你可以把它当作本章的思维导图。
从这张图可以看出，系统时钟（STC）是所有时间戳的源头。音频时钟和视频时钟都基于 STC 生成各自的 PTS/DTS。同步比较器则负责将视频 PTS 与音频时钟进行对比，最终输出同步后的画面和声音。