WebRTC音视频同步

红太狼 2024-02-22 07:34 13阅读 0赞

### 1. 介绍 ###

音视频同步 ，通常也被称作音画同步、唇音同步，它是一项让音频和视频的同时播放以提升交互和观看体验的技术。一般在实时音视频中，视频的处理一般都滞后于音频（比如美颜、视频帧传输等导致），在网络稍有波动的场景音频和视频不同步会严重影响用户体验。因此，在大多数场景我们都需要开启音视频同步以保障用户体验。

这篇文章，将从音视频同步的标准、音视频不同步的形成原因、音视频同步的原理、音视频同步的WebRTC实现这几个方面介绍音视频同步，希望能够帮助大家深入了解音视频同步，能够自己分析和解决音视频同步问题。

### 2. 音视频同步标准 ###

对于音画同步，我们需要同步到何种程度才行？ 我们从参考业界的标准中找到答案。关于音画同步, 业界有3个标准:

*  ITU-R BT.1359（1998）：国际电信联盟标准
 *  ATSC IS/191（2003）：美国的数字电视国家标准
 *  EBU R37（2007）：欧洲广播联盟标准

目前在音视频同步方面影响最大的国际标准是，[ITU-R BT.1359-1(RELATIVE TIMING OF SOUND AND VISION FOR BROADCASTING)][ITU-R BT.1359-1_RELATIVE TIMING OF SOUND AND VISION FOR BROADCASTING]，该标准由国际电联组织在1998年提出, 针对电视广播的音画同步标准, 该标准至今依然被使用, 也被扩展到互联网直播领域。

![4fbfe44301d24131b9e313261e996d74.webp][]

该标准的评测者既包括专家, 也包括一般人, 采用5级评分标准, 给出的答案是:

![da092d8f68aa4c30b83523c5c086749c.png][]

> 这里的delay time是用视频延迟减去音频延迟, 负数表示音频延迟更大, 正数表示视频延迟更大。 生活中光速快于音速，因此`画面快于声音是一个普遍现象，因此对声音滞后有更大的耐受度，而音频提前于视频会有不适`。 所以信息的你会发现以上的阈值不是对称的！

一般，delay < -200ms或者delay > 100ms，则认为存在较大不同步！在实际使用中，我们可以使用这个阈值来作为同步是否达标的标准。

### 3. 同步的原理 ###

在其他的实现中（非webrtc），会使用`lipsync`协商是否需要做音视频同步。webrtc中是否要做sync是隐含的。WebRTC标准中两个相同stream id的流是默认需要做同步的（见[Media Capture and Streams][ITU-R BT.1359-1_RELATIVE TIMING OF SOUND AND VISION FOR BROADCASTING]）。

#### 3.1 不同步的原因 ####

> 为了能够解决音画不同步的问题，我们首先需要了解这个问题，只有了解音画不同步的原因，才能够提出更好的同步方案，在遇到不同步问题的时候才能想的更全面。

第一步，我们还是按照处理节点，对不同步做拆解。在RTC中，一般音频和视频都是独立的采集、编码和传输，两者在端到端的链路上是相互独立，因此任何一个环节的处理都会导致最终播放时间不一致。

![4ce4eb38c56b4bf5b7b5d1437260d4b0.webp][]

麦克风和摄像头的硬件采集时间存在差异，这里涉及到模拟信号到数字信号的转换等操作，处理时间一般不同，忽略声音和光传播差异后，采集处理可能有几ms的差异。而且，一般都是用采集完成的时间点作为音视频帧的时间，因此会忽略采集处理时间，如果视频采集有较大延迟，这里的延迟就无法测量出来。

![2135224014434a85b8fb240b170089f3.webp][]

音视频的前处理延迟差异较大：对于视频来说，前处理有美颜；对于音频来说前处理有3A。视频的前处理延迟一般比音频大很多！某些美颜库可能需要延迟一帧输出，可能会引入30ms+的延迟。而音频3A的处理延迟和算法延迟一般较低，最多几ms。

