本文首发在云+社区,未经许可,不得转载。

腾讯云H5语音通信QoE优化-LMLPHP腾讯音视频实验室高级工程师张轲

11月份,W3C发布了WebRTC的标准。另外一个专注于WebRTC的国际组织RETF在12月份也发布了第一个RFC8298,目前还没有成为真正的标准。我今天讲的重点,是围绕网络传输的一些心得。

2017年3月份CallStatus.io WebRTC发布的全球质量报告中,第一个有10%的通话会因为各种带宽、丢包、流失原因,造成中途中断。第二个是有10%到15%的用户,对音视频通话的质量不满意。第三个是有7%左右的大丢包,有95%左右的用户已经流失在240毫秒以下。

正是因为现在的WebRTC方案有很多问题,我们简单分析一下刚才的一些质量不佳的原因,有大概三个原因:

第一个,本身WebRTC涉及的是P2P的网络连接,中间可能没有大量的中转系统,在遇到跨运营商,甚至小运营商的时候,它的网络链路是没有质量保证的。

第二个,各个浏览器互操作性、兼容性很差。这些问题刚好都是我们的专长。我们基于此开发了一套解决方案。

两个核心的技术优势

第一个是我们的实时音视频;第二个是基于QQ浏览器的TBS内核的浏览器上面支持了WebRTC的能力。我们可以针对WebRTC代码做很多修改,甚至优化。

我们用户端可以在微信、QQ浏览器上面,对WebRTC进行编程。我们还有一些推流、录制、点播等等的能力。

三种差异化的服务质量

实现一套基本的WebRTC,工作量是后台的搭建,接入部署,包括在后台实现传输控制、媒体加密,增加运营能力。QQ的东西是十多年海量用户的经验,我们现在每天QQ的通话时长大概在10到20亿分钟左右。扩展的WebRTC,是相当于在QQ浏览器内核里面,集成了WebRTC的内核,同时对它做了一个扩展,解决了现在WebRTC的一些问题。我们对QOS也做了一些简单的扩展。我们会根据后面用户量的一些使用情况来决策,看这三个怎么更好地协调,或者说优势互补。

接口机的分配及接入的状况

我们建立了一套机房节点全球链路质量监控系统,在WebRTC项目里面,大概部署了60多个节点,覆盖了30多个国家。国内98%的节点之间链路延时小于36ms。有90%全球的网络节点之间,大概链路节点小于100毫秒。链路优化是持续的过程,包括节点的部署,也会根据用户量的使用情况来决策,在哪些地域或者是地区投放我们的节点部署。

QOS优化——拥塞避免算法和抗丢包技术

后台质量控制示意图中能看到我们实现了SFU和MCU。质量控制,就是三级策略,接口级这个地方,先估计终端上行网络的质量,包括做带宽估计,包括抗丢包机制的对接。下行的带宽估计,抗丢包的一些机制对接。最核心的地方,控制策略是根据上下行的一些质量信息,来决策我们的流量控制到底应该怎么做,这里面有一个核心决策体系,这个东西也是我们整个实时数据里面一个非常核心、非常有竞争力的技术。

QOS优化到底有哪些技术?

分带宽、丢包和延时、抗抖四个领域。想做好QOS,环节特别多,从编解器、链路、传输、处理、设备等众多环节,处理好技术的协作关系,各种算法的调度、管理、配合是核心难点。

带宽工具,包括网络拥塞,有GCC、NANA、SCReam、FRACTal。抗丢包技术里面有ARQ、FEC、PLC延时构成,包括我们的核心在做采集播放的时候,我们会控制很多领域的东西。不同的问题牵扯到不同的技术,各种基础技术的理解深度和广度以及应用策略,这是第一个层面的东西。

第二个层面,各种技术、各种因素,它的配合影响,包括反馈以及联动策略,相对来说比较综合的第二个层面的东西。

第三个层面,很多业务特性决定了基于场景的差异化的策略,也会导致要采用的策略不一样。

想做好QOS,必须要把这三个层面的东西解决好,不然QOS是做不好的。

什么样的算法才是比较好的拥塞控制算法?

