Intel Quick Sync性能简单测试

目前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使用情况如下:

 

qsv_dec_enc_cpu

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

基于ffmpeg自带解码+libx264编码

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

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

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

ffmpeg+libx264_dec_enc_cpu

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))

qsv_enc_cpu

基于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))

libx264_enc_cpu

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))

qsv_dec_cpu

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

基于ffmpeg自带解码测试

命令如下:

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

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

ff_dec_cpu

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使用率以及内存的使用率。那么你就可以同时做更多的事情了!!

 

 

转载请注明: 转载自elkPi.com

本文链接地址: Intel Quick Sync性能简单测试

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

Scroll to top