FFmpeg在Intel GPU上的硬件加速与优化

  • 时间:
  • 浏览:0

接下来我将介绍Linux平台上Video加速API的进化历史。朋友 知道,每两个多 突破性创新都会从细微之处结束英语 慢慢演化,最后才而且成为举世瞩目的创造;另外所以技术的进化过程中,都会工程与算法科学相互交织,Linux上的硬件加速API的进化流程也遵循了你什儿 点。最初的Linux Video API被称为Xv,基本只能借助硬件加速实现Scaling与Color Space Conversion两个多 功能,明显无法满足行业需求;并且 经过扩展,使得在那个MPEG-2称霸的时代实现了对MPEG-2 Decoding硬件加速API的支持, 也可是我Xv/XvMC,不过你什儿 次要在当时还等待歌曲在比较初级的阶段,iDCT、XvMC-VLD等还未实现被API所标准化;并且 社区便结束英语 尝试实现Slice层加速API标准化,以处置时候包括不支持解码所有阶段硬件加速且依赖于X-Protocol协议等在内的诸多大问题,演化到现在,最终的结果可是我VA-API。

9.3 硬件或驱动不支持

FFmpeg提供了有些Filter用于实现硬件加速pipeline的建立,分别为Hwupload、Hwdownload、Hwmap、Hwunmap,使得在组成硬件的Pipeline时尽量处置几瓶的数据交换,所有操作尽量在GPU内部管理直接完成以提升性能。

9.2 FFmpeg中的硬件加速

VA-API可用的后端驱动非常多:Intel VA(i965)Driver是Intel OTC Team开发的一套全开源驱动,并且 也再次出现了Intel Hybird Driver、Intel iHD Driver等;在后端实现中还有Mesa‘S state-trackers包括Radeon、Nouveau、Freedreno等的支持,另外,还有些公司开发了有些API Bridge,包括Vdpau-va Bridge、Powervr-va的bridge以提供VA-API的支持,但多少bridge大次要而且种种意味着着慢慢转为封闭而逐渐被废弃;与此一并,英特尔的态度则更为开放,它希望大次要的开发者有能力在现有性性成长期期是什么 图片 的句子的句子期期期平台上进行更深度1次的定制与探索,开放出更多的硬件能力以及驱动代码,这也是英特尔作为两个多 开源大厂的风范吧。

朋友 好,今天与朋友 分享的主题是FFmpeg在 Intel GPU上的硬件加速与优化。

上图展示的是FFmpeg VAAPI的有些细节信息,时候我而且对HWAcceled的解码与Native的解码进行了说明。提及编码,硬件加速的编码带来的最大好处是数率优势:我只能 基于Skylake-U只能 双核四程序运行的低电压CPU上测试103000P的转码,基本可实现240FPS的实时转码;一并,在大规模部署时只能不考虑功耗比与性价比,也可是我单路的编码或转码也能 消耗多少电能以及单路转码的成本。现在集成了GPU的英特尔PC处置器,其功耗在40~65w,而且是面向服务器工作站的Xeon E3系列,可在两个多 65w的处置器上实现14到18路的103000P转码,而能达到相同性能的NVIDIA GPU所需的能耗合适在3000w左右。另外,对于硬件编码,有有些客户而且在图像质量上有更高的需求,现在英特尔的GPU在低码率上处置效果还有提升空间,但在处置中高码率文件时,其评测结果与X264相比并无明显的差距。而且客户期望借助本人的有些高阶算法通过更深度1的定制实现更强大的功能,Intel也开放了被称为Flexible Encoder Interface (FEI)的底层接口。此接口可完正全面展示Intel GPU的完正硬件编码能力,并让用户拥有足够的灵活度去Tunning各种算法;而且说FFmpeg代表的是两个多 也能 直接调用的性性成长期期是什么 图片 的句子的句子期期期平台,只能 FEI则是可定制Codec算法的通用接口。与此一并,FEI对客户的能力要求也更高,而且有高阶深度1次定制化的编码需求,也能 考虑FEI。最后,附带一句,朋友 同样在AVFilter中集成了GPU的VPP以实现硬件加速的Scaling与Deinterlace等操作,后续也会支持Overlay、CSC等。

