10. 音视频同步机制：同步策略、时钟源选择、A/V同步算法、丢帧与插帧策略
音视频同步，圈里人常说的 A/V sync，是多媒体播放器里最磨人的环节。我早年刚接触 Stagefright 时，觉得解码、渲染这些才是硬功夫，同步嘛，不就是对个时间戳？后来被各种不同步的 case 折磨过之后，才明白这里面的水有多深。
说白了，音视频同步的核心就一句话：让音频和视频在正确的时刻被呈现出来。但实现起来，要考虑的东西太多了——时钟源选哪个？音频跟不上怎么办？视频掉队了是丢帧还是插帧？
嗯，我们一个一个来看。
10.1 同步策略：主时钟与从时钟
Stagefright 采用的是一种经典的主从同步策略。简单说，就是选一个时钟作为“老大”，另一个作为“小弟”。小弟要时刻跟着老大的节奏走。
具体到 Android 系统，音频输出设备（AudioTrack）通常被选为主时钟。为什么？因为人耳对声音的抖动比眼睛对画面的抖动敏感得多。你想想看，画面卡一下可能还能忍，声音一卡一卡的，或者忽快忽慢，那体验就彻底崩了。
所以，视频渲染器（VideoRenderer）会作为从时钟，不断去对比音频时钟的进度。如果视频跑快了，就等一等；跑慢了，就追一追。
核心原则：音频时钟是锚点，视频时钟向音频时钟对齐。
我在项目中遇到过一种特殊情况：某些设备在播放纯视频文件（没有音频轨道）时，音频时钟就不存在了。这时候 Stagefright 会退而求其次，使用系统单调时钟（CLOCK_MONOTONIC）作为主时钟。说白了，就是靠系统时间来驱动。
10.2 时钟源选择：AudioTrack 时钟 vs 系统时钟
时钟源的选择，直接决定了同步的精度。Stagefright 里主要有两种时钟源：
| 时钟源 | 来源 | 特点 | 适用场景 |
|---|---|---|---|
| AudioTrack 时钟 | 音频 HAL 层反馈的播放位置 | 精度高，与真实听觉同步 | 有音频轨道的视频播放 |
| 系统单调时钟 | CLOCK_MONOTONIC | 精度一般，但稳定可靠 | 无音频轨道、或音频时钟不可用 |
AudioTrack 时钟是怎么工作的？每次音频数据被写入硬件缓冲区，硬件会通过回调告诉上层“我已经播放到哪个位置了”。这个位置信息，就是视频同步的基准。
但这里有个坑。我记得有一次调试一个低端设备，发现视频总是比音频慢半拍。查了半天，原来是 AudioTrack 的时钟反馈有延迟——硬件报告的位置比实际播放位置慢了 100ms 左右。嗯，这就是典型的硬件问题，只能通过软件补偿来解决。
避坑指南：我曾经在某个平台上发现 AudioTrack 时钟在播放开始时会有短暂的不稳定期。建议在播放启动后的前 500ms 内，不要做严格的同步判断，否则容易误触发丢帧或插帧逻辑。
10.3 A/V 同步算法：时间戳比较与调整
有了时钟源，接下来就是具体的同步算法了。Stagefright 的同步逻辑，核心在 VideoRendererScheduler 和 MediaClock 这两个类里。
算法的基本流程是这样的：
- 获取当前音频时钟的时间
audioTimeUs。 - 获取当前视频帧的时间戳
videoTimeUs。 - 计算差值
diff = videoTimeUs - audioTimeUs。 - 根据差值大小，决定是等待、丢帧、还是插帧。
代码层面，核心逻辑大致如下：
// 伪代码，展示核心逻辑
int64_t diff = videoTimeUs - audioTimeUs;
if (diff > SYNC_THRESHOLD_MAX) {
// 视频比音频慢太多，丢帧
skipFrame();
} else if (diff < -SYNC_THRESHOLD_MIN) {
// 视频比音频快太多，插帧或等待
if (diff < -WAIT_THRESHOLD) {
waitForAudio(diff);
} else {
repeatFrame(); // 插帧
}
} else {
// 在同步范围内，正常渲染
renderFrame();
}这里有个关键点：阈值怎么设？我个人的习惯是，SYNC_THRESHOLD_MAX 设在 40ms 到 80ms 之间，SYNC_THRESHOLD_MIN 设在 -20ms 到 -40ms 之间。为什么不对称？因为人眼对视频落后的容忍度比对视频超前更低。你想想看，画面比声音慢，你会觉得口型对不上；画面比声音快一点点，反而不太容易察觉。
小技巧：不同内容类型可以设置不同的阈值。比如直播场景，延迟要求高，阈值可以设小一点；本地播放，流畅度优先，阈值可以适当放宽。
10.4 丢帧与插帧策略：何时舍弃，何时重复
丢帧和插帧，是同步算法的最后手段。说白了，就是当视频和音频实在对不齐时，通过牺牲一些帧来换取同步。
丢帧策略
什么时候丢帧？当视频帧比音频时钟落后太多时。比如视频解码器突然卡了一下，积压了好几帧，这时候如果一帧一帧地渲染，视频就会越来越慢。
Stagefright 的丢帧逻辑是这样的：
- 如果当前帧的时间戳比音频时钟落后超过 40ms，直接跳过。
- 如果连续多帧都落后，可以一次跳过多个帧，直到追上音频时钟。
- 但要注意，不能无限制丢帧。我建议设置一个最大连续丢帧数，比如 5 帧，超过这个数就强制渲染一帧，否则画面会长时间静止。
经验之谈：我曾经在一个项目里发现，如果丢帧太频繁，用户会感觉到画面“跳了一下”。后来我们加了一个平滑策略——丢帧时不是直接跳过，而是把这一帧的渲染时间压缩到原来的一半。这样画面看起来是加速了，而不是跳过了。
插帧策略
插帧的情况正好相反。当视频帧比音频时钟超前太多时，就需要重复显示上一帧，或者插入一帧。
Stagefright 的插帧逻辑：
- 如果当前帧比音频时钟超前超过 20ms，就保持上一帧不变，等待音频追上来。
- 如果超前太多（比如超过 100ms），可以考虑重复显示上一帧，或者插入一个中间帧。
- 插入中间帧的做法比较复杂，需要做帧间插值。Stagefright 默认不开启这个功能，因为计算量太大。
嗯，这里要注意，插帧不是越多越好。插帧多了，画面会显得“粘滞”，有拖影感。我个人的建议是，插帧只作为临时手段，不要持续插帧超过 3 帧。
10.5 整体同步流程
为了让你更直观地理解整个同步流程，我画了一张图：
从图上可以看得很清楚：音频时钟优先，系统时钟兜底。同步计算模块拿到时钟后，比较时间戳差值，然后做出丢帧、等待或插帧的决策。最终，经过调整后的视频帧被送到渲染器输出。
这个流程看起来简单，但实际调试起来，坑很多。我建议你在做同步优化时，先把日志打全——记录每一帧的时间戳、音频时钟、差值、决策结果。有了数据，才能对症下药。
调试建议：在 VideoRendererScheduler 里加一些关键日志，输出格式类似：[AVSync] frameTime=12345678 audioTime=12345700 diff=-22 action=WAIT。这样一眼就能看出问题在哪。
好了，音视频同步这块，核心就是这些。时钟源选对，阈值设好，丢帧插帧策略合理，大部分同步问题都能解决。剩下的，就是针对具体设备和场景的微调了。