实时媒体拥塞避免控制方案,一直是IETF RMCAT的热点研究课题。传输延时要小于100毫秒。数据流之间不能相互干扰,不能因为自发引起不恰当的使用带宽。丢包是越小越好,带宽应用率要高,尽可能使用带宽。在带宽有限的情况下,传输通道不能饿死。出于安全的考虑,要对可能的一些拥塞控制领域的反馈攻击做一些处理。安全性方面,媒体数据的发送一定要是平滑的。公平性方面,不要饿死,也不能抢更多的带宽,要共享带宽。

适应性有很多方面,第一适应实际带宽的波动。比如说在音频里面会启动不连续传输,可能导致带宽越来越弱,这时候怎么处理?最后一个就是反馈,反馈通道不好了怎么办?反馈包丢失了怎么办?怎么去控制好?能把这10个方面做好,就提供了比较好的工具。

TFRC是大概十年前用的技术,最大的问题是延时不可控,视频帧大小经常发生变化。有速率振荡行为。高丢包下的准确度有问题。

LEBDBT,好处是延时相对来说绝对可控。它的缺点是太灵敏了,有网络波动或者是在带宽上有一些突发流量,都会导致它迅速崩溃,导致带宽饥渴。还有一个是后来者效应。它会把第一路的带宽给抢占了。

GCC,它是有两部分,第一部分是收端是基于延时的控制算法,发端是基于丢包的。它主要有几个问题:它在移动网络环境多流共存情况下,表现很差。

在有TCP流并存的情况下会过度退让从而导致WebRTC流饥饿在多WebRTC流并发的情况下,新加入的WebRTC流会损害已有流的通信质量。 SCReam是基于窗口和面向字节。缺点是见SCREAM-CPP-implementaion,有线网络不如GCC。NADA是基于延迟和损失,目前仍是实验代码。FRACTal是FEC探测带宽,缺点是鲁棒性仍需要提高,移动和无线网络待验证。QUIC是Quick UDP,默认拥塞控制算法无法保证低延时,可提供私有拥塞算法。

两套实现方案:现有WebRTC已切换到绿色部分基于延时的发端拥塞方案,上下两套算法通过SDP参数控制。

这是几个主流的浏览器的实践状况。Edge还是老的算法。OpenWebRTC主要推荐的是SCReam算法。

我们的应用策略对于不同的浏览器、不同的版本能力是不一样的,提供WebRTC解决方案,必须要清楚。我们在基本的WebRTC通话场景,通过SDK参数交换使用的拥塞控制方案。不同浏览器里面,必须要管理好这些拥塞控制算法。我们提供私有的拥塞控制算法,主要是基于我们已有的经验积累,包括刚才我对各种算法的解读,包括优缺点的优化方法,同时我们也会在运营层面上对比不同的算法。

FEC算法有很多种,第一个是Inband FEC,在语音的编码器里面,生成一部分冗余信息。它的缺点是以牺牲语音质量为前提的,虽然可以保证流量是稳定的,但是它的质量是不好的。

异或,这个是WebRTC里面一个主要的实现方法。

Reed-Solomon的纠错率比较高一点。交织编码,在WebRTC里面也有使用。它的目的不是纠错,而是把丢包给散化。还有一个Fountain,这个技术也非常老了,近两年在实施领域,可能在广播里面应用比较多。它是无码率的注册编码,特别适合多场景使用。它增加了流量和延时,但是相对来说FEC机制增加的延时量是比较稳定的,适合信道特征稳定的场景。

WebRTC提供了异或和交织编码这两种。 WebRTC中使用的XOR FEC,异或是通过分组的原码实现的。我提了4个数据包生成三个冗余包。如果收到数据包123,数据包123丢失了,收到4567。123是数据包,4也是数据包,冗余包是567,通过47,把数据包给否了。

需要损失程度和乱序相关的反馈,才能正确选择KFecMaskRandom还是KFecMaskBursty。

这个是WebRTC中FLEXFEC,还是刚才的异或关系。一种是非交织,一种是交织的。非交织的比如说1234进行异或生产一个数据包。5678生成一个数据包。

对于交织的情况,可能就是159,然后生成一个纵向的冗余包。现在还有二维的,横向的也生一个冗余包,纵向也生成一个冗余包,它的纠错能力不是那么强,这是WebRTC里面的事情。

