小言_互联网的博客

BIGO | imo实时语音传输优化揭秘

435人阅读  评论(0)

​2020年新冠疫情持续蔓延全球,亿万人的生活因此发生了巨大的改变,人们对实时音视频通话的日常需求也越来越大。作为BIGO公司旗下重要的全球性即时通讯产品imo为全球2亿多用户提供优质稳定的即时通讯服务,在2020年上半年全网通话时长提升30%以上,开斋节(穆斯林节日)更是提升50%以上。是什么技术力量支撑让imo能够适应全球各式各样的网络环境和用户类型,在各类竞品中脱颖而出,为imo全球化的战略保驾护航,乘风破浪,迎难而上的呢?接下来我们就结合imo的语音传输业务和大家探讨一下。

 

一、imo实时语音业务背景和面临挑战

 

众所周知当前的绝大部分手机即时通讯产品都是基于VoIP技术。基于IP网络的VoIP技术,我们公认在网络架构存在着挑战。因为VoIP一般走的都是公共网络,网络环境不稳定,会面临丢包、延时以及语音包抖动等问题,所以基于IP的通话是没有质量保障的。

 

                                                                图1  VOIP系统示意图

 

业界上使用QoE/QoS的模型来介绍和分析这样的问题。

QoE(Quality of Experience)的评价主体是终端用户,评价对象是业务和支撑业务的网络。其设计理念是为了更贴近用户的真实感受,主要是用来衡量用户的主观体验,例如通话过程发生频繁卡顿,有多少用户会因为无法忍受而选择结束通话。

与之对应,QoS(Quality of Services)主要反映的是客观指标,如一次通话过程中发生了多少次网络卡顿或者丢包。其更专注于纯网络范畴的指标,设计理念主要负责从网络的角度进行业务管理和提供业务的差异性,网络实体根据不同的质量需求来处理不同业务。终端+整条网络链路的一系列服务需求,例如带宽,延时,抖动,丢包这些都反应着服务质量QoS。

不难看出,服务质量QoS的优劣与否很大程度上影响着用户体验质量QoE,并最终反映在用户对产品的喜爱和依赖程度等主观感受上。因此为了更好的让用户获得清晰流畅的用户体验,我们imo音视频传输团队需要尽可能的提升QoS保证服务质量。

而要想提供优质和稳定实时服务,保证服务质量不是一件容易的事情。因为不同于许多国内同类型的其他产品,作为一个全球性的实时音视频通讯产品,imo面对着更多复杂的挑战。首当其冲的就是复杂多样的网络。

 

                                                         图2  imo全网用户和东南亚某新兴市场用户网络比例图

 

imo用户的一大特点就是遍布全球各地,网络环境丰富动态差异大,有较好的4G/WIFI网络,但更多地方特别是近年来用户增长率高的一些新兴市场主要是3G/2G的弱网环境为主。和中国地区4g网络覆盖比例达95%以上相比,imo用户接入网络相对较为落后。从上图可以看到全网imo用户接入网络占比中,4G网络比例只占了39%,2G/3G占了29%,而以东南亚某新兴市场为例,其imo用户接入网络占比中2G+3G的用户比例占比高达49%。

 

                                                   图3  中东与南亚两个主要市场国内国际电话比例图

 

imo用户的另一大特点就是对跨国甚至跨洲际的通话有着极大的需求。

据imo线上数据统计,以中东和南亚的两个主要市场为例,某中东市场imo用户的国际电话比例占到总通话次数的60%,而某南亚主要市场imo用户的国际电话次数比例则高达69%。这样的国际通话就涉及到更复杂多变的媒体服务中转和较长的传输链路。这会导致用户之间的网络链路较长,使得抖动甚至拥塞突发不可避免。要想在这样的背景下提供优质稳定的QoS可谓困难重重。

因此我们imo音视频传输团队围绕QoS深耕服务,着重设计强化了相关需求模块,同时针对imo的特殊情况我们也做了许多差异化的服务来应对挑战。接下来我们就先来了解一下imo语音传输技术体系是如何在这样的网络环境下提供稳定优质服务的。

 

