WebRTC | 音视频实时通信的本质
目录
一、音视频实时通信的两种指标
1. 实时通信延迟指标
2. 视频相关的基本概念
3. 音视频服务质量指标
二、解决实时通信的主要矛盾
1. 增加带宽
A. 提供更优质的接入服务
B. 保证云端网络的带宽和质量
C. 更合理的路由调度策略
2. 减少数据量
A. 采用更好的压缩算法
B. SVC技术
C. Simulcast技术
D. 动态码率
E. 甩帧或减少业务
3. 适当增加时延
4. 提高网络质量
5. 快速准确地评估带宽
音视频实时通信追求的本质是尽可能逼近或达到面对面交流的效果，同时这也是音视频实时通信的目标。
一、音视频实时通信的两种指标
一是实时通信中的延迟指标；二是音视频服务质量指标。
1. 实时通信延迟指标
在端到端之间，引起延迟的因素有很多，比如音视频采集时间、编解码时间、网络传输时间、音视频的渲染时间以及各种缓冲区所用的时间等。在众多延迟因素中，网络传输引起的延迟是动态的（时快时慢，飘忽不定），所以其最难以评估、难以控制且难以解决，而其他因素引起的延迟时间则基本是恒定不变的。
2. 视频相关的基本概念
（1）分辨率：指图像占用屏幕上像素的多少。图像中的像素密度越高，图像的分辨率越高。对于实时通信而言，图像默认分辨率一般设置为640×480或640×360，如果分辨率低于该值，则图像中包含的信息太少，基本只能看到一个头像，效果就会很差。另外，分辨率还指明了图像清晰度的最大上限。
（2）帧率：指视频每秒播放帧（图像）的数量。播放的帧数越多，视频越流畅。一般动画片/电影的帧率在24帧/秒以上，高清视频的帧率在60帧/秒以上。对于实时通信的视频来说，15帧/秒是一个分水岭，当帧率小于15帧/秒时，大部分人会觉得视频质量不佳，卡顿严重。
（3）码率：指视频压缩后，每秒数据流的大小。原则上，分辨率越大，码率也越大。如果出现分辨率大而码率小的情况，说明在视频编码时丢弃了大量的图像信息，这将导致解码时无法将图像完整复原，从而造成失真。
在相同分辨率的情况下，码率越大还原度越好，图像越清晰。当然，这里的码率大小是有限制的，超过一定阈值（MOS=5）后，再大的码率也没有意义了。
（4）MOS值：用来评估业务服务质量好坏的，MOS值越高，业务质量越好。它共分为5级，由高到低分别为：5——优秀；4——较好；3——还可以；2——差；1——很坏。
3. 音视频服务质量指标
业务服务质量指标，包括音频服务质量和视频服务质量。
要想使在线实时通信可以逼近或达到面对面交流的效果，就必须尽可能地降低传输的延迟，同时增大音视频传输的码率。然而，降低延迟与增大码率是矛盾的，除非所有用户都有足够的带宽和足够好的网络质量，但这显然是不现实的。
二、解决实时通信的主要矛盾
实时通信的主要矛盾是音视频服务质量与带宽大小、网络质量、实时性之间的矛盾。以下几种方法可解决这一矛盾：
- 一是增加带宽；
- 二是减少数据量；
- 三是适当增加时延；
- 四是提高网络质量；
- 五是快速准确地评估带宽。
1. 增加带宽
除了等待5G提升网络能力这种被动的方法外，还有一些变相增加带宽的方案，分为客户端方案和服务端方案。
在客户端方案中，最典型的就是WebRTC支持的选路方案——它可以按优先级选择最优质的网络连接线路。
在服务端方案中，有三种可以间接提升带宽的方法，分别是：提供更优质的接入服务，保证云端网络的带宽和质量，更合理的路由调度策略。
A. 提供更优质的接入服务
一般情况下，同类型运营商（如联通）的用户相互通信时，都不会遇到什么问题，但跨运营商（如联通与电信）的用户进行通信时，网络质量就很难得到有效保障。解决这一问题的一般办法是，让用户连接同一地区、同一运营商的接入服务器，这样就可以有效保障用户与服务器之间的连接通道。如上海的电信用户在接入时，一定要选择一台位于上海的、电信的、负载最低的服务器接入。
B. 保证云端网络的带宽和质量
即数据进入云端后，云内部的网络质量一定要好。因为云内部的带宽大小和质量是可以控制的，所以提升这部分的网络能力相对简单一些。最简单的办法是，可以购买优质的BGP网络作为云内部使用。但优质的BGP的费用也是比较高的。
C. 更合理的路由调度策略
选路的基本原则是距离最近、网络质量最好、服务器负载最小的线路是最优质的线路。
2. 减少数据量
减少音视频数据量一定是以牺牲音视频服务质量为代价的，但这就是一种平衡。
通过减少数据量来保障音视频的实时性有哪些方法呢？这里总结了5种方法，分别是采用更好的压缩算法、SVC技术、Simulcast技术、动态码率、甩帧或减少业务。(用得最多的是Simulcast和动态码率)
A. 采用更好的压缩算法
H265、AVI是最近几年才推出的编解码器，它的压缩率要比现在流行的H264高得多。
B. SVC技术
其基本原理是将视频按时间、空间及质量分成多层编码，然后将它们装在一路流中发给服务端。服务端收到后，再根据每个用户的带宽情况选择不同的层下发。其好处是，可以让不同网络状况的用户都得到较好的服务质量。但它也有缺点：一是上行码流不但没减少反而增加了，所以需要上行用户配置很好的带宽；二是由于SVC实现复杂，又没有硬件支持，所以终端解码时对CPU消耗很大。
C. Simulcast技术
Simulcast与SVC技术类似，不过它的实现要比SVC简单得多。其基本原理是，将视频编码出多种不同分辨率的多路码流，然后上传给服务端。服务端收到码流后，根据每个用户不同的带宽情况，选择其中一路最合适的码流下发给用户。它与SVC技术相比有以下几点不同：
- 一是Simulcast上传的每一路流可以单独解码，而SVC做不到；
- 二是由于Simulcast的每一路都可以单独解码，所以它的解码复杂度与普通解码的是一样的；
- 三是由于Simulcast上传的是多路单独的流，所以上传码率要比SVC多很多。
D. 动态码率
当网络带宽评估出用户带宽不够时，会通过编译器让其减小输出码率；当评估出带宽增大时，又会增加输出码率。这就是动态码率。如果你发现在网络抖动比较大时，某个音视频产品的图像一会儿清晰，一会儿模糊，那多半是因为其采用了动态码率的策略。
E. 甩帧或减少业务
除了上面介绍的那些方法外，还有一种不太友好的方法，就是甩帧或关闭某些不重要的业务来减少数据量。当然，这种方法是在用户带宽严重不足的情况下才使用的，只有到了万不得已的时候才会使用这种策略。
3. 适当增加时延
我们将数据传输时出现的时快时慢现象称为网络抖动。对于视频来说，网络抖动会造成频繁卡顿和快播现象；对于音频而言，则会出现断音、吞音等问题。如何解决这一问题呢？方法其实很简单：增加时延，即先将数据放到队列中缓冲一下，然后再从队列中获取数据进行处理，这样数据就变得“平滑”了。
不过对于实时音视频直播而言，必须把延时控制在一定范围之内。只要让单向延迟小于500ms，大部分人都是可以接受的。由于音视频的采集、编解码、渲染等时间是固定的，所以只要将网络时延计算出来，就可以确定缓冲区的时延了。
4. 提高网络质量
提高网络质量是有默认前提条件的，即网络没有发生拥塞时才能提高网络质量，否则提高网络质量无从谈起。
在网络上，丢包、延迟、抖动会对网络质量产生影响：
- 丢包，是网络传输过程中网络质量好坏的最重要标志，对网络的影响是最大的。优质的网络丢包率不超过2％。对于WebRTC而言，大于2％且小于10％的丢包率是正常的网络。
- 延迟，也是网络质量的重要指标，但与丢包相比，其对网络的影响要少一些。如果在两端之间数据传输的延迟持续增大，说明网络线路很可能发生了拥塞。
- 抖动，对网络质量的影响是最小的。一般情况下，网络都会发生一些抖动，如果抖动很小的话，可以通过循环队列将其消除；如果抖动过大，则将乱序包当作丢包处理。在WebRTC中，抖动时长不能超过10ms，也就是说，如果有包乱序了，最多等待该乱序包10ms，超过10ms就认为该包丢了（即使在第11ms时，乱序的包来了，也仍然认为它丢失了）。
解决丢包、延迟、抖动问题的5种方法：NACK/RTX、FEC前向纠错、JitterBufer防抖动、NetEQ、拥塞控制。
- NACK/RTX，NACK是RTCP中的一种消息类型，由接收端向发送端报告一段时间内有哪些包丢失了。RTX是指发送端重传丢失包，并使用新的SSRC（将传输的音视频包与重传包进行区分）。
- FEC前向纠错，使用异或操作传输数据，以便在丢包时可以通过这种机制恢复丢失的包。FEC特别适合随机少量丢包的场景。
- JitterBufer，用于防抖动，可以将抖动较小的乱序包恢复成有序包。
- NetEQ，专用于音频控制，里面包括了JitterBufer。除此之外，它还可以利用音频的变速不变调机制将积攒的音频数据快速播放或将不足的音频拉长播放，以实现音频的防抖动。
- 拥塞控制：见后文。
5. 快速准确地评估带宽
在实时通信领域，有四种常见的带宽评估方法，分别是Goog-REMB、Goog-TCC、NADA、SCReAM。它们对网络带宽的评估各有优劣，但整体上来看Google最新的带宽评估算法Goog-TCC是最优的。