还有一种是FEC和交织搭配的使用。数据包1234、1234,写入一个矩阵,然后读的时候是按列取的,这样就实现了交织。

交织目标是为了把差错离散化,再用FEC技术恢复。交织深度M越大,离散度越大,抗突发丢包能力越强,延时越大。

怎么设计一套好的FEC算法?

1、抗丢包算法要纳入拥塞控制算法,必须是网络自适应的,非常重要,是前提。

2、保证抗丢包能力的前提下如何减少冗余流量。

3、如何最大化发挥各种FEC机制的优点,场景反馈(连续丢包次数,丢包特性)。

4、FEC算法,分组大小的选择,对流量、延时,抗丢包性能的影响均要考虑到。

5、动态冗余率机制,收敛速度。

6、FEC效果评价。

7、一对多场景,需要对每路接收定制化FEC保护方案。

收端要做好各种反馈,收端收到数据包的时候,要做一些成功率的计算,都反馈到策略中心,来做相应的统计、控制。

NACK算法关键点:

1、结合音频/视频的Jitter buffer状态决策请求。

2、发端/收端延时控制。

3、其它很多精细化控制细节。

4、重传效果的评估。

5、运营、数据监控。

结合纠错和同传的机制。上面对比了一下ARQ和FEC的能力。ARQ引入了突发抖动,较难处理。突发丢包处理能力好,流量效率高。引入延时不固定,但可以设置限制。

FEC抖动变化小,大小丢包均能处理好,但要牺牲带宽突发丢包处理不好。引入延时相对固定。

WebRTC RetEQ算法里面的关键点:

1、延时估计算法。

2、播放延时估计算法。

3、自适应决策逻辑。

4、语音变速算法。

5、VAD、CNG数据算法。

关于流量。

1、降低传输包头:传输层包头。

2、增加组包时长,20毫秒调整到60或者80毫秒,减少包头负载。

3、降低内核码率。1:VAD、DTX2codec层面优化码率。

4、降低冗余。

关于延迟

网络延时:处理延时,排队延时,传输延时和传播延时。

设备延时:采集、播放设备。

播放延时,是数据包到达时和播放时间之间的延时,抗抖延时。

编解码和处理延时:编解码和各种前后处理算法延时。

运营方法

第一部分是专业的实验室,保证了我们测试数据的准确性和可靠性,以及可追诉性,为系统正式上线运营提供了保障。

QOE的影响因素是非常复杂的,目前我们仅关注客观质量,设计了一套评估体系。我们在线上系统运营的时候,可以提供一个简单的指标,衡量我们的算法到底是好还是坏,直到后续的优化方向,做一些板块监控。甚至具体到算法调优层面,可以做一些聚类,划定一些分析样本,做进一步的有针对性的优化。

问题分析工具:还原通话过程技术参数,快速问题还原,分析、诊断,也为进一步优化提供丰富案例。

我们通过ABTest运营进行工作方法效果验证。安卓平台FEC优化版本新策略(奇数房间)质量明显优于老策略(偶数房间)。好的系统和算法是要通过运营数据来验证和不断迭代的。

我们云语音质量的数据到底怎么样?2分以下占比小于3%。10%的通话中断了,10%到15%的用户对质量不满意,这个数据可以做一下对比。

我们的优化是永无止境的课题。WebRTC从M56到前两天发布的M66版本,WebRTC解决了1000多个Bug。

Q/A

Q:我想问一下,比如说在接入请求的时候,可能会有一些效率,你的软件、你的网络,还有一些其他硬件的原因。我想了解一下,您这个优化的时候,都是会遇到什么样的问题点?怎么避免这些问题?问一下,比如说你硬件会有一些传输的效率,还有你的软件,或者各个系统之间的一个集成交互的时候,这些忧患点能不能分享一下?

A:我刚才讲到的,系统集成层面上,如果仅仅用浏览器,除了在后台做优化之外,没有太多的优化方法。可能更多的是优化你的流程层面的。如果你有从WebRTC内部层面做优化,那就太多了。音视频所有的领域都可以做,这个范围太大了。我讲的仅仅是网络传输这一个层面,有回升、有效率等等,太多方面了。

05-11 13:23