找回密码
 立即注册
LiveVideoStack 首页 资讯 查看内容
  • QQ空间
  • 回复
  • 收藏

Hulu 视频QoS优化策略(2)

2018-6-26 08:02

接上文


基于带宽估计的码率自适应算法的主要挑战是带宽的准确实时估计实际上是有困难的,一方面由于客户端没有对网络全局的一种认识,它得到的只是一些片面,不太准确的数据。另一方面,在客户端进行选择时,资源和性能实际上是有些Constrain(限制)的,并不能说用一些Fancy(奇特)的机器学习方法在Client(客户端)上进行这样的估计。


基于缓冲的码率自适应算法



带宽估计不好做,怎么办呢?在学界和工业界,有人提出了基于缓冲大小的一类方法。这类方法很有意思,直接把带宽估计完全抛弃,核心思路就是Buffer的大小恒定在一定的范围内,每当Buffer低于一定阈值的时候,就选择一个更低的码率进行Streaming,Buffer很快就会慢慢的填充回来,重新回到合理的设定范围之内,当Buffer太大的时候也是同样。这类方法的好处是规避了带宽估计这个相对麻烦的问题,另一个优势是可以比较稳定地充分利用带宽资源。这是因为在带宽估计时,一般我们都会留一些余量。假设估计的是1.5Mbps的带宽网速,但我只会给它Streaming 1.2Mbps的一个流,这样就比较保险。由此带来的问题就是说我的Buffer很可能会填充到最大值,这时就不能再继续向服务器请求了。再请求的话,Buffer就会爆掉。基于缓冲大小的算法因为是灵活的调整,只要当前带宽不是特别高,都会保持在半满的一种状态,Buffer会不停的下载,与服务器之间的下载行为也是连续不断的。因此基于缓冲大小的码率自适应方法能比较稳定的充分利用带宽资源。



基于缓冲大小的码率自适应算法也存在着一些问题,首先它的参数比较多,每一个比特率都要为其设定相应的带宽切换的阈值,这在工程实践中是非常头疼的。因为每当码率的设置由于种种原因发生一些变化,都需要进行相应的调整。而且如果Maximum Buffer Size比较小的话,这些阈值几乎就变得没法调节,甚至就会相互之间Overlap,根本不能用。另一个问题是这类算法会带来比较多的码率切换。假设当前的带宽是1.2Mbps,可用的码率有两个,一个是1Mbps,一个是1.5 Mbps。这类算法会使Streaming一直在1Mbps和1.5 Mbps之间进行切换,直至基本用满1.2Mbps的网络。虽然整体上看,视频画面的质量提高了,但带来的切换是多次的。实际应用中这种切换对于用户是带有负面效应的,尤其是当带宽的Ladder / 档次设置的比较粗,上下的两节画面适量的差别比较显著的时候,会有很多次的切换。对于用户来讲,这种画面质量的增益是得不偿失的。


混合算法



考虑到这两种算法各有优劣,现在大家会考虑混合类的算法,这类算法会综合运用带宽估计和缓冲区大小的信息,明显比上述的两类算法的都要更优一点。常见的一种方法是,当Buffer Size比较大的时候,主要依赖基于带宽估计的方法做决策,反之当Buffer比较小的时候,就用Buffer Size的方法进行调整,可以针对业务需求对各项权重进行相应的调整。

流媒体服务质量优化的挑战



接下来结合Hulu的技术实践介绍我们在优化时遇到的一些挑战,虽然这些挑战主要是我们从优化ABR算法中总结出来的,但其实对于所有QoS类的优化都适用,基本上是一些常见的痛点和通用的解决方法,这里遇到的挑战主要在以下三个方面。一个是数据的规模特别大,每一个用户在每一个播放Session中,都在产生QoS Data,怎么对这些数据进行处理?怎么对数据进行过滤?这实际上需要公司内部有大数据相关的基础架构。第二个挑战是线上的数据噪声比较大,各种各样的设备、各种各样的网络情况,各种各样的软件版本,比如说安卓各种各样的型号和版本,这些都会使得QoS数据有很高的噪声,导致真正想看到的趋势和规律可能隐蔽在很重的噪声下。所以如何屏蔽噪声对算法研发造成的影响是一件颇具挑战的事情。最后一个挑战就是影响用户的体验的维度较高,像我们刚才提到的,很多非技术因素都会导致用户的体验发生变化。由于QoS的优化最终还是为了优化QoE,因此我们的实验和论证设计必须要仔细,否则我们想得到的增益就可能被一些随机因素所埋没。


