简介:
如果你用优酷客户端追剧,会发现现在选择清晰度没那么麻烦了。以前在地铁上为了“不 卡”用低清晰度,在家里的 Wi-Fi
环境为了看得更舒服再手动换 1080P。现在清晰度选择那么 多,有的时候网络不好还得纠结下用哪个能够刚刚合适。优酷“智能档”,随时随地实时地提供
最合适的清晰度给你。
如果你用优酷客户端追剧,会发现现在选择清晰度没那么麻烦了。以前在地铁上为了“不 卡”用低清晰度,在家里的 Wi-Fi 环境为了看得更舒服再手动换 1080P。现在清晰度选择那么 多,有的时候网络不好还得纠结下用哪个能够刚刚合适。优酷“智能档”,随时随地实时地提供 最合适的清晰度给你。
“智能档”要解决的关键问题就是“高清、不卡”。这背后需要自适应码率技术的支持,按 一般流程,首先在视频生产端对同一视频源使用不同的配置编码成不同码率/清晰度的视频流, 按同样的播放时长(一般 10s 以内)对齐地切分成视频分片,并以 metadata 的形式组织起来(如 HLS 的 m3u8) ,然后结合视频播放的环境和状态,不断选择和切换最合适的清晰度。
但这样的技术在实际应用中面临着诸多挑战,国内其它主要的视频平台目前都还在探索阶 段,没有实际上线的同类产品功能。接下来就介绍下优酷智能档的技术实践。
智能档要解决的问题是播放体验问题,就一定是和播放器有关,为了支持丰富的业务场景, 优酷播放器有多层封装,最内层的部分使用自研的播放器内核(Ali Player)。
如上图所示,优酷的播放器内核支持多个播放实例,每个实例在播放链路上由三个主要部 分构成:
数据源处理模块(Source Module):负责理解播放服务传递下来的视频信息,都有哪些清晰度,多少个分片,去哪里下载;解复用(demuxing)拿到需要进一步处理的音频、视频数据包;
解码模块(Decoder Module):对音频、视频等流的数据包进行解码,得到一帧帧的图像数据 和声音数据;
消费者模块(Consumer Module):同步音频、视频流,通过对应设备渲染出来。
智能档和播放器内核最主要的交互就在数据源处理部分,因此也就有了下面这张图。
需要着重介绍的有这么几个点: 智能档控制器与数据源及其他模块的交互和控制:收集视频元数据和播放状态信息(比如缓冲区时长 buffer )、网络信息,分片级别的码率/清晰度选择,清晰度切换控制,还有其它数据源链路上的事件响应和超时控制等;
策略引擎框架:支持多种策略实现运行的一个接口/环境/容器,每种算法策略实现根据从播 放器内核和网络环境信息等输入,给定一个清晰度选择的输出;
数据链路闭环:客户端决策信息埋点上报,云端数据分析处理,优化后的配置更新或模型 下发;
其中,策略框架及各种清晰度选择算法策略实现是整个智能档的核心灵魂,策略框架提供
了一个平台,目前优酷的智能档使用 ABTest 的方式支持了从基于各项离散规则到基于强化学
习神经网络模型的多种算法策略的实现,这些算法可以根据配置或模型下发动态调整算法参数, 互相对比优化,互相补充。
说起算法策略,从 2002 年码率自适应这项技术被定义开始,学术界的相关论文就层出不穷。这些论文中主要讨论了几大类决策算法:
如上描述,每一类算法都有其优势和缺点,这些算法思想为我们提供了理论基础,使得我 们能够站在前人的肩膀。但与此同时更需要注意的是,这些学术性的理论很多是停留在实验室 阶段,在实际播放场景应用时会面临诸多挑战。
很多论文在说到播放体验的时候,都提到一个概念 QoE (Quality of Experience),然而不 同的算法里似乎计算方式都不完全相同。更重要的是,这是一个绝对值,在一个特定的网络环 境下我们其实更关心用户的相对体验,比方说用户明明在一个网络较差的环境下,他的 QoE 不 可能非常高,但有可能已经是最好的选择了,因而我们需要衡量的是一个海量用户下的总体统 计值。此外,QoE 的结果是一个冷冰冰的值,可解释性并不好。结合我们的业务指标情况,我们为了更直观说明体验好不好,使用了更为直接的卡顿率 & 清晰度时长占比 等数据,但光有 这些还不够。一次播放体验好还是不好,在很大程度上用户是有共同认知的,比如用户明明知 道家里网很差,对清晰度预期就不会太高,如果“智能档”在这种情况下还要勉强用高清晰度, 造成的卡顿都是可以预期的,这就是一种反认知的情况,因此我们也针对一些主观上反常的 bad case 进行定义和统计,多角度来评价体验情况。
按照学术界的理论,避免卡顿非常重要,在没有缓冲和没有分片下载速度的条件下,选择
最低的清晰度开始起播。然而,在实际应用中,这完全是不现实的,很多对播放体验要求比较高的用户,尤其在认为网络状况非常好的环境中,无法忍受第一个分片(一般长达
10s)的模 糊画面,会考虑直接放弃使用“智能档”。尤其作为国内视频播放场景下的一个新生产品,在绝
大多数用户从来没有使用过自动切换清晰度的情况下,不利于让这个体验得到认可。
因此,智能档在起播阶段就尽力收集影响数据下载和可能造成卡顿的所有因素,在起播第 一片就给用户最合适的清晰度、最优的播放体验。目前,作为起播参考的因素有网络信号强度、 连续播放场景下的上一次播放清晰度、到服务端的请求耗时等。一段简单的伪代码描述如下:
人们常说“天道无常”,其实网络也是如此。在网络条件比较差的情况下,通常下载速度波 动非常大,而且可以是毫无规律任意幅度的变化,这对清晰度决策带来了很大风险 , 除 了 Robust 方案(即考虑预测误差)之外,超时处理机制是非常重要的,而这一点却很少在学术 论文中提到。当预期时间内视频文件没有下载完成,则我们可以认为网络变化超出了预期,需 要紧急降级。这里需要注意的是,编码后视频帧的信息是以 GOP(Group of Pictures) 为单位 的形式存在,为了能够不间断不跳帧的连续播放,不能在一个 GOP 内部切换数据流。 超时机 制的引入带来的一个问题就是,为了能够超时中断,数据无法在部分完成下载的情况下提前传 递给播放链路,一定程度上提高了解码及后续渲染链路上数据断流导致的卡顿风险,因此超时 机制是需要精心设计调试的。智能档的做法是按需设定超时,像 buffer 本身已较小这类情况,直接放弃超时设置。 其实除了上述三点以外,出于实际问题考虑,优酷平台存在着一些其它的业务特点,也带来了一些新的挑战:学术界的论文中,涉及到的实验视频文件,一般是 4s 以内,而优酷的生产端从成本考虑出发,一般一个 GOP 持续 10s,一个分片一个 GOP,这无形中增加了下载失败 的风险,也拉长了每次统计速度的时间间隔;还有,为了视频压缩的足够小,同一清晰度的视 频文件的编码码率波动也非常大,而且正片流里也会从业务角度考虑中插一些码率不同的广告; 非 Wi-Fi 网络下,怎么协调播放体验和流量消耗等。这些都是在实际应用场景当中需要面对的问题,由于篇幅原因不在此一一详述。
除了上文提到的整体结构和算法策略方面的理论与实践之外,一些新的新技术和应用场景 也在智能档上得到了应用。
目前智能档内采用的是基于
A3C(Asynchronous Advantage Actor-critic) 的强化学习神经网 络模型,离线训练后,通过
MNN(Mobile Neural Network,阿里集团开源的移动端神经网络引擎)
在移动端上动态更新部署。随着整个“采集-分析-优化-更新”的数据链路不断完善,智能档历史
决策数据的收集积累,基于强化学习等策略的模型将进一步得到增强。
下面是客户端运行神经网络模型来进行决策的一个示意图。
在“天猫双 11 狂欢夜”晚会上,智能档也在直播中得到了应用。在直播场景下,除了上述 提到的播放体验优化外,智能档也可以做到分钟级的带宽和流量控制,同时在某一路流出现问 题时,能够灵活避开,为流控与降级等提供了重要保障手段。
优酷的智能档策略最初的雏形是根据一些已知理论和不同条件下的播放场景定制了一些离
散规则,随着策略框架的逐步迭代,逐渐衍生出了基于 MPC 思路和基于强化学习的多套算法
策略,并且在对比中不断互补和优化。经过这些优化,智能档的今天有了非常不错的播放体验, 成为优酷播放器默认的清晰度选择。
从统计数据上看,与传统的清晰度相比,在卡顿率(卡顿频次与播放次数的比值)稳定低于 720P 的前提下,720P 及以上的播放时长占比不低于 80%;在移动蜂窝网络条件下,智能档和传统清晰度相比,能够避免掉近 50% 的卡顿发生;
主观体验变化,随着半年来的迭代优化,从用户的反馈上来看,也从最初的不太认同,到逐步接受,甚至缺“智能档”不可;
最后,再以几个点对本文做一个小结。
优酷“智能档”最终展现给用户的是客户端上的一个功能点,但从技术角度上来说,这是贯穿了从视频生产到播放服务,整合了数据的收集、监控、分析,配置的实时下发和模型的动态更新的体系化工程,“智能档”需要这样的平台上,才能做到真正有效的快速试错和优化迭代;
在智能档码率选择的算法策略上,学术界已经有非常多的基础理论,但由于实际播放场景 的多方面体验要求、每个平台的自身的特点等原因,这些理论到直接应用还存在距离,需要通 过实践来填补和改进;
以上是对优酷智能档技术实践的介绍,目前智能档也在持续优化当中,相信随着场景的丰富、新技术的应用,将来会为用户带来更好的播放体验。
本文系作者在时代Java发表,未经许可,不得转载。
如有侵权,请联系nowjava@qq.com删除。