二、基于QoS的imo语音传输技术体系

 

01  用户接入

imo通过一系列的措施保障用户无论何时都享受各种网络的高可用性

1、通过实时探测计算整体用户网络,计算分配最合适的接入节点

随机挑选少量空闲用户,通过对用户到不同节点到小流量的探测,判断当用户到节点的网络状况,并将探测结果上报到后台,后台通过结合客户端探测结果和各个节点的负载情况,汇总分析出用户最合适的接入节点,当相同运营商用户通话时,将实时计算出来的最优节点分配给用户

2、使用多Relay(中转服务器)转发保证跨国用户通话网络质量

通过使用计算出来的最优节点解决的是用户第一公里和最后一公里的接入问题,当用户进行跨国通话的时候通过多条relay转发保证用户通话长链路质量的最优

3、通过多协议转换,保障高可用性

imo通话支持UDP,TCP, HTTP等多种协议,并且数据格式灵活多变,通过不同协议间切换,保障用户在各个网络情况下的高可用性。

 

                                                           图4  imo通话各个协议占比

 

如图4所示,可以看到imo通话中有超过10%的通话使用的不是传统的UDP协议,通过后台的配置,将部分用户配置成TCP或者HTTP,以保证用户的通话可用性,提高通话接通率。

 

                                                图5  北美和中东用户通话接入示例图

 

如图5所示:北美用户和中东用户进行国际通话,通过分别接入伦敦服务器和阿姆斯特丹服务器保证用户接入最优节点,两个服务器再进行中转,以保证整个链路的高可用性。

 

02  流量控制模块

带宽自适应是指在语音的收发过程中,根据网络带宽的变化,自动的来调整发送码率,来适应带宽的变化。在带宽足够的情况下,增加采样率和码率,提高语音的质量,带来更好的通信体验。在带宽不足的情况下,主动降低采样率和码率,保证通信的流畅性和可用性,也是带来更好的通信体验。带宽自适应的核心,就是如何准确的估计带宽。

imo使用了基于接收端的丢包率和延时反馈的带宽估计算法,同时引入pacer,pacer会根据评估出来的码率,按照最小单位时间(5ms)做时间分片进行递进发送数据,避免瞬时对网络的冲击。pacer的目的就是让媒体数据按照评估码率均匀的分布在各个时间片里发送, 所以在弱网环境,pacer是个非常重要的关键步骤。

imo的自适应码率方案,收集全部模块的输出流量按优先级分配,根据带宽估计反馈的丢包率和延时,决定ARQ和FEC的使用策略。采用冗余包进行上探,码率稳定后再提升源码率。

 

                                                        图6 码率自适应示意图

 

1、Receiver接收到报文,计算进行到达时间统计和丢包统计

2、Detect根据收端的延迟增量和丢包率信息计算出网络拥塞状态, 评估出适合当前网络传输的码率,并通过feedback反馈到发端

3、收到反馈码率,pacer会根据这个码率改变pacer的网络发送速度,流量控制模块根据反馈信息,决定是否需要上探或者下调,调整ARQ&FEC的使用策略

4、sender收到pacer的发送事件,开始新一轮的码率评估流程

 

03  抗丢包模块

音频实时通信对信息要求确保尽可能完整恢复信息的同时,尽量降低延时,而且要避免拥塞。业界有多种策略可以解决丢包问题,一般包括:自动重传请求ARQ、前向纠错FEC、HARQ(Hybric ARQ)等。

 

▼ 分段和透传的灵活调度

                                                         图 7 分段与透传FEC示意图

 

在1v1通话中,需要考虑的一个问题是 server 采用分段还是透传的方式做FEC。两种方式各有优缺点。恢复的方式相对直接透传冗余包的方式,虽然会增加server对RS包的编解码消耗和编码时延,但是可以避免丢包率小一侧链路的冗余流量,因为主被叫两段链路的丢包率往往是不同的。此外,分段恢复的方式也容易扩展到群语音。imo通话中,我们灵活调度这2种方法,对于对流量较为敏感,或者RTT较大的通话,选择分段恢复的方式;对于流量不太敏感,或者RTT较小的通话,选择透传的方式。

 

