文章插图
![服务质量差距分析模型 服务质量评价模型](http://img.hubeilong.com/220623/0G45L3C-0.jpg)
文章插图
为了保证音视频的质量,WebRTC底层做了大量的工作,尤其是网络传输与服务质量,更是其核心技术,本文由北京音视跳动科技有限公司 首席架构师 李超在LiveVideoStack线上分享的演讲整理而成,详细解析了WebRTC底层技术与优化在网络质量、传输实时性与服务质量之间的矛盾以及平衡之道 。
作者 | 李超非常高兴和大家一同探讨WebRTC传输是如何保证音视频服务质量的 。
整理 | LiveVideoStack
1. 实时通信的目标
1.1 实时通信的目标是什么?
1.2 线上与现在不同的原因
1.3 实时通信的目标
2. 几个重要指标
2.1 几个重要指标
最为关键的是实时通信的延迟指标,只有将延迟指标搞清楚,才能知道做实时通信时,达到怎样的延迟才算符合要求的,即接近面对面交流的效果 。然后是音视频服务质量指标,延迟指标达到后,再根据这项指标判断音视频服务质量的好坏 。
2.2 实时通信延时指标
所以最关键的一级是500ms,只有延迟低于500ms,才可以说是合格的实时互动系统 。
2.3 音频服务质量指标
2.4 视频服务质量指标
【服务质量差距分析模型 服务质量评价模型】从以上可以看到,在保证传输的实时性时,由于带宽是一定的,可能会牺牲一定的服务质量 。
3 主要矛盾
3.1 实时通信与服务质量的矛盾
第一,码流与带宽之间的矛盾 。要想达到好的质量,码流一般会比较大(当然,不能超过最大码流),而带宽是有限的,于是码流和带宽之间就会产生矛盾;第二,实时性和服务质量之间的矛盾 。通常为了保证好的实时性我们会选择UDP,而UDP不保证网络传输的可靠性,丢包、乱序是经常发生的 。一旦出现丢包、乱序,网络传输质量就无法得到保证,最终会影响到音视频的质量 。
4 解决矛盾方法
4.1 解决矛盾的方法
5 保障数据的实时性
对于WebRTC来说,为了保障数据的实时性,提供了两种方法:一种是传输路径的选择,它首先会选择最佳的传输路径,使得端到端传输时采取最好、最短的传输路径从而保障数据传输的实时性;另一种是传输协议的选择,可以选择TCP或者UDP 。下面咱们先看一下WebRTC是如何选择最佳传输路径的 。
5.1 选择一条最好的路径
5.2 使用TCP还是UDP?
5.3 为什么极端网络环境下不能用TCP?
图中显示了多次丢包时的延迟情况:从客户端向服务端发送数据包,服务端需要返回ACK消息进行确认; 客户端收到确认消息后, 才能继续发送后面的数据(有滑窗时也是类似的) 。每次客户端发完数据后,都会启动一个定时器,定时器的最短超时时间是200ms 。如果因某种原因,在200毫秒客户端没有收到返回的ACK包,客户端会重发上一个包 。由于TCP有退避机制,以防止频繁发送丢失包,因此会将重发包的超时时间延长到400ms 。如果重发包依然没有收到确认消息,则下一次重发的超时时间会延长到800ms 。我们可以看到,连续几次丢包后,就会产生非常大的延迟,这就是TCP在弱网环境下不能使用的根本原因 。
5.4 选择UDP带来的问题
6 如何提高网络质量
6.1 网络质量包含哪些指标
要想解决网络质量,首先要知道影响网络质量的几个因素:它包括了丢包率、延迟时间、抖动、乱序 。如果网络丢包率低、延迟时间小、不抖动、不乱序,这就是非常优质的网络啦 。但如果丢包率很高,那么网络质量一定会很差 。
6.2 造成丢包的原因
6.3 减少丢包的方法
6.4 NACK
6.5 NACK适合使用的场景
所以可以得出结论,丢包重传仅适用于网络传输时延比较小的情况,如果RTT比较大时,就不适合使用丢包重传来保障网络质量了 。
6.6 FEC
在图中我们可以看到,Data1和Data2同时发送到对端,在发送时对它们做一下异或操作,即Data1的最后一位0与Data2的最后一位0异或为0,Data1的倒数第二位1与 Data2的倒数第二位1异或为0,依次类推,最后就产生了冗余数据R,同时将三个包从一端传输到另一端 。传输过程中,如果Data1丢失,通过Data2和冗余包R就可以将Data1找回来 。找回包的算法也是异或操作,即在接收端将Data2的每一位与冗余包中的相同位进行异或操作就算出了Data1 。这就保证了不用重新请求,就将丢失包找回的作用 。
而且异或具有传递性,A、B、C三个包可以同时异或得到D,如果其中任意一个包丢失,可以通过D和其它包找回丢失的包 。
6.7 ULPFEC
6.8 FlexFEC
此时,当4和5同时丢失时,通过1、7和C1可以找到4,2、8和C2可以找到5,这样就可以找回连续的两个丢包 。当然它也有弊端,其弊端是无法处理批量的连续丢包,例如连续丢失了10个包,FlexFEC对这种情况也无能为力 。
以上就是WebRTC对于丢包的解决方法,通过“NACK+FEC”防止丢包 。
6.9 如何解决抖动和乱序
WebRTC处理抖动和乱序使用的是JitterBuffer和NetEQ 。JitterBuffer用于处理视频包,NetEQ用于处理音频包 。它们的原理大致相同(NetEQ更为复杂一些),都是通过一个队列(缓存区)对接收到的数据做下缓冲,然后再从队列的另一端将数据包一个个均匀的取出, 这样取出的数据就是平滑的了 。
对于乱序的处理也比较好解决,如图中所示,每个RTP包进来的时候有一个序号(Sequence Number),在数据进入队列时,它会根据序号插到对应的位置上,比如图中104、107包已经到达,并且在对应的位置上,而103、105和106没来,位置就空着,等它们来了再插入对应的位置,这样就可以防止乱序,所以通过JitterBuffer和NetEQ就可以同时解决乱序和抖动了 。
总结一下,NACK和FEC解决丢包问题,NACK会增加时延,FEC会占用带宽 。JitterBuffer解决视频的乱序与抖动,NetEQ解决音频的乱序与抖动 。
6.10 网络延时产生的原因
所以对于延时来说,我们需要解决的是因拥塞而造成的延时,链路问题无法解决 。下面咱们就来看看WebRTC是如何防止拥塞的 。
7 准确的带宽评估方法
7.1 如何解决抖动和乱序
7.2 基于丢包的带宽评估
7.3 基于延时的带宽评估
而基于延时的带宽评估就不会产生这种情况 。它的基本原理是,如果接收到的数据包的网络传输时延在持续增长,就说明网络变差了,当达到一定程度时,就要将评估的带宽值降下来,以防止发生网络拥塞 。它的计算公式是根据状态机来的(状态机比较复杂,我这里就不讲了),当状态非常好时,需要增加带宽,同丢包增加带宽一样,每次增加8%;如果延时一直累加,则需要降低带宽,带宽降为原来85%,其它情况就保持当前带宽,无增无减 。
8 媒体数据与带宽的平衡
8.1 媒体数据与带宽的平衡
带宽评估方法和网络质量的提升在前面我已经介绍了 。在有限的带宽下,如何才能提供更好的音视频服务质量,是人们一直孜孜不倦追求的目标 。因此在同等条件下,可以将数据压缩的更小,一直是解决服务质量的一种关键方法 。目前最常用的视频编码器还是H.264,不过新的编码器已经有了很大突破VP9/H265、AV1/H266提供了更高的压缩率,这使得我们在网络条件有限的情况下,可以传输更多的数据从而保障更好的服务质量 。
另一方面,在带宽相同且码流无法压缩的情况下,还可以采用动态码率 。通常,在使用动态码率时,我们可以直接从产品上看出来,你会发现视频一会儿清晰,一会儿模糊 。即在带宽小时,编码器压缩码流,此时视频变得模糊;带宽大时,编码器放大了码流,所以视频变得清晰 。以上就是通过减少数据量的方法来保障实时通信质量的 。
8.2 Simulcast与SVC
SVC与Simulcast最大的区别:SVC上传的是一路码流,但这一路码流是由多层构成的 。服务端会按照不同接收端的带宽大小,选择传输不同的层 。如上图所示,手机端带宽小,就传输小的一层数据,PC端带宽大,就将所有层全部传输过去;而Simulcast上传的是多路流,一般分为小、中、大三路 。对手机端传输小的一路,对PC端传输最大的一路 。Simulcast的好处在于,每一路流都是独立的,所以可以对每一路流使用硬件编解码器,而 SVC的分层方式目前没有硬件支持,所以无法通过硬件加速 。
8.3 流控
正如我前面所说的,流控虽然防止了网络拥塞的发生,但会增加一些延时,增加的延时最终会反应到实时通信的总指标里,总的延时必须控制在500ms以内 。比如以前端到端时延是200ms,由于带宽不足,时延增加到300ms、400ms都是可以的,但一定不要超过500ms 。
此外,对于编码器的输出码流来说,如果流控通过直接降低码流仍然不能与带宽适配时,还可以通过降低分辨率的方式来降低码流 。总之,在带宽不足时,要想尽办法减少数据量 。实在不行,也可以关掉视频只保留音频来保障网络的畅通 。
9 总结
以上就是本次分享的全部内容,谢谢!
Q&A (部分)
1. 路径的选择是WebRTC内部自动选择的吗?
是自动选择的 。WebRTC会自动判断通信的双方是否在同一个局域网内,如果是就直接在局域网内建立连接;如果不是,会通过STUN协议获取各自的外网地址,然后进行NAT穿越;如果还不成功的话,才会选择TURN服务进行数据中转 。
2. WebRTC网络传输质量衡量指标有什么?
衡量任何一个实时传输系统时,首要看它的时延是否达到500ms以内 。其实500ms对于实时通信而言,也是比较苛刻的标准了,因为网络的变化是非常大的, 所以要实现这个指标其实难度也是蛮大的 。其次是丢包率,这是非常关键的指标,刚才说到2%的丢包率代表网络比较好;小于10%,对于WebRTC来说,代表目前的带宽是准确的;超过10%则代表发生了拥塞 。有些厂商说它的产品可以抗xx%的丢包,这样的前提是不认为丢包是一个指标,但在真网络中,当路由的缓冲被撑爆后,必然会出现大量丢包,如果不把丢包当作指标的话,就缺少了一种判断网络拥塞发生的条件,这显然是不合理的 。
3. 视频JitterBuffer怎么具体控制平滑的?
其实JitterBuffer平滑处理的难度并不像我们想像的那样复杂,之所以大家认为它复杂,可能是因为一些额外的因素,如还要处理音视频同步等问题 。对于平滑处理,我们完全可以自己通过一个Buffer来实现 。Buffer可以是动态大小或固定大小 。为了简化,我们假设它是固定大小,比如定义一个可以存放 100 个元素的数组,在数组的一头每隔 10 毫秒取一个包,这就是一个最简单的平滑处理 。当然更好的方式是可以根据网络的变化让这个平滑数组的大小也动态变化,这样就更高级一些 。当然,如果Buffer是动态变化的,那在计算平滑数组的动态大小时,会稍难一些 。
4. WebRTC要和SIP客户端通讯有什么好的方案?
一般与SIP通信最好借助流媒体服务器比如Janus,它既支持SIP协议也能支持WebRTC客户端 。这样SIP终端就可以将数据传输流媒体服务器,然后再转发给WebRTC终端了,同理WebRTC终端也可以通过流媒体服务器与SIP终端通信了 。
5. FEC和NACK默认是不是都要开启?
是的 。对于WebRTC来说,FEC和NACK都是开启的,也可以控制它们的开关 。
6. 能说下为什么TCC比REMB准确吗?
TCC和REMB主要有两个区别 。第一是计算的端不同,REMB是在接收端计算的,接收端计算后再将结果返回给发送端进行控制,而在回传结果时,可能网络又发生了新的变化,这就造成了REMB的及时性不够;TCC是将所有数据都交给发送端做计算和控制,因此及时性和准确度会更高 。第二是滤波器不同,REMB是卡尔曼滤波器(Kalman),TCC是最小二乘法滤波器(Trend line) 。最小二乘法滤波器在网络延时评估这方面比卡尔曼滤波器效果更好一些 。
7. 在内网环境下p2p想让延时尽可能小,可以做哪些工作?实验室环境最小延时可以达到100ms以下吗?
如果在同一个局域网内,实际只有几十毫秒的延迟 。有同学可能会疑惑,有的产品在同一局域网内延迟非常小,为什么用WebRTC反而延迟增大了?这就是因为WebRTC为保障网络质量,在内部通过多种机制,各种缓冲,来做到的 。所以它必然会产生一定的延迟,也就是拿延迟换质量 。而在局域网内,网络基本没有延时,不丢包、不抖动、不乱序 。这时什么策略都不采用,网络的传输才是最快的,因此在内网通信时,WebRTC的实时性一定不如什么策略都不加的产品好 。
8. ULPFEC和FLEXFEC区别是?
ULPFEC只能进行单向冗余处理,而FLEXFEC可以进行双向冗余处理,即可以横向分组还可以纵向分组做冗余,所以它的抗丢包性要比ULPFEC好,同时占的带宽也比ULPFEC多 。
9. 可靠性这块,UDP上的WebRTC做ack是自己封装了seq吗?然后,一样需要ack重传的话,跟TCP SACK有什么区别呢?
WebRTC使用的是RTP协议传输数据 。RTP协议中有seq字段 。此外,WebRTC用的NACK与TCP的ACK机制不同 。TCP每一块数据都需要通过ACK进行确认,如果没收到ACK就重发,直到成功收到ACK或断连;而NACK允许丢包,当重传多次不行时,就不传了 。且而即使重传了数据包,在接收端发现它已经过期时,也会将其丢掉 。
10. WebRTC后面会用QUIC协议吗?
这个问题争论较大 。WebRTC也在一直在尝试使用QUIC协议,从我的角度来看,QUIC协议最主要的是解决Http3,Http3解决的是TCP的问题,就要保证数据的可靠性,那么实时性就会受到影响,什么时候QUIC如果可以解决好实时性问题就可以用,反之则不能 。
从我的角度看,一种协议最好只解决一件事儿,很难通过一套协议解决所有问题 。
- 用户研究:如何做用户画像分析-简书 什么叫用户画像分析
- 如何分析项目的可行性 项目可行性分析分哪些方面?
- 产品对比分析报告怎么做 同类产品对比分析报告模板
- 毕业设计选题系统可行性分析 毕业设计选题系统的设计与实现
- 固定资产报表分析是会计师还是经济师 固定资产报表怎么分析
- 完整设计方案 物联网应用案例分析报告 物联网应用案例分析
- 外汇交易分析软件排名 最好用的外汇行情软件
- 苏宁易购财务报表分析2017年—2019年 苏宁易购财务报表分析论文3000字
- 电子商务客户关系管理的特点分析 电子商务客户关系管理的特点有哪些
- 喜欢冷暴力的人不适合谈恋爱 恋爱冷暴力的人性格分析