OpenMax

OpenMAX (Open Media Acceleration) is a royalty-free, cross-platform set of C-language programming interfaces that provides abstractions for routines especially useful for audio, video, and still images. It's intended for devices that process large amounts of multimedia data in predictable ways.

OpenMAX provides three layers of interfaces: 

                 Application Layer (AL)

                 Integration Layer (IL) 

                 Development Layer (DL). 

OpenMAX is managed by the non-profit technology consortium Khronos Group.

1) OpenMax Al interface between Applications like Media Player and Media framework.
2) OpenMax IL interface between Media framework and Codec’s.
3) OpenMax DL interface between Codec’s and Hardware.

OpenMax IL:
The OpenMax IL (Integration Layer) API defines a standardized media component interface to enable developers and platform providers to integrate and communicate with multimedia codec’s implemented in hardware or software”.

The Open MAX IL API allows the user to load, control, connect, and unload the individual components.

OpenMax IL Features:

• A flexible component-based API core 
• Ability to easily plug in new codec’s 
• Capable of being implemented as either static or dynamic libraries 
• Ease of communication between the client and the codec’s and between codec’s themselves

OpenMax IL Use:

           Open MAX IL Components are used like any typical Multimedia features such as playing video, recording audio and capturing images. For example, two Open MAX IL Components, decoder and render, are loaded by Open MAX IL and communicate with each other for decoding and rendering.

In the OpenMax IL, components represent individual blocks of functionality. Components can be sources, sinks, codec’s, filters, splitters, mixers, or any other data operator.

• An IL client always communicates with a component via the IL core.
• The IL client uses the Open MAX core for loading and unloading components, setting up direct communication between two Open MAX components, and accessing the component’s method functions. 
• IL Client: MDF (Multimedia Device Framework) plays the role of the Open MAX IL client within the Open MAX IL architecture. 
• IL core: Open MAX IL Core is used to load and unload the Open MAX IL Components and to facilitate communication between them. Open MAX IL Core is a platform-specific entity which is used to load and unload Open MAX IL Components, and to facilitate communication between them.

OMX Components handle data communication through ports. A port is an interface that represents: the connection to other components, the type of streamed data and the buffers needed to maintain such connection. In Open MAX a buffer is an entity that holds the information and represents the minimum unit of data that can be exchanged between two OMX Components. One OMX Component sends/receives buffers to/from other OMX Components through output/input ports.

OpenMax IL Profiles:Base Profile: support non tunneled communication

Interop Profile: support non tunneled communication and tunneled communication.

Non tunneled communication: exchanging data buffers b/w IL client and component.

Tunneled communication: components to exchange data buffers directly with each other.

Proprietary Communication:Third party based

OpenMax IL Component States:

• WAIT FOR RESOURCES 
• IDLE 
• EXECUTING 
• PAUSED 
• INVALID 
• LOADED 
• UNLOADED

Non Tunnel Call Sequences:

1) Non tunnel initialization:

• IL client shall call OMX_getHandle function, which activates actual component creation by core. 
• The core passes IL client callback functions to the component by means of the Set Callbacks. 
• If successful, OMX will be in OMX_StateLoaded state. 
• IL Client configures the component and its ports using OMX_SetParameters. 
• After configuration, It can request the component to make the state transition to OMX_StateIdle. After that only client can set up the buffers to component to use all of its ports. 
• IL Client use OMX_AllocateBuffer and OMX_UseBuffer to set up buffers. 
• If OMX_UseBuffer is used, the IL client shall have allocated buffer and passed it to component. 
• IL client may ask component to allocate buffer and buffer header using OMX_AllocateBuffer. 

2) Non tunnel Data Flow:

     IL Client entirely responsible for moving data buffers among components if data tunneling is not used.

• IL Client delivers data buffers to component using OMX_EmptyThisBuffer call. 
• As soon as one buffer is available from the component output port, component shall send OMX_FillBufferDone call back. 

3) Non tunneled De Initialization:

• First switch the components to the OMX_StateIdle state so that all buffers are returned to their suppliers. 
• The component to change its state to OMX_StateLoaded.                                                                    The IL client shall free all of the component’s buffers by calling OMX_FreeBuffer for each buffer.                                                                                                                            OMX_FreeBuffer : free port buffer headers 
• When all of the buffers have been freed, the component shall complete the state transition. 
• The IL client calls the OMX_FreeHandle function that disposes of the component.