作者简介： 百度 CyberPlayer、云端非线性编辑、音视频工程师 

h265web.js 作者  (https://github.com/numberwolf/h265web.js)

01 背景

随着视频内容的占比逐步扩大，直播、点播内容越来越多；在此基础上，视频传输的带宽成本也跟着上涨，降低成本为第一要务，首先要考虑的就是增加视频的压缩率。而目前网络上多为 H.264 的视频，若将网络上的视频压缩为 H.265，可以较 H.264 压缩率更高、节省更多成本。

浏览器对编码的支持

当前浏览器下我们常用的方式是 Video 标签和 MSE 的方式来进行视频播放，但是现阶段的浏览器基本都只支持 H.264 的解码和播放(浏览器内部完成了解码)。

对于原生对于 265 几乎无支持能力，仅仅只有 Apple 的 Safari 浏览器的部分版本支持 H.265 解码播放，但是根本无法满足生产环境下的需求。

图 1. 浏览器对于 H.265 播放的能力支持度

浏览器对于 MSE 的支持

下图，为浏览器对于 MSE 的支持程度，可见 MSE 支持也不是很普遍。

图 2. 浏览器对于 MSE 的能力支持度

02 网页 H265 播放架构

目前需要解决两个问题：

• 网页端的一个通用 H.265 视频播放问题。

• 网页端对于 MSE 不支持的问题解决方案。

一个播放器的组成部分

图 3. 播放器的组成部分

• 视频部分

对于 H.265 播放问题，我才用了 WebAssembly 的解决方案，通过 C/C++开发的解码和解封装模块打包为 wasm 文件。

如下图，大部分浏览器都已经支持了 wasm。

图 4. 浏览器对 wasm 的支持度

• 音频部分

音频部分，采用了 WebAudio 方式去进行音频解码和播放。

如下图，大部分浏览器都已经支持了 webaudio。

图 5. 浏览器对 Webaudio 的支持度

H265 播放详细设计

• 整体设计

图 6. H265 播放整体设计图

主要分为：

1. Js-Demuxer/Wasm-Demuxer

         解封装器，分为 JS 部分和 WASM(C/CPP)部分实现，应对不同的 BOX。

     2.  Wasm-Decoder

          解码器，主要针对 265 帧的解码。

     3. WebAudio-Player

         音频播放器，承担了 AAC 音频的播放，包括 Seek、Play、Pause 等行为。

• 具体流程

     * 根据视频流`URL 尾缀`和`协议`进行初始化 BOX 判断

     * Fetch 获取到视频流媒体开始下载

     * 下载 Chunk 输入`Demuxer`进行 Probe

     * 探测到具体的`Mediainfo`后，开始进行帧数据读取

     * 读取到音视频帧后喂给`Queue`* 视频帧喂给`wasm-decoder`进行解码，缓存一定的帧数据

     * 视频帧交给 OpenGL(WebGL)进行渲染

     * 音频帧获取 Body 数据，根据 samplerate 和 channel 等数据组合 ADTS 头。（如下图）

图 7. 音频帧获取 Body 数据

     * 音频组包，ADTS 头+Body 组音频包喂给 Webaudio 进行解码播放。

• 难点

     * WebAudio 不支持 push 队列播放的方式，我才用了交叉上下文的形式解决了此播放问题。

     * 视频下载过程中可能会阻塞浏览器其它行为，抢用资源，这部分需要才用 worker 异步下载的方式。

    * 视频 Seek 如何最快精准 Seek 操作，这部分我采用了类搜索引擎的方式，构建了多层帧索引进行检索后精准 Seek。

效果

• 整体播放 Demo

图 8. 播放器整体 Demo

• 性能

     * 目前保守测试可以并发两路 1m/s 的 720P HEVC 视频播放。

     * 支持 1 路 1080P 视频播放。

• 能力

    * 支持点播、直播

     * 支持安防、点播、直播场景

03 心路历程

起点

最初要写 web 265 播放器的念头始于去腾讯之前一段时间，之前也做过 Native 端的播放器；为了深耕音视频，当时回顾总结了一下自己的技术深度和广度，想从 Web 端 265 播放器入手把 web 上的音视频技术栈的广度和深度进行补充。

之前也只是写了一个 Demo 级别的挂在 Github，后来来了百度，才开始正式在个人业余时间开始维护起来，逐步引入生产环境，对外输出。

研发那些事

其实整个研发历程中，让我懂得了，无论做任何事情，要`勇于重构`（建立在你对整体技术架构非常自信能 hold 住才可以）.

没有一劳永逸，一成不变的产品设计和技术架构，你总要随着用户、时代的变化而变化；当然你也可以不去重构，而是堆砌，最终导致的结果就是：一个月不去维护的话，你可能"看着镜子里的自己都感觉陌生"。

• 困难

* 整体项目都是一个人维护与研发，你的出发点建立在技术实验上，但是后续用的人越来越多，开始考虑生产环境，你不得不重构，这注定是一个耗时且用户无感知的 痛苦过程。

* 越来越多的 Feature 需求，你要做非常多的取舍，因为`周末只有 2 天`，对于产品的设计、技术需求的取舍必须做精确的判断；对标竞品、确定你的用户群体是安防、短视频、长视频 或者是研发类用途，这部分的成本投入也占了不少的比例。

* 社区用户不看 README、喜欢私聊（不在群里提问）也会带来很多困扰，会花费非常打的成本投入去打磨用户。

* 做开源就要有做开源的觉悟，哪怕只有付出。

• 收获

其实搞得开源项目不止这一个，只不过今天的主体是 265 播放器。

    * 对于 Web 端 265 的播放器使用群体有了一个清晰的认知和划分，这部分对于日后的产品设计和迭代有非常大的帮助。

    * 对于我个人而言，对于播放的音视频技术场景和 Web 端的音视频技术栈有了从前到后的完整认知 和 技术储备（从 0-1 全部是我一个人完成的）。

    * 结识了许多业内大佬朋友、还有前辈，生活也更加充实了。

    * 这几年开源产品、技术架构做了非常多，产品设计、交互设计、产品运营思维也是不知不觉的就培养了起来。

04 结语

播放器并非一个一劳永逸的事情，随着时代的进步、场景的递增，播放器也需要紧跟步伐。

百度 Cyberplayer 正在支持 HDR10 的播放开发（欢迎使用）。

点击进入获得更多技术信息~~