▼ 冗余表

 

                                            图8 FEC 控制模型     黑线数据流,红线控制流

 

在FEC的控制中,冗余表扮演一个非常重要的角色,决定了冗余是否高效,在恢复丢包的同时不引入过多冗余。在imo中,我们根据下面的方法计算冗余表。

假设 n 个原始包编 k 个冗余包,每个包的丢包率为p,那么收到 i 个包的概率为:

在收到 i 个包的条件下,原始包个数为 j,那么恢复后的原始包个数期望值为:

如果希望恢复后的丢包率小于某个丢包率,例如1%,那么,对方程求解,就可以得到特定 (n, k) 下可抵抗链路丢包率的最大值。

选择不同的 n 和 k,可以求解得到如下表,如果选定n=5,链路丢包率在[4.7%, 9.6%)区间,那么使用 5+2 的冗余,可以使得恢复后的数据丢包率小于1%。下面,我们称恢复后的数据丢包率为容忍丢包率。

根据这个计算方法,我们可以画出组包个数 n=5 的容忍丢包率对应的链路丢包率率切换阈值曲线。

                                              图 9  n = 5时,容忍丢包率与链路丢包切换阈值的关系

 

从上表和图9,我们可以发现几个特点:

1、如果控制容忍丢包率趋向0,那么链路丢包率切换的曲线也趋向0。

意味着需要增加越来越多的冗余流量,才可以使容忍丢包率控制在一个很小的值,性价比越来越低,以0%为容忍丢包率是不现实的。

2、在不同的容忍丢包率要求下,FEC覆盖的丢包率范围不同。

例如,设置1%的容忍丢包率下,只能覆盖到24.5%的链路丢包率。

3、同样的容忍丢包率和冗余率,组包数n越大,覆盖的丢包率范围越大。

例如,同样在1%的容忍丢包率要求下,n = 1 时,1+1的冗余只能覆盖到10%的链路丢包率;而 n =5 时,5+5 能覆盖 24.5%的丢包率。

在此基础上,根据连续丢包个数和容忍的最大延时,选择不同的分组组合,理论上可以达到高效利用带宽的目标。真实场景的丢包率并不是恒定的,丢包率的统计、连续丢包数和RS编码改变冗余有滞后性;因此需要考虑运行中的动态性,适当增加冗余,才可以达到较好的效果。

 

▼ 动态冗余率的收敛速度

冗余率的收敛速度是影响恢复效果的。我们发现开启FEC的丢包率阈值附近,存在频繁启停与冗余率切换的问题,这个问题不仅使恢复率大大降低,而且浪费了冗余流量。针对这个问题,我们采用了滞回的策略:在不拥塞前提下,冗余率至少保持一段时间不下降。如下图9所示,冗余率频繁切换过程中,丢包不能得到及时恢复,在增加滞回后,恢复效果明显变好。

 

图10 

左:频繁调整    

右:滞回   红线代表丢包率,黑线代表冗余率  特定场景下恢复后丢包率从7.35%下降到1.14%

 

▼ HARQ

针对ARQ与FEC两种抗丢包方法的特点,我们采用了扬长避短的策略,尽可能发挥各自的优势,这就是HARQ(Hybric ARQ)。整体思路是,HARQ在RTT较小的网络中,主要采用重传策略,减少冗余流量;在RTT较大的场景中,主要使用FEC,降低恢复延时。

                                      图11 HARQ策略转换图

 

难点一:切换阈值确定

HARQ一个难点是不同策略的切换阈值如何确定,rtt/丢包率的阈值设定小了会浪费流量,阈值设定大了恢复率可能达不到预期。

我们的方法是以恢复率为目标做自动调整:

1、根据当前rtt和链路丢包率,先计算ARQ在最大引入延时下的理论恢复率

(1)如果srtt大于设定的ARQ最大引入延时,则关闭ARQ。

(2)如果ARQ恢复率满足设定目标,则只开启ARQ。

(3)如果ARQ恢复率不能满足设定目标,则剔除ARQ恢复后的丢包率作为输入,计算并调整FEC的冗余度。

