Android OpenMAX（一）漫谈

在开始正式的学习前，我们先来聊一聊Android音视频开发中的一些问题、感受与想法。（有一点要事先说明，我的问题与答案、想法并不一定正确，请读者带着审慎的思考来阅读，后续的文章也是一样，希望读者边阅读边思考，看到错误可以指出让我改正，如有问题也可以提出一起讨论。）

• 为什么要有Android OpenMAX？

  • Android系统可以跑在多种类型的设备上，比如说手机、电视、平板或者是现在的车机上，这些设备会有不同的芯片，手机用的比较多的是海思、高通、联发科，电视见的比较多的是AML、RTK，这些芯片厂商会有自己编解码器的实现（VPU API），Android作为一个通用的平台为了调用不同芯片的VPU API引入了OpenMAX框架，各大厂商实现Android OpenMAX框架提供的接口之后，开发者就可以用统一的接口使用硬件编解码了。

• Android OpenMAX（OMX）和OpenMAX有什么异同？

  • 在网上搜寻资料，一般介绍OpenMAX框架会包含三层，自上而下分别是OMX AL层、OMX IL层、OMX DL层，每一层都定义有一套标准的API，但是在Android中只用到了IL层的部分并且做了部分裁减。

• OMX IL层包含哪些内容呢？

  • 简单来讲，OMX IL层定义了编解码组件的结构（我们应该如何实现OMX组件，一个OMX组件包含哪些东西）、组件的调用接口（我们应该如何获取、管理、调用、控制OMX组件）。

播放器可以分为如下几个部分：IO、Demux、Control、Decoder、Render，一般来说IO和Demux可以看作是一部分，Control用于控制IO-Demux、Decoder、Render协同工作，数据在三个组件之间来回流转，所以我觉得播放器控制，实际指的是Buffer流转的控制，Buffer传递方式的控制。

回到Decoder中来，我们在看ACodec、OpenMAX代码时可能会感觉写的十分复杂，这是因为考虑了非常多的情况，以Buffer传递方式为例：

• 对于普通Input buffer或者是普通Output Buffer，传递给Decoder时用共享内存可以减少Buffer的拷贝，共享内存可以在ACodec这一层分配，可以由OMX组件分配；
• 对于需要加密的Secure Input Buffer，Buffer由OMX组件分配并且将Buffer Handle回传给ACodec使用，本质上是一块共享内存，只不过是加密的物理内存；
• 如果需要渲染到Surface上，那么可以直接将解码后的数据直接存储到graphic buffer上，graphic buffer也是一块物理共享内存，ACodec与OMX组件之间的Buffer传递需要通过Fence和Handle来完成。

input/output buffer有多种类型，分配方式和传递方式也是各不相同，所以看代码只看流程是很难理解实现原理的，我们要知道Buffer是从哪儿分配的，从哪里来又到哪里去，不同状态下是如何控制的。

最后，也是非常重要的一点，我们还需要对音视频的基础知识有所了解。

目前就想到这么多，后续如果有想到其他内容会继续补充。