![8876d19fa76d428e90762c67f96f5901.webp][]

> 音视频编解码时间存在差距，音频的编解码时间一般在1ms内，而视频的延迟在不同机型、使用不同编解码器实现差异很大，耗时通常在几ms到几十ms不等。视频的编码器在性能不足时，如果buffer数据，可能会引入非常大的延迟，比如1s都有可能。 视频解码一般很少会出现瓶颈，但是也不排除一些设备的硬件解码性能不行。这个差异也需要关注。
> 
> pacer延迟差异巨大：带宽充足时需要平滑发送，带宽不足时需要控制发送量。因为音频包的量比较少，因此受pacer影响较小，WebRTC甚至可以支持音频包不受pacer平滑调度。而视频一帧非常大，通常需要分包发送。如果当前带宽1M，视频编码打包输出某一帧刚好1M，那么这1M的数据需要1s才能发送完成。因此pacer的平滑会引入延迟差异。

> 网络传输延迟差异巨大：这是传输链路的限制，和pacer有点类似，一个是本地buffer，一个是网络buffer；一个受本地估计带宽限制，一个受路由器的码率限制。这都会导致视频帧传输比音频帧时间长。
> 
> 丢包重传策略差异：音频和视频在丢包重传策略上一般会存在差异，因此其恢复时间也会有较大差异。音频还有PLC可以允许部分包丢失，而视频对于丢包会严格很多，特别是在没有SVC的场景，需要恢复所有的包才能解码，否则只能请求关键帧。这一部分不能确定音频和视频谁的恢复延迟更大，需要看具体的策略实现。

> Jitter buffer延迟差异：音频和视频有各自的jitter buffer，它们有不同的抗抖动能力，在引入的延迟上也会有差异。一般来说，在弱网的时候，`这个部分和传输部分都是贡献不同步的大头`。多关注jitter buffer引入的延迟就对了。
> 
> 后处理延迟：如果存在一些后处理（如视频超分），视频的处理延迟肯定会比音频大。

> 渲染延迟：一般来说，这个时间是固定的，和设备以及用户调用有关。在部分CPU较高的时候，渲染也会出现延迟。

#### 3.2 同步拆解模型 ####

同步拆解模型是理解webrtc中音视频同步原理的重点！

怎么去衡量不同步呢？预期上，音频和视频的采集到渲染的端到端延迟应该相等，才能保证是同步的，因此，不同步可以表示为：`视频的端到端延迟 - 音频端到端延迟`。

![93cc163685c842ef92bc3d47707a889e.webp][]

以上的方法可以用来精准衡量最终的同步效果，但是并不能指导我们去做音视频同步。**在webrtc的架构中，我们能够想到的就是调整jitter buffer的延迟（结合加速、减速），间接控制播放延迟，从而达到音视频同步的效果。**

鉴于以上的思路，我们可以进一步对端到端延迟做拆解，我们把延迟拆分为两个部分，即`采集到接收端组帧完成 + jitter buffer引入延迟`。如下图所示

![256be41c2be540d382e6e2d38b1c8e7e.webp][]

通过以上的拆解，我们可以将jitter buffer延迟独立开来，可以确定我们需要调整的jitter buffer增量，从而达到同步的效果。下面来解释下为什么可行。

视频端到端延迟组帧完成时间采集时间延迟音频频端到端延迟接收时间采集时间延迟当前不同步视频端到端延迟音频端到端延迟视频端到端延迟=(组帧完成时间−采集时间)+��延迟音频频端到端延迟=(接收时间−采集时间)+��延迟当前不同步=视频端到端延迟−音频端到端延迟

因为接收时间是在接收端，而采集时间是在采集端，它们不能需要对齐到一个时间轴上才能够运算，但是通过上面的相减，我们可以消除时间差异，免去时间同步的问题。有：

相对延迟视频组帧时间音频接收时间视频采集时间音频采集时间当前不同步相对延迟视频延迟音频延迟相对延迟=(视频组帧时间−音频接收时间)−(视频采集时间−音频采集时间)当前不同步=相对延迟+(视频��延迟−音频��延迟)

