音视频互动WebRTC

音视频实时通信的本质

音视频实时通信追求的本质是尽可能逼近或达到面对面的交流效果，同时这也是音视频实时通信的目标。

要达到面对面交流的效果，我们需要关注两个重要指标：一是实时通信中的延迟指标；二是音视频服务质量指标。

我们在做很多的技术就是围绕这两个指标来做的。

延迟指标

端到端之间，引起延迟的原因有很多，比如音视频采集时间、编解码时间、网络传输时间、音视频的渲染时间以及各种缓冲区所用的时间等。在众多因素中，网络传输和引起的延迟是动态的，所以也是最难以评估，难以控制且难以解决的。其他因素基本是恒定不变的。

延迟200ms以内基本接近面对面交流的效果；

延迟300ms还可以接受，400ms就明显能感觉到，超过500ms基本就很影响互动效果了。

音视频服务质量

除了实时通信延迟指标外，音视频通信中还有业务服务质量指标，包括音视频服务质量和视频服务质量。

视频服务质量和分辨率，码率，帧率三个概念相关。

• • 分辨率越高图像包含的信息越多，分辨率决定了图像清晰度的最大上限。
  • 帧率指视频每秒播放帧的数量，帧数越高越流畅，对于实时视频来说，15帧/秒是一个分水岭，当帧率小于15帧/秒时，大部分人会觉得视频质量不佳，卡顿明显。
  • 码流，是指视频压缩后，每秒数据流的大小。原则上，分辨率越大，码流也就越大。在相同分辨率的情况下，码率越大还原度越好，图像越清晰。不过，码率大小也是有限制的，超过一定阈值（MOS=5）后，再大的码率也没有意义了。
  • MOS值是用来评估业务服务质量好坏的，MOS值越高，业务质量越好，最大值是5。

所以MOS值越高，视频的质量越好，码率也就越大，需要的带宽也就越多。

由于音频数据量比较小，对于网络的影响不大，音频服务质量主要和3A相关。

实时通信的主要矛盾

用户“较差”的网络与接受“较好”的服务质量之间的矛盾，更准确的说，是音视频服务质量与带宽大小、网络质量、实时性之间的矛盾，这个矛盾也就是实时通信的主要矛盾。

如何解决这个矛盾呢？

1.增加带宽；2.减少数据量；3.适当增加时延；4.提高网络质量；5.快速准确地评估带宽。

1.增加带宽

多方实时通信时，属于典型“木桶效应”，单个用户增加带宽对整个服务质量起不到什么作用。除了等待网络升级，比如5G等之外，还有一些变相增加带宽地方案，分为客户端方案和服务端方案。

客户端方案中，典型地就是WebRTC支持地选路方案---它可以按优先级选择最优质地网络连接线路。

服务端方案中，（这个要考虑大规模服务部署的情况下来考虑，我们目前还没达到这样的部署规模）有三种可以间接提升带宽地方法，分别是：

• 提供更优质地接入服务，比如让用户连接统一地区、同一运营商的接入服务器；
• 保证云端网络地带宽和质量。指下图中的2云服务内部网络质量一定保证好，这个是最容易的，比如购买优质的BGP网络作为云内部使用，不过价格会很高。
  • BGP网络：
• 更合理地路由调度策略，比如下图中的3，从A到B有很多路径可选择，选择距离最近，网络质量最好，服务器负载最小的线路就是最优质的线路。

大规模实时流媒体服务框架图

2.减少数据量

当网络带宽一定的情况下，为了解决实时通信的矛盾，我们必须通过减少数据量来解决。

通过减少数据量来保障音视频的实时性方法有以下5种：

• 采用更好地压缩算法:比如H265和AVI编码算法的压缩率比H264高，比如H265能比H264提高25%，AVI比H264能提高40%。

缺点：编码速度慢，这个可能导致目前大家没在使用的原因。

• SVC技术：是减少传输数据量地非常好地一种方法。其基本原理是将视频按照时间、空间和质量分成多层编码，然后将它们装在一路流中发给服务端，服务端收到后，再根据每个用户的带宽情况选择不同的层下发。

缺点：是上行码流不但没有减少反而增加了；SVC实现复杂，又没有硬件支持，所以终端解码时对于CPU的消耗很大。这个是要求发送端的带宽足够好，接收端的带宽有好有坏。

• Simulcast技术：与SVC类似，不过它的实现要比SVC简单得多。基本原理是，将视频编码出多种不同分辨率得多路码流，然后上传给服务端。服务端收到码流后，根据每个用户不同得带宽情况，选择其中一种最合适的码流下发给用户。

