虽然我群里天天在炸这点事最近。我觉得你们也不是很急着我发这玩意。发了其实也没啥人看。呵呵…但还是说说吧。手机写的 尽量说清楚。
首先 先来介绍最原始的方式…Video标签。
就HTML里写一个标签video 告诉它你的视频地址就能播放了～是不是很神奇？但是有一些限制：
1.不是所有的封装格式都支持。比如HLS FLV就不支持
- 不是所有的编码格式都支持。比如HEVC就不支持。
视频的播放其实就 解封装 解码 然后就是一帧一帧的图像再按时间展现。就这么点事儿…其中解封装CPU占用率低 解码CPU/GPU占用率高。
这就产生了第二种方式：
JS解封装，重新封装成浏览器可识别的封装格。比如著名的HLS.js flv.js 或是之前在熊猫写的Mccree(当时因为要为直播做特殊的帧控 以及在裸H264流层搞了点事情。所以重写了）或者在头条写的xgplayer(也是为了搞事情）都属于这一类。但是这样一来 解码仍然是交给浏览器的。仍然面临第二个问题。
不是所有的编码格式都支持！
然后衍生出了第三种方案。第二种方式解出来的HEVC裸流不再进行重封装。也不给浏览器解吗了。C写的解码器库打包成webassambly 也就是wasm文件。解码，然后webgl 播放。至于这两层代码…xgplayer 和mccree都是开源的。找不着私我。
然后引入了新的问题。
1.wasm是沙盒环境 用不了显卡的解码器（别跟我说OpenGL。显卡图形和图像就不在一个模块，我说的是解码器）所以只能软解。
2.wasm和JS数据交互是打包时分配的固定内存。也就是一旦用了。内存占用，你设置的内存大小打底。打包时候设置大了内存占用怎么优化都别想下来。设置小了，一旦JS取数据不及时就崩盘。分辨率高的…你敢设置小么？
总结一下
这是个示意图 凑合看。
1 H264一般是浏览器解码。默认状态下硬解码（GPU运算）强行关闭硬解码会软解。
2 HEVC web端只能用wasm软解。没其他办法。
3 H264如果电脑起飞 可以考虑更新浏览器版本或换一个。实在不行换电脑。
4 HEVC解码电脑起飞特别正常。但是可以催促平台优化解码器的代码。因为解码器是平台写的。（向官方反馈，不负责传话）
from:https://www.bilibili.com/read/cv7312670