作者
阿里文娱高级无线开发工程师去疾
责编
屠敏
5G时代，从生产端到播放端，超高清音视频将成为主流，如何让播放更加“智能”，让用户随时随地都有流畅观看体验，既“高清”又“不卡”？
本文将详解优酷“智能档”的是什么、为什么以及落地效果，尤其是如何突破“传统自适应码率算法”的局限，解决视频观看体验中高清和流畅的矛盾，并以“热综热剧”等场景为蓝本，一睹“大项目”背后的视频播放实践。
本文主要分为四部分：
背景：智能档是什么、有什么？挑战：传统自适应码率理论与播放实践的碰撞实践：清晰度策略优化迭代过程——整体框架建设，从数据中分析和学习总结：优酷智能档的成果和新技术的应用
优酷“智能档”是什么、有什么？
为了大家能够对优酷智能档有一个比较直观的了解，我这里准备了一个带宽限速条件下播放的视频。视频1是传统P蓝光清晰度，视频2就是今天要提到的“智能“清晰度。我们看到视频1已经开始卡了，视频2还在继续播放，但清晰度角标已经变为超清了。
00:48视频1
01:03视频2
好，刚刚播放的是《长安十二时辰》张小敬追捕狼卫的一段视频，是在带宽限速的情况下播放的，大致是在1.5Mbps左右。在这样的条件下左侧使用P清晰度，当画面变化较大，对应的码率也波动较大的时候，发生了卡顿，而且提示是否要切换到智能播放。而右侧的“智能”清晰度则在这种情况下，发现了网络不足以支撑蓝光，降级变成了超清，避免了卡顿，然后在这段播过去之后又重新恢复到蓝光。
优酷“智能档”简介
看完这段视频，我们来明确一下，关于智能档的几个基本问题：
1）什么是智能档，这个大家刚刚也都看到了，智能档是一种新的清晰度选项。
2）为什么要有智能档？我们可以从两个角度回答：
让播放体验更加智能。例如，用户在一个不确定的网络环境下，不知道什么清晰度最合适，选择高清晰度，卡了；选择低清晰度，画质体验又不好。优酷智能档就是要解决这个选择问题，智能匹配最合适的清晰度，避免用户自己反复去尝试；避免播放卡顿。例如刚才的《长安十二时辰》视频，在网络限速或者更常见的4G下，网络波动大，智能档实时地调节清晰度，在保证用户观看更高清晰度的情况下，避免播放卡顿。3）是如何实现的呢？这就要提到自适应码率技术，根据网络环境和播放过程中的状态，去实时决策选择最合适的清晰度。
自适应码率技术
自适应码率这项技术，早在年前后就已经被人提出，大致在年开始在互联网领域得到应用，逐步走向成熟。关于自适应码率的技术方案，一般由两部分构成：
第一部分协议框架：支持多个不同码率的清晰度传输和播放，约定服务器端、客户端的；第二部分算法策略：更具体地确定什么状态下匹配哪种码率、哪种清晰度更好。在协议框架上，苹果较早提出了HLS的方案。后来MPEG专家组提出行业标准DASH；除此之外，微软、Adobe等公司也有技术方案，但设计上比较类似，大同小异。
在算法策略上，是百花齐放。过去几年，学术界涌现出不少相关论文，比如右侧列表中所示，归纳起来分为4类：
第一类，基于网速预测，根据网速带宽和码率的大小进行选择；
第二类，基于播放器的buffer来判断决策；
第三类，引用一句话网络名言“小孩子才做选择，我全都要”，即融合前面两种因素；
第四类，更高级和领先的，将近几年的人工智能领域的技术引进来，根据机器学习、神经网络模型来选择清晰度。
自适应码率技术的工作流程
自适应码率技术在从生产到播放的整个链路，分成5步：
第一步，原始的视频资源文件，它可能只有一个比较高的清晰度；
第二步，生产端对视频进行转码和切片，根据播放需要，转码成不同清晰度的码流。一般清晰度越高，码率越高，文件越大。每个码流都切分成时间对齐的分片，一般是10s；
第三步，在转码和切片之后，经过CDN节点在网络上进行分发；
第四步，各自适应码率的算法按策略选择需要的清晰度；
第五步：客户端下载这个清晰度的分片文件，进行播放。
自适应码率算法：基于带宽速率
看完框架链路，我们再来看算法策略，先是最简单的基于带宽的策略。
这类算法的原理很简单，就是基于过去一段时间的网络下载速度，对网络情况做预测，如果比视频某一个清晰度的码率大，那么就可以选择这个码率，否则只能尝试更低清晰度。右上角图中列出了4种算法，都是基于速度进行判断的，清晰度和网速变化是正相关。
这个算法简单直接，缺点是如果过去网速高，对网络的预估又过于自信，网络波动落差大时，就无法下载完预期的清晰度内容，容易卡顿。
另外，清晰度受网络波动影响大，网络一波动，就会频繁的切换清晰度，这相当于忽略掉播放器中buffer的作用。
自适应码率算法：基于Buffer
基于buffer，就是播放器的缓冲区还能播多长时间来选择。这种方式直接放弃速度，只看buffer，没数据可播时才会卡。当buffer低时，选择最低清晰度，buffer随播放进度和下载进度一点点变化，清晰度不会有太大波动。
缺点是buffer的变化相对缓慢，会丧失对网络变化判断的灵敏性。比如用户网络换环境立刻变好了，但是buffer涨到最高清晰度的区间是需要一个过程的。
一个典型的案例就是BBA算法，我们可以右侧这张图，横轴是buffer，纵轴是清晰度码率，它们之间维持一个线性关系，buffer越高清晰度越高，直到达到最高的清晰度；同时为了保证不卡顿，最低清晰度也要攒够一定的buffer，才开始考虑换更高的清晰度。
自适应码率算法-MPC
这类算法有一个里程碑式的进步，给出一个QoE的公式化定义。QoE就是体验质量，包含清晰度、卡顿时间、清晰度切换3个因素。一旦确立好QoE的计算公式，在网络状况完全确定的情况下，我们就可以将自适应码率算法转化为一个求最大值的数学问题。
但是网络状况完全确定需要“上帝视角”。一般情况下，网络波动是可完全预测的，在一个较短时间内，我们认为网络波动会比较小，后面网络情况和前面已经统计到的速度存在一定关联性，所以上面的这种求全局最大值的就可以退化成为一种局部的计算，并尝试通过局部累加，达到近似全局最优解，这好比是从一个全局的动态规划变成一个局部的贪心思路。
所以它的具体决策过程是：
第一步，根据过去的情况，判断网络质量，预测速度；
第二步，生成未来N片，比如5片，将所有可能的清晰度组合做列表；
第三步，逐一尝试，找出所有可选项中QoE最大的组合；
第四步，将选择中下一片清晰度作为本次清晰度选项，每个分片选择时都依次类推。
自适应码率算法-基于机器学习
机器学习就是为计算机提供大量数据，让计算机基于这些数据进行计算，在特定领域做出判断，并针对判断给出评定标准，告知机器判断是否正确、准确，经过反复大量的学习过程，提高计算机判断能力的准确性。
强化学习是机器学习的一种，是针对一个过程该如何做决策的学习。
如下图，机器人学习养花，看见花要枯死了，选择用水浇花，获得一个正向的奖励；如果看到花快被淹死了，还去浇花，那么就只能得到惩罚，此外还可以根据情况考虑是否施肥、打药，训练机器人把花养好。
近年比较火的机器学习方式就是深度神经网络。我们可以将“养花过程中机器人的动作”理解为一个非常复杂的数学函数，输入是花的状态，输出是应该浇水还是施肥的决策选择，花是否养好作为不断调整函数内参数的依据，一旦参数调整好，这个函数就可以给出准确决策，神经网络就相当于这个复杂的函数，具体的一个模型实例就相当于这个函数里所需的所有系数。
我们做清晰度选择的例子和养花的过程很像，输入是过去的网速情况、buffer情况等，输出是清晰度的选择。
年开始有论文提出类似的方案，优点是用大量的数据去训练，训练好了就相当一个“经验丰富”的人，它看过很多历史网络变化的数据和选择结果、知道遇到特定的情况应该如何选择。弊端是太“高深莫测”，可解释性不强。
业界应用情况
国外的视频产品，Youtube和Netflix的手机客户端都有对自适应码率技术的应用。在国内，早在两年前，优酷就在做类似尝试，但最初的清晰度选项叫做“自动”，在起播时帮用户选择一个合适的清晰度，但是播放过程中如果网络有波动它不会变。随着优酷技术体系不断升级，现在优酷能够通过“智能”选项，随时随地的根据网络情况进行清晰度选择和必要的切换。
实际应用中的挑战
自适应码率技术的理论虽好，在大规模实践中，却屡屡碰壁，归纳起来有如下的挑战：
实际应用中的挑战：起播处理
起播的典型挑战是：
典型策略：环境未知，如何避免卡顿；网络环境良好的状态下，如何提升清晰度。按照学术界的算法论文，起播时为了避免卡顿，都是从最低清晰度开始，但实际尤其对于没有使用过同类产品的用户，10s的模糊不能被接收的；起播速度：如何快速播放。为了高清和起播后不卡顿，多加载一会儿，行不行？不行！快速起播是良好播放体验的开始。所以我们要遵循的原则是：
如果网络足够好，起播就提供高清晰度；为了避免卡顿和起播太慢，必须在网络差的情况，适当地选择低清晰度；不能为清晰度选择而给播放带来太大的额外开销。优酷是如何解决的？
首先，根据视频是否为首次播放进行分类。不是首次播放的，可参考前一次播放的清晰度；是首次播放的，参考播放服务的请求耗时。在连播情况下，既然可以用上一次播放的清晰度，也可以利用上一次的播放中的速度信息，更确切知道当时的网络情况；
其次，我们发现请求耗时的区分度并不大。播放器也在进行一个网络质量评估的项目，这样就引入了网络评分机制，作为清晰度的一项参考；
最后，秒播项目也全面铺开，在播放前下载一个分片。一方面下载过程提供了速度信息，另一方面我们也需要结合分片的清晰度进行选择，避免起播清晰度频繁波动。
实际应用中的挑战——网络情况预测
第二个挑战就是对网络情况的判断，即对带宽的预测；虽然不少论文都提到了根据历史下载速度求平均值，对当前或接下来速度做预测，但是关于细节基本都避而不谈。
网速非常重要，它是对当前网络判断最直接的数据来源，也是保证升降档快速灵活的一个关键因素。
速度预测的难点是网络情况是实时变化的，不同环境变化形式和方向都不同。例如，上图中就是截然不同的两种网络条件，第一个网速高且稳定，第二个网速在极速波动。所以预测速度的原则是尽量保守、尽量平缓，吸收掉波动情况，即对过去一段时间的速度取平均值。平均值的计算方式，可以结合上图的两种情况来看：
一是，传统算数平均数和调和平均数的方式；
二是，将对过去速度预测的误差考虑进去，也是robustmpc方案中提到的，更适合我们的需求。
那么，只有速度预估就够了吗？当然不是。由于网速是可随时波动的，实际网速也可能达不到预测速度，所以我们需要兜底方案。这里采用的是超时，即在预期的时间内，如果当前清晰度分片下载不完，将自动调整，避免buffer消耗后发生卡顿。
超时设置也需要精心考量，超时意味着当前分片如果下载不完就要丢弃，那么已下载完成的部分是不能用来播放的，否则就会出现同一视频内容用两种不同的清晰度重复播放。所以buffer较小时，不适合超时，否则容易增加卡顿。
什么情况设置超时呢？预期超时是用来解决问题的，首先是选择清晰度预期它能下载完，如果下载不完，我们可以用更低清晰度来替代。我们要保证现有的buffer足够这两个清晰度下载完成的时间，此外要尽量留足时间，让当前清晰度的下载能够在较小的波动下完成，避免频繁切带来的网络浪费和不好体验。
体验衡量
随着智能档的推广和应用，我们也需要考虑带宽成本，行业通用解决方案是使用PCDN，在播放允许的情况下，避免直接向成本较高的CDN服务器请求转而找到成本较低，但质量不太稳定的节点，这样就会引起速度的波动。
这个问题如何解决？首先，PCDN调度的原则，是将buffer趋于划分为三段：第一段是buffer较低的情况，为了避免卡顿保证服务质量，会直接走CDN；第二段是部分从CDN下载，部分使用质量较差的P2P节点；第三段是buffer较高的情况，卡顿风险低，直接断开CDN，只使用P2P。
简单来说，为了保证智能档用户有稳定体验，我们在节点切换的过程中，始终保持使用一个较高的速度，比如使用连接CDN时的速度，如果P2P的速度比CDN的速度高，我们可以使用这个更高的速度，当质量较差的节点满足不了当前速度时，buffer就会降低，迫使PCDN逐步切换回高质量的节点，这样就做到了和PCDN结合的自适应调整，做到了速度的相对稳定。
实际应用中的挑战——其它
在实践过程中面临的挑战，如何衡量智能档的体验，如何评价效果。
学术论文的衡量标准是看QoE，它包含了对清晰度质量、卡顿和清晰度波动的因素。但它是单一值，两次不同的播放，QoE一个高一个低，说明前一个体验更好，但是无法知道差的原因，是卡顿太多还是清晰度太低？所以单一值，不利于我们衡量真实效果，也不利于明确优化方向。
所以，我们最终通过和实际业务目标相结合，整体看全盘数据，同时将卡顿率、高清晰度的播放时长占比拆开来看。卡顿率高了，要想办法降卡顿，策略上要相对保守；如果高清晰度少了，就要适当调整策略，让用户更容易升到高清晰度。
此外，播放的体验好不好需要多维度考量，除以上两个关键指标外，我们也增加了其它维度数据，比如，使用智能档用户的播放量占比、一次播放的清晰度切换频次，高buffer降档的反常体验发生比率等。
实际上，我们在实践的过程中遇到的挑战还不止这些，比如倍速播放的情况，4G下考虑流量的问题等。受时间和篇幅的限制，就不一一展开了。
智能档的设计、实现与优化迭代
以上介绍了自适应码率技术的一般原理和挑战，接下来从整体分析，优酷智能档是如何设计的，又是如何优化。
优酷智能档的整体结构设计
智能档的整体框架分为上下两部分，下层是客户端，上层是服务器端。
第一，清晰度选择的控制器是在客户端，包含一个策略引擎，支持多种策略实现运行，为策略的运行提供了统一接口；控制器需要与播放器内核的数据源处理部分打交道，从播放器内核获取到视频的基本信息，比如支持几个清晰度、每个清晰度码率多少，有多少个分片、每个分片多大，同时也从播放器收集当前的播放状态，比如当前的buffer状态；此外，客户端还需要从下载器那里得到各分片的下载速度，从全局的网络监测模块感知当前的网络质量情况，最后执行策略，输出下一个清晰度，通过内核交由下载器去下载，进而播放；
第二，智能档的控制器每次播放后会收集整个决策过程中的输入/输出信息，并上报到服务器端，服务器端用这个数据做统计、分析、优化，然后进一步改进策略，形成一套完整的闭环的数据体系。
策略实现-多策略支持
结合前面算法论文中的理论，我们先后尝试过实现四种策略：
第一种：Pattaya是我们最早尝试的一种策略，将单独基于速度的一类策略，后来也引入了基于buffer策略，不断根据数据情况增加一些经验规则进去，也是早期进行链路调试的一个策略；
第二种：基于强化学习的策略；
第三种：实现和调试了基于MPC思路的策略；
第四种：根据经验创造出来的，基于下载尝试和超时的SBit策略。
我们以ABTest的形式分桶开启各个策略，观察效果逐步优化，最终形成一套统一策略，包含起播/Seek决策、播中决策、超时处理、卡顿处理等几个关键组成部分。
数据体系建设-信息的收集与解析
上面提到四类策略，在衡量效果时，我们提到了一些关键指标，相关的统计数据在上线之初就进行了支持。那么，这四类策略是不是上线就表现良好，表现不好的原因是什么，这就需要对每一次播放数据的输入和输出都有详细记录，如图中的数据结构。
第一步，早期我们考虑一次播放的决策数据量比较大，同时还不具备这种批量数据处理分析的能力，主要是以日志的方式打出来；
第二步，我们了解到阿里云的数据工场能够提供这样一种能力，通过自定义UDF解析结构复杂的编码数据，并且通过一般的编程语言以实现插件的形式，完成各式各样的分析，这样我们就将客户端上每次播放的所有相关的输入和输出，按照一定的格式组织起来，进行压缩、编码通过埋点渠道报上来，需要分析的时候在数据平台上解码分析。
上图，是一个经过编码的智能档播放信息，报到服务器端之后，我们通过数据平台对立面的信息进行解析。当然这张图立面只画出了其中一部分信息，包含原始的输入速度、预测的速度、播放器buffer的变化情况，这样整个智能档的决策过程就尽收眼底。
数据体系建设-优化应用
当完整数据体系建立之后，我们就可以进行优化。下面以卡顿优化为例，我们是这样操作的：
第一步，当版本发布后，观察整体的大盘数据，发现卡顿超出预期，我们会分析用户用例，对卡顿情况有初出认知。
第二步，基于已知信息做分类规则，比如，是起播就卡，还是播了很久之后才卡；是因为网络差，清晰度降底都还会卡，还是在策略上有优化的空间？
第三步，根据规则将所有发生过卡顿的播放数据做聚合分析，知道每种可能情况的占比，有针对性分优先级的去解决和处理问题；
不只卡顿，还是其它像高清晰度没有达到预期，都可以用这种方式进行分析。这些数据除了分析这些问题以外，还有利于我们对整个优酷用户播放过程有一个更全面的了解，比如说他们的网络情况分布等。
智能档的应用推广
在智能档完成设计、实现、优化，我们希望它能够在更多的场景上得到应用。智能档最初是在手机两端上率先完善和放量，其次是iPad端。在过去一年，我们也在iKuOTT等客户端场景下投入使用。
这里面需要强调是大型直播场景，比如双11猫晚、近期的义演直播《相信未来》，直播和点播场景有差异：
第一、直播要求低延迟，比如看球赛，不能隔壁进球了，这里还在射门。所以这个特点就决定了端上播放器不能有太多buffer，智能档的决策需要做适当的调整，更多的从网速上获取信息；
第二、直播是实时性的，生产端生产出视频流是实时进行的，而且通常的直播时长比一集电视剧时间还要长，所以存在技术风险，这时候智能档就有了用武之地。
和直播场景有关的第一个问题是流量控制，某一场直播开始前，会预估流量，但实际可能因为某个节目特别火爆，新用户源源不断地涌进来。在服务器流量压力大时，智能档可以通过实时下发配置适当的调整用户的清晰度，例如，必要情况下，降低一个清晰度，实时缓解服务器带宽和流量压力。这是传统清晰度所做不到的，传统清晰度可能从进入直播间到看完就固定在一个清晰度码率上。
另外一个常见问题是直播时，在生产端可能会出现某一路流转码失败，智能档发现问题后，可以直接标记这路流不可用，在后面的播放切到其它相近的清晰度时，保证整体直播效果不会受到太大的影响。
智能档的应用总结及未来
在过去一年，优酷智能档已经逐渐走向成熟：
优酷智能档在过去一年的建设过程中，覆盖了移动端约30%的播放量，甚至比播放某些传统的清晰度播放量都高；从智能档内的各个清晰度播放时长来看，能够让用户在90%以上的时间观看比较高的清晰度，同时保持着比一般清晰度更低的卡顿率，尤其在4G网络下，能够做到传统清晰度的一半；智能档为优酷整体的播放体验优化提供了工具，也在直播等场景成为了技术保障的必要手段；最重要的，经过过去一年的优化，获得了用户的认可。对于未来，主要有两点思考：
随着5G的发展，越来越多的用户将移动蜂窝网络下观看视频，智能档会得到更多应用。可能大家要问了，5G网速那么快，还需要智能档吗？这里我想到了一句话，WhatAndygivesBilltakesaway，“安迪比尔定律”，这里面Andy是Intel的CEO，Bill就是比尔盖茨了。意思是无论Intel的CPU造的多么先进，都会被新的Windows系统消耗掉。回到播放场景，网络技术是在发展，但人们对高清视频的需求也在不断提高，所以智能档是必要的；另外，一定会出现新的手段，让自适应码率技术的效果更好。比如今天提到的Pensieve，利用强化学习来进行清晰度选择。这个原作者在年又发表了一篇新论文，大致内容是他又改进了算法模型，开始在Facebook进行实验，这是个未来的方向，现在的可解释性等等问题应该都会逐步得到解决。参考文章
J.Jiang,V.Sekar,andH.Zhang..ImprovingFairness,Efficiency,andStabilityinHTTP-basedAdaptiveVideoStreamingwithFESTIVE.InCoNEXT.T.Y.Huangetal..ABuffer-basedApproachtoRateAdaptation:EvidencefromaLargeVideoStreamingService.InSIGCOMM.ACM.X.Yin,A.Jindal,V.Sekar,andB.Sinopoli..AControl-TheoreticApproachforDynamicAdaptiveVideoStreamingoverHTTP.InSIGCOMM.ACM.Mao,H.,Netravali,R.,andAlizadeh,M..Neuraladaptivevideostreamingwithpensieve.InProceedingsoftheACMSIGCOMMConference.ACM.L.DeCicco,V.Caldaralo,V.Palmisano,andS.Mascolo,“ELASTIC:aclient-sidecontrollerfordynamicadaptivestreamingoverHTTP(DASH),”inPacketVideoWorkshop(PV),.更多精彩推荐
苹果或在WWDC宣布放弃英特尔转向自研5nmARM芯片，这次时机成熟了？
国产数据库技术全面破冰，金融核心系统打破国外巨头垄断指日可待
Linux之父怒删工程师提交的补丁，称“太蠢了”网友：怼得好！
干货！3个重要因素，带你看透AI技术架构方案的可行性！
干货
大白话彻底搞懂HBaseRowKey详细设计
热评
警惕新基建热潮中的区块链项目烂尾