在WebRTC里面，我们将这个不同步记为SyncDiff，代码有：

SyncDiff = (video_jb_current_delay - audio_jb_current_delay) + RelativeDelay

相对延迟是从采集到接收端组帧完成后的相对时间差，是我们无法控制的部分；当前的JB延迟是我们可以控制的部分，通过这样的拆解，就把问题变得简单了！

如果我们拿到了SyncDiff，就可以根据当前diff值调整音视频延迟达到同步效果。同步的两个重点分别是：

*  估计不同步量sync diff
 *  调整音视频延迟以达到同步

#### 3.3 不同步的准确估计 ####

根据上面的公式，我们需要`在接收端`知道这些信息：

*  音频帧采集时间戳、视频帧采集时间戳
 *  音频帧接收时间、视频帧组帧完成时间（这个在接收端可以直接拿到，不多介绍）
 *  音频jitter buffer当前延迟、视频jitter buffer当前延迟（从jitter buffer直接获取）

因此，我们只剩下，在接收端根据音视频帧信息获取其采集时间。这个是通过SR报文(详见[RFC3550][ITU-R BT.1359-1_RELATIVE TIMING OF SOUND AND VISION FOR BROADCASTING])来获取到的。

> 发送端会定时发送SR报文，其中包含了最后一次发送的RTP报文的RTP timestamp，这个timestamp和采集时间对应，但是单位是采集点个数；同时还包含了这个RTP timestamp对应的NTP时间，单位可以转换为ms。![f5ff0b9fbb7b4335ad49501a2910476e.png][]

> timestamp是RTP数据第一个字节的采样时刻（PCMA/PCMU编码比较好理解，每一个字节都有不同的timestamp，而不是像部分编码无法直接区分）。
> 
> timestamp来自于一个线性单调增加的时钟，且精度足够，如果不满足这两个条件，那么对于jitter计算以及音视频同步来说会有较大误差。
> 
> timestamp对应的频率就是音频/视频的采样率，音频的采样率8k到48k都存在，视频一般固定90k。拿8k 8bit量化的PCMA编码来说，即每秒采样8千个点，每个点8bit，即每增加一个字节（8bit），timestamp加1。对于48k采样率 20ms打包时长的opus编码来说，每秒采样48k个点，20ms有960个点，即每多一个包，timestamp增加960。
> 
> 对于视频帧来说，同一帧的所有rtp包时间戳相同。
> 
> timestamp是的初始值是随机的，初衷是为了防攻击。因此timestamp是一个相对时间，不同的rtp流的timestamp无法比较。
> 
> NTP（[Network Timestamp Protocol(Wikipedia)][ITU-R BT.1359-1_RELATIVE TIMING OF SOUND AND VISION FOR BROADCASTING]，[RFC5905][ITU-R BT.1359-1_RELATIVE TIMING OF SOUND AND VISION FOR BROADCASTING]） timestamp表示从1900年1月1日到现在经历的时间，它使用一个64位的无符号定点数表示，分为正数部分32位、小数部分32位，正数部分单位为秒，小数部分单位为1/(2^32)秒。
> 
> 在部分领域会使用更紧凑的表达方式，即使用32位表示一个NTP timestamp，即16位正数部分、16位小数部分(如SR和RR中的ReportBlobck中的LSR和DLSR就是使用32位表示)。

SR报文虽然不是每发送一个RTP包就会发送一个，但是RTP timestamp和NTP的对应关系基本不会怎么变（除非时间戳跳变或者时钟漂移），接收端使用[最小二乘法][ITU-R BT.1359-1_RELATIVE TIMING OF SOUND AND VISION FOR BROADCASTING]来拟合rtp和NTP timestamp关系，得到:NTP\_ts = rtp\_ts \* k + b。这样任何一个RTP timestamp都可以估算其真实的时间。![595ff36f465848319fa928431f724a8f.webp][]

