爱奇艺播放技术——300ms背后的故事

原创技术产品团队爱奇艺技术产品团队 2022年09月30日 04:00

爱奇艺大播放内核运行在 Android Mobile、Android TV、Apple TV、iPhone、iPad、GPad、MAC、Windows PC 等不同业务平台，支持以“直播、点播”为核心的广告、会员、VR、AR、交互视频等业务，经过9年4个大版本迭代，对于用户长视频播放“点击/播放”场景已经达到了相对稳定阶段，性能上基本能满足了所有的长视频播放场景。期间，在播放性能优化上，不同业务均围绕着大播放内核已有的性能展开，大播放内核也会为根据业务场景的不同进行一些迭代优化，犹如同一款发动机，总会针对不同综合工况做出不一样的调校，以便最大限度发挥其性能。

背景

01 问题

近两年，随着极速版业务、主 APP 短视频等“瀑布流”模式“滑动/播放”场景的需求增长，原有的开播性能已经无法适应业务场景。为了更好的应对业务需求，业务开发方面，需要创建 2~3 个播放器实例，以便在界面滑动时，采用“预加载+实例切换”的方案达到“零秒”开播的目标，即当前播放的时候，创建另一个或者几个播放器准备后续播放视频，切换的时候，画面可以直接展现出来。多实例的方案在开发上简单快捷，也带来内存使用量、线程数量的暴增，典型的“空间换时间”方式，对于高端设备来讲不会存在性能上的问题，但在中低端设备，则可能会对整个 APP 带来较为严重的卡顿问题。因此，该方案在使用场景上受到了一些限制。

02 调查

从平台角度来看，主要是交互相对较多的 Android 移动设备上问题比较集中。由于在早期版本中就已经支持了“预加载”功能，即播放当前影片时，加载接下来可能要播放的视频流，播放下一个视频是否命中缓存比较容易判断。通过测试数据发现，确实如预期一样，问题并不是出在网络层。相比 Apple 的设备的统一性，Android 设备市场价格从几百元到上万元，性能差异也悬殊。

对于视频行业来讲，一般会从视频播放的能力角度，按分辨率⽀持⾼低、码流⽀持⾼低、H.265/H.264 等 Codec ⽀持等维度划分，可以将 Android 设备按性能简单的分为“⾼、中、低”不同等级的设备，我们计划从这一方面入手调查。为了简化测试流程，进一步优化测试流程，从单机的本地视频播放的测试结果来看，播放业务流程耗时大约在 60ms 左右（即内部消息、数据路由及线程切换等，不同性能会略有差异），主要耗时产生在解码器创建及打开解码器阶段，且与设备性能呈现一定相关性：高端机耗时在 20ms 左右，中低端机平均在 350ms 左右，个别机型达 500ms 以上。

解决方案

从上面数据可以得知，达到“零秒”开播的目标，重点解决 Codec 耗时，并优化业务逻辑层面上的耗时。业务逻辑层面耗时，通过架构层面上的优化，相对比较容易解决，但对于硬件耦合极高的解码耗时耗时，似乎没有太好的方案，只能绕开它。经过内部讨论，我们得到以下几种方案，并对这些方案进行了初步分析：

采用多解码器方案

即内核内部创建多解码器，预解码并交替使用，相比 APP 层“多播放器”来讲，可以降低内存、线程数量，也能达到目标。通过前期我们之前的实验结果来看，该方案在中高端机表现还不错，但低端机仍然大概率会有问题，仍然存在明显的弊端。

软解方案

相对来讲软件解码器的创建时间开销基本在 20ms 以内，与高端机的硬件耗时差不多，但弊端也非常明显，由于所有的解码处理都是在 CPU 里进行，解码时需要消耗大量的计算资源，外在表现就是 CPU 占用过高，从而产生功耗过高的问题，特别是高码流视频的解码时尤其明显，对于用户来讲是不可接受的。

采用直播技术架构

即播放器在整个生命周期中，仅打开一次解码器，之后一直使用，节目切换时 Android 平台采用 Adaptive Playback 技术，好处是对于任何点播节目来讲，减少了解码器创建与打开的过程，但弊端也显而易见：所有的点播节目都必须单独维护时间轴，如果涉及到用户 Seek、码流切换、广告播放等等，情况将会异常复杂，且采用单一解码器长时间解码播放也存在稳定上的风险。

