音视频研发分享：关键帧截图+wasm快照--我又做了一件有益于社会的事情

简单的一个视频设备快照功能到底有多费事多费电？

以前，我做多路视频设备接入的时候，为了能更好地展示设备当前的画面状态，我们经常是每隔3分钟、5分钟去设备取一次视频流，不管是GB28181设备通过SIP调阅，还是RTSP设备通过拉流调阅，亦或是SDK设备取流的过程，都是先取流，然后呢，通过像播放视频一样的过程，调用ffmpeg、avfilter、avcodec，从视频流中截取一张jpg图，保存在视频服务的目录里面，然后再以接口的形式发布给客户端，例如：

这些图，都是平台费劲地从设备取过来的，然后就为了这么展示一下，废了多事？GB28181-》PS-》ES-》ffmpeg-》JPG，实际这些图片的展示率有多少？
可能一晚上机器都在不停的取流-》解码-》转码成图片，但是一晚上都没有一个人在看的，浪费了多少电？

新的方法

有什么方法可以解决这些浪费资源的事情呢？我们拆解了一下这个事情：

1. 取流过程大多数情况下需要设备协议支持，比如让设备推送一个快照过来、比如让GB28181设备发一个关键帧过来，但是这个不通用，所以，还是得走老路，直接通过各种协议把流取过来；
2. 数据流取过来之后，就是各种解封装，直到解成ES，这一步资源消耗很少，无所谓；
3. 耗费资源的来了，ES-》JPG这个过程涉及了一次解码和一次编码，整个过程可以说是仅次于GPU视频分析的资源消耗，我们能不能把这部分省去？

有方法！

我们可以这样，我整个快照过程ES取流就到此为止，我们只需要根据需求，取到ES的IDR帧数据，然后将整个"sps+pps+I"存储下来，当做一个raw的快照保存就可以了，raw帧数据放到前端Web Assembly去解码，有人看就解码，没人看就不解码，这样就能省去很多事情

省了多少电？

1. 服务器不用再无时无刻解码、转图片了；
2. 编码逻辑更简单了，关键帧就可以当图用，不要再费开发时间转图片；
3. 充分利用客户端前端资源，看的时候解码一下RAW数据，比如1000路设备接入，快照间隔是5分钟（300s），也就是常规情况下，机器每秒要快照3张图片，而且是没日没夜的运行，现在不需要了，周末没人看视频，就不会产生任何编解码消耗！
   
   如果大家都采用这种方式，我们每年会给整个社会省多少电费？所以，做程序开发也是一个可以为社会做贡献的事情！