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

  • 时间:
  • 浏览:0

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

9.2 FFmpeg中的硬件加速

6.3 Intel GPU 支持

6.2 FFmpeg & Intel GPU加速方案

当亲们 在补救许多异构计算时,始终需用面对此难题:CPU与GPU、DSP之间的数据交换。数据从CPU拷贝到GPU与从GPU拷贝到CPU并就有有有4个对等关系,一般而言,数据从CPU到GPU进行拷贝的速率单位更慢且不发生性能瓶颈;就说 意味是GPU到CPU的拷贝交换有是意味面临性能瓶颈,其是意味是两者使用了不同的缓存策略。是意味亲们 通过mmap GPU的memory到CPU侧,刚刚不进行任何优化就说 直接使用诸如memcpy函数将数据拷贝到CPU侧,会发现性能是意味不如预期。关于你是什么难题,英特尔也提供了许多优化妙招,这类使用SSE4/AVX等指令集中提供的bypass Cache的特定指令,也就说 所谓的Faster Copy肩头的特定指令;另外,也可考虑直接用GPU进行拷贝而非使用CPU,是意味考虑从OpenCL层面进行优化。

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

8、FFmpeg VA-API的细节信息

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

2、何谓FFmpeg/VA-API?

10、To Do List 

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

1)解码支持

9.3 硬件或驱动不支持

挂接 / LiveVideoStack

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能力就很强,这从不正确,实际使用中,需用把这有有4个指标分开来根据具体的使用场景来分析与比较,以选择最离米 的硬件方案。

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

编码方面,Intel GPU很早现在现在开始就支持了H.264编码,到了Broadwell增加了对VP8的支持;而Skylake则增加HEVC和MJPEG,到了Kaby Lake时亲们 增加了对VP9和10Bit HEVC的编码支持。关于VP9我还可以强调许多,据我所知,现在量产的SoC/GPU/CPU中是意味必须英特尔的Kaby Lake及其后续的产品与三星的SoC支持VP9的编码硬件加速。

大每种客户偏向于使用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中集成了有有4个Plugin到FFmpeg中:第有有4个是QSV Plugin,其这类于libx265的做法,其Codec实现的底层与MediaSDK相关;但FFmpeg社区更倾向于基于libva/vaapi的妙招,即直接在FFmpeg中进行集成,不warpper第三方的库,一是意味此方案相对而言更加轻量,二是意味此方案更加开放;没能 做是意味将完整性的硬件Codec每种的代码都集成在FFmpeg中,与FFmpeg融为一体,是意味客户希望进行定制或改变,没能 直接在FFmpeg內部代码中修改即可实现。除了补救基本的解码/编码硬件加速难题,亲们 也在考虑集成OpenCL、OpenCV等以适应客户的许多许多需求。  

4、VA-API

3、Linux Video API

7、FFmpeg硬件加速全览

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

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

当时的英特尔现在现在开始涉足硬件加速领域,于是在1999年左右英特尔提出VA-API接口。这是一套在Linux上的标准接口,从上层来看亲们 还可以将其理解为有有4个OS层面的Video加速Spec,且与硬件无直接关联。这套通用接口,同需用用特定的后端实现支持。与大多数开源项目这类,VA-API并没能 有有4个有点儿好的Document进行说明,需用另一方仔细的去读它的头文件以了解其设计思想和细节。另外,既然这是有有4个Spec,其设计上自然想剥离与特定硬件的强关联,就说 实在今天我的分享主要围绕Intel GPU实践进行,但实际上VA-API这套Spec从不只限于英特尔的GPU。

9、许多难题

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大每种是意味种种是意味慢慢转为封闭而逐渐被废弃;与此同去,英特尔的态度则更为开放,它希望大每种的开发者有能力在现有心智心智性开花结果是什么是什么的句子的句子的句子的句子 是什么是什么平台上进行更速率单位次的定制与探索,开放出更多的硬件能力以及驱动代码,这也是英特尔作为有有4个开源大厂的风范吧。

6.4 使用案例

是意味完成了编解码的部署,需用AVFilter相关的优化但硬件是意味驱动层面却不支持,面对你是什么情况汇报,亲们 可考虑OpenCL。是意味OpenCL现在可与FFmpeg Video的编解码进行Buffer Sharing,这离米 是有有4个GPU內部零拷贝的过程;只需用依靠Hwmap和Hwunmap实现的map就能直接用OpenCL对现有的AVFilter进行优化,从而帮助开发者补救此类是意味CPU/GPU的数据交换是意味的性能难题,与此同去,把OpenCL作为对GPU通用计算的标准接口,来优化亲们 的各种视频或图像的补救;另外,亲们 还可以将此思路放得更宽许多,是意味客户不希望直接使用来OpenCL来手动优化AVFilter,也可考虑把OpenCV作为有有4个是意味被OpenCL优化好的算法集合再集成进FFmpeg中。亲们 现在也在考虑此类妙招并在其上进行尝试。

文 / 赵军

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

上图展示的是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。它实际上是有有4个历史遗产,在FFmpeg中,很早便实现了H.264的软解码,在此基础上,是意味想使能GPU的解码能力则需用面临以下有有4个选择:还可以选择重新实现有别于软解码的另一套基于GPU解码实现,还可以考虑为需用完整性实现有有4个这类h264_vaapi的解码其;也可将解码相关的许多硬件加速工作直接Hook在已有的软解码Codec中,当时的开发者选择了后者,就说 大每种基于OS的硬件加速解码方案都基于后者的方案也就说 Internal AVHWaccel;但诸如NVIDIA等提供NVDEC,NVENC的方案,是意味自身是意味是有有4个完整性的硬件解码器,就说 在 FFmpeg内只需实现成有有4个简单的wrappe人即可,不需用借助FFmpe已有的软解码Codec的任何功能。

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

2)编码支持

6、Intel GPU

1、Media pipeline review

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

9.1 CPU与GPU的数据交换

作为最为流行的开源媒体补救方案,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。

上图展示的是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的解码支持,其解码能力稳步增加。

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

6.1 Intel GPU Media 硬件编程模型