音画同步原理：从时间戳到唇音同步

音画不同步，说白了就是音频和视频在时间轴上「走岔了」。你想想看，视频帧已经播到第 30 帧了，音频还在第 25 帧的位置磨蹭。观众看到的是张嘴，听到的是闭嘴——这体验，谁受得了？

我在项目中遇到过最离谱的一次，延迟差了将近 2 秒。用户投诉说「你们这是配音版吧？」嗯，从那以后，我对时间戳的敬畏心就拉满了。

音画不同步的成因分析

为什么会不同步？我把它归结为三大类：

• 采集端时钟漂移：音频采集卡和摄像头用的是不同的晶振。一个跑 48kHz，一个跑 30fps，但晶振都有误差。时间一长，偏差就累积起来了。
• 网络传输抖动：RTP 包走 UDP，没有重传保证。有的包先发后到，有的包后发先到。接收端如果按到达顺序播放，那画面和声音就彻底对不上了。
• 编解码延迟不一致：视频编码通常比音频慢。H.264 编码一帧可能要 10-20ms，而 AAC 编码一帧只要几毫秒。如果发送端不等视频，直接发音频，接收端就会先听到声音，后看到画面。

RTP 时间戳与 NTP 时间的关系

RTP 时间戳是干什么用的？它标记的是媒体数据的「采样时刻」。但有个坑：RTP 时间戳是相对于媒体时钟的，不是绝对时间。比如音频用 48kHz 时钟，每采样一次计数器加 1。这个计数器值就是 RTP 时间戳。

那问题来了：接收端拿到两个流的 RTP 时间戳，怎么知道它们是不是同一时刻采样的？

答案就在 RTCP 的 Sender Report（SR）包里。SR 包里同时携带了 NTP 时间戳 和 RTP 时间戳 的映射关系。

字段	含义	作用
NTP 时间戳	绝对时间（秒 + 微秒）	统一的时间参考系
RTP 时间戳	媒体时钟计数	帧/样本的播放顺序
SR 包	NTP ↔ RTP 映射	桥接两个时间域

举个例子：SR 包说「NTP 时间 = 1000s 时，音频 RTP 时间戳 = 48000，视频 RTP 时间戳 = 300」。接收端收到一个音频包 RTP 时间戳 = 48000，一个视频包 RTP 时间戳 = 300，就知道它们是在同一时刻采样的。播放时对齐这两个时间点，唇音就同步了。

发送端时间戳生成策略

发送端怎么做？我总结了一套「三步走」策略：

1. 统一时钟源：音频和视频采集线程，都从同一个 NTP 时钟获取绝对时间。不要各用各的晶振。
2. 计算 RTP 时间戳：用 NTP 时间换算成媒体时钟计数。公式很简单：RTP_ts = (NTP_time - NTP_base) × clock_rate。其中 clock_rate 音频是 48000，视频是 90000。
3. 定期发送 SR 包：把当前 NTP 时间和对应的 RTP 时间戳打包发出去。接收端靠这个映射来对齐。

// 伪代码：发送端时间戳生成
uint32_t generate_rtp_timestamp(uint64_t ntp_time, uint32_t clock_rate) {
    static uint64_t ntp_base = 0;
    if (ntp_base == 0) {
        ntp_base = ntp_time;  // 第一次采样时记录基准
    }
    uint64_t delta_us = (ntp_time - ntp_base) * 1000000 / (1 << 32);
    return (uint32_t)(delta_us * clock_rate / 1000000);
}

接收端时间戳解析与同步

接收端的工作更复杂。你拿到两个流的数据包，每个包都有 RTP 时间戳。怎么把它们对齐到同一个时间轴上？

我习惯用「参考时间轴法」：

• 以 NTP 时间为基准轴
• 每个媒体包到达后，用最近的 SR 映射，把 RTP 时间戳换算成 NTP 时间
• 音频和视频都换算到同一个 NTP 时间轴后，直接比较时间戳就能决定谁先播放

具体步骤：

1. 缓存 SR 映射：收到 SR 包后，保存 (NTP, RTP) 映射对。至少保留最近两个 SR 包，用于插值。
2. 换算时间戳：对每个媒体包，用最近的 SR 映射计算对应的 NTP 时间。
3. 计算播放延迟：音频和视频分别维护一个播放队列。比较队列头部的 NTP 时间，差值超过阈值（比如 40ms）就触发同步调整。
4. 调整策略：如果视频比音频快，就丢帧或拉长显示时间；如果视频比音频慢，就重复帧或缩短显示时间。

// 伪代码：接收端时间戳换算
uint64_t rtp_to_ntp(uint32_t rtp_ts, uint32_t clock_rate,
                    uint64_t sr_ntp, uint32_t sr_rtp) {
    // 计算 RTP 时间戳差值（处理回绕）
    int32_t delta = (int32_t)(rtp_ts - sr_rtp);
    // 换算成 NTP 时间（微秒）
    uint64_t delta_us = (uint64_t)delta * 1000000 / clock_rate;
    return sr_ntp + delta_us;
}

音画同步的核心流程

我把整个流程画了一张图，方便你理解：

这张图把整个流程串起来了。发送端从统一时钟源出发，音频和视频各自生成 RTP 时间戳，同时定期发送 SR 包。接收端拿到 SR 映射后，把两个流的 RTP 时间戳都换算到 NTP 时间轴，然后比较、调整、播放。