目前Intel I系列的很多CPU都是支持QuickSync Video硬件编解码技术的，可以有效的降低CPU软解的负荷。而如果要测试下性能上的提升，可以使用ffmpeg来测试，因为ffmpeg有提供对QuickSync的完整支持，此次简单测试主要是通过ffmpeg调用QuickSync的编码方式对比基于libx264的编码方式进行对比测试。

需要下载最新版本的ffmpeg二进制可执行文件，推荐在windows上测试，Ubuntu上会有些问题，相对麻烦，后面会说到。当然，如果你喜欢折腾，搞搞也无妨。

准备工作

ffmpeg windows的二进制下载地址：https://ffmpeg.zeranoe.com/builds/ 推荐下载静态链接的方式，省事一些。

ffmpeg linux的二进制下载地址：http://johnvansickle.com/ffmpeg/

源文件准备，主要需要准备以下几个片源文件，选取同一个源文件进行测试即可：

1. src.264，H264的裸数据，用来做编解码、解码测试。如果没有H264裸数据，那么可以直接用ffmpeg进行转换。片源不要选择太长了，因为后面使用原始YUV数据，如果时长过长，会非常的大！

   ffmpeg.exe -i src.mp4 src.264

2. src_1280_720.yuv，YUV420P的原始数据，目前我使用的是1280×720的分辨率，YUV原始数据最好是在名称上把分辨率给记住，不然下次忘记了，也是很麻烦的。一般用ffmpeg默认的YUV420P格式就好，不需要太麻烦。可以用ffmpeg将上面转换的src.264进行转换（一分钟之类的，也就够了，不然太大了）。yuv原始数据，用来做编码测试！

   ffmpeg.exe -i src.264 src_1280_720.yuv

编解码测试

由于libx264只能编码，因此测试libx264的时候，我们使用的是ffmpeg默认自带的解码功能。

编码测试的话，大体是这样的，使用QuickSync进行编解码，对比使用ffmpeg自带的解码+libx264编码。需要带上-re参数，这样根据源文件的时间走，然后对比CPU使用情况。

基于QuickSync的编解码测试

执行的命令如下：

ffmpeg.exe -re -c:v h264_qsv -i src.264 -c:v h264_qsv out_qsv.264

Stream mapping:
  Stream #0:0 -> #0:0 (h264 (h264_qsv) -> h264 (h264_qsv))

会看到stream mapping，是从h264_qsv->h264_qsv说明解码是使用h264_qsv编码也是使用h264_qsv的方式。具体CPU使用情况如下：

 

CPU使用率极低！基本可以忽略。内存在200M左右，也还是可以接受的。

基于ffmpeg自带解码+libx264编码

这个处理上，基本也就算是软解，软编码了。具体命令如下：

ffmpeg.exe -re -i src.264 out.264

Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))

CPU 20%+，内存使用率也高达300M+，可见对比QuickSync的硬件加速处理上，软解，软编码，还是相对比较吃力的！

编码测试

编码测试的话，是将原始的yuv文件编码成264文件，分别使用QuickSync的方式，以及使用libx264的方式进行编码。

基于QuickSync编码测试

命令如下：

ffmpeg.exe -re -s 1280x720 -i src_1280_720.yuv -c:v h264_qsv enc_qsv.264

Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (h264_qsv))

基于QuickSync的编码CPU使用率也是极低，内存也才160M+，完全可接受。

基于libx264的编码测试

命令如下：

ffmpeg.exe -re -s 1280x720 -i src_1280_720.yuv libx264_enc.264

Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))

CPU 20%+ 内存280M+，对比下，基于QuickSync的硬件编码优势不错。

解码测试

解码来说，就是将src.264通过ffmpeg自带的解码对比基于QuickSync的解码。

基于QuickSync的解码测试

命令如下：

ffmpeg.exe -re -c:v h264_qsv -i src.264 qsv_dec.yuv


Stream mapping:
  Stream #0:0 -> #0:0 (h264 (h264_qsv) -> rawvideo (native))

依旧是极低的CPU使用率，这次解码的话，内存使用率相对编码要低不少！

基于ffmpeg自带解码测试

命令如下：

ffmpeg.exe -re -i src.264 ff_dec.yuv

Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> rawvideo (native))

ffmpeg自带的软解压力并不是很大，不过内存也低不少，可见现在硬件对于软解264还是没什么大的压力的。

Ubuntu二进制可能出现的问题

如果出现以下的错误

[h264_qsv @ 0x38cbfc0] Error initializing an internal MFX session

一般情况下，也就是不可用了，毕竟预编译的并不能确定使用libmfx版本是多少，而且一般出现该情况是因为SDK没安装好。所以，需要去下SDK并安装，可以看我之前的文章：LINUX安装INTEL® MEDIA SERVER STUDIO 需要安装下对应的SDK，编译下内核，并且需要是在硬件支持列表范围内。安装好后，去ffmpeg官网下载最新版本的ffmpeg，并如下编译。

• 创建MFX开发链接

  cd /usr/local/include
  sudo ln -s /opt/intel/mediasdk/include mfx
  cd /usr/local/lib
  sudo ln -s /opt/intel/mediasdk/lib/lin_x64/libmfx.a

• 创建MFX pkg-config所需的pc文件/usr/local/lib/pkgconfig/libmfx.pc，内容如下：

  prefix=/opt/intel/mediasdk
  exec_prefix=${prefix}
  libdir=${prefix}/lib/lin_x64
  includedir=${prefix}/include
  Name: libmfx
  Description: Intel Media Server Studio SDK
  Version: 16.4.2
  Libs: -L${libdir} -lmfx -lva -lstdc++ -ldl -lva-drm -ldrm
  Cflags: -I${includedir} -I/usr/include/libdrm

• 编译ffmpeg

  tar -xf ffmpeg-3.0.1.tar.xz 
  cd ffmpeg-3.0.1
  ./configure --enable-libmfx --enable-nonfree --enable-static --enable-libx264 --enable-gpl
  make
  

  因为需要使用libx264进行对比测试，所以最好也把libx264给编译进去。如果没有安装libx264的开发头文件可能会出错。安装下即可。

  sudo apt-get install libx264-dev

然后再试试，是否可以正常执行。

简单总结

从上面的对比测试来看，目前的硬件对于软解h264都是没有多大的压力的。QuickSync虽然在解码上有提升，但是提升并不是很明显。但是在编码上，提升效率不是一点半点。当然，可能是因为我选择的片源是720P的缘故吧，如果是高码率1080P，甚至2K,4K之类的片源，软解可能就压力很大了。但是也不要忘记，硬解也有分辨率上限的，并非所有的分辨率都能硬解。而如果你有做编码的操作，基于QuickSync是个很不错的选择，可以降低不少CPU使用率以及内存的使用率。那么你就可以同时做更多的事情了！！