QoS直接关系到用户体验，如何提升QoS就成为视频平台技术实力的体现。本文来自Hulu全球高级研发经理、视频编解码与传输领域资深专家傅徳良在LiveVideoStackCon 2017上的分享。尽管Hulu提供服务的网络环境与国内大相径庭，但其相关QoS保障策略依然值得借鉴。
文 / 傅徳良
整理 / LiveVideoStack
概述：
大家好，我是Hulu北京的傅徳良，主要负责音视频编解码和视频传输相关优化的团队。非常高兴在这里给大家分享一些Hulu 在流媒体服务质量和用户体验优化方面的经验。由于Hulu是一家美国公司，所以使用的技术路线跟国内常见的技术路线并不完全相同，从技术上讲，不存在谁更先进或者优秀的说法。不过既然是不同的技术路线，那么Hulu也就可能会做一些国内厂商目前还没有太多投入去做的一些事情。今天，主要跟大家分享一下Hulu在QoS优化中的思路、在实践中遇到的问题以及解决方案。首先简单介绍一下Hulu的视频系统以及为什么要做QoS优化？其次会分享对QoS优化和用户体验之间关系的基本理解，最后结合Hulu的技术实践介绍在客户端通过自适应码率调解的方法优化QoS的基本思路和原理，以及构建的一整套QoS优化框架。
一：Hulu视频系统简介
Hulu是一家由美国最大的几家传统媒体行业巨头出资创建的在线视频流媒体服务公司，其创建目标是把更多的优选内容与全美国用户更好地连接在一起。Hulu的终端是跨越全平台的，涵盖网页端、移动端还有电视端。跟国内业态有所不同的是，除了浏览器，Android和iOS外，在美国还需要支持很多在国内看来比较神奇的一些设备，例如以Roku，FireTV和AppleTV为代表的电视盒子和以PS（Sony PlayStation系列），XBox为代表的游戏主机。我们需要在所有的这些平台上面都支持我们的Streaming服务，如大家所知，这些平台相对来讲都是比较异构的，并不像国内的设备，基本都是基于安卓平台进行开发的。因此为了实现对北美市场上所有平台的支持，给技术层面带来了不小的挑战，尤其是对于QoS调优和用户体验调优一致性上的挑战更加艰巨。
Hulu提供的观看内容是比较丰富的，包括当季的美剧、优选电影、自制剧、体育节目、儿童节目等。2017年，Hulu的直播业务上线，美国数百个Broadcast电视台可以在Hulu的应用和网站上进行播放，而且没有UGC（User Generated Content），都是从较大的渠道获取的有版权的视频内容。值得一提的是，在2017年的艾美奖评选中，Hulu的自制剧也大获成功，共斩获10项大奖，堪称是本届艾美奖评选的最大赢家，《使女的故事》（The Handmaids Tale）还获得了Outstanding Drama Series（最佳剧集奖），这在全世界的在线流媒体行业中，都是一件具有里程碑意义的事情。可见，Hulu是有非常多优选内容的，那么如何把这些优选内容以最好的体验呈现给用户，也就成为了工作中的关键。
Hulu商业模式
值得一提的是，Hulu的商业模式也比较特别，采用注册用户+广告的模式。Hulu是由几家传统媒体公司创建的，商业模式跟整个美国电视行业的模式相似，如果你想要观看Hulu，首先需要付费，注册成为我们的用户。在此基础上，可以选择不同的，有广告或无广告的套餐。这种注册用户+广告的模式使得Hulu在整个商业竞争中处在一个十分特殊的位置，也使得技术层面上需要做出相应的改变。在这种商业模式下，用户的单位价值是比较高的，一方面，用户缴纳了注册费。另一方面，用户还观看了广告，这些广告也带来了很多收入。 在此基础上，如何使更多的用户观看Hulu的视频，观看更多的视频，对Hulu来讲特别重要。当然，这个逻辑基本上对于所有的在线流媒体服务公司也都是成立的。由于内容都是花费大价值买来的，用户的单位价值是较高的，因此Hulu有非常强烈的意愿把用户体验做得更好。更好的用户体验可以带来更多的用户，更大的视频播放量，也就是更多的用户订阅数和更高的广告营收。所以说，用户体验是极其重要的，那么通过哪些技术和方法能够优化用户体验呢？我们发现优化流媒体服务质量的方法是非常有效的一种手段。
二、流媒体服务质量和用户体验
QoS
这一节主要介绍Hulu对流媒体服务质量的认知，它和用户体验之间有着怎样的联系。流媒体服务质量常被称为QoS(Quality of Service)，在传输领域，这其实是一个老词。对于流媒体服务来讲，QoS到底意味着什么？在我们的理解中，QoS其实是衡量音视频播放质量的一系列客观指标，可以划分为三个重要维度：
第一个重要维度是连续性，也就是用户在播放音视频时的连贯性。其中最常见的指标就是Rebuffer（卡顿），Failure rate（播放的失败率）。显而易见，这些事件的发生意味着播放更加的不连续。此外，还有Frame drop（掉帧）等指标。
第二个重要维度是响应速度，这个维度表征了用户在进行交互行为时，我们的Player以及整个应用对于用户的交互行为能否有及时的反馈，常见的一些指标包括Loading time（加载速度），Seek（视频跳转时）带来的延迟，以及广告和内容切换时的延迟等。
最后一个重要维度就是画面质量，常用的指标有码率，分辨率。一般来讲，在同样的Encoding参数下，我们认为码率越高，分辨率越高，用户看到的画面质量也更高。
QoE
与QoS相对应的是概念是QoE（Quality of Experience）。QoE与QoS的不同之处在于QoE是一系列衡量用户对流媒体服务满意程度的一种主观的体现，虽然QoE也是由客观指标构成，但实际上是用户主观满意度的一种衡量。QoE的常见指标包括了观看时长、观看视频数量、观看完成度、用户的退订率等。通过比较，可以发现QoE与Business KPI更加的贴近，是我们最终想要优化的目标。但是由于QoE衡量用户的主观感受，因此会受到很多非技术因素的干扰。如果直接把QoE指标运用到实践中进行优化，效率比较低，容易出现一些问题。Hulu内部也曾对QoE的优化进行过一些尝试，比如想要优化视频的观看完成度，并在技术上做了很多魔改的东西。但是上线AB测试后，发现仅仅是略微有所变化，和周末上了一个新剧带来的抖动相比，基本可以忽略。这样的一些问题就会使得相关的技术优化变得难以实现。另一方面来看，QoS指标要好很多，因为QoS指标客观的反映了我们的服务质量，如优化Rebuffer的比例，从5%降到3%，相对来说这是比较客观、稳定且容易实现的一些指标。从这些问题中，我们可以发现：QoE是我们希望优化的目标，QoS是比较可行的手段。那么能否把QoS和QoE连接起来，通过优化QoS来实现优化QoE？如果这个方式可行，就可以把工作重心放在对QoS的优化上。
流媒体服务与用户体验
幸运的是，这个问题的答案非常乐观的，学界的研究和业界的实践充分证实了流媒体的服务质量是可以显著影响用户体验的。
上图简单罗列了几个数据
（1）在播放卡顿或是加载时间太长的时候，66%的用户会直接退出当前的播放。
（2）17%的用户会因为服务质量的问题退订流媒体服务。
（3）严重卡顿会使用户的满意程度从接近满分跌到几乎为0。
这些研究和以及Hulu的技术实践都充分论证了流媒体的服务质量QoS能显著的影响QoE，因此可以通过优化QoS去达到优化QoE的目的。
这张图是美国一家相关公司对美国市场上流媒体服务的退订原因进行的调差问卷数据统计。我们能够看到Technically Problems（即与OoS相关的因素），占到了17%的比重。值得一提的是， 服务太贵，视频内容不够丰富， 广告太多这三个指标，虽然是比Technical Problem更为重要，但是这些指标是相对难以优化的。如果减少广告投放，那么营收必然会下降。如果购买更多的内容，肯定会带来更多的支出。相比于QoS来讲，在这些维度上想要做出优化所付出的代价会更大，并且不能单纯的通过技术途径来有效的解决。从这里我们能够看出：QoS优化是有效率的，也是相对经济的一种方法。
三、流媒体服务质量优化
前面主要介绍了为什么QoS优化能做，有必要去做 , 接下来从三个方面介绍如何进行QoS优化。
首先介绍如何根据码率自适应的算法进行流媒体服务质量的优化，然后根据Hulu的技术实践，介绍在流媒体服务质量优化中遇到的一些挑战，以及我们自己设计的QoS优化的一套体系。
码率自适应算法
码率自适应算法在国际上的应用已经比较广泛了，不过出于各种各样的原因，在国内的应用的还不是很广泛，所以我就在这里多赘述几句，介绍它的一些原理，希望能让大家更好地认识这项技术，也希望大家能更多地去运用这一项技术。
码率自适应算法是随着自适应视频传输这类协议的兴起而出现的，我们常把它称为ABR(Adaptive BitRate Streaming)或者MBR(Multiple BitRate Streaming)。这类算法的基本思路是在客户端根据用户的网络情况实时对用户当前播放的码率进行切换，这一点跟自适应视频传输协议是分不开的。在常见的自适应视频传输协议下，如HLS和Dash，音视频都被切成了时域上较短的一个个片段，可能是2秒或是5秒，这样的一种切分使得在客户端灵活地对当前的码率进行切换，变得可能和高效，也就可以做到在Player端无缝地对码率进行切换，这样的自适应视频传输协议使得码率自适应算法变得可行而且有效率。Hulu既使用了HLS（因为它是苹果支持的一套协议），同时也使用了Dash，实际上在全球整个业界范围内，Hulu可以说是最早大规模使用标准的Dash的协议来做流媒体服务的公司之一，因此也在这一领域积攒了大量经验。
下面介绍一下为什么码率自适应算法是有必要的，假设说我们的用户的带宽分布如图所示（单峰样式）。
那么如果需要定一个固定码率给用户进行Streaming，该怎么定呢？不论怎么定，其实都不会优。现在图上画的已经还算OK了，我的第一思路是在用户最多的这个点确定固定码率，但是会立刻遇到问题，有一半的用户好像都有卡顿的风险，那怎么办？保守一点，把固定码率往低调一点，就长成现在这个样子，变成在平均值稍微低一点的地方切一刀。但是我们可以看到，这仍会使一些用户存在卡顿的风险，并且另外一部分用户的带宽也没有被充分地利用，其实它的码率是可以更高的。所以说固定码率不能够达到最优化用户体验的一个目的，码率自适应的算法是必要的。其实我们仔细看这张图，思考一下，会发现这张图将问题简化了许多。首先，用户的带宽分布并不容易得到，得到了也可能不是单峰的，也可能是多峰的，这就使固定码率的选择更加艰难。另一方面，用户的带宽会随时域变化，每年的不同时候：过节和不过节会不一样、很多Show上映的时候和没有Show上映的时候会不一样、每天的不同时段会不一样、白天的工作时间和晚上的Peak hour（高峰时间）肯定是不一样的。在每一个用户播放的同一个Session中时带宽也会变化，因为网络的情况是非常复杂的，可能不知道在什么地方就突然发生了一种竞争或者拥塞。所以说这样的一种时域上的抖动，更是固定码率的方法不能够很好地去解决的，也就说明了码率自适应算法的必要性。常见的码率自适应算法有基于带宽估计的方法，基于缓冲大小的方法和混合类的算法。
基于带宽估计的码率自适应算法
基于带宽估计的码率自适应算法比较直观，通过实时估计用户当前可用带宽大小，根据带宽选取一个比较合适的码率。如图，黑色实线是用户的带宽，我们假设固定带宽是1000kbps，在两个阴影的区域，用户就会遇到卡顿，因为它当时的带宽低于Streaming的码率。基于带宽估计的码率自适应调解算法会灵活的估计，估计当前的带宽的位置相应地进行选择。
如上图所示，它会从1000kbps切到500kbps切到1500kbps，通过这样一种灵活的切换，我们就能够使得一方面充分利用带宽。另一方面，减少可能出现的卡顿。基于带宽估计的码率自适应算法的优势是逻辑比较简单，带宽估计加上一个比较就可以实现，参数也比较少，可以轻松的调节算法激进或者保守一些。
基于带宽估计的码率自适应算法的主要挑战是带宽的准确实时估计实际上是有困难的，一方面由于客户端没有对网络全局的一种认识，它得到的只是一些片面，不太准确的数据。另一方面，在客户端进行选择时，资源和性能实际上是有些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提交演讲信息。了解大会更多详情，点击【阅读原文】访问LiveVideoStackCon 2018官网，报名即刻享受7折优惠。