2、理论计算和实际情况会有偏差,为了矫正这个偏差,接收端反馈丢包恢复情况给发送端,发送端根据反馈的恢复率和目标恢复率比较,如果偏小则对应调大冗余。

 

难点二:拥塞避免

不管是ARQ还是FEC,都需要增加额外的流量来实现抗丢包。然而在拥塞场景,这种额外的流量反而会恶化网络,使丢包率变大;这时如果抗丢包模块不对这种情况做区分发送更多额外流量,只会使得网络更差。

我们在刚上线HARQ的时候,就碰到了这样的问题。从AB实验数据中,我们发现部分的case的恢复率较低,一小段时间出现丢包率特别高、rtt增大明显的情况,可以推测发生了拥塞。为此,我们在抗丢包模块增加了基于rtt梯度变化来做拥塞判断逻辑。在srtt大于一定阈值,认为可能存在,这时计算梯度变化,变化大则认为拥塞,从而调整抗丢包冗余。另外,我们也设计增加BWE做更精确的拥塞判断,这个工作也正在进行之中。

下图12是东南亚某市场增加拥塞判断逻辑前后线上数据对比,在丢包恢复率相当的前提下,优化后rtt从增量100ms到变化不大,拥塞现象减少:

                                                  图12 增加拥塞判断逻辑前后线上数据对比

 

下图13是不同场景下HARQ和ARQ+FEC各自处理的效果对比,可以看到,限速场景HARQ恢复率提升明显,减少拥塞发生提升了恢复率;另外引入流量降低明显,HARQ统一决策有效降低无效流量。

                                                   图13 不同场景下恢复率和引入流量

 

▼ 抗丢包整体效果

丢包场景下,抗丢包模块明显提升了mos,丢包率40%以下mos分能保持在4分以上,音质平稳度较高,有效地提升了用户体验。

                                                    图14  无抗丢包版本mos分测试 

 

                                                   图15 抗丢包版本mos分测试

 

▼ 运营挑战和思路

在运营中,因为很多数据是基于整个通话来统计,但是在实际问题和排查中,难以定位具体的原因。例如,在一个30分钟的通话中,前28分钟的通话质量非常好,最后2分钟因为通话卡顿或者听不到声音而挂断电话。在这样的场景下,分析整个通话的播放丢包、网络丢包情况,丢包率并不高,难以定位到用户发生了什么问题。为了解决这个痛点,我们设计了trace运营思路:

                                                  图16  抗丢包trace运营流程图

 

通过trace抽样上报,我们达到了全链路包级别数据可泛化,这样让我们对于问题收集和分类更加充分和完备。对线上具体bad case分析,以此推动了抗丢包模块的不断优化迭代;同时,对线上用户的痛点了解更加深刻,对如果评价抗丢包效果有更多思考。

 

04  抗抖动模式

抗抖动的基本思路是用适当的延时来换取卡顿率的下降并在二者之间达到最优的播放体验,业界常见的抗抖动算法有基于自回归(AR)估算算法,基于统计(Statistically)的算法和基于自适应滤波(Adaptive Filter)的算法。

基于自回归估算的算法,输入的是单向延时,经过自回归估算得出播放延时。实现上可在talkspurt之间调整延时(需要静音信息),或talkspurt期间调整延时(需要引入TSM,变速器),甚或引入Spike检测,可以适应网络拥塞引入的突发抖动,快速响应网络变化。

基于统计的算法,以过去一段时间收包的网络延时做直方图统计,取一定概率总和所对应的延时值作为网络抖动的估计,难点在于过去一段时间长短的取舍,取得太长,最近网络变化会被平均,取得太短,估值起伏随网络变化太快,也就失去了统计的意义,经典的实现代表是webrtc neteq,使用遗忘算法对每种迟包概率进行动态调整,结合峰值检测得到较好的网络抖动估值,在此就不作详解。

基于自适应滤波器的算法没有对网络延时做出反应,而是尝试预测网络延时。自适应滤波算法旨在最小化实际网络延时和估计之间的期望均方误差。先前的延时通过有限脉冲响应(FIR)滤波器传递,以计算当前估算值。然后,将均方误差用于调整自适应滤波器的抽头权重。经典实现有归一化最小均方算法(NLMS)。

