3. 音视频同步原理

在 RTSP 流媒体部署中，音画不同步是最常见、也最容易被误判为“网络卡顿”的问题。要真正定位它，必须回到同步的底层机制：媒体数据本身并不携带“播放时刻”，播放时刻是由时间戳与本地时钟共同推导出来的。理解时间戳、时钟频率、PTS/DTS、抖动、延迟与同步误差这六个概念，就掌握了音画同步的分析语言。

一、核心原理：时间戳是媒体自己的时间坐标

音视频同步的本质，是让接收端在“正确的时间”呈现“正确的数据”。RTP 包中的时间戳（Timestamp）并不是墙上时钟，而是以采样率为单位的计数。对于 48 kHz 音频，时间戳每增加 48000 代表前进 1 秒；对于 90 kHz 视频时钟，每增加 90000 代表前进 1 秒。因此，时间戳必须结合时钟频率才能换算成真实时间。

换算关系可以写成：

媒体时间(秒) = RTP时间戳差值 / 时钟频率
音频：Δt = Δts / 48000
视频：Δt = Δts / 90000

PTS（Presentation Time Stamp）表示“这一帧应该在什么时刻被显示或播放”，DTS（Decoding Time Stamp）表示“这一帧应该在什么时刻被解码”。在没有 B 帧的简单编码中，PTS 与 DTS 相同；一旦存在 B 帧，解码顺序与显示顺序分离，DTS 必须早于 PTS，否则解码器无法在正确时刻输出参考帧。RTSP 传输的 RTP 时间戳最终会被映射为 PTS，而 DTS 由容器或码流中的信息给出。

二、时钟频率与时钟漂移：同步的隐形敌人

发送端和接收端各自拥有独立时钟。即使都标称 48 kHz 或 90 kHz，实际频率也会有微小偏差，称为时钟漂移（Clock Drift）。假设音频时钟比视频时钟快 0.01%，播放一小时后就会累积约 360 毫秒的偏差，足以让人耳察觉口型不对。因此，实际系统通常以音频为主时钟（Audio Master），视频向音频对齐，因为人耳对音频断续更敏感。

RTCP 的 SR（Sender Report）报文携带 NTP 时间与 RTP 时间戳的对应关系，接收端据此计算时钟偏移和网络往返时延，并动态调整播放节奏。没有 RTCP 或 RTCP 被阻断时，接收端只能依赖本地估算，漂移会持续累积。

三、抖动、延迟与同步误差：三个容易混淆的量

抖动（Jitter）是数据包到达时间间隔的变化量，反映网络传输的不稳定；延迟（Latency）是数据从发送到可播放所经历的总时间；同步误差（Sync Error）是音频与视频在呈现时刻上的差值。三者关系密切但不等价：抖动大不一定同步误差大，只要缓冲区足够；延迟大也不一定不同步，只要音视频延迟一致。

四、方法流程：从时间戳到同步播放

一个典型的 RTSP 接收端同步流程如下：

1. 接收 RTP 包，读取 RTP 时间戳与序列号，按序列号排序并检测丢包。
2. 通过 RTCP SR 建立 RTP 时间戳与 NTP 墙钟的映射，得到每个包的“绝对媒体时间”。
3. 将 RTP 时间戳换算为 PTS，视频帧按 DTS 送入解码器，按 PTS 送入渲染队列。
4. 抖动缓冲吸收到达间隔波动，通常设置为 50~200 ms，过大增加延迟，过小导致丢帧。
5. 以音频时钟为主时钟，视频渲染时比较自身 PTS 与音频当前播放时间，偏差超过阈值时丢帧或重复帧。
6. 持续用 RTCP 反馈校正时钟漂移，避免长时间播放后误差累积。

五、案例场景：一次口型不同步的排查

某监控项目使用 RTSP 拉流，播放 20 分钟后画面比声音慢约 300 ms。排查发现：RTCP 端口被防火墙拦截，接收端无法获得 SR 映射，只能以本地时钟估算；同时音频时钟实际为 47990 Hz，与标称 48000 Hz 存在漂移。修复方式是放行 RTCP 端口，并在播放器中启用音频主时钟与漂移补偿。修复后同步误差稳定在 40 ms 以内。

六、复盘要点与参数清单

• 时间戳必须结合时钟频率换算，不能直接比较数值大小。
• PTS 决定显示时刻，DTS 决定解码时刻，有 B 帧时二者不同。
• 抖动靠缓冲吸收，延迟靠架构优化，同步误差靠主时钟对齐。
• RTCP SR 是消除时钟漂移的关键，部署时务必放行 RTCP 通道。
• 可接受的同步误差通常为音频超前视频不超过 25 ms、音频滞后不超过 45 ms，工程上常以 80 ms 为上限。

掌握这六个概念后，再面对音画不同步，就可以按“时间戳换算 → 时钟频率核对 → PTS/DTS 排序 → 抖动缓冲 → 延迟测量 → 同步误差计算”的顺序逐层排查，而不是盲目重启或加大缓冲。