OMX1.

1 Current Design &

Implementation

-Rabbani Patan
-May 28 2008

Page 1 For TI Internal Use Only

Tmpl: WTSD_Slide_Tmpl_95_00_02_02954, Revision 1.2, 08 May 2007
 General OMX Architecture

Page 2 For TI Internal Use Only

Tmpl: WTSD_Slide_Tmpl_95_00_02_02954, Revision 1.2, 08 May 2007
 OMX1.1 – TI Design

Khronos Standard OMX1.1 Interface IL Client

OMX-base is a complete OMX1.1

component (except Component
Init/Deinit – which are in derived
component).
Run-loop (Command & data
operations) is implemented in OMX-
base.
Derived component can configure
base to run in Application context
or in a separate task
OMX Base OMX-base is generic in terms of
number of ports. It handles
Derived component can override or
tunnelling and other related
inherit desired base OMX interface
operations per port basis
Derived component, minimally,
invokes base init and deinit &
optionally base OMX interfaces if
derived

Base provides an hook related to

ETB,FTB and Send Command(); Derived component can
which will be invoked in base allocate/destroy resources,
context and a hook (set by base) to process data & release them
return processed buffers (OMX) Derived after processing
Component Typically, Get/Set parameter &
Get/Set Config will needs to be
derived

Page 3 For TI Internal Use Only

Tmpl: WTSD_Slide_Tmpl_95_00_02_02954, Revision 1.2, 08 May 2007
 OMX1.1 – TI Design

• OMX-Base is domain-independent
• Bulk of OMX protocols & Interaction implementation in OMX-Base
• Can be Configured to run in IL client task or a separate task context
• Processing is triggered by Events if base runs in a Separate task or by functional
interface if base runs in IL client task

• OMX-Base Scope
– Tunneling
– State Transition
– Port Enable/Disable
– Port Flush
– Marking Buffers

• OMX-Base Not in Scope

– Data Process
– Parameters and Configurations
– Any Resource Allocation(SN init/..)

Page 4 For TI Internal Use Only

Tmpl: WTSD_Slide_Tmpl_95_00_02_02954, Revision 1.2, 08 May 2007
 Base  Derived Interface
• Hooks from Base (invokes) to Derived (implements):
• CommandNotify(hComp, Cmd, nParam, pCmdData);
– Will be called in base context, after it has done the typical allocation of resources or
corresponding omx command operation
– Derived component can further process the command if required and must complete all
operations on return
• DataNotify(hComp, unPortIndx, Buffer);
– Base component does not have anything much to do here except some error checking or
omx specific operations
• Callbacks from Derived to base:
• ReturnEventNotify(hComp, OMX_EventType, EventData1, EventData2, pEventData)
– Asynchronous API call from derived component to base component. Based on Derived-
>Base events, but taking into account full OMX information flexibility.
• ReturnDataNotify(hComp, unPortIndx, pBuffer)
• Any New OMX Component can be added by:
- Invoking Base Component Init(Along with the number of ports) during component init
- can Override desired OMX API’s if specific operations are required
- Implement DataNotify() & CommandNotify() interfaces which will be invoked from base
context
– Return buffers via base ReturnDataNotify() hook
– Clean up base instance during Component deinit

Page 5 For TI Internal Use Only

Tmpl: WTSD_Slide_Tmpl_95_00_02_02954, Revision 1.2, 08 May 2007
 Non-Tunneled Initialization

Page 6 For TI Internal Use Only

Tmpl: WTSD_Slide_Tmpl_95_00_02_02954, Revision 1.2, 08 May 2007
 Tunneled Initialization

Page 7 For TI Internal Use Only

Tmpl: WTSD_Slide_Tmpl_95_00_02_02954, Revision 1.2, 08 May 2007
 State Transition to Idle in Tunneled Comps

Page 8 For TI Internal Use Only

Tmpl: WTSD_Slide_Tmpl_95_00_02_02954, Revision 1.2, 08 May 2007