作为最为流行的开源媒体处置方案,FFmpeg有什儿 使用土妙招:直接使用它自带Tools,而且把FFmpeg作为Library调用它的API而实现本人的逻辑。其中的Tools暗含朋友 时不时看过的转码工具FFmpeg;轻量媒体播放器FFPlayer;进行格式的探测分析的FFProbe ;轻量级流媒体测试的服务器FFServer等。另外,FFmpeg的内部管理实现基本以C语言为主,辅助以次要汇编优化;一并它支持Linux、MacOSX、Android、Windows等不同OS,有着良好的跨平台兼容性。这里另外强调有些的是FFmpeg自身的License大问题,他说国内的厂商不必怪怪的在意License,但在实际使用场景中,所使用软件而且库的License即版权是只能不考虑的大问题。最近几年FFmpeg而且将License的大问题澄清得比较清楚,目前它的大多数内部管理实现代码使用GPL2.1版本的License。

1)解码支持

当时的英特尔结束英语 涉足硬件加速领域,于是在1999年左右英特尔提出VA-API接口。这是一套在Linux上的标准接口,从上层来看朋友 也能 将其理解为两个多 OS层面的Video加速Spec,且与硬件无直接关联。这套通用接口,一并也能 特定的后端实现支持。与大多数开源项目类事,VA-API并只能 两个多 怪怪的好的Document进行说明,也能 本人仔细的去读它的头文件以了解其设计思想和细节。另外,既然这是两个多 Spec,其设计上自然想剥离与特定硬件的强关联,所以觉得今天我的分享主要围绕Intel GPU实践进行,但实际上VA-API这套Spec好的反义词只限于英特尔的GPU。

4、VA-API

9、有些大问题

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/8357273000

6.1 Intel GPU Media 硬件编程模型

英特尔提供了一套基于VA-API/Media SDK的硬件加速方案,通过在FFmpeg中集成Intel GPU的媒体硬件加速能力,为用户提供更多的收益。本文来自英特尔资深软件开发工程师赵军在LiveVideoStackCon 2017大会上的分享,并由LiveVideoStack分发而成。

6、Intel GPU

编码方面,Intel GPU很早结束英语 就支持了H.264编码,到了Broadwell增加了对VP8的支持;而Skylake则增加HEVC和MJPEG,到了Kaby Lake时朋友 增加了对VP9和10Bit HEVC的编码支持。关于VP9我不并且强调有些,据我所知,现在量产的SoC/GPU/CPU中而且只能英特尔的Kaby Lake及其后续的产品与三星的SoC支持VP9的编码硬件加速。

而且完成了编解码的部署,也能 AVFilter相关的优化但硬件而且驱动层面却不支持,面对你什儿 情形,朋友 可考虑OpenCL。而且OpenCL现在可与FFmpeg Video的编解码进行Buffer Sharing,这合适是两个多 GPU内部管理零拷贝的过程;只也能 依靠Hwmap和Hwunmap实现的map就能直接用OpenCL对现有的AVFilter进行优化,从而帮助开发者处置此类而且CPU/GPU的数据交换意味着着的性能大问题,与此一并,把OpenCL作为对GPU通用计算的标准接口,来优化朋友 的各种视频或图像的处置;另外,朋友 也能 将此思路放得更宽有些,而且客户不希望直接使用来OpenCL来手动优化AVFilter,也可考虑把OpenCV作为两个多 而且被OpenCL优化好的算法集合再集成进FFmpeg中。朋友 现在也在考虑此类土妙招并在其上进行尝试。

大次要客户偏向于使用FFmpeg的一并,也希望其具备出色的硬件加速能力,朋友 现在致力于在FFmpeg中集成Intel GPU诸多的媒体硬件加速能力,使用户可通过FFmpeg的接口使能调用英特尔的GPU的各种能力从而带来更多收益。这里的集成土妙招主要有什儿 :1)直接实现为与FFmpeg融为一体的Native Decode/Encode。FFmpeg的大次要Decode如H.264、H.265、VP8、VP9等都使用Native Decoder的土妙招,2)Warpper第三方库的,如在FFmpeg中集成Libx264的土妙招;现在次要Encode都以第三方库的形式集成进FFmpeg的。根据上图朋友 也能 看过在Intel GPU中集成了两个多 Plugin到FFmpeg中:第两个多 是QSV Plugin,其类事于libx265的做法,其Codec实现的底层与MediaSDK相关;但FFmpeg社区更倾向于基于libva/vaapi的土妙招,即直接在FFmpeg中进行集成,不warpper第三方的库,一是而且此方案相对而言更加轻量,二是而且此方案更加开放;只能 做意味着着将完正的硬件Codec次要的代码都集成在FFmpeg中,与FFmpeg融为一体,而且客户希望进行定制或改变,只能 直接在FFmpeg内部管理代码中修改即可实现。除了处置基本的解码/编码硬件加速大问题,朋友 也在考虑集成OpenCL、OpenCV等以适应客户的有些有些需求。  

