文 / 沈悦时

整理 / LiveVideoStack

大家好，我是来自Twitch的沈悦时，接下来我将为大家介绍Twitch如何辨识用户社区中繁复多样网络状况，提高视频服务质量。实现理想的网络状况辨识我认为需要着重关注如何更好地描述用户播放行为，以及如何高效发挥码率自适应播放的全部威力。我们希望通过“魔镜”项目将用户观看直播的体验提升至新的高度。

1. Twitch是什么？

在正式分享开始之前，先为大家介绍一下Twitch——Twitch是中国市场以外最大的互动直播平台。

直播内容主要以游戏为主，当然也包括少量户外或室内直播。我们更侧重于互动性较强的直播场景，需要借助低延时的互动直播技术在主播与用户之间构建双向沟通交流的桥梁。在我看来，直播不仅仅用于观赏，更陪伴用户的生活，因此我们希望将Twitch打造成为一个供游戏爱好者联系彼此的社区。

2. 码率自适应播放的威力

言归正传，“魔镜”项目亟需解决的用户痛点是什么？在我看来，首先是提供一种更加全面的方法评估用户观看游戏直播的体验，其次是发掘码率自适应播放的威力，实现快速的迭代升级从而提高服务质量与用户渗透。

自适应码率检测与切换可以说是用户期待已久的功能。早在2015年诸如YouTube这样的视频网站就实现了码率自适应播放，具体原理为播放器根据后台自动检测获取到的带宽环境相关数据判断带宽质量好坏，并针对不同带宽质量的用户提供合适的视频码率与分辨率，如果网络环境良好带宽资源充足则为用户播放全高清画面，如果网络环境一般带宽资源紧张则会适当降低分辨率与码率，播放质量会随着网络环境动态变化。对一些处于弱网环境的用户来说这是一项可保证播放流畅体验的重要功能。

上图展示了Reddit上有用户对我们没有在播放端集成码率自适应播放功能提出意见，可以看到大部分特别是其网络带宽不好的用户他们非常期待此项功能。由于中美两国在网络资源定价上的差异，美国的直播多使用H264或DASH以控制成本。这样做的好处便是可同时实现ABR，通过将码率切分的方式，播放器可根据网络状况动态切换。需要强调的是，点播的内容早已在最终节点准备好，播放器可根据已知内容信息作出较为合理的动态码率控制决策；对于直播来说，由于其对低延迟的要求很高，尤其处于互动直播场景时，我们需要控制播放器缓存为一个较为合理的区间，如果缓存过大会对交互实时性产生不利影响。一般情况下点播需要的缓存为15～20秒，而对直播来说5秒就已经算是非常大的缓存。Twitch的缓存约为2.5秒，较小的缓存虽然能降低延迟但也会造成错误发生的频率提高，这对直播来说也是一项亟需攻坚的难题。

内容是视频生产环节最关键的元素，播放器需要侦测不断更新的直播内容与播放清单从而优化ABR过程。2015年时学术界基本没有将ABR技术用于直播场景的研究，因此从那时我便开始了对此领域的探索——如何将ABR技术应用于直播场景并实现良好效果？

2016年时我们做出了第一版Demo并进行了A/B测试，取得了令人满意的结果。上面两幅图，横坐标表示带宽，从左往右递增，纵坐标表示每一种码率的分布情况；左侧表示手动切换码率而未使用ABR的测试结果，右侧表示使用ABR自适应切换的测试结果。

从以上两幅图我们不难发现，不使用ABR的情况下用户选择码率相当盲目，即便在带宽资源充足时也会有相当一部分用户选择低清晰度的画面观看；码率并未随着带宽变化调整到最适合的位置以为用户呈现在此网络环境下体验最好的视频服务，直接带来的影响就是带宽充足时低码率造成画质劣化，带宽紧缺时高码率带来播放卡顿。

