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

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

2018-3-9 09:00

  • macOS: VideoToolbox


在macOS上的硬件加速接口也是跟随着Apple经历了漫长的演化,从90年代初的QuickTime 1.0所使用的基于C的API开始,一直到iOS 8 以及 OS X 10.8,Apple 才最终发布完整的 Video Toolbox framework(之前的硬件加速接口并未公布,而是Apple自己内部使用),期间也出现了现在已经废弃的Video Decode Acceleration (VDA)接口。Video Toolbox是一套C API ,依赖了CoreMedia, CoreVideo, 以及 CoreFoundation 框架 ,同时支持编码,解码,Pixel转换等功能。Video Toolbox所处的基本层次以及更细节的相关结构体如下:

 


关于Video Toolbox的更多细节,可以参考https://developer.apple.com/documentation/videotoolbox。


Android: MediaCodec 


MediaCodec是Google在Android API 16之后推出的用于音视频编解码的一套偏底层的API,可以直接利用硬件以加速视频的编解码处理。MediaCodec的概念中,一般而言,编解码器处理输入数据并生成输出数据。它异步处理数据并使用一组输入和输出缓冲区。在简单的层面上,需要请求(或接收)一个空输入缓冲区,填充数据并将其发送到编解码器进行处理。编解码器使用数据并将其转换为其空的输出缓冲区之一。最后,你请求(或接收)一个填充的输出缓冲区,消耗其内容并将其释放回编解码器。



MediaCodec可以处理的数据有以下三种类型:被压缩的Buffer(Compressed Buffers)、原始音频数据(Raw Audio Buffers)、原始视频数据(Raw Video Buffers)。可以使用ByteBuffers处理所有三种数据,但一般应该使用Surface以提高编解码器的性能。 Surface使用本地视频缓冲区,无需映射或复制到ByteBuffers; 因此,效率更高。 通常在使用Surface时无法访问原始视频数据,但可以使用ImageReader类来访问不安全的解码(原始)视频帧。 这可能比使用ByteBuffers更有效率,因为一些本机缓冲区可能被直接映射到ByteBuffers。 当使用ByteBuffer模式时,也可以使用Image类和getInput / OutputImage(int)访问原始视频帧。FFmpeg自3.1版本加入了android MediaCodec硬件解码支持,其实现Follow了FFmpeg的HWaccel接口,但直到现在为止,FFmpeg都并未支持基于MediaCodec的硬件加速编码。


1.基于Chip 厂商的私有方案


这里所提及的私有,并非是说代码没有Open,更多层面上是指所提供的相应的API接口和实现,是厂商所特定的,而非行业标准定义的API ,诸如OpenMAX或者OS层面剥离了硬件具体实现相关抽象的API。更进一步说,是采用相关厂商私有方案之后,如果想要二次深度开发,其困难度较大一些。实际上,从开放的角度而言,Intel,AMD,Nvidia这3家GPU大厂所提供的方案的Open 程度不尽相同,总的说来,其开放程度是Intel好于AMD, 而AMD又好于Nvidia。


Intel: Media SDK: 


Intel提供的Media SDK,本质是一套跨平台的加速方案,它在Windows/Linux上提供了相同的API,底层则分别使用了Windows上的DXVA2和Linux上的VAAPI接口,以Windows平台上为例,它的基本结构框图如下:



而在FFmpeg的集成中,基本上是在Libavcode/Libavfilter内提供了一个基本的wrapper去调用Media SDK的API来提供相应的功能。下图展示了Libavcodec集成MediaSDK的h264/hevc/mpeg2 Codec的状态,需要注意的是,FFmpeg master开发分支上支持的FFmpeg QSV已经支持了更多的Codec和相关VPP功能。




来自: LiveVideoStack
文章点评