openMAX IL介绍

OpenMAX Integration Layer介绍

单位名称：无锡东集电子有限责任公司

部门名称：SOC系统研发部关键技术组

报告人：陈小晓

日期：2010-3-23

目录

1. OpenMAX IL的初步认识 (3)

1.1 OpenMAX overview (3)

1.2 OpenMAX IL introduction (3)

1.2 OpenMAX IL features (3)

1.3 OpenMAX IL design philosophy (3)

2. OpenMAX IL的分析 (4)

2.1 Key definitions (4)

2.2 The interface (4)

2.2.1 core (4)

2.2.2 component (6)

2.3 Ports (8)

2.4 Communication types (8)

2.5 Port Reconnection (9)

2.6 Component States (11)

2.7 Component Architecture (12)

2.8 Tunneled Buffer Allocation (12)

2.9 Queues and Flush (14)

2.10 Marking Buffers (14)

2.11 Events and Callbacks (15)

2.12 Buffer Payload (15)

2.13 Buffer Flags and Timestamps (17)

2.14 Synchronization (17)

2.15 Rate Control (18)

1. OpenMAX IL的初步认识

1.1 OpenMAX overview

OpenMAX是由Khronos组织所发布的一种开放标准，用来实现高效能的多媒体加速。为了因应目前众多的平台与开发装置，在media上也需要制定开放标准的APIs，OpenMAX是一个免费的跨平台API，适合用在multimedia components 的开发，特色是可以在不同的平台上开发整合。

OpenMAX可以广泛运用在如MPEG-4、H.264、音频或影像的编解码器、2D 或3D图像的视讯编解码器中的多媒体处理进行标准化。OpenMAX API会根据处理器的演进来扩充数据库，无须考虑底层的硬件架构，以求更有效的发挥更快的硬件加速效能，并加速跨OS和silicon平台的多媒体components的开发、整合。

1.2 OpenMAX IL introduction

OpenMAX IL 是由Khronos 组织发起并起草的一个公开的技术标准，2005 年12月发布第一个版本，目前的最新版本是version 1.1。该标准针对嵌入式设备或/和移动设备的多媒体软件架构，在架构底层上为多媒体的codecs和数据处理定义了一套统一的编程接口(OpenMAX IL API)。IL层接口抽象了系统硬件和软件的架构，每个组件和相关的转换都被封装成一个组件接口，为用户屏蔽了底层的细节，OpenMAX IL API允许用户加载、控制、连接和卸载组件。因此，多媒体应用程序和多媒体框架通过OpenMAX IL 可以以一种统一的方式来使用codecs和其他多媒体数据处理功能，具有了跨越软硬件平台的移植性。

1.2 OpenMAX IL features

IL层集合了一些特征，致力于解决在众多不同的媒体系统间的移植性问题，这些特征包括：

●灵活的基于组件的API内核；

●容易插进新的组件；

●通过Khronos Group和各个vendors保持目标域（音频、视频和图像）可

扩展性；

●容易实现客户端和组件、以及组件之间的通信；

1.3 OpenMAX IL design philosophy

如上所述，openMax IL API的关键点是媒体组件的可移植性，但现有的设备和媒体解决方案的多样性，使得openMax IL API把更高一层的媒体软件栈（media software stack）作为初始用户，对于许多操作系统，这个媒体软件栈理解为现有的媒体框架或者是一些多媒体中间件。

另一个关键目标是OpenMAX AL API，它标准化了一个更高层的应用接口。一些系统中已经存在一个用户层的媒体框架，但对于那些没有多媒体中间件的系统则由OpenMAX AL去填补。OpenMAX AL设计用于顺应OpenMAX IL的执行，IL很容易与AL层衔接。因此，大多数openMax IL API接口能很容易的插入许多软件栈和多媒体解决方案。

API的设计是致力于兼容尽可能多地操作系统，因而设计使用高同步通信机制，即允许在多处理单元或专门的硬件上处理另一个线程。另外，硬件加速组件具有通过通道同另一个组件直接通信的能力，使得执行架构更灵活和高效。2. OpenMAX IL的分析

2.1Key definitions

OpenMAX IL component：封装了目标系统所需功能的组件，IL封装为函数提供了一个标准接口。在IL层，component代表各个功能模块，可以是sources, sinks, codecs, filters, splitters, mixers等等。

OpenMAX IL core：相关平台的代码，具有将OpenMAX IL component载入主存储器的功能，当应用程序不再需要某组件时，IL core将负责把该组件从存储器卸去。一般来说，组件一旦载入存储器，IL core将不在参与应用程序与组件之间的通信。