这个代码可以见WebRTC中`RtpToNtpEstimator`类，后续我们也会直接使用这个类完成rtp timestamp到NTP timestamp的转换，因此后续在使用时间的时候，我们都是用ms为单位，发送端的时间我们都默认做过转换。

这样，是不是就解决了sync diff的估计问题了呢？

#### 3.4 音视频同步的实现 ####

音视频同步一般来说有三种方法：

*  视频同步到音频，即音频不调整，视频按照音频的播放节奏来做加减速调整
 *  音频同步到视频，即视频不调整，音频按照视频的播放节奏来做加减速调整
 *  音视频互相同步，各自都会做加减速，最终收敛到一个合理水平。

这三个方法各有优劣，主要看应用场景，重点是保障哪个流。在webrtc中，音频和视频是互相同步，逐渐收敛到合理的延迟。

有了sync diff测量，我们就可以通过调整jitter buffer达到预想的效果了。具体策略如下：

*  同步按照1s间隔定时处理，如果你嫌它不够快，可以自己调整
 *  SyncDiff在较小范围内，如\[-30ms, 30ms\]，此时比较同步，不用立即调整
 *  延迟调整采用渐进方式，单次调整控制在\[-80ms, 80ms\]范围内，避免步长过大导致明显的加减速。
 *  如果SyncDiff > 0，表示视频相对音频有延迟，降低视频延迟或者增加音频延迟。当之前增加过视频延迟，则可以在之前增加的基础上降低；否则只能增加音频延迟。
 *  如果SyncDiff < 0，表示音频相对视频有延迟，增加视频延迟或者降低音频延迟。当之前增加过音频延迟，则可以在之前增加的基础上降低；否则只能增加视频延迟。
 *  ![2f39aba692d049e197dc3d88013cd55a.webp][]
 *  同步存在阈值kMaxDeltaDelayMs=10s，超过10s以上直接按照10s计算。这个10s可以认为就是能够同步的极限了。
 *  通过上面的调整，我们就得到一个目标延迟，这个目标延迟便可以设置到音频和视频的jitter buffer中，来调整延迟了，见webrtc代码：
    
        syncable_audio_->SetMinimumPlayoutDelay(target_audio_delay_ms);
          syncable_video_->SetMinimumPlayoutDelay(target_video_delay_ms);
    
    这里只是把目标延迟同步到jitter buffer模块，实际上的加速和减速，还是需要jitter buffer模块去实现，完成最终的同步。最终我们的目标当然是音频、视频的端到端延迟差尽可能小，也就是sync diff尽可能小！
 *  ###  ###
    
    4. 总结
    
    以上便是对音视频同步的详细介绍，希望大家有所收获。

[ITU-R BT.1359-1_RELATIVE TIMING OF SOUND AND VISION FOR BROADCASTING]: http://1
[4fbfe44301d24131b9e313261e996d74.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/9c2302421a7b4c5ba7e840f4c4ef0061.png
[da092d8f68aa4c30b83523c5c086749c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/8b3a284816884a2a87223dc6070086b9.png
[4ce4eb38c56b4bf5b7b5d1437260d4b0.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/99395be6351e4cee889d2e5ee5991fec.png
[2135224014434a85b8fb240b170089f3.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/23a4b434b47f49d698f291a4e828b792.png
[8876d19fa76d428e90762c67f96f5901.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/235a104de200427b9813a994cd204c8e.png
[93cc163685c842ef92bc3d47707a889e.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/3e71f1b42a1946b487f6707ac283e08a.png
[256be41c2be540d382e6e2d38b1c8e7e.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/f4c2d31c23ea40c58515aebab9636545.png
[f5ff0b9fbb7b4335ad49501a2910476e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/73261f1dd7c44826bd678e8b63cb9931.png
[595ff36f465848319fa928431f724a8f.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/860109d0da5c4cd096284df03236a381.png
[2f39aba692d049e197dc3d88013cd55a.webp]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/22/6b5c18cb3ef547d4aada867c5ea99c20.png