imo用户分布全球,通话类型也以跨国通话为主,为适应这种网络链路引入的抖动,我们引入并优化了业界多种抗抖动算法,经过比较,最终Bigojitter胜出。

                                             图17  BigoJitter原理架构和网络抖动估算示意图

 

如上图17所示,Bigojitter主体包括语音包缓冲区,网络抖动估算,播放延时估算,播放决策,解码器,变速器,解码数据缓冲区等模块,核心算法在于网络抖动估算,播放延时估算以及播放策略,Bigojitter使用历史抖动范围和自回归算法来估算播放延时,从而可以快速适应网络的抖动变化。

Bigojitter的优化主要分为两个阶段:第一阶段是在实验室构造各种弱网场景,使MOS分和延时都能达到最佳状态。由图17可见,MOS分在各个场景平稳下降,延时和网络抖动符合线性关系。

                                                图18  BigoJitter实验室优化效果示意图

 

虽然Bigojitter优化在实验室测得较好成绩,但上线运营符合预期才是关键。借助强大的ab实验系统,可分析不同版本各个维度参数的变化趋势,甚至提取trace数据进行研究,我们发现imo用户在某些地区和通话场景下,网络拥塞和超大抖动是不可避免的。在这种情况下,jitter基于实时通信的要求触发了主动丢包降低延时,导致信号完整性问题。于是我们及时调整了策略,增加jitter自适应范围的上限,用适当的延时来换取迟包丢包率和播放丢包率的下降,事实证明,这个优化使得ab结果从一直负向转向显著正向,最终达到技术优化和业务增长双赢的目标。

                                          图19 Bigojitter迭代优化过程:迟包丢包率和播放丢包率明显下降

                                                  图20  Bigojitter迭代优化过程:buffersize分布

                                                  图21  某新兴市场的音频单次通话时长趋势(注:该新兴市场在4月推全BigoJitter优化版本)

 

04  完善的语音质量测评体系

想要持续运营维护一款受众数亿用户的产品,单单只专注于功能性需求的开发是肯定不够的。搭建一套完善而全面的语音质量评测体系,不仅能支撑各项优化开发稳步前进,提供数据平台的支持,还能赋能各个开发人员,提供驱动力在各种评估体系中探寻不断优化完善产品的突破。

 

▼ 实验室内部自动化测评工具建设,分为以下几方面

(1)采购第三方语音质量评测仪器,该仪器采用ITU-T P.863(POLQA)算法,覆盖了超宽带语音传输评测,用到感知模型和认知模型模拟了人耳听觉对外界声音信号的心理物理反应;

(2)搭建网络实验室,采购了能够精确模拟的硬件网络损伤仪、自己搭建TC网络模拟环境以及自研内嵌网络模拟配合白盒测试,模拟用户各种网络场景;

(3)打通测试平台,与CI结合建立全自动音频质量测试,制定音频质量基线。

                                                图22 自动化测试流程示意图

 

                                               图23  自动化测试报告对比图

 

通过实验室自动化测试,基于质量基线开发,不仅节省测试人力成本提高测试和研发效率而且还支持异地和海外同事远程使用。

 

▼ 研发线上无参考评估系统

在基于网络参数的无参考这方面参考ITU-T G.107(E-Model)等标准,首先模拟网络情况构造严重卡顿和轻微卡顿的测试样本,记录卡顿次数break_num;其次是获取codec、采样率、编码码率等参数,记录为codec_type、sample_rate、encode_rate;然后将测试样本通过polqa/主观打分得出mos;最后通过mos、codec_type、sample_rate、encode_rate、break_num多元拟合得到无参考模型;根据大量的polqa/主观打分修正无参考模型。

在基于音频信号的无参考模型建模方面,建立纯粹的语音通话Demo(排除网络因素);构造噪声,响度,回声,内容卡顿检测等测试样本,同样测试样本需要polqa/主观打分得出mos;通过LSTM深度学习提取无参考模型;最后根据大量的polqa/主观打分修正无参考模型。

                                                 图24  imo语音线上质量评估体系图

 