IL client：访问IL core或IL component的软件层，可能是位于GUI应用程序的下层，如GStreamer。IL client是一个典型的功能块，如filter graph multimedia framework, OpenMAX AL, 或application。IL client与OpenMAX IL core进行交互，利用IL core 加载和卸载组件、在组件间建立直接通信以及获得组件方法的入口。

Tunnels/Tunneling：直接在两个IL component间操作的标准的数据隧道。

2.2The interface

OpenMAX IL API是一个基于组件的媒体API，由两部分组成：内核API和组件API。

2.2.1 core

OpenMAX IL API core的作用是用来动态地装载和卸载component，并且用来建立component之间的通信的。组件一旦加载，则API允许用户直接与组件进行通信。另外，内核允许用户在两个组件之间建立一个communication tunnel，一旦建立，将不再使用内核API，通信直接在组件间进行。

Core的实现机制：

1. Core的初始化过程

Core 的初始化过程由函数OMX_Init()完成，主要任务就是获得一份所有已经向系统注册的component的名单。Core用一个数组来维护所有的component装载器和其可以装载的component信息。这种实现机制提供了很大程度的灵活性，OpenMAX IL开发者可以自己编写component装载器，以便core可以按照特定的方式装载component。

2. 装载Component

初始化之后，core就可以按照IL client的要求动态地装载component了。因为是按名字来装载component，因此要求component向系统注册时，必须确保component名字的唯一性。装载component的工作由OMX_GetHandle函数完成。例如：启用装载器，按指定名字查找component；如果找到，则分配内存空间，将component装载到内存，调用component的构造函数，设置component的参数和回调函数等；如果没找到，则返回失败。当OMX_GetHandle 函数成功返回后，一个新的component实例就被成功创建了。但是IL client还需进一步对component 进行参数配置，才能正式开始使用这个component实例。

3. 设置component之间的Tunneled连接方式

Component之间可以以tunneled的方式进行数据交换。Tunneled的components 构成一个component链条，IL client只需要驱动这个链条上的第一个component就可以使整个链条上components开始有条不紊地工作了。

建立component之间tunneled连接方式由OMX_SetupTunnel函数完成，主要处理过程如下：

①判断component要tunneled的port是否满足tunneled的条件，主要指port处理的数据是否属于同一个domain内（指audio、video等）和数据的格式是否相同；

②协商确定由哪个port作为buffer的提供者。

2.2.2 component

在IL层，component代表各个功能模块，可以是sources, sinks, codecs, filters, splitters, mixers等等。一个组件通过一系列相关的数据结构和接口可以设置或检索各个参数，这些参数包括相的组件操作数据或是组件的实际状态。

如图1所示，每个函数可能来自不同的提供商，因此每个函数可能有不同的搭建和拆卸要求以及不同的配置和数据传送的方法。IL API提供一种途径，将这些函数单独地或者以逻辑组的方式集成到组件中，API提供一个标准的协议，使得这些来自不同供应商的组件能够交换数据以及可交替使用。

图1 Possible Partitions for an OpenMAX IL Implementation Component 的实现机制：

1. Component的继承关系

OpenMAX IL是用C语言来实现的，但是采用了面向对象的思想。定义了一

个基类omx_base_component，实现了component的基本功能，其他所有component 必须从omx_base_component继承，可以覆盖其中的方法。

2. component的数据结构

按照OpenMAX IL规范，component用OMX_COMPONENTTYPE结构来描述，里边记录了component的属性和函数入口。其中pComponentPrivate字段记录了指向component的私有数据结构的指针。Component的私有数据结构记录了component在内部处理过程中需要的信息，这个数据结构是内部使用，OpenMAX IL client无法访问到的。

主要有以下几种：

●omx_base_component_PrivateType

记录了例如状态、端口、消息队列、数据处理线程号等一些component基本信息。

●omx_base_filter_PrivateType

继承omx_base_component_PrivateType，并增加了数据处理回调函数指针等信息。

●omx_base_sink_PrivateType

继承omx_base_component_PrivateType，并增加了数据处理回调函数指针等信息。

●omx_base_PortType

是omx_base_component_PrivateType的组成部分。记录了component的port的基本信息，比如port类型、状态等。

3. component的工作方式

OpenMAX IL client与component的通信有两种类型：一种是发送控制命令；另一种是发送数据处理消息。因此，为了保证数据处理过程独立，Component

会创建两个线程：一个是事件处理线程，构造此线程时Constructor中创建，用来处理用户发给component事件，比如：

●OMX_CommandStateSet ：改变component 状态

●OMX_CommandFlush ：清空component 的数据队列

