关于我们

大播放内核V3.0(一)
2017-10-20

一、导读:

“大播放内核”是一个基于在线流媒体特性、爱奇艺CDN架构与云平台架构的底层播放组件,不以独立的产品形态存在,存在于爱奇艺各独立APP中,实现在线视频、本地视频的播放功能。下面将从项目背景、技术架构、研发方向等方面介绍爱奇艺大播放内核(以下简单“大播放”)。

二、播放器发展史

先说一下播放器发展的历史,1995年诞生第一款产品级播放器——RealPlay,至今已经22年历史。在时间维度上,可以将播放器发展分为三个阶段:

第一阶段,从1995年到2003年。这期间,以本地播放市场为主,播放的介质主要有CD、VCD,主要的软件产品有《金山影霸》、《豪杰超级解霸》、《东方影都》等。同时在线音乐播放的发展由RealPlay引领,但受限于网络带宽发展(典型的上网场景是通过调制解调器进行电话线的拨号上网,典型的传输速率为56kbps~128kbps),在线播放市场一直比较冷淡。

第二阶段,从2004年到2009年。本地播放的市场继续发展,但人们已经不再满足于VCD片源质量,开始追求更高质量的片源,介绍开始发展为DVD和网络共享(FTP站点),代表产品为《暴风影音》、《迅雷看看》、《RealPlay》等。得益于中国互联网基础设施的发展,以及视频压缩算法的改进(H263的普及和H264的推出),以Web2.0和P2P技术两类技术为代表,在线视频企业如雨后春笋,发展出一批至今都比较有影响力的企业。其中,Web2.0技术为代表的的视频企业有:Youku、Tudou、Ku6、56等,以P2P技术为代表的视频企业有PPS、PPTV、快播等。

第三阶段,从2009至今。以Windows为代表的PC平台用户人群开始下滑,本地播放的市场开始萎缩,此时的播放介质主要是P2P网络传输的本地视频。互联网基础设施进一步发展,家庭用户的网络带宽成本逐年下降,带宽质量进一步提高;H264解码算法得到各芯片厂商的支持,H265算法的推出并进一步普及,使得OTT设备具备了低功耗、高画质的播放能力。基于这些基础能力的提供,人们不再满足于本地非常有限的视频源,更加渴望随时随地的观看高品质视频。在上一个阶段中生存下来的视频公司,越来越无法满足用户需求。爱奇艺自诞生之日起,为用户提供了海量的正版、高清在线视频,在满足用户基本需求的同时,还提供了720p、1080p、4K、杜比音效、HDR等更高品质的视频,逐步成长为行业的引领者。除了爱奇艺外,同样也诞生出了腾讯视频、搜狐视频、A/B站等一批优秀的在线视频网站,但产生了爱奇艺、腾讯视频、优酷三家独大的局面。

上图为互联网视频流量在整个互联网流量占比情况,可以看出视频的迅猛发展和在整个互联网行业中的举足轻重的作用。

我们再回顾一下播放器的发展:第一个阶段为本地播放为主满足用户基本的播放需求,第二阶段为在线视频的群雄逐鹿的战国时期,第三阶段则是整个行业三国演义时期。后两个阶段为在线视频快速发展的阶段。整个视频行业,除了互联网视频,另一个不得不提的、熟悉而又陌生的领域就是安防监控,这个行业的视频编解码技术的应用应该是始终走在前列的,但这不是这里要说的重点。

三、大播放项目背景

从上面发展历史可以看出,虽然爱奇艺进入时期较晚,但“流畅、高清”的体验为用户带来全新视听盛宴,播放记录、视链等技术创新也是深入人心。Web2.0大潮中,2012年爱奇艺Flash播放率先使用硬件加速、率先成功解决分段播放卡顿、码流的平滑切换等业内难点问题,使得爱奇艺页面播放技术一度代表国内最先进技术水平。与此同时,我们也在思考,Web2.0的浪潮即将退去,我们将剩下什么?整个行业正处于PC平台向移动平台转移时期,而公司则处于与PPS合并的特殊时期。总体来讲,2013年之前,公司在播放技术方面,存在以下痛点:

(1)页面播放方面,Flash技术因性能、漏洞等问题被Apple和Google拒之门外,Adobe也表示放弃Flash在移动平台的更新;

(2)PC客户端(Windows平台和macOS平台)没有独立的播放内核形态;

(3)移动端迅速崛起,双品牌双平台共4个播放内核都不稳定,播放还是以系统播放器为主;

(4)技术实现不同,导致播放产品体验不统一,用户体验的一致性难以得到保障;

(5)播放内核开发团队不统一,重复投入严重且技术分化较为严重,产品功能对接效率低下;

(6)爱奇艺云平台优势得不到最大限度的发挥,流量浪费严重,P2P技术(Peer to Peer,一种端到端的传输技术)在各端中接入困难;

2013年5月,大播放内核项目组在爱奇艺PC客户端内部成立,开始孵化跨平台播放内核项目。该项目的使命就是解决当时的痛点问题,并保持技术的领先性。

四、大播放版本迭代

