2016年9月21日
By Amit Jain 雅虎视频平台团队高级首席架构师
专题文章

超越Flash: Yahoo HTML5 Video Player

Adobe Flash, 曾经是网络媒体播放的事实上的标准, 是否由于对安全性和性能的日益关注而失去了业界的青睐. 同时, 在浏览器中需要视频播放插件的做法也正在失去用户的青睐. 因此，整个行业正朝着HTML5视频播放的方向发展.

HTML5视频播放开发仍在进行中 nascent它最初以最简单的形式得到浏览器的支持. 直到最近才将支持扩展到包括自适应流的功能. 自适应流提供了两个关键优势:

自适应比特率(ABR) 一种检测用户带宽、CPU容量、播放器大小等的算法. 实时并相应地调整下载到流视频的比特.
可变缓冲区大小一种允许我们控制播放开始所需时间的功能.

没有ABR和可变缓冲区大小, 用户的观看体验很差, 因为视频播放不能适应用户设备上不断变化的条件.

这些新功能使视频流媒体行业从Flash转向HTML5和JavaScript.

At Yahoo，我们的视频播放器在所有现代浏览器上使用HTML5进行视频播放. 在这篇文章中，我们将描述我们如何使用HTML5提供业界领先的播放体验, 列出我们面临的一些挑战, 并讨论我们看到的未来机遇.

迈向HTML5的第一步

2015年10月，我们迈出了HTML5之旅的第一步全球直播了一场NFL常规赛第一次. For the event, we deployed a "pure" HTML5 player on Safari; this was based on the native HTML5 support in the browser for HTTP直播(HLS). 作为这一努力的一部分, 我们在视频播放器中构建了功能，允许基于客户端环境的不同视频渲染技术. 浏览器，Flash支持，设备配置，操作系统等.).

体系结构决策

为了在所有浏览器上广泛支持HTML5视频, 我们需要重新设计播放器播放视频的方式. 这就提出了许多选择, 所有这些都可能影响雅虎的业务和用户体验.

第一个可能也是最关键的是确定要支持的流协议. 在HLS和 DASH，两者都支持HTTP上的自适应流. However, 为了维护一个简单的服务栈，并迅速进入市场, 我们决定支持HLS. 为了支持iOS，我们需要支持HLS，随着标准的发展，媒体源扩展(MSE) 能与HLS合作吗. MSE是HTML5标准的最新进步，它允许动态生成媒体流，以便通过 .

我们的下一个决定是为HTML5播放器构建、购买或利用开源. 雅虎并不是唯一一家希望开发html5播放器的公司, 并且存在许多开源选项. 利用这些参与者中的一个将启动我们的工作. However, analysis, 包括对市场参与者的实地测试, 确认可用的球员不能提供质量, performance, 达到了我们对雅虎视频播放器的期望.

最后，我们现有的支持Flash的视频播放器已经成熟并经过了实战测试. 我们需要决定是否将设计和逻辑从Flash移植到JavaScript中, 或者重新设计我们的玩家. 我们选择了后者. In doing so, 我们能够解决几个新的设计目标, 包括使其可扩展以在后期支持DASH. 这个决定让我们避免了继承之前设计中flash特有的缺点.

正如您将在下面看到的，所有的设计决策都为我们提供了巨大的好处.

展望未来

决定已定, 我们开始编写一个播放器，以消除我们对Flash播放视频的依赖. 该项目代号为“Zoom”，以DC漫画超级英雄闪电侠的死敌命名.

玩家对传入的传输流(MPEG-TS)转换成音频和视频部分，然后打包成碎片 MP4 浏览器中的MSE层可以理解的格式.

我们在设计新的HTML5播放器时有几个目标. 内容如下:

Modular: 每个组件可以单独发展，可以独立测试.
Extensible: 新玩家将能够支持新功能.g.(DASH)，无需重新设计.
Stateless: 我们会在页面或应用中的多个播放器实例中使用组件(如ABR).

框架服务提供常见的功能，如HTTP Loader(用于加载视频百家乐软件), Web worker(用于多线程), 和带宽估计器.

Stream & Media Services 包括处理上面所示的媒体管道各个阶段的服务. 这包括加载传输流, 拆分并打包成MP4，可以使用MSE播放.

流控制器是管理视频内容流的组件吗. 它也是与ABR引擎协商以决定下载的正确比特率的组件.