而如果是使用ABR，可以看到ABR根据带宽变化动态且精准地找到了每一项带宽指标所能实现的最佳码率，高带宽条件下可以看到码率也保持在一个较高水平，随着带宽的降低码率也相应降低，并且每一带宽都对应一个最佳码率。可以说ABR准确地检测用户的带宽并给用户一个最佳码率选择，同时也将我们平台的卡顿时间降低了7.4%，我们为了降低卡顿率需要斥巨资在全球部署数据中心，7.4%的卡顿降低可以说非常了不起。产品公测时，有49%的用户选择使用自适应码率播放功能，其中有超过60%为带宽低于1Mbps的用户。

我们的自适应码率功能于2017年3月在平台全面上线。也许有人会问，为什么花了这么久的时间才上线此项服务，这就不得不讲到我们对ABR产品漫长的调试与优化过程。

3. 产品上线的痛点

产品初期A/B测期间我们收到了大量用户反馈，这些反馈为我们调试优化整套系统提供了颇具价值的参考信息。其中较为典型的就是有用户反馈自适应码率功能造成码率与清晰度不断频繁切换，给正常的观看体验带来的严重影响。这也为我们带来了一定思考：这位用户的网络状况所触发的某种算法异常行为是小概率事件还是普遍现象？如何通过模拟这位用户的网络状况妥善解决这项问题？

需要强调的是，虽然Twitch非常看重数据的价值，但我们更将用户主观感受摆在首要位置。一味相信数据而不考虑用户主观感受便会带来像上面这样的反馈问题。我们需要首先清楚针对不同的网络环境，如何通过一套标准衡量体系对每位用户的主观感受做出准确判断，从而规避单纯的数据参考所带来的对用户体验的忽视？

除了上述问题，我们在仅需A/B Test时也遇到了另一项问题：上图表示平均带宽利用率，左侧黄线代表有ABR作用，绿色线代表无ABR作用。不难发现ABR算法仅可为网络带宽很高或很低的用户带来较为明显的优化效果，那么我们该如何进一步发挥ABR的价值？

4. 必须克服的“元无知”

为什么会出现上述这样无法明确找到原因的问题？主要是由于网络状况复杂多变，汇总的服务质量指标无法描述最终用户的观看体验；而在研究算法时单纯的实验室仿真远无法覆盖现实当中各种复杂的网络状况，这也为利用算法优化用户体验带来了更大挑战；最关键的原因在于可影响用户主观观看体验的因素太多，从网络接入类型到网络运营商，从用户所在位置到最终节点服务器甚至骨干网的容量与性能等等，都可影响到用户对于视频画面的主观感受，而这些感受背后的微量信息我们只能通过用户行为与主动反馈获知，更增加了优化的难度。

正因为上述这些亟待攻克的问题，导致我们A/B测试的部署周期十分冗长。虽然我们使用的测试策略就如上图展示的那样，属于业界通用的测试策略，却也用了很长一段时间才让测试反馈的数据能够指导我们进行更深次的优化工作。

此时摆在我开发团队面前一项重要的命题就是：有什么信息可以使我们加速整个流程？与以往从网络状况入手优化算法的思路不同，我们尝试通过研究用户行为来确定观众观看视频时各方因素对主观视觉体验的影响。

5. “魔镜”项目

这就是我们后来的工作重点——魔镜项目

5.1 项目概要

魔镜项目抛开了传统的将卡顿率等网络指标作为开发导向的思路，转而将用户播放行为作为指导开发与优化的关键。我们尝试构建一套类似于”词典“一般可检测用户行为并推测其背后体验感受的指标体系，基于对播放行为的研究，首先我们定义对用户而言最为理想的播放层架构；有了理想的播放器模型，我们还需针对每个国家与地区所拥有的不同网络状况等外部因素调整播放器模型，并将特定的用户播放行为映射至已构建好的用户典型播放行为“词典”，同时重点分析特殊或单一播放行为的网络状况等参数并进行单独优化。

5.2 构建“词典“