和SVC相比，Simulcast的每一路都可以单独解码，所以它的解码复杂度与普通解码是一样的；Simulcast上传的每一路流可以单独解码，但是SVC做不到；Simulcast上传的是多路单独的流，所以上传的码率要比SVC多很多。这个是要求发送端的带宽足够好，接收端的带宽有好有坏。

SVC和Simulcast比较

• 动态码率技术：当网络带宽评估出用户带宽不够时，会通过编译器让其减小输出码率；当评估出带宽增大时，又会增加输出码率。如果你发现再网络抖动比较大时，某个音视频产品的图像一会儿清晰，一会儿模糊，那么多半时因为其才采用了动态码率的策略。

这种方式也是目前我们主要采用的技术。

• 甩帧或减少业务：这种方法是在用户带宽严重不足的情况下才使用的，只有到了万不得已的时候才会使用这种策略。比如保证音频，降低视频帧率甚至放弃视频业务。这个也是我们目前的策略之一。

3.适当增加时延

网络抖动是指数据传输时出现时快时慢现象称为网络抖动，也就是时延忽大忽小。

网络抖动的衡量是最大延迟与最小延迟的时间差，如最大延迟是20毫秒，最小延迟为5毫秒，那么网络抖动就是15毫秒，它主要标识一个网络的稳定性。

如果不对于网络抖动加以处理的话，它会对音视频服务质量造成严重影响：对于视频来说，网络抖动会造成频繁卡顿和快播现象；对于音频而言，则会出现短音、吞音等问题。

解决的方法很简单：增加时延，即先将数据放到队列中缓冲一下，然后再从队列中获取数据进行处理，这样数据就变得“平滑”了。但是必须把时延控制再一定范围内，比如小于500ms。

4.提高网络质量

要提高网络质量的前提是网络没有发生拥塞。

对网络质量产生影响就三点：丢包、延迟、抖动。

丢包：优质的网络丢包率不超过2%。对于WebRTC而言，大于2%且小于10%的丢包率算是正常的网络。

延迟：如果在两端的数据传输的延迟持续增大，说明网络线路很可能发生了拥塞。

抖动：抖动对网络质量的影响时最小的。一般情况下网络都会发生抖动，如果抖动很小的话可以通过循环队列将其消除；如果抖动过大，则将乱序包当作丢包处理。

在WebRTC中，抖动时长不能超多10ms，超过10ms就该包丢了（即使在第11ms时，乱序的包来了，也仍然认为它丢失了）。

哪些方法可以解决丢包、延迟、抖动问题？

1.NACK/RTX

NACK是RTCP中的一种消息类型，由接收端向发送端报告一段时间内有哪些包丢失了；

RTX是指发送端重传丢失包，并使用新的SSRC（将传输的音视频包与重传进行区分）。

2.FEC前向纠错

使用异或操作传输数据，以便在丢包时可以通过这种机制恢复丢失的包。FEC特别适合随机少量丢包的场景。

3.JitterBuffer

用于防抖动，可以将抖动较小的乱序包恢复成有序包。

4.NetEQ

专用于音频控制，里面包括了JitterBufer。除此之外，它还可以利用音频的变速不变调机制将积攒的音频数据快速播放或将不足的音频拉长播放，以实现音频的防抖动。NetEQ使得WebRTC语音引擎能够快速且高解析度地适应不断变化的网络环境，确保了音质优美且缓冲延迟最小，其集成了自适应抖动控制以及丢包隐藏算法。

5.拥塞控制

拥塞控制是指通过评估网络带宽来控制数据发送速度的策略。算法比如，Goog-REMB、Goog-TCC、NADA、SCReAM。

Transport-CC的拥塞控制算法是被验证过，认为是最优秀的拥塞控制算法。

Transport-CC的拥塞控制算法不但能实现UDP和TCP并存时的公平性，也能保证同类型的拥塞控制算法之间的公平性。

5.快速准确的评估带宽

为了防止网络拥塞，客户端就要有快速、准确地评估带宽方法，这个和我们前面讲到的动态码率以及甩帧或减少业务的使用是非常关键的。

在实时通信领域，有四种常见地带宽评估方法：Goog-REMB、Goog-TCC、NADA、SCReAM。总体来说Goog-TCC是最优地。

原文  音视频互动WebRTC - 知乎 

 

★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。

见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