流媒体服务质量优化的实践



针对于此,我们设计了一整套QoS优化的系统,这套系统包括数据分析,线下实验和线上AB测试三个主要的模块。


数据驱动



数据驱动是整个优化工作的起点,它的目标是通过分析线上实际的QoS数据,找到用户在哪里的体验还不够好,然后指明优化工作的方向。比如我们想要优化Rebuffer,可以看到哪些用户的Rebuffer是最严重的、在哪些设备上我们应优先做出优化、是不是在地域上面有某种形式的关系、他们使用的网络条件、软硬件的版本是否有什么特殊之处,诸如此类问题都是在数据驱动里面需要去回答的问题。其实在工作的开始之初,对于数据驱动我们并不太重视,也踩了很多的坑。开始时,我们的研究员或者开发人员的做法是直接杀到代码里面去:“这块逻辑是不是可以改的再优一点,那块能不能改的更优一点,改完以后就直接进行AB测试,看看有没有性能,有性能的话就上线,没性能的就不上线。”不过最后发现这样其实是没有效果的,虽然通过对代码逻辑的分析,能够找到对于某一些场景是能做出优化的,但是由于没有分析这些数据,我们不知道优化的场景在实际用户中占的比例到底有多大,到底是不是一个主要矛盾,或者说只是Design了一个不存在的问题的答案。这就使得我们整个优化相对来讲比较盲目,得到的结果是算法变的特别复杂,相关逻辑是以前2倍甚至是3倍,而增益却非常的小。我们采用的解决方案就是通过使用数据驱动的方法,在优化的初期甚至是优化开始前,就能够知道优化这样子一个Scenario,它是我们现在问题的主要矛盾。对网络的这种环境,这样的一种Pattern进行优化是有意义的。我们能在工作开始之前就对想要得到的增益进行估算,这就使得相关的工作可以做到有的放矢,具有逻辑性和计划性.


在Hulu内部,我们也做了很多工作。首先,刚才提到我们是跨越了所有的平台,所以需要把所有平台上的QoS Data全都整理清楚,让它们的定义变得一致,让它们的发送逻辑变得一样,这样才能在不同的设备之间进行对比。这在Hulu的系统里面还是颇具挑战的,因为平台的数量确实很多。同时,我们还搭建了一整套的大数据的平台,使得我们可以灵活的对数据进行聚合,处理以及分析,借此搭建整个的数据驱动的基础。


线下论证



第二个重要组成模块是线下论证,这个模块的主要目的是实现算法的线下快速迭代。跟刚才提到的数据驱动一样,在直觉中,线下论证也是可以不存在的。最初的实践中我们也确实没有做这一步,后来却发现线下论证必须要做,原因有两个方面:一方面是线下论证的成本比线上论证低,主要是在时间上会节省很多。线上做一个AB测试至少要一周的时间才能够看到有意义的结果,而线下的可以没日没夜的跑。并且线下论证成本低的另一个维度是不会对线上用户造成任何影响,即使是比较Crazy的Idea,线下都可以测。如果是以前那种刀耕火种的年代,很多比较激进的可能带来负面效果的想法最终都会胎死腹中,并不能得到在线上实测的机会,原因就是害怕影响用户的体验。另一方面,线下论证还能做一些线上实验做不到的事,主要在于可以控制变量、降低随机干扰。在线下环境中,我们可以把不希望影响用户体验的一些维度屏蔽掉,还可以对网络环境进行相应的配置,这就使得整个对比比较单纯,整个环境比较清爽。这样的实验在线上我们是没办法实现的,因为线上影响的维度实在太多,有很多的维度我们甚至没有真正有效的衡量手段。