从2013年5月至今,大播放发展已经经历了4年多时间,整个团队也从单一的、传统的PC客户端开发转型为跨平台开发团队。大播放支持所有的播放类型可以分为四大类:在线点播、在线直播、VR播放、本地播放。大播放所支持的APP如下图所示。

图、大播放所支持的APP

图、大播放发展的历史

(一)封闭开发:大家应该都知道,Android是基于Linux,主要开发语言是Java;macOS和iOS是基于Unix,主要开发语言是Object C和Swift;Windows开发语言则比较多,主流则是基于Microsoft .NET Framework的托管代码编程模型和基于VC的非托管的传统编程方式。但无论哪个操作系统,都支持C/C++,大播放开发的语言自然选择了C/C++。在各种基础库选型中,选择了非常轻量级的XBMC里的baselib部分实现。经过接近一个月的讨论,确定了整体架构后,进入开发,开发小组经历5个月开发与调试,第一版内核诞生。

(二)V1.0:在PC Windows平台和macOS平台上线,由于整个团队之前都是从事PC客户端开发,在PC上线还算比较顺利。值得一提的是,由于解码需要直接跟硬件打交道,TV平台的很多不确定性,让我们遇到较多的坑。当时的TV平台已经是Android4.0系统,但TV平台厂商为了节省成本,采购小厂商芯片,早期的这些方案并未按Android标准执行,更谈不上通过Google CTS认证(Compatibility Test Suite,兼容性测试,防止厂商对Android的改动影响其兼容性,通过该测试以确保Android上开发的程序在系统上正常运行),基于OpenMAX(一种多媒体框架标准,一般用于移动设备中)在不同平台上的支持情况也是参差不齐,为此,我们甚至直接对接了底层芯片解码SDK。如果每款设备都逐个适配下去,会将整个团队拖进去,根本就没有精力进行产品级功能迭代。直到2014年7月1.0版本顺利在移动端Android平台成功上线,才让整个团队彻底舒了一口气。手机设备厂商通常采用高通或者MTK的解决方案,这两大厂商比较规范(至少通过Google CTS认证),同时也意识SDK在TV平台上的局限性。

(三)V2.0:播放过程中,会持有音频解码器、视频解码器、OpenGLES等资源,并持有大量的内存,对于播放视频时来电的资源管理、前后台切换过程、及推后台后的资源管理等移动特性缺乏足够深的理解,导致1.0在移动后期对接过程中,遇到很多困难,如果不进行一次彻底改进,将来的维护将欲加困难。于是,在1.0的上线后期,团队针对上述问题,对大播放进行2.0的重构工作,产品层面接入DRM(Digital Rights Management,数字版权保护,用于对内容加密达到对内容的保护作用),杜比播放等功能;技术上支持了 HCDN(iQiyi特有的CDN技术,融合了P2P网络与CDN网络),针对TV端增加了一种“兼容播放模式”,该模式就是使用厂商提供的系统播放器,搭配我们的数据加载模块,可以将大部分适配工作解放出来。该版本于2015年上半年完成所有APP产品上线。

(四)V3.0:相对来讲,V2.0已经是一个稳定、可靠的版本,但随着产品功能的迭代,发现了越来越多的不足之处,比如,VR功能的需求,不能针对一个球形画面进行整体渲染;技术上对于独立多音轨的支持占用资源过多,OTT兼容模式占用内存过多,线程数量过多;实时直播要求启播速度尽可能短等等问题。基于稳定性和扩展性、可维护性角度出发,发起了此次版本第三次重构。此次重构技术上重点在于优化线程数目(下降了40%)、优化内存占用(下降37%)、后台的播放流程优化(2s内启播用户达到80%)、实时直播优化(500ms启播)、支持广告SDK的独立、规范SDK API与文档;产品层面则支持VR播放(全景、3D单双屏播放)、多播放实例支持、秀场双人连麦、倍速播放、截视频/Gif、联通/电信/移动定向流量等需求。

(五)未来:下一代播放器版本将在2018年初推出,从目前技术调研的结果来看,相信将在Native播放器各方面技术指标做到遥遥领先。同时,也为将来“智能”播放打好一些坚实的基础。

五、总结

总的来讲,大播放前两个版本主要是在平台集成过程中的自我完善阶段,以完成基本播放需求为主,同时保证最基础的体验(降低卡顿和成本优化),也是整个团队最繁忙的时期。3.0则是侧重要于技术层面的优化迭代。SDK以一个月一个版本的节奏,每个主版本至少迭代15次以上。到目前为止,大播放SDK支持主流操作系统:Windows, iOS,Android,macOS,承载着所有的播放相关的功能。为了方便各端对接,减少团队对接的工作量,我们在SDK API层面做了全平台统一,也就是说,除了语言和数据结构的差异,调用方式完全一致。同时欢迎感兴趣的同学浏览我们SDK的内部文档。值得一提的是,考虑到本地播放对格式支持的复杂性和功能支持的独特性,在大播放2.0的时候,将本地播放SDK独立出来维护,对本地文件的播放成功率,我们做了大量的兼容性工作,在不考虑无效文件的情况下,从之前的92%提升至98.5%。

(待续……)

返回