Imo线上的无参考质量体系实现了对语音通话的实时评估,捞取低分案例,结合低分原因以及诊断工具可以更好地分析跟进badcase,提升通话质量;imo线上的无参考质量体系打破了以通话时长作为技术优化的标准,同时给AB实验提供支持。

 

▼ 线上质量问题分析跟进利器-诊断工具

要能够及时解决线上用户的问题,就必须具备以下的两个条件:1. 聚合线上用户所有相关的日志  2. 高效分析用户日志。诊断工具已把以上的两个条件全程自动化,开发员只要输入用户的UID就能一键查询到相关日志和看到这通通话的初步分析拓扑图。

                                                       图25  诊断工具分析拓扑图

 

从拓扑图25可以看到服务器与被叫的下行链路丢包率异常的高,并也导致jitter的播放丢包率升高。根据这个分析,我们就能快速的定位到发生问题的模块,让模块的负责人深入的调查问题根源。这样,解决问题的效率能够大大的提升,提升了团队的问题响应速度和定位问题的能力。

 

▼ 竞品对比-主动寻找与业界差距

技术在不断更新,我们会定期与业界竞品进行质量对比,主动发掘与竞品的差距,例如在一次与竞品的测试中发现,imo的丢包抗性不如某国外竞品,通过对抗丢包模块进行专项优化实现了对齐该竞品甚至超越。

                                               图26  imo语音抗丢包优化前后音质对比某竞品

 

同时,我们也不局限于实验室,imo是一个全球化的产品,每个用户所处的环境都是不一样,特别是跨国通话,网络环境的差异、服务器的部署等都环环相扣,imo在新加坡等海外地区也有专业的测试团队,imo团队也是全球化的团队,依托Bigo海外30多个办公室,可以比较全面的与竞品进行实地评测。

 

三、基于imo特点的差异化服务

 

为了能够从众多竞品中脱颖而出,imo除了深耕于传统的QoS相关模块,提高服务质量的基础上,针对全球化用户的特点,也不断探索了出一些差异化的服务需求。

 

01  用户数据的隐私性和安全性

随着网络音视频产品的普及和需求日益增加,相对的安全性问题也在不断凸显,私人音视频信息遭泄露等事件时有出现,前不久爆红视频会议软件ZOOM也因其安全性问题而饱受抨击。而imo在早期就已经开始关注用户数据的隐私性和安全性的保护。

                                                              图27  imo媒体加密示意图

 

imo客户端之间的数据传输使用128比特AES-CTR加密模式加密,客户端与服务器之间的数据传输使用256比特AES-CBC加密模式在确保用户数据安全的同时性保护用户隐私,这两种加密模式都是当前主流商用密码加密模式,加密安全强度有保障。相较于AES-ECB,RC4,imo采用的AES-CBC加密模式可以较好的隐藏数据细节,以此为用户数据提供更高的安全性保护。

 

02  针对机型碎片化改进的统计上报机制

如上文所提到的一样, imo用户的手机机型碎片化是非常严重的。通过分析线上数据imo用户机型分布,我们发现前一百机型的比例只占不到50%。而且imo用户手机升级也较为缓慢,以android机为例,Android系统从4.1~11都存在,所以音频采集和播放需要考虑设备的兼容性。为此,imo在设备运行各个环节都埋下状态码统计,并对最终采集和播放结果进行检测,通过后台数据分析和用户反馈,即可发现碎片化的问题,并实现设备各种模式和参数切换的可配置,从而及时解决线上用户的设备异常问题。

 

03  基于统计学设计的AB测试实验

为优化imo音视频的通话质量,需要不断迭代并上线新的feature,而在未证实该feature确切有效之前,是绝不可轻易上线的。AB实验正是为了验证feature是否有效而设计的,它是一个样本推断总体的过程,方式是进行小流量的测试,利用样本的效果来推断上线后的效果。AB实验的解读思想是假设检验,通过定义原假设,并试图利用小概率事件推翻原假设。AB实验的正确设计和正确解读,能够帮助开发人员更好评估新特性,以决定是上线还是继续优化。