●OMX_CommandPortDisable ：禁止component 的特定port

●OMX_CommandPortEnable ：打开Component 的特定port

●OMX_CommandMarkBuffer ：申请用于数据交换的buffer

另一个是数据处理线程，当component创建成功后，数据处理线程由StateLoaded状态转换到StateIdle状态时创建，用来对component的数据队列进行管理。例如，对于一个codec component来说，主要完成如下功能：

①从input port的数据队列取得一个输入buffer，如果没有取到则等待，直到成功；

②从output port的数据队列取得一个输出buffer，如果没有取到则等待，直到成功；

③调用BufferMgmtCallback 函数进行解码；

④解码完成后，触发input port和output port的ReturnBufferFunction函数，然后进入等待状态，等待下一轮处理过程。

OpenMAX IL client与component两种通信的过程如下：

●发送控制命令

OpenMAX IL client通过调用OMX_SendCommand，来触发messageSem信号量，通知事件处理线程。

●发送数据处理消息

OpenMAX IL client通过调用OMX_ EmptyThisBuff和OMX_ FillThisBuff来触发bMgmtSem信号量，通知数据处理线程，完成component的数据处理功能。Input ports are always called from the IL client with OMX_EmptyThisBuffer ，Output ports are always called from the IL client with OMX_FillThisBuffer。

2.3Ports

组件间的数据进出由叫做ports的接口进行传输，ports不仅代表组件间的数据联系，还代表需要维持这个联系的buffers。用户可以经过input ports发送数据到组件，或经过output ports接收数据。将一个组件的output port与另一个组件类型相似的input port相连，在组件间建立一个communication tunnel。

OpenMAX IL定义的ports的类型相当于port上可能传送的数据类型：audio, video, and image data ports, and other ports。每个port可以定义为input或output，这个取决于它是销毁还是产生buffers，input port是销毁buffers，output port是产生buffers。

2.4Communication types

三种通信类型：

Non-tunneled communication：It defines a mechanism for exchanging data buffers between the IL client and a component.

tunneled communication：It defines a standard mechanism for components to exchange data buffers directly with each other in a standard way.

Proprietary communication：It describes a proprietary mechanism for direct

data communications between two components and may be used as an alternative when a tunneling request is made, provided both components are capable of

doing so.

图2 Three types of communication

值得注意的是，component可以同时与IL client和tunneling component进行通信，即tunneled case和non-tunneled case可同时存在于一个component上。2.5 Port Reconnection

端口重接即在不拆卸周围components的情况下，一个tunneled component可以被另一个tunneled component所替代。

如图3所示，B2要替代B1，过程如下：首先A的输出端口和B的输入端口要断开（port shall first be disabled with the port disable command），一旦所有分配的buffers都返回到它们的提供者并释放时，A的输出端口就与B2的输入端口连接。B2的输出端口与C的输入端口连接同理（Then all ports may be given the enable command）。

图3 Port Reconnection

图4中，A和C都有一个未连接的端口，IL client首先在A和B2、B2和C 间建立tunnel，然后将两tunnels间的端口连上。假设这些都是audio components，则C可能是B1和B2的混合数据，因此下一步则将B1从A、C间断开。

图4Reconnecting Components

2.6 Component States

图5 Component States

如图5所示，每个组件都会经历不同的状态。每个组件一开始都被认为是unloaded state，需要向core发出一个请求使其进入到loaded state。当遇到无效

数据时，component 将会进入invalid state。退出invalid state的唯一途径就是unload and reload the component。

一般来说，组件在idle state时应该要拥有所需的所有的操作资源。若某一状态

要求分配所有的静态资源时，那过渡到idle state将可能失败。

The IDLE state indicates that the component has all of its needed static resources but is not processing data.

The EXECUTING state indicates that the component is pending reception of buffers to process data and will make required callbacks.

The PAUSED state maintains a context of buffer execution with the component without processing data or exchanging buffers.

Transitioning from PAUSED to EXECUTING enables buffer processing to resume where the component left off. Transitioning from EXECUTING or PAUSED to IDLE will cause the context in which buffers were processed to be lost, which requires the start of a stream to be reintroduced. Transitioning from IDLE to

LOADED will cause operational resources such as communication buffers to be lost.

2.7 Component Architecture

图6 描述了component architecture.注意component 只有一个入口指针，但可能有多个outgoing calls，这取决于component有多少个ports。每个component将会向特定的IL client请求event handler。每个port也会make calls (or callbacks)到一个特定的external function。buffer headers的指针队列也与每个port相联系。这些buffer headers指向具体的buffers。每个port应该支持callbacks到IL client。对于interop profile component，应该支持同其它组件的ports通信。

