1. 软解和硬解

我们在电脑上点开一段视频文件，都是软解，对于一般的几百MB的电影，默认的软解就够了，不用操心去设置什么东西可是大到一二十G甚至更大的高清电影文件，配置不够高的玩家通过默认的软解一般会比较吃力，播放起这种大体积文件一般会出现影音不同步，卡顿，延迟甚至根本放不起的现象，通常都需要硬解。

  • 软解：
    • 用CPU解码，无需任何专门的播放器和额外的设置
    • 适应性强
    • 不用考虑硬件的解码情况
    • 增大CPU负担，影响性能
    • 耗电
    • 使用音视频解码库，比如FFmpeg
  • 硬解：
    • 用GPU解码，需要特定播放器，设置复杂
    • 并行运算能力远高于CPU
    • 减少CPU占用，提高手机流畅度
    • 省电
    • 用自带播放器播放，如android中的VideoView

Android视频播放软解与硬解的区别
软解和硬解的区别和两者的优点和缺点

2. 硬加加速(Chrome)

2.1 开启硬件加速

2.1.1 使用硬件加速

chrome://settings/system -> 使用硬件加速模式（如果可用）
image.png

2.1.2 激活硬件编解码

  1. chrome://flags/#disable-accelerated-video-decode -> Hardware-accelerated video decode -> Enabled
  2. chrome://flags/#disable-accelerated-video-decode -> Hardware-accelerated video encode -> Enabled

image.png

2.2 检查硬件加速是否启用

2.2.1 检查是否启用

在地址栏中输入 chrome://gpu/， 如果硬件加速已启用，您应该看到硬件加速：
image.png

2.2.2 欺骗性

chrome://gpu/具有欺骗性，它仅表明Chrome将尝试使用GPU解码，但这可能成功也可能不会成功。如果出错，它将悄悄地退回到软件解码。要查看发生了什么，请在播放视频的同时打开chrome://media-internals/，点击视频的 URL（为了展开它）， 往下滚动查看 Player Properties 的下面，你应该可以找到 video_decoder 属性。如果video_decoder 的值是 GpuVideoDecoder ，这说明当前在另一个标签页播放的 视频正在使用硬件加速的的视频解码。如果它显示的是 FFmpegVideoDecoder 或 VpxVideoDecoder ，说明正在使用软件解码，加速视频解码无效。此外，在页面的最底部，有时还会记录一些有关GPU视频解码的错误消息。image.png
image.png

可以用以下方法验证chrome在播放在线视频时是否打开GPU加速:

  1. 在Chrome菜单中选择More tools -> Developer tools
  2. 在Developer tools界面上部点击三个竖点，选择其中的More tools->Media
  3. 如下图所示，播放视频时可以看到其中的Video Decoder为 VDAVideoDecoder（decoder的名字可能不一样），hardware decoder为true，这表示成功启用了GPU加速

image.png

2.2.3 如何在Chrome中强制硬件加速

您可以尝试启用加速的最后一件事是覆盖众多系统标志之一：
a. 在地址栏中输入 chrome://flags
b. 在该页面上找到名为 Override software rendering list 的部分
c. 将 Disabled 选项更改为 Enabled
d. 启用硬件加速后，在Chrome底部显示蓝色 RELAUNCH NOW 按钮
e. 返回 chrome://gpu 页面并检查是否启用加速
image.png

Chrome 如何开启 GPU 硬件加速
如何在Chrome中打开和关闭硬件加速
确认在Chrome（Windows 7）中硬件加速正常工作吗？
如何在Ubuntu启用Chromium硬件加速的视频解码

3. WebAssembly

在HTML里写一个标签video 告诉它你的视频地址就能播放了～是不是很神奇？但是有一些限制：

  1. 不是所有的封装格式都支持。比如HLS FLV就不支持
  2. 不是所有的编码格式都支持。比如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解码电脑起飞特别正常。但是可以催促平台优化解码器的代码。因为解码器是平台写的。

由于浏览器自身会进行会硬件加速，且wasm的沙盒限制只能软解，所以将c写的解码库打包成wasm进行解码并不会提升解码性能，只能扩展解码器，支持更多的编码格式。

关于网页 硬解 软解 H264 HEVC 和你电脑起飞了那点事…

4. 编解码格式

4.1 H265测试

我们来测试一下H.265直播流解码播放。经测试，在 MacBook Pro 2.2GHz Intel Core i7 / 16G 内存笔记本上，使用 Chrome 浏览器长时间观看直播，内存使用量稳定在 270M ~ 320M 之间，CPU 占用率在 40% ~ 50% 之间。由于CPU占用过高，无法满足可以在同一客户机下面播放多路视频的效果。