既然是用样本推断总体,就难免犯错,指标解读过程中会存在以下两种错误:

  • 第一类错误α:原假设为真,却被我们拒绝了

  • 第二类错误β:原假设为假,却被我们接受了

传统的ab解读,基本上都只对第一类错误α进行控制,因为第一类错误是人为定义的,是确定的,易于控制。但是,如果只控制α错误,而不对β进行控制的话,会发生“实验有效果,但是却没被检测出来”的情况,导致错过有效果的feature。

实际上,在实验中,如果发现指标不显著,有可能是流量不足而没被检测出来,这时候我们需要加大样本量。那么,样本量越大越好吗?其实不然,因为在大样本的情况下,我们会检测出那些细小但有时不具有任何意义的差别,也就是说,即使假设检验的结果具有统计显著性,但是由于该结果效应量太小,实际上并没有什么意义。

为解决这个问题,在imo实验中,我们会基于定义好的α错误,期望达到的效应量,以及可接受的β错误,事先计算出合适的样本量。这样在实验观察过程中,如果发现指标不显著,并且没有到达预期样本量,那么我们便会加大样本量,再观察实验结果。

下表为演示具体case的计算流程,比如我们拿到的样本数据如下所示(此处数据为伪数据,主要用于公式说明,非实际线上数据):

1、提出假设

(1)H0(原假设):假设Bigojitter表现和speexjitter表现无差异,即μ1-μ2=0

(2)H1(备择假设):Bigojitter表现优于speexjitter,即μ1-μ2>0

2、如果原假设成立,那么得到该样本,即x1-x2=4.46的概率多大?

(1)抽样分布均值:0

(2)抽样分布标准差:利用样本标准差替代总体标准差,可得到

  

3、计算当前样本之差4.46距离0有几个标准差:4.46÷1.43≈3.12

#sigma为3.12,说明在原假设成立的条件下,该样本均值距离总体参数超过3个标准差,出现概率极低(如下图红色面积),所以我们有理由拒绝原假设,认为Bigojitter表现优于speexjitter。

                                            图28 Bigojitter抽样结果概率分布图

 

当前,imo音视频已有一套强大的ab系统,该系统不仅涵盖了几百个关键指标,并且每个指标都会自动计算出#sigma。利用ab系统,开发人员能快速判断核心指标是否显著,以决定功能是否上线。

下面为imo ab系统的部分指标,对于第一个指标,其#sigma为107.2,远高于阈值3,可以得出指标显著的结论。对于第二个指标,虽然指标不显著,但我们可以根据效应量计算理论样本量,评估当前样本量是否ok,从而决定是否放量再进行观测。

                                             图29  imo AB实验系统指标展示图

 

四、总结 

 

综上所述,imo音视频传输团队围绕QoS不断深耕核心模块,以解决网络丢包,抖动,延时等实时音视频通信中的核心挑战。与此同时也在不断完善完整的语音质量评价体系,完备的测试环境和置信度更高专项性更强的线上ab测试实验与统计。这一切都是为了能够不断产生新的驱动力去优化imo的音频传输业务。

目前而言我们已经具备了语音传输相关的QoS相关算法模块并各自取得了一定的成绩,但实际上QoS保证牵扯到了编解码,链路,传输,处理, 设备等众多环节,处理好技术的协作关系,如何对各种 QoS 算法的调度、管理、配合是核心难点,也是我们未来阶段不断前进的目标与方向。相信随着对更多基于业务细节的不断深入研究和探索,我们团队会找到更加适合imo的协作策略,让我们的实时音频传输体系能够在更多的业务场景中发挥它的优势和价值。

 

 

版权声明

转载本网站原创文章需要注明来源出处。因互联网客观情况,原创文章中可能会存在不当使用的情况,如文章部分图片或者部分引用内容未能及时与相关权利人取得联系,非恶意侵犯相关权利人的权益,敬请相关权利人谅解并联系我们及时处理。

 

关于本文

本文首发于公众号【BIGO技术】,感兴趣的同学可以移步至公众号,获取最新文章~

 


转载:https://blog.csdn.net/Sprite_CJ/article/details/113058733
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场