构建全网用户的典型行为“词典”，详细来说第一步是收集大量Session的时间序列，其中包括码率、卡顿等可反映网络传输状况的常规数据。当然这一步需要大量的人力物力用于数据收集、检索、清洗等，可以说是成本昂贵。

接下来我们对每个国家、地区的时间序列做分群处理，得到各个区域的典型播放行为。其中的时间序列分群处理主要是以时间为横坐标码率为纵坐标构建分群图像，并基于全网所有用户的播放行为与不同国家与地区用户行为的典型共有特征，将所有时间序列进行聚合分类处理。具体来说，首先定义两个采样点（时间序列）之间的距离为Dynamic Time Warping，随后对时间序列进行分类操作，从而规避对相似特征视频序列的繁琐分析。最终基于分组我们可以得到每一国家或地区的用户典型的播放行为画像，进一步把众多区域的典型播放行为再做一个分群处理，从而得到全网用户的典型播放行为“词典”。

5.3 实践中的发现

通过上述对用户行为的系统性分析，我们有了一些可为自适应编码的优化提供指导的发现。积极的发现是全网用户最典型的四种播放行为分别是：1080p60、720p60、720p30和480p30（或360p30）。码率稳定在以上几种参数之间的播放行为基本不会受到卡顿的困扰。这说明我们的大多数用户所体验到的播放体验是良好的，且ABR算法整体起到了至关重要的作用。

消极的发现便像上图展示的那样，个别用户观看的视频会在1080p 60fps、720p 60fps与720p 30fps之间或720p 60fps、720p 30fps与480p 30fps之间频繁切换。

极个别用户更是会面临最高码率与卡顿之间频繁切换的现象，可以想像此情形下用户体验一定非常糟糕。

以上是我们为全网用户构建的20种最典型的播放行为“词典”中的几项，接下来我们需要将每个国家的播放行为映射至辞典中。

为每个国家或地区构建特定的服务质量指标，例如在墨西哥有超过50%的用户观看1080P，其中有0.3%的用户遭受了从1080p60到卡顿的频繁切换现象，贡献了大于10%的卡顿时间；而由于网络质量较为出色，美国有超过83%的用户可流畅观看1080P60，中国*则次于美国而优于墨西哥。除了宏观分析，我们也针对特定群体重点分析其行为与卡顿之间的关系，例如墨西哥中那0.3%的用户究竟是具有什么特殊的播放行为，使其遭受了从1080p60到卡顿的频繁切换，同时破坏了整体质量指标的向好。

我们对这些用户进行重点分析，发现这些用户的带宽下载量非常高，甚至超过20Mbps，但其响应时间却很慢。具体来说就是当播放器向最终节点发送请求后需要很长时间才能收到第一个字节数据，但下载所占用的带宽却非常庞大。其原因可能是用户离最终节点距离很远或者虽然下载速度快但网络响应的时间很长，而ABR并未将响应时间作为一项指标考虑在内。给用户带来的直接影响便是如果用户下载一个两秒钟的影片却需要花费1.5秒钟等待第一个字节数据的到达，最后0.5秒的时间无法下载完成片段，而此时ABR默认网络状况与下载速度满足1080P的要求，此时就会出现频繁的卡顿。这给我们的启示是ABR算法需要针对一些特别的非常见网络状况作出优化，才能根据网络为用户提供精确而自然的自适应码率切换。

6. 总结与未来展望

Twitch作为一个布局全球，峰值在线观众高达近300万的国际性互动直播平台，所上线的ABR算法明显提高了服务质量与用户渗透。想要进一步优化最终用户的观看体验，冗长的A/B测试周期与不够细分的服务质量指标是两大亟需改进的瓶颈。这就是我们开发“魔镜”项目的原因，也就是试图通过大数据理解Twitch社区的典型播放行为从而寻找关键问题。未来我们希望进一步构建网络模型，从而在实验室重现播放行为；同时把后台的网络事件与前台的播放数据相关联，从而实现更加出色的互动直播使用体验。

————————————————

版权声明：本文为CSDN博主「LiveVideoStack_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/90252739

「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。