最近折腾intel media sdk，主要硬件平台是在HD4600的核显上进行测试，intel media sdk是intel提供的一种基于核显的硬件编解码的解决方案，之前已经有使用ffmpeg进行了测试，可以极大的降低CPU的使用情况。只与编解码出来的画质如何，并没有做多大的对比。从其官方文档来看，可以支持的近9路1080P（H264）的转码。但是对H265的支持，则需要专业版才行，通过so插件扩展的方式才能编解码成功。因此主要做的还是H264的编解码测试。
其提供的samples代码，是使用C++写的，功能很是完善，我这边是在centos7.1（使用ubuntu安装过，不过稳定性不敢恭维，不介意内核经常挂掉的，可以在ubuntu上测试），也就是官方文档中推荐的操作系统上做的一些测试。下面会简单说一下几个测试。
首先，解压了samples的代码后，在每个模块的源码中，都有几个readme-xxx.pdf的文档，也就是对应模块的readme说明文档。有详细说明了对应模块的参数，以及使用示例等，对后面做简单的测试，还是很有帮助的，下文只是对sample做一个简单的说明，并没有readme中的文档详细。
测试，主要有几个，一个是sample_decode，也就是解码的sample；一个是sample_encode，也就是编码的sample；一个是sample_vpp，是视频图像处理的sample；还一个是sample_multi_transcode，做的是编码转换的一个工作。配合intel_gou_top对gpu的使用情况进行关注。
| 1 | ./sample_decode h264 -i input.264 -vaapi |
带上-vaapi参数，则说明使用的是显存的数据，这里没有-o做输出，sample_decode的代码是可以不用输出参数的。解码会以最高的GPU使用率进行输出。如果是有输出文件，输出为yuv的文件，默认nv12格式的yuv数据。
| 1 | ./sample_encode h264 -i input.yuv -o out.264 -w 1920 -h 1080 -vaapi |
由于输入是yuv的数据文件，yuv是不包含分辨率信息的，因此必须-w 宽 -h 高，来告知编码器需要进行编码的分辨率大小是多少。
sample_vpp则是作为视频合成，视频缩放等视频处理的操作，输入为yuv的数据，输出为处理后的yuv的数据，可以通过配置文件的方式，对数据进行多路合成。目前合成一个1080P 2×2的视频图像。由于yuv文件相对较大，因此合成的时候，都使用同一个输入源。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | stream=1080p_nv12_t60.yuv width=1920 height=1080 cropx=0 cropy=0 cropw=1920 croph=1080 dstx=0 dsty=0 dstw=960 dsth=540 stream=1080p_nv12_t60.yuv width=1920 height=1080 cropx=0 cropy=0 cropw=1920 croph=1080 dstx=960 dsty=0 dstw=960 dsth=540 stream=1080p_nv12_t60.yuv width=1920 height=1080 cropx=0 cropy=0 cropw=1920 croph=1080 dstx=0 dsty=540 dstw=960 dsth=540 stream=1080p_nv12_t60.yuv width=1920 height=1080 cropx=0 cropy=0 cropw=1920 croph=1080 dstx=960 dsty=540 dstw=960 dsth=540 |
执行操作命令如下：
| 1 | ./sample_vpp -composite 1080p_2x2 -o out.yuv |
如果想要查看输入文件的合成情况，可以使用ffplay进行播放：
| 1 | ffplay -video_size 1920x1080 -pixel_format nv12 out.yuv |
而由于输入是yuv的数据，数据量比较大，而输出也是yuv的数据，其实vpp的操作，用显存进行操作，反倒效率会比较低，毕竟需要将内存的yuv数据拷贝到显存，然后合成后的显存数据再拷贝到内存。所以可以将-vaapi参数去掉。
sample_multi_transcode是可以执行多路的转码，可以将一个文件作为解码后的输入源，根据这个源再做其余的转码，有个join session的概念，据说join的操作，可以提高不少的效率，具体多少，这个还没研究太深。
| 1 2 3 | -i::h264 1080P_30fps.264 -o::sink -join -o::h264 output1.264 -i::source -join -w 640 -h 480 -o::mpeg2 output2.mpeg2 -async 2 -u 3 -i::source -join |
这边的配置，1080P_30fps.264解码后作为后面几个的输入源，-i::sink说明其作为输出源，而后面两个-i::source，则说明使用-o::sink作为输入源。
执行的话，只需要执行
| 1 | ./sample_multi_transcode -par parfile |
执行期间，都可以通过intel_gpu_top进行对gpu使用情况的查看。intel提供的sample代码已经将所有的API都有做了相关的演示，可以很方便的对API进行一个理解以及自己往上面添加log之类的操作，可以很好的调试一些信息。整体来说，实现了一个GPU该有的大部分功能。有初步做了一些测试，编解码/VPP操作一个分辨率的视频，GPU使用情况是编码>解码>VPP。
转载请注明： 转载自
本文链接地址: