360视频云Web前端HEVC播放器实践剖析

360视频云前端团队围绕HEVC前端播放及解密实现了一套基于WebAssembly、WebWorker的通用模块化Web播放器，在LiveVideoStackCon2019深圳的演讲中360奇舞团Web前端技术经理胡尊杰对其架构设计、核心原理，具体痛点问题的解决方式进行了详细剖析。 

文 / 胡尊杰

整理 / LiveVideoStack

奇舞团是360集团最大的大前端团队，同样也是TC39和W3C会员，拥有Web前端、服务端、Android、iOS、设计、产品、运营等岗位人员，旗下的开源框架和技术品牌有SpriteJS、ThinkJS、MeshJS、Chimee、QiShare、声享、即视、奇字库、众成翻译、奇舞学院、奇舞周刊、泛前端分享等。

 

奇舞团支持的业务基本上涵盖了360大部分业务线。我个人最开始的时候也曾带队负责360核心安全平台的Web前端支持，包括大家耳熟能详的安全卫士、杀毒软件等。随着公司的业务发展，后面也负责了IoT业务前端支持，最近两年主要配合360视频云的一些Web前端支持工作。基于HEVC的播放器，实际上就是来源于我们最近做的一个叫QHWWPlayer的播放器。HEVC并不是一个新鲜事物，但对于我们团队来说，Web前端的HEVC播放器一直是个亟待优化的领域。虽然移动终端或PC端HEVC播放器已经遍地开花，但在Web端仍旧有很多地方需要改进。包括现存一系列智能硬件产品，也在固件采集端已经应用了HEVC的编码，不过如果想让其在Web端呈现并达到用户需求仍需加倍的努力。本次分享将从以下几个维度展开，希望能给大家带来一定的参考价值。

 

1. 需求背景

1.1 浏览器端HEVC的支持情况

 

上图展示了HEVC在浏览器端的支持情况，其中红色代表不支持的浏览器对应版本，绿色代表对HEVC具有良好的支持，青色代表无法保证浏览器可以很好地支持HEVC。总体上来说HEVC在浏览器端并不是一个得到广泛支持的靠谱方案。

 

一般情况下，PC端浏览器都给我们提供了相应的API，如果我们的业务场景是支持HEVC的浏览器，可尝试有效利用浏览器的原生能力。

基于浏览器原生video，配置source时指定解码器，告知浏览器当前视频采取的是哪一种编码方案。如果浏览器自身有能力进行解码那么其自然会走入“支持HEVC”的逻辑分支当中。

也可以另外通过JS实现检测功能，JS也提供了相应API——canPlayType来判断当前浏览器环境是否支持HEVC解码。

 

但如果以上流程无法得到有效支持呢？这也是本次分享我们讨论的重点。

 

1.2 Web端解码方案

 

浏览器端视频解码总共有以上三种方案，首先就是前文我们提到的基于浏览器原生能力的播放，例如基于video标签拉流、解码以及渲染播放，整个过程完全由浏览器实现。第二种方案是首先通过JS来下载视频流、对视频流进行解封装与转封装处理，最后再通过浏览器提供的相关API，交由浏览器原生video进行解码与渲染播放。如开源社区当中的HLS.JS或FLV.JS等就是基于该思路。

 

但是HEVC不能仅靠解封装与转封装来实现，因为其本质上在解码层就不支持。因此第三种方案就是：JS下载的视频流首先经由解封装（解密）处理，并在接下来进行解码，解码完成后渲染播放。如果我们这里转成浏览器普遍支持的解码格式并让video标签进行播放，尽管理论上可行，但成本显然是非常高的，并且中间存在一个无端的浪费。因此这里通常直接采用浏览器端Canvas+WebAudio API实现视频与音频的渲染，而不再使用浏览器原生video能力。这里如果使用纯浏览器原生的JS，由于 JS天生单线程执行的弱势，会导致整个处理的效率比较差。

 

近期，万维网标准化委员会正式推出了WebAssembly规范。一方面我们可以借助WebAssembly高于JS的能力，实现更加出色的大规模数据处理与解码，另一方面基于WebAssembly，我们也能方便地将传统媒体处理中基于C或C++开发的一些媒体处理能力集成在浏览器端执行，并且可通过JS来调用API。对于熟悉传统Web前端开发的我们来说，这也是一个值得我们坚持探索与实践的全新领域。有了WebAssembly之后，我们就可以让部门内擅