123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596

## demo因为直播流时效性的缘故，发布了一个播放[H.265 mp4视频](https://gw.alicdn.com/bao/uploaded/LB1l2iXISzqK1RjSZFjXXblCFXa.mp4?file=LB1l2iXISzqK1RjSZFjXXblCFXa.mp4)（该视频地址直接在浏览器中播放只有声音而没有画面）的在线demo，读者可以有一个直观感受。地址：https://g.alicdn.com/videox/mp4-h265/1.0.2/index.html效果：![demo.gif](https://img.alicdn.com/tfs/TB1uRatJhYaK1RjSZFnXXa80pXa-600-341.gif)# 前期调研## 视音频基础因为前端领域对视频领域的涉及场景不多，一个```<video />```标签就可以满足大部分场景，但是经历了这几年直播和短视频的爆发，视频的需求和功能也变得越来越复杂，开发之前阅读了很多视音频领域相关的书籍和文章，在此先对视音频基础进行一个简单的介绍。视频中我们通常说的视频的格式，比如 .mp4, .mov, .wmv, .m3u8, .flv 等等被称为```container```。在一个视频文件中音频、视频数据是分开存储的，使用的压缩算法也不一样。其中container作为容器主要包含了video数据、audio数据、metadata（用于检索视音频payload格式等信息）。每个格式的封装格式不一样，比如FLV格式的基本单元是Tag，而MP4格式的基本单元是Box，辅助的meta信息用于检索找到对应的原始数据。而平时听到的H.264, H.265等视频编码标准被称为```codec``` (COmpress and DECompress )。一个视频格式比如mp4可以使用任何标准化的压缩算法，这些信息都会被包含在一个视频文件的meta信息中来告诉播放器该用什么编解码算法来播放。## 客户端播放器一个传统的客户端播放器播放一个视频流经过了如下各个环节：拉取数据 => 解封装 => 音视频解码 => 采样/像素数据发送到设备进行渲染。![client](https://img.alicdn.com/tfs/TB1VaB_JmzqK1RjSZFLXXcn2XXa-1024-768.png)对于流媒体，播放器客户端通过拉流以数据源（音视频流）为中心，进行管道式的传输。在此期间，对视频流的读取，转换，分类，复制等一系列操作处理，以封装的mp4流为例，需要对流进行解封装、解码、渲染等步骤：![stream](https://img.alicdn.com/tfs/TB1aridJkvoK1RjSZFDXXXY3pXa-1055-524.png)## 浏览器video标签在探究的过程中，为了了解主流浏览器不支持H.265视频播放的原因，以及浏览器端实现播放器原理的了解，通过对Chromium浏览器[官方文档](https://github.com/chromium/chromium/tree/master/media#playback)及video标签实现源码的阅读，整理了一个流程图。![chromium](https://img.alicdn.com/tfs/TB1UxCyJhjaK1RjSZKzXXXVwXXa-1502-1008.png)可以看到浏览器内部对视频流播放的实现，在经过了PipelineController等数据传输管道的处理后利用FFmpeg软解或者Gpu硬解之后交给视频设备及音频设备进行同步及渲染。其中H.265的视频因为硬解支持情况不完善，软解可能有性能风险，所以在chrome中被关闭了不支持，在chromium中可以通过参数打开。我们就依照这个思路，利用浏览器提供的接口来实现一个模拟的video标签。# 设计过程## 开发思路开发思路按照从简单到复杂的过程，对任务进行拆分，来完成H.265视频点播及直播等各个场景的覆盖，以mp4短视频出发完成播放流程，再覆盖直播场景，考虑如网络抖动、内存控制等复杂因素，再针对直播m3u8等回放文件进行播放并开发视频seek、倍速等功能。mp4播放=>flv播放=>hls播放=>加入seek、倍速等功能## 可行性分析* 思路：在最开始进行可行性分析时，参考结合了已有工具videoconverter.js和libde265.js对H.265视频ffmpeg的编译提取了hevc文件及mp3音频文件在浏览器端进行了播放。* demo地址：https://sparkmorry.github.io/mse-learning/h265/* 表现：将720P的mp4视频进行视频和音频的分离，通过 `<canvas />` 绘制图像，通过 `<audio />` 标签播放音频，画面在Macbook Pro上Chrome浏览器下在23fps左右。* 问题：	* **不能达到解码性能标准**: 720P的视频在Macbook Pro上仅在**23fps**左右，而原视频是**25fps**，不能达到解码性能标准，无法流畅播放。	* **无法做到音画同步**: 该方案因为直接提取了hevc裸流文件，无法获取视频和音频每帧的pts时间戳，无法做到严格的音画同步。* 解决方案：	* 性能：因为libde265.js是asm.js，通过对libde265.js开源库的改造，打包WebAssembly测试性能情况	* 音画同步：参考flv.js、hls.js等开源视频库的方案，根据曾经的实践经历，js在解封装方面的性能能够完成视频流文件解封装，获取每帧视频、音频播放的pts及原始数据交给解码器进行解码再渲染。* 方案调整：![1](https://img.alicdn.com/tfs/TB17KKAJiLaK1RjSZFxXXamPFXa-1024-768.jpg)## MP4点播流播放* 思路：根据上一过程调整的解决方案，通过js对mp4流进行解封装，因为音频解码的复杂度不高，也先用js进行解码，仅将视频解码模块用已有的三方模块libde265并替换为wasm解决性能问题，音视频解码模块都自身维护一段缓存区，负责存储解封装模块传过来的packet数据，解决音画同步的问题。* 表现：通过开源libde265实现的视频解码模块，针对于720p的视频流，平均解码时间是45ms，不能满足每一帧音频播放时间间隔（40ms）。* 问题：视频解码性能仍然不够。* 解决方案：	* **丢帧**：保证了音频同步，丢掉部分非参考帧，但损失了部分体验。所以提升解码性能和改善播放策略才能有可能满足当前方案的可行性。提升解码性能和改善播放策略。	* **提升解码性能**：用解码性能更好的ffmpeg替换掉libde265。	* **改善播放流程**：因为每个requestAnimationFrame循环任务都是同步的，边解码边播放。引入用WebWorker线程。通过改善视频解码模块，解码器内部开启循环解码，当外部的视频播放设备需要播放下一帧时，直接从解码器解码完的帧缓存中读取下一帧数据。实现了worker和主线程并行执行。* 方案调整：	* demo地址：https://static-assets.cyt-rain.cn/h265/index.html	* 设计流程![2](https://img.alicdn.com/tfs/TB1_emeJkvoK1RjSZFDXXXY3pXa-1024-768.jpg)## FLV直播流播放* 思路：mp4视频流畅播放，但在直播场景（如FLV视频流）中，客户端需要和服务端建立长链接，不断接收流消息，借用FFmpeg本身对流媒体的支持，对视频数据进行解封装及解码。* 表现：无法编译FFmpeg网络库，TCP无法建立连接。* 问题：无法编译FFmpeg网络库：TCP建立连接创建Socket时报错，Emscripten工具无法编译TCP连接相关配置codec不支持：FLV官方协议不支持H.265。* 解决方案：	* 无法编译FFmpeg网络库：主线程利用fetch方法进行拉流，放到FFmpeg自定义缓冲区进行解封装及解码。因为直播流长时间播放需要不停的开辟、释放内存空间，采用环形的数据缓冲区。	* FLV官方协议不支持H.265：对FFmpeg及编码端对H.265进行扩展，因为FFmpeg内部数据结构嵌套较深，替换js解封装函数直接用FFmpeg的解封装函数。* 方案调整：	* 设计流程![3](https://img.alicdn.com/tfs/TB1HgiaJb2pK1RjSZFsXXaNlXXa-1024-768.jpg)# 当前方案## 播放流程![current](https://img.alicdn.com/tfs/TB1zsS3JhnaK1RjSZFtXXbC2VXa-1024-768.png)1. 因为FFmpeg支持多种格式解封装，只需要在在主线程中通过浏览器API（通常是fetch方法）拉取原始流数据并放到缓存中，等初始缓存到一个阈值时开启Worker进行解封装及解码；2. 在子线程（Worker）中通过主线程fetch方法触发的数据回调接收数据存入环形缓冲区（内存环）中；3. 子线程将读取到的音频帧输送到主线程中，通过Web Audio API缓存音频数据，根据已解码的视频帧缓存队列循环解码保证缓存中一直缓存10帧rgba图像数据；4. 主线程中canvas根据音频播放回调的pts消费并渲染视频图像；5. 循环以上操作直到fetch接口返回流已结束。## 解码器编译通过Emscripten工具可以把C语言编写的FFmpeg库编译成wasm并在浏览器中应用到视音频解码中。我们的视频解码场景和通常的播放器一样，通过依赖FFmpeg的通用接口来实现解封装和解码的工作。先通过emscripten编译ffmpeg库，再通过静态库的方式依赖到解封装和解码入口程序中。![compile](https://img.alicdn.com/tfs/TB10qJ.JkvoK1RjSZPfXXXPKFXa-1024-768.png)# 测试表现## 性能测试### 测试视频因为flv直播视频受时效性影响较大，拿720P高清的H.265 mp4视频作为**稳定输入**测试* 地址：https://gw.alicdn.com/bao/uploaded/LB1l2iXISzqK1RjSZFjXXblCFXa.mp4?file=LB1l2iXISzqK1RjSZFjXXblCFXa.mp4* 视频参数：