14、音视频同步机制：时间戳管理、同步策略（AudioTrack vs VideoScheduler）、丢帧与重采样
音视频同步，圈里人常说的“A/V sync”，是多媒体开发里最磨人的问题之一。我做了这么多年MediaServer，坦白讲，每次遇到同步问题，都得打起十二分精神。你想想看，画面和声音对不上，用户第一反应就是“这播放器不行”。
这一章，我们就来拆解同步的核心。我会从时间戳管理讲起，然后对比AudioTrack和VideoScheduler的同步策略，最后聊聊丢帧和重采样这两个“救火队员”。
14.1 时间戳管理：同步的基石
同步靠什么？靠时间戳。没有准确的时间戳，一切策略都是空谈。
在Android MediaServer里，时间戳通常有两种：PTS（显示时间戳）和DTS（解码时间戳）。对于大多数场景，我们主要关注PTS。音频和视频各自维护一个时间轴，同步就是让这两个时间轴对齐。
核心原则：音频是“主时钟”，视频是“从时钟”。音频播放的连续性要求更高，丢一帧音频人耳立刻能察觉。视频稍微丢一帧，人眼反而不敏感。
时间戳管理有几个关键点：
- 基准时间统一：音频和视频的时间戳必须基于同一个时钟源。我见过不少项目，音频用系统单调时钟，视频用wall clock，结果同步永远对不上。
- 时间戳转换：不同容器格式的时间戳单位不同。比如MP4是毫秒，TS流是90kHz时钟。必须做统一转换。
- 起始偏移处理：有些视频流的第一帧PTS不是0，而是某个偏移值。需要做归一化处理。
// 时间戳归一化示例
int64_t normalizePTS(int64_t pts, int64_t basePTS) {
// 减去第一帧的PTS，让起始时间从0开始
return pts - basePTS;
}
// 不同时间单位转换
int64_t convertTimeScale(int64_t timestamp, int srcScale, int dstScale) {
// 比如从90kHz转成毫秒
return timestamp * dstScale / srcScale;
}
我的经验：曾经有个项目，视频流里混入了乱序的PTS。我花了两天排查，最后发现是解封装器里时间戳处理有bug。从那以后，我习惯在时间戳进入同步模块前，先做一次合法性校验——检查PTS是否单调递增，差值是否在合理范围内。
14.2 同步策略：AudioTrack vs VideoScheduler
Android里，音频走AudioTrack，视频走SurfaceFlinger。两者的同步策略完全不同。
14.2.1 AudioTrack：主时钟的担当
AudioTrack是同步的“锚点”。它内部维护了一个精确的播放位置计数器。我们可以通过getTimestamp()获取当前播放到的音频帧位置，然后换算成时间。
// 获取AudioTrack的播放位置
AudioTimestamp timestamp;
if (audioTrack.getTimestamp(timestamp) == SUCCESS) {
// timestamp.framePosition 是已播放的音频帧数
// 换算成时间：framePosition / sampleRate
int64_t audioTimeUs = timestamp.framePosition * 1000000 / sampleRate;
}
AudioTrack的同步策略很简单：它只管自己播放，不关心视频。视频需要主动去“追”音频的位置。
注意：AudioTrack的getTimestamp()在有些设备上可能不准确。我遇到过某款芯片，返回的framePosition会偶尔跳变。解决方案是加一个滑动平均滤波器，或者用多个采样点做中值滤波。
14.2.2 VideoScheduler：视频的“跟屁虫”
VideoScheduler的任务就是让视频帧在正确的时间显示。它的核心逻辑是：
- 拿到当前音频播放时间
- 计算下一帧视频的PTS与音频时间的差值
- 根据差值决定：立即显示、等待、还是丢帧
说白了，视频就是音频的“跟屁虫”。音频走到哪，视频就得跟到哪。
// VideoScheduler核心逻辑伪代码
void scheduleNextFrame(int64_t videoPtsUs) {
int64_t audioTimeUs = getAudioPlaybackTime();
int64_t diffUs = videoPtsUs - audioTimeUs;
if (diffUs < -THRESHOLD_DROP_US) {
// 视频落后太多，丢帧
dropFrame();
} else if (diffUs > THRESHOLD_WAIT_US) {
// 视频超前，等待
waitForTime(diffUs);
} else {
// 在同步窗口内，直接显示
presentFrame();
}
}
同步窗口：一般设置±40ms。在这个范围内，人眼感觉不到不同步。超过这个范围，就需要干预了。
14.3 丢帧与重采样：最后的救火队员
当同步偏差超出容忍范围时，就得用“非常手段”了。
14.3.1 丢帧策略
丢帧不是随便丢的。我总结了几条原则：
- 优先丢B帧：B帧依赖前后帧，丢了对后续解码影响最小。
- 不丢关键帧：丢I帧会导致后续所有帧都无法解码，这是灾难性的。
- 连续丢帧不超过2帧：丢太多会感觉画面卡顿。
我曾经踩过的坑：有一次为了追同步，连续丢了5帧P帧。结果画面直接卡住不动了，因为P帧的参考链断了。后来我加了一个“丢帧计数器”，每次丢帧后检查参考帧是否完整。
14.3.2 音频重采样
音频重采样是另一种同步手段。当音频播放速度与视频不匹配时，可以通过改变音频的采样率来微调速度。
比如，视频比音频慢了1%，我们可以把音频的采样率从44100Hz调整到44541Hz。这样音频播放速度变快，就能追上视频。
// 音频重采样调整速度
int adjustAudioSpeed(int originalSampleRate, double speedRatio) {
// speedRatio > 1.0 表示加速，< 1.0 表示减速
return (int)(originalSampleRate * speedRatio);
}
// 使用SoundTouch或类似库做重采样
SoundTouch soundTouch;
soundTouch.setSampleRate(originalSampleRate);
soundTouch.setTempoChange((speedRatio - 1.0) * 100);
注意：重采样会改变音调。虽然现代算法（如SoundTouch）能保持音调不变，但调整幅度超过5%时，音质会有明显下降。我一般限制在±3%以内。
14.4 整体同步流程
下面这张图展示了音视频同步的整体流程。你可以看到，音频作为主时钟，视频通过VideoScheduler不断调整自己的显示时机。
从图中可以看到，音频时间作为主时钟反馈给VideoScheduler。VideoScheduler根据偏差决定是直接显示、等待、还是触发丢帧或重采样。
14.5 实战中的避坑指南
最后，分享几个我在项目中遇到的坑：
- 不要迷信getTimestamp()：不同厂商的实现有差异。我建议在初始化时做一次校准，对比AudioTrack位置和系统时间。
- 丢帧要“温柔”：一次性丢太多帧，画面会“跳一下”。我习惯用渐进式丢帧——先丢一帧，观察同步情况，如果还不行再丢。
- 重采样要“留一手”：别把采样率调到极限。留点余量，防止音频播放器内部缓冲波动。
- 日志要打全：同步问题最难排查。我习惯每帧都打印PTS、音频时间、偏差值。虽然日志量大，但定位问题快。
总结一下：音视频同步没有银弹。时间戳管理是基础，AudioTrack和VideoScheduler各司其职，丢帧和重采样是最后的保障。关键是要理解你的场景——直播和点播的同步策略完全不同，硬件解码和软件解码的延迟特性也不一样。多测试、多打日志、多积累经验，这才是解决同步问题的王道。
公众号:蓝海资料掘金营，微信deep3321