OpenMAX IL框架

OpenMAX IL框架

OpenMAX
是一个多媒体应用程序的标准。由NVIDIA公司和Khronos™在2006年推出。
它是无授权费的、跨平台的C语言程序接口序列，这些接口对音频、视频、静态图片的常用操作进行封装。它包括三层，分别：
应用层（AI）、集成层（IL）和开发层（DL）

其中IL层已经成为了事实上的多媒体框架标准。嵌入式处理器或者多媒体编解码模块的硬件生产者，通常提供标准的OpenMax IL层的软件接口，这样软件的开发者就可以基于这个层次的标准化接口进行多媒体程序的开发

OpenCore StageFright OpenMax架构:

OpenMax IL层，通常可以用于多媒体引擎的插件
Android的多媒体引擎OpenCore和StageFright都可以使用OpenMax作为插件，主要用于编解码（Codec）处理。在Android的框架层，也定义了由Android封装的OpenMax接口，和标准的接口概念基本相同，但是使用C++类型的接口，并且使用了Android的Binder IPC机制。Android封装OpenMax的接口被StageFright使用，OpenCore没有使用这个接口，而是使用其他形式对OpenMax IL层接口进行封装

主要的功能和优点
OpenMAX IL API 能够在应用程序、多媒体框架和编解码库，以及其支持的组件（比如，sources 和 sinks）之间建立统一的接口。对于用户来说，组件自身及其内部的软硬件结合情况都是完全透明的。其主要功能如下：
• A flexible component-based API core;
• Ability to easily plug in new components ;
• Coverage of targeted domains (audio, video, and imaging) while remaining easily extensible by both the Khronos Group and individual vendors;
• Capable of being implemented as either static or dynamic libraries;
• Retention of key features and configuration options needed by parent software (such as media frameworks);
• Ease of communication between the client and the components and between components themselves;
• Standardized definition of key components so all implementations of such “standard components” expose the same external interface (i.e. same inputs, outputs, and controls).

OpenMAX IL 软件结构一

OpenMAX IL 软件结构二

客户端（Client）:
访问IL core或IL component的软件层，可能是位于GUI应用程序的下层，如GStreamer。IL client是一个典型的功能块，如filter graph multimedia framework, OpenMAX AL, 或application都可以调用它。IL client与OpenMAX IL core进行交互，利用IL core加载和卸载组件、在组件间建立直接通信以及获得组件方法的入口。
core:
相关平台的代码， 负责动态加载和卸载组件，协助组件间通信。一旦加载组件，API 允许用户直接与组件进行通信，类似的，core API 允许用户在组件之间建立tunnel通信通道，一旦建立，core API 不再被需要，其通信直接发生在两个组件之间
端口（Port）:
组件的输入输出接口
组件（Component）:
OpenMax IL的单元，每一个组件实现一种功能。组件按照端口可分类为：
Source（只有一个输出端口）、
Sink（只有一个输入端口）、
Host组件（一个输入端口和一个输出端口），
Accelerator组件，它具有一个输入端口，调用了硬件的编解码器，加速主要体现在这个环节上。组件间的tunnel通道也是通过将一个组件的输出端口连接到另一个组件的输入端口来建立的。
隧道化（Tunneled）：
让两个组件直接连接的方式。通过隧道化可以将不同的组件的一个输入端口和一个输出端口连接到一起，在这种情况下，两个组件的处理过程合并，共同处理。尤其对于单输入和单输出的组件，两个组件将作为类似一个使用

OpenMAX IL 定义了三种通信方式：
1）Non-tunneled：
用于client 与 component 之间交换data buffers；
2）Tunneling：
用于组件之间互相交换data buffers的标准机制；
3）Proprietary communication：
用于两个组件之间直接数据交换的专属机制，并且可以作为tunneling的备选机制。
Component profiles：OpenMAX IL 组件的功能被分成两种profiles
1、base profiles
2、 interop profiles。

Component states

1、无效的数据会导致组件进入invalid状态；
2、在IDEL状态，组件应该获取了所有所需的静态资源；
3、executing状态:
组件不再接收buffer，而是进行处理数据；
4、paused状态:
组件维护一个buffer context，且不再处理数据和交换buffers；

Component architecture

Client与component之间的通信：
1、client通过OMX_EmptyThisBuffer来调用component的输入端口；
2、client通过OMX_FillThisBuffer来调用component的输出端口。

Tunneled buffer allocation
对于tunnel的两个端口，
supplier端口会调用UseBuffer函数来要求邻接的端口来处理buffers；
non-supplier端口会接受UseBuffer调用。
Component需要遵循以下规则：
1、supplier端口都要提供buffers；
2、在端口上可靠的传输buffer配置；
3、通过OMX_EmptyThisBuffer调用将buffer从输出端口传递到另一component的输入端口；
4、通过OMX_Fill_This_Buffer调用将buffer从输入端口返回给component的输出端口。

Buffer payload
一般情况下，buffer中可用数据的起始点和范围由定义在buffer头中的 pBuffer，nOffset 和 nFilledLen 三个参数来决定:
pBuffer: 指向buffer的起始地址；
nOffset: 代表了buffer起始地址与实际可用数据地址之间的偏移量；
nFilledLen: 表示buffer中连续可用的数据的大小。
因此，buffer中可用数据的起始范围分别为:
pBuffer + nOffset 和
pBuffer + nOffset + nFilledLen

在buffer中数据的存放方式有三种：
1、buffer要么填满，要么部分填满；
2、buffer中存放的压缩数据都是以完整的帧为单位的；
3、buffer中只存放一帧的压缩数据。
前两种都要求解码器在解码的之前对每帧数据进行解析，第三种情况则不需要解析。

Buffer flags and timestamps
Buffer flags 是存放在buffer中的表示特定属性的数据，比如数据流结束；
Timestamps 是以微秒为单位的存放在buffer中的数据，用来在播放时确定各buffer的播放时刻。