作者｜Gavin
作者介绍
Gavin，任职于爱奇艺技术产品中心云平台播放核心技术Leader兼架构师，2011年加入爱奇艺，先后负责Flash播放器开发、爱奇艺影音客户端开发等工作，目前负责公司所有产品线的播放内核开发工作，主要方向为播放技术优化、智能播放等。
请输入标题 abcdefg
导 读
“大播放内核”是一个基于在线流媒体特性、爱奇艺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%。
（待续）……