从FFmpeg到具体的GPU,是如保进行有些Media处置的?首先FFmpeg会通过VA-API接口,调到对应的Driver类事i965或iHD,时候数据经过OS Scheduler进入OS KMD,接下来经过一系列硬件编程抽象和GPU&CPU数据交换,生成Command streamer并传输给EU(也可是我Intel GPU中的两个多 计算执行单元)而且特定的IP以执行相关的Media任务。注意,GPU的Media次要有时也会使用EU多少通用计算资源,而像Sampler、VDBOX、VEBOX、SFC等都会基于有些特定的Fix Function硬件实现相应功能。所以,也能 只能 理解,英特尔的GPU实际上是将媒体的大次要功能通过Fix Function土妙招实现,一并必要时候使用EU作为两个多 通用的计算资源只能 协同工作的。

7、FFmpeg硬件加速全览

上图展示的多少Use Cases可基本暗含大次要用户的使用场景。解码次要主可是我使用hwaccel vaapi进行硬件解码,而且一款设备上而且居于多款GPU,而且朋友 需可是我hwaccel_device选择不同的硬件设备。对比硬件编码与硬件解码朋友 不能自己发现,在解码次要朋友 使用hwaccel_device而编码次要则使用vaapi_device。这里的vaapi_device是两个多 Group Option,而且FFmpeg中居于Group Option与Per-Stream Option,解码次要的hwaccel_device是Per-Stream Option,而编码次要的vaapi_device是全局的而且Decoder和Encoder只需指定一次。从中间看来,转码的例子更为僵化 ,首先进行硬件解码,而后在GPU中进行de-interlace与Scall和HEVC编码,实际上整个过程是两个多 硬件解码结合GPU中的Deinterlace/Scale和并且 的HEVC硬编的过程,这里也能 注意有些关于码控设定的大问题,对此大问题有兴趣的同学也能 直接阅读FFmpeg的文档而且代码。

10、To Do List 

上图展示的是朋友 正在实践与探索的技术点,期待通过以上优化为音视频行业带来技术进步与行业发展。

Intel GPU从Gen 3的Pinetrail发展到Gen 9.5的Kabylake,每一代GPU的功能都会增强,在Media上的能力也在增强。关于GPU性能朋友 比较关注以下三次要指标:第一次可是我3D渲染能力,你什儿 次要的标准化程度较好,也能 使用标准接口包括OpenGL或Vulkan,当然都会Windows上可与OpenGL与Vulkan适配的DirectX等;第二次可是我Media;第三次要则为通用计算,其中包括NVIDIA的CUDA与AMD、ARM等公司采用的OpenLL。附带说一句,另一个人会混淆GPU的通用计算能力与Media处置能力,以为通用计算能力很强,则Media能力就很强,这好的反义词正确,实际使用中,也能 把你什儿 个多 指标分开来根据具体的使用场景来分析与比较,以选择最合适的硬件方案。

5、VA-API可用的后端驱动

上图展示的是FFmpeg硬件加速全览,我不并且你什儿 次要对探索基于FFmpeg实现跨平台的开发者来说非常有帮助。开发者时不时也能 面对不同的硬件厂商:Intel、NVIDIA、AMD等等,朋友 希望仅仅与FFmpeg经过一次集成,就可在不同硬件上实现同样的功能。而现实情形,即是居于OS层面也能 进行硬件优化的API诸如Windows上的Dxva或MacOS上的VideotoolBox、Linux的Vaapi等,觉得现而且还是非常分散,而FFmpeg在支持各种硬件加速接口时候,则帮助处置了中间的你什儿 大问题。另外,对于上表,Decoder次要只列举了算不算支持硬件surface的输出。除此之外还有有些附加功能类事Filter,作为FFmpeg中非常重要的一次要,它主可是我为了进行Video 后处置等;上表中的Hardware Context是指基于FFmpeg内部管理的硬件加速接口的实现,Useable from FFmpeg CLI是指FFmpeg的命令行算不算直接可用硬件加速(它的典型使用场景是,在Server端将FFmpeg直接作为工具使用,通过PHP在后端直接调用FFmpeg的Tools)。另外,而且开发者也能 调用FFmpeg API进行解码,此时也能 关注Hwaccel的支持情形。最后我不并且强调一下图中Decoder次要里的Internal和Standalone。它实际上是两个多 历史遗产,在FFmpeg中,很早便实现了H.264的软解码,在此基础上,而且想使能GPU的解码能力则也能 面临以下两个多 选择:也能 选择重新实现有别于软解码的另一套基于GPU解码实现,也能 考虑为也能 完正实现两个多 类事h264_vaapi的解码其;也可将解码相关的有些硬件加速工作直接Hook在已有的软解码Codec中,当时的开发者选择了后者,所以大次要基于OS的硬件加速解码方案都基于后者的方案也可是我Internal AVHWaccel;但诸如NVIDIA等提供NVDEC,NVENC的方案,而且自身而且是两个多 完正的硬件解码器,所以在FFmpeg内只需实现成两个多 简单的wrappe人即可,不也能 借助FFmpe已有的软解码Codec的任何功能。

