作者| 阿里文娱高级技术专家 肖文良
本文为阿里文娱高级技术专家肖文良在【阿里文娱 2019 双 11 猫晚技术沙龙】中的演讲， 主要内容为如何通过优酷智能档，降低用户卡顿尤其是双 11 直播场景下，提升用户观看体验。 具体包括智能档的落地挑战、算法架构、技术策略。
一、优酷智能档的前世今生
优酷智能档技术，即自适应码率播放技术。一方面是一个比较新的探索尝试：因为优酷在 这方面的投入是国内比较前沿的，是大规模进行产品化落地的流媒体服务公司；另一方面这个 技术本身比较老了，大约从 2000 年就开始形成比较完整的理念和框架体系，并成为流媒体传输 领域的标准产品技术形态，在 Netflix、YouTube 已经大规模应用。自适应码率播放技术不仅是 国外的工业界应用很成熟，学术界研究也很成熟，有的同学本科生研究生阶段在流媒体领域也 很有可能做过相关的技术研究工作。
但这样一个成熟技术，优酷在整个大规模落地其实遇到了很多问题和挑战：
第一是国内用户不太理解这个功能到底是解决什么问题，觉得这个功能比较“傻”；
第二是用户体验自身比较主观，所以流畅和高清之间的体验平衡点比较难把握；
第三是公开算法框架的线上效果不是特别理想，主要是公开算法的特征纬度比较单薄，并且比较少考虑实际产品体 验中的细节问题。
二、智能档带来了哪些变化
优酷智能档大规模上线发布已有一段时间，整体线上效果是令人满意的。
第一是 VoD 点播的整体卡顿缓冲次数下降了 11.1%，直播猫晚这一块下降 27.8%；
第二是 对提升高清观看体验、保证服务稳定性等，从工程实现方面做了很多优化和考量。在 VoD 点播 上大概提升了 5.8%的高清播放时长占比，源自算法根据缓冲 buffer 时长以及视频码率的动态变化，通过为用户播放远超当前带宽水平码率的视频分片来实现的，即可以在一个平均只有 2Mbps 带宽的环境下，为用户提供平均需要 4Mbps 带宽的视频分片内容；
第三是随时间的推移，用户 越来越接受这个产品形态，它确实很省心，打开视频看就好了，客厅走到卧室，信号弱一下强 一下对整体体验的影响是非常低的。
三、优酷智能档的整体框架
整体的技术架构，主要是由转码生产中心、内容分发网络、客户端三部分构建。 在转码生产中心，我们把大的文件切成非常小的分片，大概是 5-10 秒的时长，文件尺寸上可能根据不同的清晰度大概从 500K 到 3-4M 这样的水平。之后这些小的文件分片被推送到 OSS 存储中心，通过骨干网再到我们边缘的混合云的缓存节点上去，这部分缓存节点包含了传统的 CDN，也包含一些合作共建的边缘计算节点，来提供相对比较廉价的内容分发服务。
从生产到分发链路，再到 PC、电视或者手机、平板等平台，本质上智能档的核心框架是一 个很直白的逻辑：根据观看视频过程中的客观情况，动态选择 1080P、720P、480P 等不同码率 的视频内容来播放。
整个智能档的产品化落地，涵盖了几个产品技术问题：第一就是业务角度看，新技术对用 户体验的价值如何衡量；其次是技术层面，我们沿用 HLS 这种 M3U8 + TS 的协议框架，算法上有 Rule-Based、Hybrid、DeepLearning 等不同模型的尝试；最后是通过工程化、数据化角度， 尝试量化主观用户体验，建立 QoE 的度量标准。
四、智能档算法框架
智能档最核心的架构设计，是一个重 C 端轻 S 端的这个架构。客户端基本上是播放器和智 能档决策模块的一个双向联动结构。所有的视频内容被切分成 10 秒钟左右的一个分片，因此每 一个分片在下载之前，播放器和决策模块有一个联动，来决策这个分片是下 480P 或者1080P。 播放器这个下载结束后，会通过下载器将非常多的信息回馈到决策模块，比如说 TCP 层面的信息，网速的信息、网络异常等。
同时我们还有一个实时的网络质量感知模块，会根据下载器的反馈、网络信号的变化等， 来时刻感知用户的这个客观的网络环境的变化趋势，来进一步回馈到决策系统以更好的决策。
同时每一次算法的决策输入和输出，会回被聚合处理后回传到优酷服务端，再结合对播放卡顿等体验数据，基本可以形成一个个标准的数据模型，进行离线的算法训练。同时，C 端和 S 端的实时数据链路也提供了一个比较强的实时的策略匹配、控制下发的能力，动态下发差异 化策略控制决策系统的行为，后面也会结合在双 11 猫晚在带宽控制层面的工作讲一下我们联动 的效果。
五、智能档算法摘要
这个策略表就是一个对智能档决策机制的直观抽象，算法对每一种可能的组合输入计算出 预期的 QoE 得分，然后选择最高的选项来执行。比如策略表里列了 5 种可选的清晰度，从 4K 到 360p，有效带宽经过估算大概是 30Mbps，然后 0.893 是对这个带宽以及当前网络质量的一个 评估置信度，再结合其它一些输入比如 buffer 大小、二次卡顿概率等，最后得出一个决策表， 选择一个 QoE 得分最高的就结束了一次决策流程。这个例子中 1080P 看上去清晰度比较容易接 受，卡顿的概率比较低，选择这个可能是一个比较好的策略。
整个决策链路有几个特点：首先这是一个动态决策的过程，在播放过程中持续的周期性进 行；其次强依赖你对带宽的判断和网络质量的评估。带宽判断方面，优酷做了非常多的工作， 包括拟合方法以及惩罚机制等，本质上起期望提升预测带宽与真实带宽的相似度，并且在发生 判断错误时降低后续二次出错的概率。
六、低延迟直播场景面临的典型挑战
点播和直播的逻辑和框架是一样的。但是直播的最大特点就是延迟低，所以播放能够预先 缓冲的数据会少很多。尤其像双 11 猫晚直播，它其实是一个互动属性比较强的，比如主持人在 台上讲到“大家打开手机要抢红包了”，如果这个直播延迟从主持人说出这句话，到你接收到这 个信息过了 30 秒，这个延迟基本上是不可忍受的。而 HLS 这种基于 HTTP 的直播协议，业界 的主流传输延迟都在 1-2 分钟，其实相对来说可以做的码率控制、决策机制等都要好很多。猫 晚直播，优酷做的延迟是多少呢？是 3 个 4 秒分片的延迟，也就是说 12 秒延迟。这所带来的技 术挑战是非常大的，因为在最理想的百兆光纤网络下，播放器最多也就 8 秒多的数据缓冲可用， 也就是一次决策出错导致的时间耗损对整体播放流畅度的影响是非常大的。
直播对网络质量的感知或者说对网络速度的判定就变成跟点播不太一样，点播场景下对网 络速度因子的影响权重是较低的，对 buffer 时长的权重加的比较高，在 buffer 充裕且网络质量 良好的情况下，我们有充裕时间给用户提供更好画质内容。
七、带宽及网络质量的评估
直播对带宽的处理有这样几个不同：第一是引入调和平均数，大幅度降低速度毛刺数据对 整体评估值的干扰。如果单纯使用算术平均，比如把过去的 2 分钟的下载器速度统计做一下平 均，偶发的抖动带来的影响是比较大的。从统计上说，这个调和平均数会让噪点数据对整体平均值拉大的幅度会极大的压缩它。
这是我做的一个数据统计分析模拟，大部分的速度是 3000 到 4000Kbps 的区间分布，如果我用数据平均数来算，它得出的速度远大于正常区间，用调和的话，会比较低，所以调和平均数再在配合加权的话，对直播场景下的带宽判定，会相对更保守一些，也相对跟健壮。
同时每一轮回馈完再结合一个惩罚机制，来比较快的将速度判定的误差收敛到合适的区间。 比如现在是第 N 个分片进行下载，用前面的积累的 N-1 个分片调和平均下来之后作为当前带宽 的一个预估。同时 N-1 分片的下载其实已经完成了，所以既有 Sn-1 的真实速度，也有调和预测 速度，这两个在一起会作为一个带宽预测的偏离惩罚因子，这个因子会作为这轮带宽预测的一个修正。
八、构建更健壮的弹性直播能力
在直播场景下智能档带来新技术能力，基于这种动态的码流切换的能力，再配合我们的实 时策略联动机制，智能档提供了一个非常完整强大的流量管理、调度框架，比如基于 Location、 ISP、设备、场景等，可以在整体带宽资源有限的情况下，进行更精细化的流量运营控制。比如 iPad Pro 的 2K 屏，应该推送 1080P 以上的清晰度，而在手机上进行半屏观看互动的用户，限制 清晰度在 720P 就足够清晰了。
以上是 2019 双 11 猫晚当天某个阶段开始带宽比较紧张的情况下，对一批符合流量调整条 件的用户进行的实时清晰度干预，基本上是 1 分钟左右，蓝色线瞬间掉下来，黄色线瞬间就上 去，非常快速地完成了一次流量的调配。同时通过对 HLS 协议的扩展，可以在端侧支持两个 GROUP 下的主备流的自适应切换，来支持故障容灾等场景的稳定性要求。
九、建立度量标准
在视频播放这个场景下，QoE 是一个避不开的大坑，基本上所有努力通过数据、公式量化 用户主管感受的尝试，结果上都不是特别理想。主要的困难在于 QoE 期望找到一个标准，来告 诉用户看 480P 从来不卡，和看 1080P 间隔几分钟卡一次，哪种体验更好。这个是很主观的一 个话题，和用户习惯、设备特点、内容特点都有很强的关联。比如说你看到非常精彩的画面的东西，不希望画面糊下来，像美食节目、自然风光； 但是如果看的一些访谈类的节目，新闻财经类的你画面糊一下可能伤害并不大，重要是要流畅。
所以对主观体验的客观量化衡量这条路基本上很难走好。这里是一个业界广泛应用的 QoE 评估的标准公式，主要是在高清观看时长得到的基础体验分上，通过对切换清晰度、卡顿等负 面体验的惩罚性扣分，来获得一个相对客观的 QoE 评估分数。整体看这个分数还是比较优雅的， 但是实际使用效果其实比较差。第一个是它这个线性加权因子的权重，其实需要你自己调，比如你非常不希望用户发生卡顿，那么可以通过加大卡顿惩罚的 θ 因子来比较粗暴的训练、调整你的算法。
再讲一个直观的例子，比如算法在 1080p 和 720p 连续切换 4 次，按照公式的定义，1080p 和 720p 切换的惩罚分相对是比较少的，连续切 4 次，基本上从和 108p 切换到 480p 切换 1 次的 分数大致相同。但这个差异在公式上是无法体现的，但实际用户会立刻感知到差异，而且很明 显高低码率的切换在视觉上会比较突兀，体验也不好。所以整体上，QoE 公式只能够具备一定的解释性，或者说逻辑上可行，但是实际应用起来，指导实践的意义相对要弱很多。
十、选择好的度量标准
在这个问题上，我们已经慢慢放弃用 QoE 来指导体验的优化方向了，也不奢求找到一个比 较简洁优雅的公式。针对体验问题，核心思路是定义清楚关键链路、环节、场景下的核心标准， 用这些子标准来定义好的体验应该是什么样。比如起播场景，出现的画面清晰度和延迟，要符 合绝大多数用户的心理预期，保证 80%的用户体验；再比如每一轮的清晰度决策，我们都很关 注决策执行后多久内发生了卡顿，如果刚把清晰度决策到 1080P 还没 30 秒又发生了卡顿，这个 也是比较难接受的。
十一、寻求技术突破
在智能档的产品化落地过程中，我们也在持续寻求一个问题的答案：这样一个无论是学术 研究还是工业化落地都比较成熟的技术，我们能寻求哪些技术上的突破和发展。现在这个答案 是相对乐观的。因为工业落地与学术研究比较大的差距就是问题的复杂度或者抽象性，自适应 码率算法的学术研究上进行了非常大的抽象和简化，输入数据纬度比较单薄。我们在落地过程 中很快就结合在流媒体播放领域的工程经验、业务理解等，丰富决策算法可参考的信息纬度， 带来显著效果就是决策的准确性、用户体验的突破和进步。比如我们会结合用户历史偏好、网 络延迟，丢包率，TCP/UDP 协议栈信息等来更好的评估带宽和网络质量的可信度，同时增加更 多主观体验上的约束条件。比如在乘坐地铁期间，打开优酷看电影，可能出现某段时间内手机 4G 信号完全不行。 传统算法，在速度降到很低或着将要卡顿时，立马就去切 360P，这个逻辑 上没问题，但是体验不友好。因为在这种情况下做清晰度降级其实没有意义，肯定还是会卡顿 的。为了保证更连贯的体验，可能我们在决策时就是什么都不做，等着网络信号变好，再提供 更合适的观看体验。
另一个技术创新突破点在于云端联动，即群体 QoE 优化。目前，所有端侧的自适应算法都 是围绕个体 QoE 的最大化来实现的。实际上每一个“自私”的设备个体，从一个群体的角度来 看，整体的体验可能不是最好的，主要是带宽资源太稀缺。比如大家都在同一个会议场使用同 一个 Wi-Fi 热点，通过云端联动来做群体 QoE 优化，一方面提升带宽的利用效率，同时又保证 每个个体都能够获得理想的清晰度体验。因此群体 QoE 优化也是我们的突破方向。
目前国内带宽占用水平是非常恐怖的，因为有游戏直播、主播直播，像抖音、快手这种短小视频，还有长视频的优酷等，基本上大家晚上都在看视频，区域性的 QoE 协同优化有助于帮 助我们在极度拥挤的场景下，让用户体验变得更好。
综合来看，我们的技术突破主要是突破 Adaptive Bitrate Streaming 这样一个相对纯工程化、 算法化的边界，往一个更贴心、更聪明的产品技术方向在走。
十二、一些算法工程化实践的经验分享
在将成熟的学术算法落地到工程业务场景的过程中的经验：
第一，要抓住算法框架的核心点，不要太在乎结构性的东西，要看算法解决的核心问题的切入点，和你要解决的是不是一个问题，是不是有借鉴参考意义；
第二，如果是和大数据有关的算法，一定要关注好数据集的质和量，要结合自身业务，积累非常高质量的大量数据，这个 底线是不能变的；
第三，算法效果的度量标准，一定要结合实际的业务场景来看，尤其是那些不是特别标准 化、不好量化的落地场景，避免生硬的套用已有标准，毕竟你才是对你要解决的问题最了解的人；
第四，像 AB 测试、大数据 Pipeline 等工程系统能力，确实对产品技术的迭代效率提升是非常大的。像我们在智能档研发过程中，曾经在线上一天跑十几组的策略，平均一组对照策略 跑 2-3 个小时就可以拿到比较好的线上效果数据，对算法迭代优化提效非常大。
