OpenMax IL开发指引

前言：

OpenMax IL参考网站：OpenMAX Overview - The Khronos Group Inc

OpenMax IL源码下载网站：Bellagio OpenMAX Integration Layer

参考文献：
https://github.com/KhronosGroup/OpenMAX-IL-Registry/tree/main/api

层次结构

OpenMax是一个多媒体应用程序的框架标准，来看一下它的层次结构：

目前要使用的是OpenMax IL（Integration Layer，集成层）,这一层上承OpenMax AL（Appliction Layer，应用层）或者客户应用，简单地说就是提供SetSource,SeekTo这样的接口；下启OpenMax DL（Development Layer，开发层）或者平台的Codec，简单地说就是提供后端音效，画质，编码处理的接口。下面一幅图提供了描述。

NuPlayer就是用OpenMax来做(codec)编解码的。

OpenMax IL

Core

OpenMax IL包括Core和Component组件，Core用来初始化，加载Compoent，一旦加载完成，用户就可以直接使用IL层提供的API和组件交互；同样，用户也可以得用Core API建立Component之间的交互通道， Component之间可以不经Core API直接进行交互。Component就是功能模组，可以是sources, sinks, codecs, filters, splitters, mixers等等模块，它可以是纯软件组件，如Audio软件解码器，也可以代表硬件甚至处理器或者软硬件结合体。

Component组件

Component的参数通过关联的数据结构进行传递；状态，错误等信息用Callback函数来传递，这样设计的原因是方便进行系统异步设计。Component的数据传递是通过Port来传递的，Port代表了Component之间的一个连接关系，同时也持有维系Component之间连接关系的Buffer，有输入/输出Port之分。

　为避免死锁，Component的Command可以取消。下图是Component的通信方式：

下图是Component组件的状态变化：

每个组件的初始状态都是 UNLOADED

1. OMX_StateIdle, OMX_StatePause or OMX_StateExecuting状态已经具备所有资源，如果需要资源的具体数量在OMX_StateIdle状态不清楚，可以推迟到需要时再分配，比如Output frame Buffer的数量和ReferFrame的数量相关，而参考帧数得在解码后才知道。而静态资源是必须在变成OMX_StateIdle之前准备好的，否则会进入WAIT FOR RESOURCES 状态。OMX_StateExecuting意味着组件正在等待接收buffer以处理数据。由OMX_StateIdle 到 OMX_StateLoaded会导致资源消失，例如Buffer丢失，所以要特别注意这一状态转换。
2. 获取到Component Handle意味着Component由Core配置完成。Component的数据通信是非阻塞的，ports的数量被配置通信就被使能。每个port被配置特定的数据格式，并且组件也被置于正确的状态。port的通信方式各异，输入Port通过OMX_EmptyThisBuffer调用获取Buffer，常用的是用OMX_FillThisBuffer来让Input Port获取Buffer；输出Port通过OMX_FillThisBuffer 调用获取Buffer，更常用的是用OMX_FillThisBuffer让输出Port输出Buffer。port 将buffer header和buffer关联，buffer header 指向buffer中间的数据和buffer内容相关的metadata。相应的OMX_EmptyBufferDone OMX_FillBufferDone 回调函数在调用返回之前被触发。
3. 为了Thread Safe,任何callback回调函数不可以调用Core 或者Component的API，并且callbacks函数也不允许被中断服务程序ISR调用；除此限制外，Caller无需特殊处理线程安全和同步。

Component架构如下图示意：

如下为Gstreamer中应用OMX的数据流：

下面是omx IL设计方案对比：