2. WebRTC基础回顾
聊完音画同步的基础概念，咱们得钻进WebRTC的源码里看看了。说实话，我第一次打开WebRTC的同步代码时，心里是有点懵的——代码量不小，调用链也长。但摸清楚之后你会发现，核心就一个模块：SyncModule。
我习惯把它叫做“同步大脑”。所有音视频流的对齐决策，都是它做的。今天咱们就把这个大脑拆开看看。
2.1 整体架构：谁在负责同步？
先看一张整体架构图。WebRTC的同步不是某个单一函数搞定的，而是一套分层协作的体系。
核心角色有三个：
- SyncModule：决策层。负责计算音视频时间戳的偏差，决定要不要丢帧、要不要拉长缓冲区。
- JitterBuffer（抖动缓冲）：执行层。音频和视频各自有一个JitterBuffer，负责抗网络抖动，同时为SyncModule提供时间戳参考。
- RTP接收器：数据层。负责解析RTP包，提取时间戳、序列号、SSRC等信息。
说白了，RTP接收器把原始数据喂给JitterBuffer，JitterBuffer做初步的排序和缓冲，然后SyncModule根据两边的进度，发出“快进”或“等待”的指令。
你看，整个链路是单向的：数据进来，缓冲，同步决策，最后渲染。SyncModule处于中间位置，它不直接处理RTP包，也不直接驱动渲染，它只做一件事——判断当前音视频是否对齐。
2.2 SyncModule 到底在算什么？
SyncModule的核心逻辑，说白了就是一个数学公式：
音视频偏差 = 音频当前播放时间 - 视频当前播放时间但这个“当前播放时间”怎么算？我刚开始看代码时也困惑过。其实它依赖两个关键信息：
- RTP时间戳：每个音视频包都带一个时间戳，但音频和视频的时钟频率不同（音频通常48kHz，视频通常90kHz）。所以不能直接比大小。
- NTP时间：发送端会在RTCP SR（Sender Report）里带上NTP时间戳，这是全局统一的绝对时间。SyncModule用NTP时间把RTP时间戳映射到同一个时间轴上。
一个小技巧：调试同步问题时，我习惯先看RTCP SR包里的NTP时间是否连续。如果发送端的NTP时间跳变，那接收端再怎么调也白搭。我曾经遇到过某个定制版WebRTC发送端NTP时间戳写死了0，结果接收端音视频永远对不上。
2.3 同步决策：三种武器
SyncModule算出偏差后，会采取三种策略之一。我整理了一张表，方便你对照：
| 偏差范围 | 策略 | 具体操作 | 我踩过的坑 |
|---|---|---|---|
| 音频领先 > 30ms | 等待音频 | 视频渲染暂停，等音频追上来 | 等待太久会导致视频卡顿感明显，建议上限设80ms |
| 视频领先 > 30ms | 丢视频帧 | 跳过当前视频帧，直接渲染下一帧 | 连续丢帧超过3帧，用户会感觉画面跳跃 |
| 偏差 < 30ms | 不做处理 | 人耳/人眼感知不到，保持现状 | 阈值别设太严，否则频繁切换策略反而更糟 |
嗯，这里要注意：丢视频帧是WebRTC的默认偏好。为什么？因为丢一帧视频，用户可能感觉不到；但音频如果丢一个包或者拉伸一下，人耳非常敏感。所以SyncModule的优先级是：保音频流畅 > 保视频对齐。
2.4 音频的“时间拉伸”是怎么回事？
刚才说的策略里，音频领先时是“等待”，但还有一种情况：音频落后了怎么办？
WebRTC的音频处理链路里有一个叫NetEQ的模块，它支持时间拉伸（Time Scaling）。说白了，就是通过算法把音频信号稍微拉长或压缩，而不改变音调。SyncModule可以告诉NetEQ：“你加速5%”，这样音频就能追上视频。
注意：时间拉伸不是万能的。拉伸比例超过10%，人耳就能听出“变声”或“回声”。我建议生产环境中把拉伸比例限制在5%以内。如果你做的是音乐类应用，甚至建议关闭时间拉伸，只靠丢帧来同步。
2.5 视频的“渲染时钟”怎么对齐？
视频这边，SyncModule不直接控制渲染。它通过一个叫VideoRenderScheduler的组件来调整渲染时机。
具体流程是这样的：
- SyncModule计算出当前视频帧应该显示的时间（基于音频时钟）。
- VideoRenderScheduler拿到这个时间，和当前系统时间对比。
- 如果应该显示的时间还没到，就等一会儿；如果已经过了，就立即渲染（或者丢帧）。
你可能会问：为什么不用视频自己的时钟？因为视频时钟可能不准。我遇到过一种情况：某款Android手机的硬件视频解码器输出的时间戳偶尔会跳变，导致视频忽快忽慢。SyncModule用音频时钟做参考，相当于给视频加了一个“稳定器”。
2.6 避坑指南：我踩过的三个坑
做音画同步调试，有些坑是绕不开的。我分享三个亲身经历：
- 坑一：音频设备延迟不一致。同一台机器，用扬声器输出和用耳机输出，音频延迟能差50ms。SyncModule默认假设音频延迟是固定的，但实际不是。解决方案是在应用层做一次延迟校准。
- 坑二：视频解码器缓存。有些硬件解码器内部会缓存几帧数据，导致SyncModule以为视频已经渲染了，其实还在解码器里排队。这时候需要从解码器回调里拿真实渲染时间戳。
- 坑三：多路流场景。如果你做的是多人会议，每个远端用户都有自己的SyncModule实例。但本地音频只有一个时钟，多个SyncModule同时调整，可能会互相干扰。我当时的做法是：以主说话人的音频时钟为准，其他用户的视频去对齐这个时钟。
2.7 小结：SyncModule 的价值
SyncModule虽然代码量不大，但它是整个WebRTC同步体系的“大脑”。没有它，音视频就是两条独立的河流，各流各的。有了它，两条河才能汇到同一个时间轴上。
我个人觉得，理解SyncModule的关键就三点：
- 它依赖NTP时间做全局对齐，而不是直接比RTP时间戳。
- 它优先保音频流畅，视频可以丢帧。
- 它的决策是动态的，每帧都在算，每帧都在调。