基于 Pipeline 的播放器开放式架构设计与实践-阿里云开发者社区

开发者社区> 阿里文娱技术> 正文

基于 Pipeline 的播放器开放式架构设计与实践

简介: 作为优酷 APP 中用户使用频度最高、停留时间最长的窗口,播放器一直以来都承载着用户 最直接的内容消费体验、产品创新、业务突破能力。

作者| 阿里文娱无线开发专家 韦兴华

一、背景

作为优酷 APP 中用户使用频度最高、停留时间最长的窗口,播放器一直以来都承载着用户 最直接的内容消费体验、产品创新、业务突破能力。随着长时间的功能迭代和业务累加,播放 器架构在面对现有的体验优化和业务支撑上,越来越显得力不从心,亟需一次全面的架构升级。
经过多方权衡,最终确定基于 Pipeline 模式进行播放器的架构设计,达到易用、开放、可定制,同时具备清晰的结构、低功耗和良好稳定性的架构改造目标。

二、设计目标

结合问题的现状,改造的目标如下:
1)减少部分播放链条中的冗余逻辑,减少函数调用数,减少链路层次,提升起播速度;
2)统一内存、文件的多份存储,提升解码、渲染的复用度,可以降低播放器内存、线程等资源消耗,提升稳定性;
3)将播放源、数据下载、后处理等模块的实现开放化和可定制化,让业务可以根据需求自 行在播放链路中插入和实现功能逻辑,实现业务的定制化能力;
4)从整体播放中心的角度思考,优化架构,以便支撑可预见的多源、多流的业务需求,快 速扩展,及时响应业务;
5)实现下载器、解码器、渲染引擎、PCDN、Netcache、智能档等功能模块的原子化,降低模块间的耦合,方便对外输出,并逐步实现单测覆盖。

三、面临的问题

如下图,通过分析现有的结构,比较容易看出目前存在的问题:
1)层次过多,一些功能和状态代码散落在不同的层次中,导致可维护性不够。
2)核心播放逻辑和业务定制逻辑耦合较重,导致对外支撑和向二、三方开放时接口易用性 不够,可配置化能力不足。
3)开放性和扩展性不足,对于需要深度定制的接入方,没有快速的方式对下载、后处理等 流程进行干预,对于合流、切流、混帧等特异化处理也没有统一的开放能力透出。

image.png

四、方案设计

1.整体设计

通过梳理,一个播放流程可以抽象为“播放源请求”、“流数据下载”、“流解码”、“后处理和 渲染”几个主要的过程,以及“数据埋点中心”“配置中心”等配套设施。在整体架构上,将原来多 个层次的实现合并到一个统一的播放框架中,将播放能力和基础业务原子化插件化,由播放框 架统一管理并提供可配置化能力。
在开放和扩展性的支持上,将以上的几个主要流程抽象成“播放源管理器”、“数据下载器”、 “渲染器”并提供统一的定制化开发能力,并提供自适应的解码能力,以满足未来业务创新上对 合流、切流、混帧和后处理的特异化开发需求。

image.png

2.统一播放框架

播放框架层负责统一管理和串联各个模块,同时对外部提供统一的 API 接口。如图所示,
1)接口层提供基础的播放上下行消息、管线注册、模块配置等接口;
2)状态管理、上下文管 理、时间轴管理和多实例管理模块,可以支持多 Period 和多 Source 的播放序列,以方便业务方 能够快速实现可变格式播放源合并、切流等业务;
3)实例池模块可以结合设备和可用资源自适应的管理解码器实例,保证稳定性和体验的平衡;
4)管线管理模块负责管线注册和管线绑定逻辑;
5)插件管理模块支持一些定制能力的内部实现,内置一些优酷业务能力并支持可配置能力。

image.png

3.播放源管理

播放源管理模块抽象了一个 PlayList 结构,用于支持业务方能够方便的实现不同格式和编 码方式的播放源合并、播放序列管理、切流等业务。 主要结构如下图,其中 PlayList 是一个总 播放序列;其下的每个 Period 节点表示一个统一的时间轴播放序列,其下的所有 source 会合并 成一个时间轴,比如由 4 个 15 秒的视频合并成的一组 60s 贴片广告;每个 Period 下可以挂载多 个 source,这些 source 可以支持相同或者不同格式、不同编码参数的视频组合。在播放过程中, 允许动态的切换当前 Peroid,或者修改后续 Peroid 的顺序。

image.png

4.缓存管线

缓存处理采用多级管线的处理,业务方可以根据自己的场景通过缓存中间件和缓存过滤器 的定制实现,来满足针对性的数据下载优化。在优酷播放场景中,针对网络请求和本地存储实 现了 NetCache 和 PCDN 两个缓存过滤器,具体如下图所示:
1)将资源存储分为三级缓存管理,由缓存管线进行调度管理;
2)业务可以通过参数自定义选择使用混合层级的缓存;
3)缓存管线针对不同资源,读取或写入存储时分别通过访问 NetCache 或 PCDN 模块进 行处理;
4)未来本地磁盘存储除预览需求外,希望统一采用PCDN 存储方式存储,以提升 PCDN的分享率,有效的降低成本。

image.png

5.渲染管线

后处理和渲染同样采用多级管线的处理。渲染管线模块提供多个渲染 Context 支持,每个 Context 绑定一个解码器和一个渲染窗口,并自动对同一个渲染窗口的多个 Context 的渲染结果 进行合并和上屏。业务方可以通过实现渲染中间件和渲染过滤器来进行定制化的开发,以进行 诸如混流、混帧、视频特效等特异化开发来满足业务和创新需求。

image.png

五、思考和总结

播放器以及端侧播放链路是一个庞大而复杂、且综合性很强的系统,尤其在优酷这样的重 视频场景消费的产品中,播放器承载的业务会随着时间不断增长。如果没有一个相对合理稳定 的架构设计,在长时间迭代之后整个系统的复杂度是不可想象的。在本次架构改造中,我们首 先抽取播放的核心过程作为整个架构的基础,把播放中心已经积累的能力模块化原子化,通过 统一的播放框架组织起来,同时结合未来业务的创新和发展方向,对外开放了统一的定制化开 发能力,基本实现了预期的改造目标。
当然播放框架的改造并不是一蹴而就的,未来在核心框架稳定的前提下,还需要继续推进 诸如端侧数据中心、端侧 AI、全链路监控等配套基础设施的建设。同时随着 5G 技术的发展, 如何将端侧和边缘结点打通,如何在端、边、云上做到计算资源的最大化利用,也是播放框架 需要思考和尝试的方向。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

带你了解阿里文娱技术

官方博客
官网链接