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

  • 时间:
  • 浏览:1
  • 来源:uu快3app赚钱_uu快3大小计划注册

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能力就很强,这不须正确,实际使用中,还要把你是什么个多多指标分开来根据具体的使用场景来分析与比较,以确定最最少的硬件方案。

6.3 Intel GPU 支持

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大每段但会 种种原因着慢慢转为封闭而逐渐被废弃;与此并肩,英特尔的态度则更为开放,它希望大每段的开发者有能力在现有性性性早熟的句子期的句子期的句子平台上进行更宽度次的定制与探索,开放出更多的硬件能力以及驱动代码,这也是英特尔作为一两个 多多开源大厂的风范吧。

上图展示的哪几种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的文档但会 代码。

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

8、FFmpeg VA-API的细节信息

9、其他问题图片

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

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

9.2 FFmpeg中的硬件加速

3、Linux Video API

上图展示的是典型的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%到30%,其身旁是对计算量的大幅渴求,CPU的计算能力有时必须实时跟上计算量的需求或在高转码密度条件下必须提供较好的性价比,在此背景下,Intel提出了基于Intel GPU的媒体硬件加速解决方案。

1、Media pipeline review

2)编码支持

接下来我将介绍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。

1)解码支持

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

文 / 赵军

4、VA-API

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

6、Intel GPU

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

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

9.3 硬件或驱动不支持

上图展示的是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的任何功能。

大每段客户偏向于使用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提供了其他Filter用于实现硬件加速pipeline的建立,分别为Hwupload、Hwdownload、Hwmap、Hwunmap,使得在组成硬件的Pipeline时尽量解决小量的数据交换,所有操作尽量在GPU内部管理直接完成以提升性能。

6.4 使用案例

10、To Do List 

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

收集 / LiveVideoStack

6.1 Intel GPU Media 硬件编程模型

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

7、FFmpeg硬件加速全览

2、何谓FFmpeg/VA-API?

从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作为一两个 多多通用的计算资源那我 协同工作的。

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

当亲们在解决其他异构计算时,始终还要面对此问题图片: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层面进行优化。

9.1 CPU与GPU的数据交换

6.2 FFmpeg & Intel 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。