01 解决之道

很明显，每种方案都存在一定的优势，也有着不同的“硬伤”问题，这对于一个拥有上亿 DAU 的平台来讲，一点点的小问题都会被无限放大，会极大地伤害一部分用户的体验，更何况明显的“硬伤”问题，完全无法接受。

工程师与科学家的区别在于，科学家会通过现象研究背后的本质或者原理，工程师则利用这些本质创造出一项项提升人们效率的技术。例如科学家会研究“指南针”这项技术背后的磁场，及电磁感应定律，工程师则利用电磁感应定律，发明创造出电磁铁、电动机、发电机、电话、电磁炉等技术，并将这些技术应用到各行各业，造福人类社会。

爱奇艺拥有大量的优秀工程师，他们开发了领先的视频平台，保持了爱奇艺技术平台的先进性，并参与制定一些行业规范。我们团队核心骨干同学在音视频行业深耕达 10 年以上，整个团队具备比较资深的流媒体方面的知识及经验。“将技术玩到极致”这个道理也深深刻入我们团队每位同学的心中，挑战面前，大家显得更加振奋。

一台复杂精密的仪器总是由多种技术通过精湛的工艺组合而成，但在提升该设备性能时，往往不是某一项技术优势决定，需要从全局出发，找出看起来不是那么重要，但又会对整体产生重要影响的那么几项问题，犹如“木桶原理”。

从每期的测试结果来看，我们的长视频播放性能一直处于领先地位。综合测试数据来看，如果能规避硬件耗时，可以将中低端设备的平均时长由 350ms 压缩至 50ms 以内，高端机可以达到 20ms 以内。“硬件耗时”就是那根最短的木板！理论分析结果就是目标！从我们对调查结果的分析来看，之前提到的每种技术方案都能在某一定程度上解决问题，但也都存在一定的弊端。似乎也找不到其他更好的方案了。最终，决定将上述三种技术方案融合在一起，将三者的优势发挥出来，同时一定程度上避免相应的弊端。技术方案存在较高的复杂性，涉及到整个播放架构的调整，为此，我们演化出了下一代播放内核。

02 播放内核5.0

原有的点播模式的播放架构为相对简单的单一流式播放，播放器生命周期中可以播放一个节目或者连续播放多个节目，播放单元模型可以简化为下图，针对上面提到的“业务逻辑层面”耗时优化，主要在此模型中解决：

此版本最大的改进，在于播放架构的调整，为适应“零秒”启播的需求，在原有的架构上，增加了“预解码”处理单元，对接已有的“预加载”单元，与播放实例解耦合，这样就可以独立于播放实例，不影响现有 APP 层对播放内核的调用规则，最大程度降低对业务的影响，确保了 API 的向下兼容。“预解码”处理单元可以为多个播放实例提供“服务”，每个播放实例在开始播放当前节目的时候，会从“预解码”单元获取当前节目的数据，如果已经存在预解码数据，则直接渲染，这样就完全绕过最耗时的解码阶段。在整个内核周期中，独立的“预解码”单元只创建一次，并优先使用硬件解码器，在硬解码器失败后，采用“软解”兜底，在有机会的时候，仍然会重新创建硬件解码器，确保其可用性。使用该处理单元的目的是获取节目起始位置的一帧或多帧图片，不需要关注其 PTS，因此，该解码器可以使用直播模式，同时规避了维护时间戳的复杂度。简化后的播放模型如下图所示：

基于高通骁龙450芯片，测试数据对比如下（时间单位为ms）：

	总耗时	业务耗时	解码渲染耗时
4.0	395.85	72.30	323.55
5.0	35.14	24.21	10.93

最终的产品效果如下：

视频加载失败，请刷新页面再试

刷新

至此，300ms耗时优化基本已经达成，部分芯片上的效果超过预期。但我们前进的道路并未因此而结束，基于5.0版本，我们会继续创造出更多的惊喜。

也许你还想看

爱奇艺海外运营系统的设计和实践

适用于影视剧场景的智能配音算法实现

安卓TV插件化9.0内联崩溃原因及解决方案

关注我们，更多精彩内容陪伴你！

播放8

2022技术年货19

播放 · 目录

上一篇爱奇艺知识播放体验优化的探索和实践下一篇视频生产大镜像优化实践

继续滑动看下一个