几个平台环境里视频编解码和图像scale的硬件加速的方法

记录一下遇到几个平台里的视频编解码和图像scale的硬件加速的方法

1，intel平台
当包含GEN系列的集成GPU时，可用libva实现视频codec、颜色空间转换和图像scale的硬件加速，具体可使用libyami这个接口友好的封装库。加速处理过程中图像位于GPU内存，用libva的Surface表示。其在原生的linux和Android NDK环境中均可用。

2，Allwinner平台
可以直接使用特有的 cedarx 硬件引擎实现视频编解码加速。使用G2D组件实现图像scale的硬件加速。其SDK包可从其官方github上获取。

3，opemnax接口
openmax只是一套开放的媒体处理接口，有些厂商不直接提供原生的媒体SDK，将媒体处理功能以Openmax接口来提供。此时只能使用Openmax来使用硬件加速功能了。具体需要阅读Openmax接口规范，以及厂商自身的额外提供的扩展接口。
此类接口比较广泛，比如MTK/Intel/RasperryPi等，都可用。具体的功能是通过OMX组件来提供的，因此具体需要看实际有组件可用。在android系统框架中也有openmax组件接口可用，但只能用于系统定制开发，在开发App时只能使用Mediacodec接口。

4，Android的MediaCodec接口
MediaCodec接口为新版Android的所提供的媒体处理接口，其本质上也是基于openmax接口来做的实现。各个硬件平台厂商对自己平台提供的硬件加速功能以openmax接口的方式进行提供，在android框架中基于OMX继续封装成MediaCodec，实际上在android框架中除了平台厂商提供的硬件加速OMX组件，也有android提供软codec组件实现。这些实现位于libstagefright中。

5，Nvidia VideoCodec
直接利用显卡的内部的硬件视频编解码音频来进行编解码（不是CUDA计算引擎），直接使用vidia-video-codec-sdk来做开发即可。好处是与CUDA交互比较方便。类似主要是视频编解码功能。

其他平台没有接触到，暂不记录。

=== update 2017年12月25日 ===
其实各个平台实现硬件加速媒体处理的基本原理都是一致的，即在图像数据放在专有memory中，然后交给专有的硬件单元进行计算处理，这些专有硬件单元对这些计算任务都是特别设计和优化的，所以其处理速度比CPU软处理要快。

因而若图像数据开始时在常规内存中，那么则需要先将其copy到专有memory中，然后才能进行这些硬件加速计算，并且结果若需要由CPU后续处理，也需要将数据从专有memory中copy回常规内存中，这些copy过程效率取决于硬件平台的设计实现（CPU和内存总线等），性能各不相同，但是都是需要额外耗时的。若数据量比较小，且这种copy动作较多，那么copy动作耗时占比可能比较大，那么整体的效率可能还不如直接由CPU对常规内存中的数据进行直接处理来的快。

类似CUDA/OpenCL的使用都有类似问题，因而是否需要采用硬件加速计算，需要视情况而定，综合考虑数据量大小/硬件加速效率之后再决定，而不是一概盲目采用。