图6 OpenMAX IL API Component Architecture

2.8 Tunneled Buffer Allocation

这部分详述下tunneling components的buffer分配。一般情况下，一个隧道的supplier port也是分配buffer的端口，但在适当的情况下，一个tunneling component 可以从一个端口重复利用buffer给另一个，避免memory的复制，优化memory的使用。

图7 Example of Buffer Allocation and Sharing Relationships

supplier port：向它相邻的port请求UseBuffer的端口称为supplier port。提供buffer的supplier port不一定需要分配它的buffers，它可以重复利用同一个component上的另一个端口上的buffer。图中的a和c都是supplier port。

non-supplier port：接收到它相邻port的UseBuffer请求的端口称为non-supplier port，如图中的b和d。

tunneling port：与其相邻port共享一个tunnel的端口称为tunneling port。如图中的a和b都是彼此的tunneling port。

allocator port：分配自己的buffers的supplier port。图7中只有a是allocator port。tunneling component：至少使用一个tunnel。

一个端口的buffer请求包括buffer数量的请求和每个buffer大小的请求。多个系列的缓冲区需求量的最大值被定义为任一系列中被托管的缓冲区的最大量和任一系列中被托管的最大容量之和。

无论组件是否分享buffer，它都应该满足以下条件：

●它的所有supplier ports都要能提供buffers；

●正确向其它端口传达buffer请求；

●通过一个OMX_EmptyThisBuffer call将buffer从一个output port传到一个

input port；

●通过一个OMX_FillThisBuffer call将buffer从一个input port传到一个output

port；

tunneling components setup

要建立tunneling components，IL client需做如下操作：

1．装载所有的tunneling components，在这些components建立tunnels。

2．将所有tunneling components从loaded state转换到idle state。

值得注意的是，如果当一些components正在共享buffers，IL client不能执行上述操作时，则tunneling component可能由于组件间的依赖性而无法转换到idle。Component Transition from Loaded to Idle State

由loaded到idle时，non-sharing component的每个supplier port需做如下事情：

1.通过OMX_GetParameter call确定它的tunneled port的buffer请求。

2.根据tunneled port的请求和自身请求的最大量来分配buffers。

3.向它的tunneled port发出OMX_UseBuffer请求。

2.9 Queues and Flush

当buffers已不再使用时，命令队列会要求component释放这些buffers，若使用的是non-tunneled communication则将buffers返回给IL client，若使用tunneled communication则返回给tunneled output port。

举个例子，假设一个组件的output port正使用IL client分配的buffers，IL client 在发送释放命令（flush command）前给组件发送了五个buffers，发出释放命令后，组件将未使用的buffers返回给IL client，并触发event handler来通知IL client。若有两个buffers已经正在使用，则组件将另外三个未使用的buffers返回并产生一个事件，IL client 在对component反初始化之前需要等待这个事件。当IL client

决定停止components的执行并处理掉components，它需要将components切换到idle状态，这样所有的buffers将返回到它们的提供者。

2.10 Marking Buffers

当遇到一个带标记的buffer时，IL client也可以触发产生事件。buffer可以在buffer header被标记。标记在OpenMAX IL components链中传送。遇到marked buffer时，这个标记可以使组件向IL client发送一个事件。

如下图所示，IL client发送命令标记一个buffer，标记传递到下一个buffer B1，组件B处理B1 buffer中除了标记外的数据然后将结果传给B2 buffer，当组件C接收被标记的B2 buffer，C不会触发event handler直到它处理B2 buffer。

图8 Marking Buffers

2.11 Events and Callbacks

通过组件把6类事件发送到IL client：

●Error events可以枚举出来并可以在任何时间发生。

●命令成功执行时可以触发Command complete notification events。

●当组件检测到一个marked buffer时则触发Marked buffer事件。

●当组件改变端口设置时产生port settings changed notification event。

●在数据流结束时触发buffer flag event。

●在组件得到所需资源后产生resources acquired event。

2.12 Buffer Payload

端口配置可以定义在一个组件端口上数据传输的形式，但却不能限定在buffer内数据的存在形式。

数据在buffer内如何存储大致有三种方式，每种方式都有自己的优势。在这三种方式中，buffer内的有效数据范围和位置被限制在buffer header的三个参数（pBuffer, nOffset, 和nFilledLen）之中，pBuffer参数指向buffer的起始处, nOffset 参数则指示了buffer起始处到有效数据起始处的字节数, nFilledLen参数具体指出了buffer中有效数据所占的字节数。因此buffer内的有效数据的范围从pBuffer + nOffset 到pBuffer + nOffset + nFilledLen。