播放控制器该组件是否使用各种模块来编排视频回放. 它维护播放可能处于的各种状态的状态机. 它还提供了播放、暂停、查找等api.

Challenges

First, 我们从单一框架(Adobe Flash)发展而来, 它提供了跨浏览器的一致环境, 到多框架(MSE), XHR, Web Workers, HTML5媒体元素)在不同的平台和浏览器(Chrome, Firefox, IE, Edge, Safari, etc.)，每一个都为系统添加了自己的怪癖.

第二个挑战涉及广告. 虽然内容视频播放已经转向HTML5，但大多数视频广告商仍然依赖Flash. As such, 我们必须找到一种无缝的方式在Flash上提供广告内容，同时利用HTML5进行内容播放. 我们构建的播放器使用不同的渲染器——组件使用给定的渲染技术(Flash), HTML5, etc.)进行视频播放，同时保持无缝体验. 这让我们能够在保护广告收益的同时为用户提供最佳体验.

第三个挑战是如何提高用户粘性, 视频消费成功的关键指标. 我们希望用户不需要任何动作就能持续地观看视频, 比如点击或额外的页面加载. 与此同时，我们也不想要这样的经历.g.在每个体验的基础上实现连续播放. Hence, 我们决定让“播放列表”成为视频播放器本身的一流API, 在哪里，我们可以编制一个精心策划的视频列表，这些视频是高度相关和个性化的.

Controller 该组件是否管理渲染器的切换并公开各种播放功能.

Ads Controller 是用来管理和播放视频广告的吗.

播放列表管理器管理视频播放列表的播放，并公开播放列表功能.

性能(即重新缓冲和启动时间)是用户粘性的关键驱动因素. 做出与性能相关的改变带来了许多障碍.

音频/视频解复用和MP4封装是cpu密集型操作. 如果这些操作是在浏览器的主UI线程中执行的, 它会影响页面和玩家的UI响应性. Fortunately, 浏览器提供Web Workers来促进多线程, 但是使用它们需要在线程之间传递消息.

我们的实验表明，在Firefox中使用一个worker来卸载和MP4打包的效率要高出20%. 不使用Web Worker). 另一方面, 我们发现，在IE和Edge中，线程间消息传递的开销很高, 导致更高的再缓冲比率. 为了克服这些挑战，我们添加了两个新的设计元素:

在工作线程内执行处理单元
最小化线程间消息

有效地使用Web Workers进行媒体转换，使Yahoo HTML5播放器在性能上比其他播放器更有优势. 这些增强使CPU性能提高了10% - 20%，重新缓冲比率提高了30%.

Opportunities

虽然我们面临着许多挑战, 在内部构建一个重新设计的播放器让我们有机会引入之前的播放器所不支持的功能.

因为我们建立了切换渲染器的能力，以支持使用Flash的广告和使用HTML5的内容, 我们能够建立预加载能力. 也就是说，我们可以在播放列表中的下一个项目之前预加载它. For example, 一旦广告被加载并开始播放, 我们可以在后台预加载内容, 从而在广告和内容之间实现类似电视的过渡.

我们还改进了我们的带宽估计算法. 以前，它纯粹是基于内容下载速率的计时. 我们用从百家乐软件计时api(如TTFB)获得的信息来增强它。.

我们还引入了一个功能，使我们能够在关键帧边界切换比特率. 这提高了我们对网络条件突然变化的反应能力.

Results

我们开始在Google Chrome上推出新的HTML5播放器，并随着时间的推移增加了对更多浏览器的支持. 我们现在拥有了能够在所有现代浏览器上运行的全新HTML5播放器. 我们现在使用基于html5的渲染处理大约70%的桌面流量. 随着我们在整个雅虎网络上完成播放器的推出，这个数字还会增加. 最突出的不支持MSE的平台是Windows 7上的IE, 哪些将继续通过Flash提供服务.

论再缓冲率这一重要质量指标, HTML5播放器的趋势与我们的Flash播放器相当，甚至更好.

在接收到用户输入的播放内容后，HTML5播放器在视频开始时间方面优于Flash播放器. 图6显示了基于Flash和HTML5播放器的用户点击和第一帧视频渲染之间的延迟(点击播放延迟).

HTML5播放器的优势，如更快的加载时间，更高的效率等. 这些结果是否得到了很好的反映.