| 前端视频帧提取 ffmpeg + Webassembly | 您所在的位置：网站首页 › webassembly开发app › 前端视频帧提取 ffmpeg + Webassembly |
前端视频帧提取 ffmpeg + Webassembly
|
基于 ffmpeg + Webassembly 实现前端视频帧提取 现有的前端视频帧提取主要是基于 canvas+ video标签的方式，在用户本地选取视频文件后，将本地文件转为 ObjectUrl后设置到 video标签的src属性中，再通过canvas的 drawImage接口提取出当前时刻的视频帧。 受限于浏览器支持的视频编码格式，即使是支持最全的的 Chrome 浏览器也只能解析 MP4/ WebM的视频文件和H.264/ VP8的视频编码。在遇到用户自己压制和封装的一些视频格式的时候，由于浏览器的限制，就无法截取到正常的视频帧了。如图1所示，一个mpeg4编码的视频，在QQ影音中可以正常播放，但是在浏览器中完全无法解析出画面。  通常遇到这种情况只能将视频上传后由后端解码后提取视频图片，而Webassembly的出现为前端完全实现视频帧截取提供了可能。于是我们的总体设计思路为：将ffmpeg编译为Webassembly库，然后通过js调用相关的接口截取视频帧，再将截取到的图像信息通过 canvas 绘制出来，如图2。  一、wasm 模块 1. ffmpeg 编译 首先在ubuntu系统中，按照 emscripten 官网 的文档安装 emsdk（其他类型的linux系统也可以安装，不过要复杂一些，还是推荐使用ubuntu系统进行安装）。安装过程中可能会需要访问 http://googlesource.com下载依赖，所以最好找一台能够直接访问外网的机器，否则需要手动下载镜像进行安装。安装完成后可以通过 emcc -v查看版本，本文基于** 1.39.18** 版本，如图3。  接着在 ffmpeg 官网 中下载ffmpeg源码 release包。在尝试了多个版本编译之后，发现基于 3.3.9版本编译时禁用掉swresample之类的库后能够成功编译，而一些较新的版本禁用之后依然会有编译内存不足的问题。所以本文基于ffmpeg 3.3.9版本进行开发。 下载完成后使用emcc进行编译得到编写解码器所需要的c依赖库和相关头文件，这里先初步禁用掉一些不需要用到的功能，后续对 wasm再进行编译优化是作详细配置和介绍 具体编译配置如下： emconfigure ./configure \ --prefix=/data/web-catch-picture/lib/ffmpeg-emcc \ --cc="emcc" \ --cxx="em++" \ --ar="emar" \ --enable-cross-compile \ --target-os=none \ --arch=x86_32 \ --cpu=generic \ --disable-ffplay \ --disable-ffprobe \ --disable-asm \ --disable-doc \ --disable-devices \ --disable-pthreads \ --disable-w32threads \ --disable-network \ --disable-hwaccels \ --disable-parsers \ --disable-bsfs \ --disable-debug \ --disable-protocols \ --disable-indevs \ --disable-outdevs \ --disable-swresample make make install 复制代码相关学习资料推荐，点击下方链接免费报名，先码住不迷路~】 音视频免费学习地址：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发 【免费分享】音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击788280672加群免费领取~   编译结果如图4  2. 基于 ffmpeg 的解码器编码 对视频进行解码和提取图像主要用到 ffmpeg 的解封装、解码和图像缩放转换相关的接口，主要依赖以下的库 libavcodec - 音视频编解码 libavformat - 音视频解封装 libavutil - 工具函数 libswscale - 图像缩放&色彩转换 复制代码在引入依赖库后调用相关接口对视频帧进行解码和提取，主要流程如图5  3. wasm 编译 在编写完相关解码器代码后，就需要通过emcc来将解码器和依赖的相关库编译为wasm供 js 进行调用。emcc的编译选项可以通过emcc --help来获取详细的说明，具体的编译配置如下： export TOTAL_MEMORY=33554432 export FFMPEG_PATH=/data/web-catch-picture/lib/ffmpeg-emcc emcc capture.c ${FFMPEG_PATH}/lib/libavformat.a ${FFMPEG_PATH}/lib/libavcodec.a ${FFMPEG_PATH}/lib/libswscale.a ${FFMPEG_PATH}/lib/libavutil.a \ -O3 \ -I "${FFMPEG_PATH}/include" \ -s WASM=1 \ -s TOTAL_MEMORY=${TOTAL_MEMORY} \ -s EXPORTED_FUNCTIONS='["_main", "_free", "_capture"]' \ -s ASSERTIONS=1 \ -s ALLOW_MEMORY_GROWTH=1 \ -o /capture.js主要通过-O3进行压缩，EXPORTED_FUNCTIONS导出供 js 调用的函数，并 ALLOW_MEMORY_GROWTH=1允许内存增长。 二、js 模块 1. wasm 内存传递 在提取到视频帧后，需要通过内存传递的方式将视频帧的RGB数据传递给js进行绘制图像。这里 wasm 要做的主要有以下操作 将原始视频帧的数据转换为 RGB 数据 将 RGB 数据保存为方便 js 调用的内存数据供 js 调用 原始的视频帧数据一般是以YUV格式保存的，在解码出指定时间的视频帧后需要转换为 RGB 格式才能在 canvas 上通过 js 来绘制。上文提到的ffmpeg的 libswscale就提供了这样的功能，通过sws将解码出的视频帧输出为 AV_PIX_FMT_RGB24格式（即 8 位 RGB 格式）的数据，具体代码如下 sws_ctx = sws_getContext(pCodecCtx->width, pCodecCtx->height, pCodecCtx->pix_fmt, pCodecCtx->width, pCodecCtx->height, AV_PIX_FMT_RGB24, SWS_BILINEAR, NULL, NULL, NULL);在解码并转换视频帧数据后，还要将 RGB 数据保存在内存中，并传递给 js 进行读取。这里定义一个结构体用来保存图像信息 typedef struct { uint32_t width; uint32_t height; uint8_t *data; } ImageData;结构体使用uint32_t来保存图像的宽、高信息，使用 uint8_t来保存图像数据信息。由于canvas上读取和绘制需要的数据均为Uint8ClampedArray即 8位无符号数组，在此结构体中也将图像数据使用uint8_t格式进行存储，方便后续 js 调用读取。 2. js 与 wasm 交互 js 与 wasm 交互主要是对wasm内存的写入和结果读取。在从input中拿到文件后，将文件读取并保存为Unit8Array并写入wasm内存供代码进行调用，需要先使用 Module._malloc申请内存，然后通过 Module.HEAP8.set写入内存，最后将内存指针和大小作为参数传入并调用导出的方法。具体代码如下 // 将 fileReader 保存为 Uint8Array let fileBuffer = new Uint8Array(fileReader.result); // 申请文件大小的内存空间 let fileBufferPtr = Module._malloc(fileBuffer.length); // 将文件内容写入 wasm 内存 Module.HEAP8.set(fileBuffer, fileBufferPtr); // 执行导出的 _capture 函数，分别传入内存指针，内存大小，时间点 let imgDataPtr = Module._capture(fileBufferPtr, fileBuffer.length, (timeInput.value) * 1000) 复制代码在得到提取到的图像数据后，同样需要对内存进行操作，来获取wasm传递过来的图像数据，也就是上文定义的ImageData结构体。 在ImageData结构体中，宽度和高度都是uint32_t类型，即可以很方便的得到返回内存的指针的前4个字节表示宽度，紧接着的4个字节表示高度，在后面则是uint8_t的图像 RGB 数据。 由于wasm返回的指针为一个字节一个单位，所以在 js 中读取 ImageData结构体只需要 imgDataPtr /4即可得到ImageData中的width地址，以此类推可以分别得到height和data，具体代码如下 // Module.HEAPU32 读取 width、height、data 的起始位置 let width = Module.HEAPU32[imgDataPtr / 4], height = Module.HEAPU32[imgDataPtr / 4 + 1], imageBufferPtr = Module.HEAPU32[imgDataPtr / 4 + 2]; // Module.HEAPU8 读取 uint8 类型的 data let imageBuffer = Module.HEAPU8.subarray(imageBufferPtr, imageBufferPtr + width * height * 3); 复制代码至此，我们分别获取到了图像的宽、高、RGB 数据 3. 图像数据绘制 获取了图像的宽、高和 RGB 数据以后，即可通过 canvas来绘制对应的图像。这里还需要注意的是，从wasm中拿到的数据只有 RGB 三个通道，绘制在 canvas前需要补上 A 通道，然后通过 canvas的ImageData类绘制在 canvas上，具体代码如下 function drawImage(width, height, imageBuffer) { let canvas = document.createElement('canvas'); let ctx = canvas.getContext('2d'); canvas.width = width; canvas.height = height; let imageData = ctx.createImageData(width, height); let j = 0; for (let i = 0; i < imageBuffer.length; i++) { if (i && i % 3 == 0) { imageData.data[j] = 255; j += 1; } imageData.data[j] = imageBuffer[i]; j += 1; } ctx.putImageData(imageData, 0, 0, 0, 0, width, height); }在加上Module._free来手动释放用过的内存空间，至此即可完成上面流程图所展示的全部流程。 三、wasm 优化 在实现了功能之后，需要关注整体的性能表现。包括体积、内存、CPU消耗等方面，首先看下初始的性能表现，由于CPU占用和耗时在不同的机型上有不同的表现，所以我们先主要关注体积和内存占用方面，如图6。 wasm 的原始文件大小为 11.6M ，gzip 后大小为 4M ，初始化内存为 220M ，在线上使用的话会需要加载很长的时间，并且占用不小的内存空间。  接下来我们着手对wasm进行优化。 对上文中wasm的编译命令进行分析可以看到，我们编译出来的 wasm文件主要由 capture.c与 ffmpeg的诸多库文件编译而成，所以我们的优化思路也就主要包括ffmpeg编译优化和 wasm构建优化。 1. ffmpeg 编译优化 上文的 ffmpeg编译配置只是进行了一些简单的配置，并对一些不常用到的功能进行了禁用处理。实际上在进行视频帧提取的过程中，我们只用到了libavcodec、 libavformat、 libavutil、libswscale这四个库的一部分功能，于是在 ffmpeg编译优化这里，可以再通过详细的编译配置进行优化，从而降低编译出的原始文件的大小。 运行./configure --help后可以看到ffmpeg的编译选项十分丰富，可以根据我们的业务场景，选择常见的编码和封装格式，并基于此做详细的编译优化配置,具体优化后的编译配置如下。 emconfigure ./configure \ --prefix=/data/web-catch-picture/lib/ffmpeg-emcc \ --cc="emcc" \ --cxx="em++" \ --ar="emar" \ --cpu=generic \ --target-os=none \ --arch=x86_32 \ --enable-gpl \ --enable-version3 \ --enable-cross-compile \ --disable-logging \ --disable-programs \ --disable-ffmpeg \ --disable-ffplay \ --disable-ffprobe \ --disable-ffserver \ --disable-doc \ --disable-swresample \ --disable-postproc \ --disable-avfilter \ --disable-pthreads \ --disable-w32threads \ --disable-os2threads \ --disable-network \ --disable-everything \ --enable-demuxer=mov \ --enable-decoder=h264 \ --enable-decoder=hevc \ --enable-decoder=mpeg4 \ --disable-asm \ --disable-debug \ make make install此做ffmpeg的编译优化之后，文件大小和内存占用如图7。 wasm 的原始文件大小为 2.8M ，gzip 后大小为 0.72M ，初始化内存为 112M ，大致相当于同环境下打开的QQ音乐首页占用内存的2倍， 相当于打开了2个QQ音乐首页 ，可以说优化后的 wasm文件已经比较符合线上使用的标准。  2. wasm 构建优化 ffmpeg编译优化之后，还可以对wasm的构建和加载进行进一步的优化。如图8所示，直接使用构建出的capture.js加载wasm文件时会出现重复请求两次wasm文件的情况，并在控制台中打印对应的告警信息  我们可以将 emcc构建命令中的压缩等级改为 O0 后，重新编译进行分析。 最终找到问题的原因在于，capture.js会默认先使用WebAssembly.instantiateStreaming的方式进行初始化，失败后再重新使用ArrayBuffer的方式进行初始化。而因为很多 CDN 或代理返回的响应头并不是WebAssembly.instantiateStreaming能够识别的application/wasm，而是将 wasm文件当做普通的二进制流进行处理，响应头的Content-Type大多为application/octet-stream，所以会重新用 ArrayBuffer的方式再初始化一次，如图9  再对源码进行分析后，可以找出解决此问题的办法，即通过Module.instantiateWasm方法来自定义wasm初始化函数，直接使用ArrayBuffer的方式进行初始化，具体代码如下。 Module = { instantiateWasm(info, receiveInstance) { fetch('/wasm/capture.wasm') .then(response => { return response.arrayBuffer() } ).then(bytes => { return WebAssembly.instantiate(bytes, info) }).then(result => { receiveInstance(result.instance); }) } } 复制代码通过这种方式，可以自定义 wasm 文件的加载和读取。而 Module 中还有很多可以调用和重写的接口，就有待后续研究了。 四、小结 Webassembly 极大的扩展了浏览器的应用场景，一些原本 js 无法实现或有性能问题的场景都可以考虑这一方案。而 ffmpeg 作为一个功能强大的音视频库，提取视频帧只是其功能的一小部分，后续还有更多 ffmpeg + Webassembly 的应用场景可以去探索。 五、结尾 如果你现在也想学习前端开发技术，在学习前端的过程当中有遇见任何关于学习方法，学习路线，学习效率等方面的问题，你都可以申请加入我的Q群:前114中6649后671可以免费获取你所需要的学习资料，只要我有，那么都是大家的。其中还有许多大厂的面试题，希望能够对你们有所帮助。 原文链接：https://blog.csdn.net/Arui_0/article/details/107730208 |
【本文地址】