下面的例子是用来说明在编解码时进出组件时buffer内数据压缩的情况，在任何情况下，buffer在没有特殊要求时都只为数据提供传输机制，而具体的需求则由端口配置参数来解决。

buffer的阴影部分代表数据区域，白色部分则是空白区域。

如图9，方式1：每个buffer内装入全部或部分压缩数据帧，帧标号从f1到fn。

图9 Case 1—Each Buffer Filled In Whole or In Part 方法1指出了在重复解码时的优势。buffer可以适应多帧结构，减少解码时

大量数据对buffer的执行次数。然而，这种方式可能需要decoder component在解

码帧时能分析数据，同时要求decoder component有建立帧的buffer，用来存放被解析的数据或保持下个buffer所需的部分帧。

如图10，方式2：每个buffer只存放压缩数据完整帧(一个或多个帧)。

图10 Case 2—Each Buffer Filled with Only Complete Frames of Data

方式2不同于方式1之处是在于方式2首先需要解析压缩数据这样才能把完整的帧放入buffer中。方式2中可能也需要decoder component解析数据，这种方式可能不需要额外的buffer来解析方式1中所需的帧。

如图11，方式3：每个缓冲区都只被一个压缩数据帧填充。

图11 Case 3—Each Buffer Filled with Only One Frame of Compressed Data 方式3的好处是decoder component不需要解析数据，而在source component中解析。但是这种方式在数据传输过程中会造成瓶颈问题（阻塞），每次数据传输时限制在一帧内。根据执行过程，每帧的执行会比从buffer内解析帧在性能上产生更大的影响。

从最低需求来讲，方式1需要一个decoder component或encoder component来支持运行，从定义上说，如果一个codec component可以支持方式1，那么也就能支持方式2和方式3，但这必须是压缩格式允许字节对齐的帧边界。有时方式2或方式3可能毫无意义，比如说，为RTP-payload格式配置一个Adaptive Multi-Rate (AMR) codec、高带宽模式时，被这种格式限制的非字节对齐的帧都不适合在此三种方式下定义的字节对齐帧边界。向buffer填充压缩数据要输入到解码器或从编码器输出时，当帧数据不是字节对齐格式时就会出现帧填充受限的问题。

2.13 Buffer Flags and Timestamps

一旦时间戳与一个buffer相关联，不需要component为速率控制或同步化来

改变时间戳，这些都由clock component来处理完成。

缓冲区数据（即标志和时间戳）适用于[第一页]缓冲区新的逻辑单元。因此，鉴于在缓冲区多个逻辑单元的存在，元数据应用于缓冲区中最早发生边界反应的逻辑单元。[随后发生的缓冲区逻辑单元没有明确的标志和时间戳。如果每个逻辑单元都要求明确的标志和时间戳，那么每个缓冲区都应该包括一个或者更少的逻辑单元]。除非另有说明，在一个标志的定义（例如标志定义，），一个组件，如果它接受一个带有标志位或者时间戳的一个逻辑输入单元，它必须把元数据复制给所有输入单元能够起到作用的输出单元。

2.14Synchronization

同步化是通过使用clock component上的同步端口来实现的。这些端口和clock component在“另一个”域里面定义，遵守相同的协议并且调用管理数据端口。clock component可以控制媒体时钟，这个时钟可以跟踪基于音频和视频参考时钟的媒体流的位置。clock component通过同步端口把包含时间信息的buffer（媒体时钟更新指示，媒体时钟当前的位置，规模和状态指示）输出到client components。当时间戳和媒体时钟一致时，client components会通过请求clock component发送时间戳来记录下操作的执行时间（例如一个视频帧的演示）。在这种情况下，client components在收到其同步端口的回应时执行操作。图12描述了在一个示例配置components中的时间流和数据缓冲流。

图12 Flow of Time and Data Buffers

2.15Rate Control

clock component还实现了通过暴露一系列的配置设置来实现所有的速率控制，以此来控制它的媒体时钟的。IL client通过改变媒体时钟的规模因素（有效的改变速率和媒体时钟推进的方向），来实现播放，快进，回退，暂停以及放慢等动作技术模式。IL client可能也可以通过这些配置来开启和停止时钟进以达到改变媒体控制时钟的状态的目的。clock component通过所有同步端口上所发送的带有规模和状态的媒体时间更新来告知其客户端媒体时钟的变化。虽然component不会通过改变buffer timestamp来回应这个规模的变化，但是component 可以改变它的处理过程。比如，audio component在特技模式或完全停止输出时改变正确音频的比例和强度。