许多计算平台提供专用硬件来执行一系列与视频相关的任务。使用这样的硬件可以让解码、编码或后处理效果等操作更快地完成，减少CPU的占用率。在PC上，视频硬件通常集成到GPU(比如AMD,Intel,NVIDIA或者VideoCore)，而在移动soc类型的平台上，它通常是一个独立的IP核心，被称为VE，或者VPU(video process unit)的Master设备。
图像编解码用到的核心算法是DCT/IDCT，它将时域信号转换到频域，得到频域的DCT系数，然后再对系数进行一次过滤，选择，忽略掉高频系数，然后再变换回时域，得到压缩后的时域图像。所以VPU本质就是将DCT/IDCT算法硬件化，然后再加上去方块滤波，熵编码等等一些列的辅助算法模块。
硬件解码器将产生与软件解码器相同的输出，但却大大提高了解码效率。而硬件编码器产生的输出质量通常比好的软件编码器(如x264)低得多，但通常速度更快，而且不占用太多CPU资源。(也就是说，它们需要更高的比特率才能以相同的感知质量进行输出，或者在相同的比特率下以较低的感知质量进行输出).
VPU的实现有很多，每个厂家IP的控制界面，控制寄存器的设计完全不同，给有效利用和推广自家IP的设计带来了很多麻烦，有鉴于此，很多原厂主动推出了一些标准的API用于标准化自家VPU的开发，也有些vendor厂商主动联合起来，指定一套标准构成一个标准联盟，这种事情多了，就出现了很多套标准同时存在的情况，如下表所示：
有些标准是IP商和操作系统商合作推出的，所以标准API不但和IP商有关，也和操作系统的类型有关，所以有些API的跨平台性很好，比如OpenCL，几乎可以泡在所有的操作系统商对接不同的硬件，也有些API，比如MMAL，只有个别平台支持。
FFMPEG中几乎所有解码器都有软解的实现，部分解码器用到了上述的API实现了硬解，具体情况如下图所示:
下面以FFMPEG中对树莓派FFMAL Video Codec的实现来分析，如果想在FFMPEG中添加一个VPU硬解码的支持，有哪些工作需要做。
在ffmpeg-3.3.2/libavcodec/mmaldec.c中，定义了四个AVHWAccel结构体, AVCodec结构体和AVClass结构体.每个结构体对应一种解码格式，它们分别是：
AVHWAccel结构体定义:
AVCodec以及AVClass结构体定义,其中AVClass结构体由AVCodec结构体中的priv_class成员指向，从这里可以看到，可以通过AVCodec结构体，索引到AVClass结构体.
也就是说，ffmpeg首先定义了h264,mpeg2,mpeg4以及vc1四种多媒体格式对应的结构体.
至于这些结构体定义后有什么用，继续看:
在ffmpeg-3.3.2/libavcodec/mmaldec.c文件中，实现了register_all函数，将所有实现了的硬加速单元的AVCodec 和 AVHWAccel注册入ffmpeg系统。
FFMPEG使用了REGISTER_HWACCEL/REGISTER_DECODER宏实现了对上述结构体的注册，因为MMAL只实现了解码器加速。还有另外两个宏REGISTER_ENCODER没有用到，它们如下：
可以看到，在宏中调用av_register_hwaccel函数和avcodec_regiser函数，对accel对象和avcodec对象进行了注册。注册进系统后，FFMPEG就可以通过命令行选项使用它们了。
实际上，register all函数执行的操作不止这些，下面流程图详细介绍了register_all函数的执行逻辑:
从上面的结构体定义可以看出，和编解码相关的最核心的结构体是 AVCodec结构体，因为它当中包含了.init,.decode,.flush.close几个函数指针，指向的函数都是直接进行解码操作逻辑的函数。
下面依次看每个接口的实现:
.init的实现流程
关于流程图中注释说明的情况，context内存分配是发生在libavcodec/utils.c文件中的avcodec_open2函数中。
这里完成后，就可以使用OMX_EmptyThisBuffer来给decoder驱动喂VBV数据了，其中handle在前面的流程中已经获取到。
.close的实现流程
.flush的实现流程
.decode的对接流程
整体看还是蛮复杂的，这里面最核心的是FFMPEG 和OMX内部之间的Buffer管理和交互，这一块理解了，基本上问题就不大了。
参考资料：
https://wiki.multimedia.cx/index.php?title=FFmpeg_codec_howto