文 / 赵军

上图展示的是Intel GPU Decode次要的的支持情形。一般情形下朋友 也能 将Decode分为8Bit与10Bit,以HEVC为例,有有些数据显示10bit的压缩率要高于8bit,感兴趣的同学也能 思考一下其意味着着。从表可是我需要 看过,英特尔的各代GPU逐渐进化,从结束英语 只支持MPEG-2、H.264、VC-1解码的Sandy Bridge到增加了MJPEG解码支持的Ivy Bridge再到多用于嵌入式平台的Bay Trail乃至时候的Haswell,从Broadwell结束英语 对VP8的支持与Cherry Trail/ Braswell对HEVC的支持再到Skylake时候的Apollo lake与 Kaby lake对VP9解码与10bit HEVC&VP9的解码支持,其解码能力稳步增加。

6.4 使用案例

9.1 CPU与GPU的数据交换

1、Media pipeline review

2)编码支持

6.2 FFmpeg & Intel GPU加速方案

6.3 Intel GPU 支持

当朋友 在处置有些异构计算时,始终也能 面对此大问题:CPU与GPU、DSP之间的数据交换。数据从CPU拷贝到GPU与从GPU拷贝到CPU并都会两个多 对等关系,一般而言,数据从CPU到GPU进行拷贝的数率加快数率且不居于性能瓶颈;而而且是GPU到CPU的拷贝交换有而且面临性能瓶颈,其意味着着是两者使用了不同的缓存策略。而且朋友 通过mmap GPU的memory到CPU侧,时候不进行任何优化可是我直接使用诸如memcpy函数将数据拷贝到CPU侧,会发现性能而且不如预期。关于你什儿 大问题,英特尔也提供了有些优化土妙招,类事使用SSE4/AVX等指令集中提供的bypass Cache的特定指令,也可是我所谓的Faster Copy身后的特定指令;另外,也可考虑直接用GPU进行拷贝而非使用CPU,而且考虑从OpenCL层面进行优化。

上图展示的是典型的Media Pipeline。朋友 知道,FFmpeg对输入格式支持非常的全面,也能 是文件、网络流等,可是我需要 使用Device的Caputer作为输入;输入的音视频经过Splitter后一般会分为什儿 常见场景:Play Back与Transcoder。上图的右上半次要实际是两个多 Transcoder的基本流程,解复用时候的Video、Audio的ES流,再经过Video、Audio的Filter,大次要情形下,Video有而且在AVFilter执行有些Scale、Frc、Crop操作(可是我需要 在AVFiter中抓取有价值的信息);并且 音视频数据会被转码成为用户指定的格式,转码时候多伴随着码率转换、指定IPB帧类型等;Audio也会经过类事的处置流程。上图的右下半部也能 视为播放器处置流程也可是我Playback,Playback流程与Transcoder处置流程的主要差异在于对解码的数据算不算进行再次编码而且直接显示。另外,众所周知,Encoder与Decoder的僵化 程度居于两个多 数量级的差异,计算僵化 度合适为10:1,且一般情形下Encoder每十年进化为一代,从MPEG2发展到H264合适用了十年时间,而从H264发展到HEVC将近十年时间(实际只能十年),其计算僵化 度提升均为上一代的十倍左右,但压缩率提升合适只能40%到3000%,其身后是对计算量的大幅渴求,CPU的计算能力有时只能实时跟上计算量的需求或在高转码密度条件下只能提供较好的性价比,在此背景下,Intel提出了基于Intel GPU的媒体硬件加速处置方案。

3、Linux Video API

分发 / LiveVideoStack

2、何谓FFmpeg/VA-API?

8、FFmpeg VA-API的细节信息