WebRTC 音视频同步原理与实现 _WebRTC

所有的基于网络传输的音视频采集播放系统都会存在音视频同步的问题，作为现代互联网实时音视频通信系统的代表，WebRTC 也不例外。本文将对音视频同步的原理以及 WebRTC 的实现做深入分析。
1、时间戳 (timestamp)
同步问题就是快慢的问题，就会牵扯到时间跟音视频流媒体的对应关系，就有了时间戳的概念。
时间戳用来定义媒体负载数据的采样时刻，从单调线性递增的时钟中获取 , 时钟的精度由 RTP 负载数据的采样频率决定。音频和视频的采样频率是不一样的，一般音频的采样频率有 16KHz、44.1KHz、48KHz 等，而视频反映在采样帧率上，一般帧率有 25fps、29.97fps、30fps 等。
习惯上音频的时间戳的增速就是其采样率，比如 16KHz 采样，每 10ms 采集一帧，则下一帧的时间戳，比上一帧的时间戳，从数值上多 16 x10=160，即音频时间戳增速为 16/ms 。而视频的采样频率习惯上是按照 90KHz 来计算的，就是每秒 90K 个时钟 tick，之所以用 90K 是因为它正好是上面所说的视频帧率的倍数，所以就采用了 90K 。所以视频帧的时间戳的增长速率就是 90/ms 。
2、时间戳的生成
音频帧时间戳的生成
WebRTC 的音频帧的时间戳，从第一个包为 0，开始累加，每一帧增加 = 编码帧长 (ms) x 采样率 / 1000，如果采样率 16KHz，编码帧长 20ms，则每个音频帧的时间戳递增 20 x 16000/1000 = 320 。这里只是说的未打包之前的音频帧的时间戳，而封装到 RTP 包里面的时候，会将这个音频帧的时间戳再累加上一个随机偏移量（构造函数里生成），然后作为此 RTP 包的时间戳，发送出去，如下面代码所示，注意，这个逻辑同样适用于视频包。

文章插图

视频帧时间戳的生成
WebRTC 的视频帧，生成机制跟音频帧完全不同。视频帧的时间戳来源于系统时钟，采集完成后至编码之前的某个时刻（这个传递链路非常长，不同配置的视频帧，走不同的逻辑，会有不同的获取位置），获取当前系统的时间 timestamp_us_，然后算出此系统时间对应的 ntp_time_ms_，再根据此 ntp 时间算出原始视频帧的时间戳 timestamp_rtp_，参看下面的代码，计算逻辑也在 OnFrame 这个函数中。

文章插图

为什么视频帧采用了跟音频帧不同的时间戳计算机制呢？我的理解，一般情况音频的采集设备的采样间隔和时钟精度更加准确，10ms 一帧，每秒是 100 帧，一般不会出现大的抖动，而视频帧的帧间隔时间较大采集精度，每秒 25 帧的话，就是 40ms 一帧。如果还采用音频的按照采样率来递增的话，可能会出现跟实际时钟对不齐的情况，所以就直接每取一帧，按照取出时刻的系统时钟算出一个时间戳，这样可以再现真实视频帧跟实际时间的对应关系。
跟上面音频一样，在封装到 RTP 包的时候，会将原始视频帧的时间戳累加上一个随机偏移量（此偏移量跟音频的并不是同一个值），作为此 RTP 包的时间戳发送出去。值得注意的是，这里计算的 NTP 时间戳根本就不会随着 RTP 数据包一起发送出去，因为 RTP 包的包头里面没有 NTP 字段，即使是扩展字段里，我们也没有放这个值，如下面视频的时间相关的扩展字段。

文章插图

3、音视频同步核心依据
从上面可以看出，RTP 包里面只包含每个流的独立的、单调递增的时间戳信息，也就是说音频和视频两个时间戳完全是独立的，没有关系的，无法只根据这个信息来进行同步，因为无法对两个流的时间进行关联，我们需要一种映射关系，将两个独立的时间戳关联起来。
这个时候 RTCP 包里面的一种发送端报告分组 SR(SenderReport) 包就上场了，详情请参考RFC3550 。

文章插图

SR 包的其中一个作用就是来告诉我们每个流的 RTP 包的时间戳和 NTP 时间的对应关系的。靠的就是上边图片中标出的 NTP 时间戳和 RTP 时间戳，通过 RFC3550 的描述，我们知道这两个时间戳对应的是同一个时刻，这个时刻表示此 SR 包生成的时刻。这就是我们对音视频进行同步的最核心的依据，所有的其它计算都是围绕这个核心依据来展开的。
4、SR 包的生成
由上面论述可知，NTP 时间和 RTP 时间戳是同一时刻的不同表示，只是精度和单位不一样。NTP 时间是绝对时间，以毫秒为单位，而 RTP 时间戳则和媒体的采样频率有关，是一个单调递增数值。生成 SR 包的过程在 RTCPSender::BuildSR(const RtcpContext& ctx) 函数里面，老版本里面有 bug，写死了采样率为 8K，新版本已经修复，下面截图是老版本的代码：