1. 课程导入
各位同学，咱们开始第一讲。
做WebRTC开发，音画同步是个绕不开的坎。我见过太多项目，视频流清晰、音频流流畅，但一开口就对不上嘴型——用户直接骂娘。说白了，音画不同步是体验的致命伤。
这一章，我们先打好地基。把RTP时间戳、NTP同步、唇同步误差这三个核心概念吃透。后面实战才不会慌。
1.1 RTP时间戳机制：音视频流的“心跳”
RTP时间戳是什么？我习惯把它理解成“采样时刻的标签”。
发送端每采集一帧视频或一段音频，就给它盖个时间戳。接收端拿到数据后，根据这个戳来决定什么时候播放。
核心要点：RTP时间戳是单调递增的，单位取决于采样时钟频率。视频常用90kHz，音频常用48kHz或16kHz。
举个例子。视频帧率30fps，每帧间隔约33ms。在90kHz时钟下，时间戳增量就是 0.033 × 90000 ≈ 3000。所以你会看到相邻视频包的RTP时间戳相差3000左右。
// 伪代码：RTP时间戳计算示例
uint32_t video_timestamp = 0;
uint32_t audio_timestamp = 0;
// 每采集一帧视频（30fps）
video_timestamp += 3000; // 90kHz时钟，33ms增量
// 每采集一帧音频（48kHz，20ms一包）
audio_timestamp += 960; // 48kHz时钟，20ms增量 = 960个样本这里有个坑。RTP时间戳的初始值通常是随机的，不是从0开始。为什么？为了安全。防止攻击者通过时间戳推测通信模式。嗯，这个细节很多初学者会忽略。
注意：RTP时间戳只反映采样时刻的相对顺序，不反映绝对时间。两个不同媒体流的时间戳不能直接比较。音频的3000和视频的3000，含义完全不同。
1.2 NTP时间同步原理：让不同设备“对表”
刚才说了，RTP时间戳是相对值。那怎么让发送端和接收端对齐时间？靠NTP。
NTP（Network Time Protocol）提供的是绝对时间。WebRTC里，发送端会在RTP包中携带NTP时间戳，告诉接收端“这个包是在什么绝对时刻发出的”。
我早期做项目时，以为只要两端都连上NTP服务器就完事了。后来发现，公网NTP的精度受网络抖动影响很大，局域网内反而更准。所以，WebRTC内部实现了一套自己的NTP时间映射机制。
我的经验：在WebRTC的RTP扩展头中，有一个叫做“绝对发送时间”（Absolute Send Time）的字段。它本质上是NTP时间戳的简化版，用于接收端计算网络延迟。调试时，这个字段非常有用。
NTP时间戳的格式是64位：前32位是秒数，后32位是小数部分。精度高达232皮秒。够用了吧？
// NTP时间戳结构
struct NtpTimestamp {
uint32_t seconds; // 从1900年1月1日开始的秒数
uint32_t fraction; // 小数部分，单位 1/2^32 秒
};WebRTC的音频和视频流，各自维护一个RTP时间戳到NTP时间的映射关系。接收端拿到两个流的数据后，通过这个映射，把RTP时间戳换算成统一的绝对时间，才能判断谁先谁后。
1.3 音画同步的衡量指标：唇同步误差
好，现在有了时间戳，有了同步机制，怎么衡量效果？
行业里最常用的指标就是唇同步误差（Lip Sync Error）。说白了，就是音频和视频之间的时间差。
| 误差范围 | 用户体验 | 行业标准 |
|---|---|---|
| < 20ms | 几乎无法察觉 | 优秀 |
| 20ms ~ 40ms | 专业用户可能察觉 | 良好 |
| 40ms ~ 100ms | 普通用户能感觉到 | 可接受 |
| > 100ms | 明显不同步，体验差 | 不可接受 |
你想想看，100ms是什么概念？就是说话时嘴型已经闭上了，声音还在继续。我测试过，超过150ms，用户基本就会投诉。
关键公式：唇同步误差 = |音频播放时间 - 视频播放时间|
注意：这里的时间是经过NTP同步后的绝对时间，不是RTP相对时间。
WebRTC内部有一个同步组（Sync Group）的概念。同一组内的音频和视频流，会被一起做同步调整。接收端会计算每个流的延迟，然后通过调整播放缓冲区的大小，让音频和视频尽量对齐。
我曾经遇到过一个案例：某视频会议产品，在弱网环境下，音频延迟比视频大。结果就是画面先到，声音后到，感觉像在看配音版。后来发现是音频的jitter buffer设置过大，导致音频被过度缓存。调整后，唇同步误差从120ms降到了30ms以内。
1.4 本章知识体系总览
下面这张图，把三个核心概念的关系串起来了。我建议你多看几遍，理解数据流的方向。
1.5 避坑指南：我踩过的三个坑
讲完理论，分享几个实战中容易翻车的地方。
- 坑一：RTP时间戳回绕——时间戳是32位无符号整数，最大值约4.29亿。以90kHz计算，大约13小时就会回绕一次。如果不处理回绕，接收端会认为时间倒流了。WebRTC内部有回绕检测机制，但如果你自己写解析器，一定要处理。
- 坑二：NTP时间戳的精度陷阱——有些实现只用了NTP的秒部分，忽略了小数部分。结果就是同步精度只能到秒级，唇同步误差直接爆炸。我见过一个开源项目犯过这个错。
- 坑三：音频和视频的时钟漂移——即使两端都同步了NTP，音频设备和视频设备的采样时钟也可能有微小差异。长时间运行后，累积误差会越来越大。WebRTC通过定期重新同步来解决，但如果你关闭了同步逻辑，后果自负。
重要提醒：不要假设音频和视频的RTP时间戳在同一时刻相等。它们来自不同的采集设备，时钟源不同。必须通过NTP映射后才能比较。
好了，这一章的内容就到这里。RTP时间戳、NTP同步、唇同步误差，这三个概念是音画同步的基石。后面每一章都会用到它们。你先把这些基础吃透，后面我们才能聊更深入的东西。