为了做线下实验,我们搭建了一整套流媒体测试的离线平台,主要分为三个重要组成部分。第一个重要组成部分是变量控制的实验环境,在这个实验环境里我们可以对不同的算法,如ABR算法或其它QoS改进的算法,做一种可重复的实验。实验中的网络环境是可以灵活控制的,可控制的参数包括像带宽、丢包率、延迟等,且可以做到Session级别Bandwidth Trace的重现。例如我设计了一种带宽变化的Pattern,它一开始是500kbps,5秒钟之后掉到300kbps,过了3秒钟又升到了1Mbps,类似于这样的一种Pattern,我们可以把它直接Configure在我们的这个实验环境中,我们可以设置很多种的 Bandwith Trace,让不同的算法在同样的Bandwith Trace下进行同一种实验,最终得到结果,所以说,这是为了更好的去模拟现实生活中的环境而进行的工作。第二个重要组成部分是我们的产品代码和真机的离线测试,在这套系统里面,我们使用的是线上真实的Player和Client端代码,并且会使用真机做一些相关的测试,这就很大程度的规避了由于设备和试验中的一些问题对整个Performance造成的影响。因为我们在实践中发现,有时并不一定是算法不对,但是在某个平台上的模块API的实现就是和别的平台不一样,就使得这个平台上的一些效果打了折扣,甚至可能发生扭曲。我们这套环境使用了真机进行测试,所以说它的保真度是很高的。最后一个重要组成部分是如图所示的这个直观的UI,在这个UI上把我们所有关心的指标,如Buffer的状态,当前Player状态机的一些状态,还有当前的带宽,码率,我们现在想要去Track 的各种各样的延迟等,所有的信息都以可视化的方式展示在这里。我们所有的离线的Session都可以展现在这个平台上,使得我们可以比较便捷的进行调试。


线上实测



最后一个重要的组成模块就是我们的线上实测部分。虽然我们前面做了很多数据分析和多线下的实验。但对于任何一个公司,线上实测这一步骤都是不应缺失的。主要有几个方面的原因,一方面,线上实测是验证性能最直接,最有效的方法,我们前面说的这些离线测试,数据分析,跟技术人员讲起来,大家是Buy-in,说你这个看起来合理,应该是有增益的。但对于一些非技术人员来讲,只有在线上证明过,才是真正有增益的。另一方面只有通过线上的实测才能够真正地获取QoE的数据,线下实验说明这个算法能够优化Rebuffer,降低10%。但用户是不是会因此看更多的内容,只有通过线上实测,才能获得相关的宝贵信息。最后一方面,线上实测实际上能够带来很多的数据,这些数据既能使我们的数据分析做得更好;也可以使得我们的线下实验更加的保真,比如说我们获取了QoS和QoE的数据,就可以进一步的推动用户数据分析中模型的建立。此外,如果线上实验和线下实验的结果在QoS上发现有些不同,就可以针对这种不同对我们的线下的实验进一步的改进。比如线下实验中可能有一些线上的Pattern没考虑,那发现了这个不同之后,我们就可以把这种Pattern加回到线下实验中,使得接下来的实验更加准确。这就是我们一整套的线下实验和线上实验以及数据分析优化的系统。


优化结果



最后简单说下结果,在Hulu内部已经用这套系统对核心的QoS指标进行了多轮的优化。优化的内容包括了像码率、Rebuffer、加载时间等Qos核心指标,并且显著提高了用户的满意度和相关黏性。比方说我们针对的QoE的指标,包括了像观看时长,退订率,观看完成度等一类指标都实现了大幅的优化。用这样一整套比较完善的系统来做优化,我们某些平台上的核心QoS指标得到了大幅优化,一些平台上的Rebuffer甚至降低了50%以上。



LiveVideoStackCon 2018讲师招募



LiveVideoStackCon 2018是音视频技术领域的综合技术大会,今年是在10月19-20日在北京举行。大会共设立18个专题,预计邀请超过80位技术专家。如果你在某一领域独当一面,欢迎申请成为LiveVideoStackCon 2018的讲师,让你的经验帮到更多人,你可以通过speaker@livevideostack.com提交演讲信息。了解大会更多详情,点击 beijing2018.livevideostack.com 访问LiveVideoStackCon 2018官网,报名即刻享受7折优惠。

来自: LiveVideoStack
文章点评