全平台视频播放方案分享(视频软解码)
近期论坛里，又多了不少有关视频播放方案的讨论，一打听原来是最近爆火了一款《拼了个剧》，这款游戏与常规拼图最大的不同就是引入了ai漫剧的播放，这其中就便用到了视频播放技术。正好最近也做了款游戏，也是视频也是拼图，虽然题材不同，但是技术栈确实是撞了。于是为大家分享一下我的实现。
目前Cocos主流视频播放方案有以下几种
1.VideoPlayer，Cocos官方视频组件。然而，VideoPlayer并不兼容小游戏,同时也并不支持自由调整层级。
2.使用微信官方api(如:[媒体 / 视频解码器 / wx.createVideoDecoder](https://developers.weixin.qq.com/miniprogram/dev/api/media/video-decoder/wx.createVideoDecoder.html)）,然而目前该api在PC端并不兼容，并且在抖音平台又需要重新适配。更别说在快手等平台根本都没有视频解码这一api；在PC端无法兼容以及只有部分平台没有相应的api支持，这两大问题无疑也是相当致命的。
3.将视频转换为序列帧，这一方案无疑在实现上是最简单的，然而在对包体限制严格的小游戏平台，序列帧无疑会占用大量宝贵的包体，即使将资源放到远程服务器上，也会大大增加服务器的成本
这几种方案都各有缺点，无法真正落实项目，因此，本贴给出一种全新方案：【自己实现视频软解码，并将解码得到的图像逐帧渲染到Sprite上】
本方案基于FFmpeg 的 libav（H.264 解码），在剔除掉无关部分和部分加工后，再用Emscripten重新编成 libav_h264.wasm文件，约550KB。
部分人可能拿到的视频资源可能并非H.264编码,此时有两种方法：
1.使用格式工厂转格式
2.如果实在必须要用其他编码，那就只能自己重新实现一遍了。
借助libav_h264.wasm即可完成对视频的解码播放，然而，视频的实时软解码相当吃 CPU。若每帧都「解码 + 转色 + 上传纹理」，主线程压力很大（实测微信官方 VideoDecoder 在弱机上同样会抖）。因此需要进一步做优化。
| 方案 | 播放性能 | 内存友好 | 说明 |
|---|---|---|---|
| 实时解码 |  |
|
几乎不占帧缓存；但是每帧解码，最容易卡 |
| 环形缓冲 |
|
|
只缓存即将播放的 N 帧（如 8～30），边播边解；解码压力可错峰 |
| YUV 全缓存 |
|
|
体积约 RGBA 的 3/8； |
| RGB888 全缓存 |
|
|
无 Alpha，约为 RGBA 的 75%，可直接作为纹理上传到Sprite |
| RGBA 全缓存 |
|
|
带 Alpha；一般无透明需求 |
以上方案不分好坏，需要自行根据项目情况（视频大小、分辨率、播放方式）自行选择。
本项目中提供了几种基本方案，有别的思路也可自行添加。
例如：在本人游戏《会动的拼图》中，关卡素材为720*960，24fps，5s,需要循环播放的视频，此时便选择了FirstPassCacheRgb第一遍边解边播并落盘 RGB888，之后直接播缓存的方案。(占用内存约为237MB，完全可接受)
/**
* 软解播放策略（Inspector 可选）
* 1 实时解码 / 2 环形缓冲 / 3 首遍缓存 YUV / 4 首遍缓存 RGB888 / 5 预载 YUV / 6 预载 RGB888
*/
export enum SoftVideoStrategy {
/** 几乎不占帧缓存；按进度逐帧解码，最吃 CPU */
Realtime = 1,
/** 只缓存即将播放的 N 帧，边播边解 */
RingBuffer = 2,
/** 第一遍边解边播并落盘 YUV，之后从 YUV 转 RGB 循环 */
FirstPassCacheYuv = 3,
/** 第一遍边解边播并落盘 RGB888，之后直接播缓存 */
FirstPassCacheRgb = 4,
/** 开播前解完全部 YUV，再播（省内存、播放时转色），需要时间进行预加载 */
PreloadCacheYuv = 5,
/** 开播前解完全部 RGB888，再播（最流畅、最占内存），需要时间进行预加载*/
PreloadCacheRgb = 6,
}
特别感谢
本项目用的框架：XForge | 开源前端开发框架 - Creator 3.x - Cocos中文社区
项目链接
Gitee:VideoPlayer: Cocos全平台视频播放器
给我点个star吧！
欢迎各位英雄提pr、issue，目前未实现的：弱机降低分辨率或帧率等方案
最后，打个广告，请大家支持我的游戏
《会动的拼图》
《谐音小高手》
《心上拼图》