找回密码
 立即注册
LiveVideoStack 首页 资讯 查看内容
  • QQ空间
  • 回复
  • 收藏

FFmpeg 硬件加速方案概览(3)

2018-5-16 09:00

Nvidia: CUDA/CUVID/NVENC 


之前提及Nvidia的时候说过,Nvidia曾经一度提出VDPAU与Intel 提出的VA-API在Linux上竞争,但最近的趋势似乎是Nvidia走向了更为封闭的方式,最主要的倾向是,Nvidia似乎放缓了对VPDAU的支持,取而代之的是提供较为封闭的NVDEC与NVENC库。另外,在FFmpeg中集成NVENC 与NVDEC的方式与FFmpeg QSV集成Intel Media SDK方式一致,也是以集成第三方库的方式集成进FFmpeg的。这带来的弊端是,对NVENC/NVDEC的依赖较大,加上Nvidia并未开放NVENC/NVDEC的代码,因此如果想做二次开发或者功能增强以及性能调整的时候,基本都得依赖Nvidia自身去改动NVENC/NVDEC,这可能对部分开发者带来一些影响。


下面是NVECN/NVDEC说支持的CODEC的一个图示,基本上FFmpeg CUVID/NVECN/CUDA部分分别集成了硬件加速的解码,编码以及部分CUDA加速的诸如Scaling这样的Filter。另外,CUVID部分,为了和NVENC统一,Nvidia已经把它改称为NVENC,但FFmpeg并没有去做这个更新。



AMD: AMF


AMF SDK用于控制AMD媒体加速器,以进行视频编码和解码以及色彩空间转换,现在开源出来的版本(https://github.com/GPUOpen-LibrariesAndSDKs/AMF),并未支持Linux,只能在Windows上进行编码,支持的Codec有AVC/HEVC。需要指出的是AMF的全称是Advanced Media Framework,之前有时会被称之为VCE(Video Coding Engine)


另外,VCE实际上支持两种模式,一种模式是所谓的full fixed mode,这种模式之下,所有的编码相关执行使用的ASIC 方式,而另一种模式则是hybrid mode,主要是通过GPU中的3D引擎的计算单元执行编码相关动作,而对应的接口则是AMD's Accelerated Parallel Programming SDK 以及 OpenCL。



除了上述的一些方案以外,还有一些使用在嵌入式平台的一些方案,能够看到的有:


  • BRCM的MMAL

    http://www.jvcref.com/files/PI/documentation/html/

    https://github.com/techyian/MMALSharp/wiki/What-is-MMAL%3F

  • RockChip:MPP

    http://opensource.rock-chips.com/wiki_Mpp

    http://opensource.rock-chips.com/images/f/fa/MPP_Development_Reference.pdf

  • TI DSP方案:

    http://www.ti.com/processors/dsp/applications.html 


有兴趣者,可以通过这些资源自行去获取相关信息。


2.独立于平台与Chip厂商的优化方案


OpenCL与Vulkan: 


Khronos在OpenGL的年代一战成名,最近这些年,围绕着高性能图形图像API提出了大量的标准,其中有两个较新的标准值得注意,一个是OpenCL,最初是Apple提出,现在则是异构高性能并行计算的标准,其出发点基本是以Nvidia的CUDA为对标;另一个则是OpenGL的后继者Vulkan。最新的动向是Khronos似乎打算把OpenCL标准整合进Vulkan,所以很可能不久的将来,Vulkan会变成统一图像与计算的API。由于OpenCL基本上是GPU上编程的唯一通用标准(另一个业内使用范围更广泛的是Nvidia的CUDA),很自然的FFmpeg也打算用OpenCL去加速相应的一些Codec或者AVfiter相关的任务。最初,x264尝试用OpenCL优化,但结果并不尽理想,主要原因估计是很多时候编码器实现是一个反复迭代的过程,数据之间也会出现依赖,导致想完全并发利用OpenCL去加速,比较困难,所以最终x264只用OpenCL加速了部分功能,更多的信息可以参考

https://mailman.videolan.org/pipermail/x264-devel/2013-April/009996.html


FFmpeg并未尝试用OpenCL去优化Codec部分,但是却优化了AVFilter部分,主要用在硬件加速转码的场景下。其最大的好处是解码,Filter、编码都在GPU内部完成,避免了GPU与CPU之间的数据交换,而一般Codec输出的数据,需要与OpenCL实现所谓的Zero Copy,这一点,需要OpenCL做一些扩展以支持接收解码器解码的出来的数据格式,并输出编码器能接收的数据格式。这里典型的扩展如Intel 提出的OpenCL与VA-API的Surface sharing:

https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_va_api_media_sharing.txt:



最近,FFmpeg社区的Rostislav Pehlivanov开始尝试用Vulkan优化AVFilter,已经提交了Patch,正处于Review阶段,从他FOSDEM的PPT https://pars.ee/slides/fosdem18_encoding.pdf 看,他似乎也想再次尝试用Vulkan来优化Codec,但初期只有针对AVFilter的优化代码出现。顺带说一句,Rostislav Pehlivanov的这份PPT中,回顾了各种CODEC上的各种尝试,整个行业在CODEC上的努力,而其中大部分的CODEC,并未流行开来,但这些人的种种努力不该被完全忘记。


3.参考文献


  • https://developer.nvidia.com/nvidia-video-codec-sdk 更多Nvidia video codec的信息,可以从这里获取到

  • http://on-demand.gputechconf.com/gtc/2016/presentation/s6226-abhijit-patait-high-performance-video.pdf 这里对NVENC/NVDEC 给出了一些详尽的说明

  • https://developer.android.com/reference/android/media/MediaCodec.html 使用MediaCodec时候,Android上的文档基本上是必须要先读的

  • https://elinux.org/images/9/9d/Android_media_framework--van-dam_and_kallere.pdf

  • https://static1.squarespace.com/static/4eb80772d09a941b5c45e0c0/t/541f2918e4b092469720191e/1411328280290/Video_DroidConNYC.pdf

  • https://www.khronos.org/  

  • khronos 最近动作不断,一方面,看到各种新标准的提出,另一方面又担心这些标准最终实施的状况。

原作者: 赵军 来自: LiveVideoStack
文章点评