在这里讲的是Opencore和OMX 的调用sequence，基本来说是根据OMX的API过程来实现的，属于将OMX集成到Opencore的原理 部分
对于omx IL的API，大家可以参考http://omxil.sourceforge.net/docs/modules.html

1 、将一个 CODEC 集成到 PV Opencore multimedia framewok 下的方式主要有三种：作为一个 compressed MIO(media I/O) component ，或者作为个 node ，或者作为一个 Openmax component 集成到 Opencore framework 下的 Openmax codecs nodes 。对于各种 codec 尤其是那些包含了 HW acceleratin 的 codec 来说， Openmax IL interface 是最直接的和有效的集成方式，为上层提供统一的接口。

2 、具体 omx component 和 omxcore 的实现在 developer 文档在讨论，在这里只讨论 Opencore 和 omx core/component 的交互作用过程，即 call sequence 。 PVMF 对 omx 的调用大概可以用下面的图来描述：

所有这些过程都是通过 PVMF 来控制的，由 PVMF 发出 command 来控制 Opencore component 的状态转换。

3 、 Opencore 和 OMX core/component 的 interaction 过程分为下面几个过程，所有这些过程都是根据 API 的典型 sequence 来实现的。

3.1 、 PVMF 对 OMX 的调用首先是从对 OMX core 的初始化开始的：

＠ PVMF 首先调用 OMX_Init 来初始化 omx core

＠ 然后 PVMF 会向 omx core 请求所有他所拥有的 component ，并根据获得的 component name ，来请求有效 component 的 role, 然后对有效的组件及其 role 建立一个 registry 。

OMX_Init() 用来对 omx core 进行初始化，它必须是进入 omx 前调用的第一个函数，而且在调用 deinit 之前只能被调用一次。

OMX_ComponentNameEnum() 实质上就是检测出 system run － time 时所有的有效 component 。

OMX_GetRolesOfComponent() 实际上根据 component name 来取得 component 所支持的 role 的 number 。

具体流程如下：

3.2 、完成对 omx core 的初始化之后就要根据开始获得的 comonent name ，对 omx component 进行初始化，并且列举出相应 component 的 capabilities 以及获得 port 目录。 PVMF 的工作流程如下：

＠根据 component name 和 role 使用 OMX_GetHandle 来初始化指定的 omx component 。

＠使用所有权 index“PV_OMX_CAPABILITY_TYPE_INDEX” 根据 OMX_GetParameter() 取得 component 的 capabilities ，根据 capabilities 就可以知道 component 是否支持部分祯，是否支持 UseBuffer 或者 AllocateBuffer 等等内容。如果 OMX componentd 对所有权 index 返回“ OMX_ErrorUnsupportedIndex” 或者其他错误信息， PVMF 必须为 component capabilities 指定一组默认的数据 。

＠使用 OMX_GetParameter 来获得 Audio/Video component 的有效 port 数［ input/output port ］，然后遍历所有的输入输出端口，来获得输入输出端口的索引。

PVMF 对“ PV_OMX_COMPONENT_CAPABILITY_TYPE_INDEX” index 的定义如下：

#define PV_OMX_COMPONENT_CAPABILITY_TYPE_INDEX 0xFF7A347

实际上所谓的 index 包括后面获取 Audio/Video component port 数使用的“ OMX_IndexAudioInit” 和“ OMX_IndexAudioInit” index 都是传到 OMX_GetParameter() 函数的第一个参数。

PVMF 需要从 component 取得的 capabilities 被包裹在下面的 structure 中，需要 component 对这个 structure 进行赋值：

typedef struct PV_OMXComponentCapabilityFlagsType

{

OMX_BOOL ilsOMXComponentMultiThreaded;

OMX_BOOL iOMXComponentSupportsExternalOutputBufferAlloc;

OMX_BOOL iOMXComponentSupportsExtrenalInputBufferAlloc;

OMX_BOOL iOMXComponentSupportsMovableInputBuffers;

OMX_BOOL iOMXComponentSupportsPartialFrames;

OMX_BOOL iOMXComponentUsesNALStartCode;

OMX_BOOL iOMXComponentCanHandleIncompleteFrames;

OMX_BOOL iOMXComponentUsesFullAVCFrames;

}

iIsOMXComponentMultiThread 默认值为 OMX_TRUE, 虽然 OMX component 一般运行在一个独立的线程，但是通过同步调用等方式也可以使其和 PVMF 运行在一个线程。

iOMXComponentSupportExternalOutput/inputBufferAlloc 的默认值为 OMX_TRUE ， OMX spec 要求 OMX component 必须支持在外部分配的额外 buffer( 比如 OMX_UseBuffer 调用外部的 buffer) ，如果 Component 不支持这个，它必须将其值设为 OMX_FALSE ，并且和 PVMF 进行协商，从而使 PVMF 使用 OMX_AllocateBuffer 。

IOMXComponentSupportsMovableInputBuffers 这个值默认也是 OMX_TRUE, 他类似于一种动态存储的概念，就是对于 external allocated input buffer ，可以将其的 omx 头部和实际数据进行分离，由 omx 头部的指针来指定实际数据的位置，如果这个指针可变，则 component 的可以访问不同的数据区域。如果 omx component 要求其起 header 总是指向同一个数据区域，则这个值必须设置 成 false 。

iOMXComponentSupportsPartialFrames 这个值的默认值为 OMX_TRUE, 根其字面意义一样，就是 component 是否支持部分桢，当桢 /NAL 的大小大于 buffer 的大小的时候，必须把桢 /NAL 分割成几块， PVMF 会在每个桢的结束位添加“ OMX_BUFFERFLAG_ENDOFFRAME”, 从而使桢的组装变得很简单，如果 component 需要由 PVMF 完成对祯 /NAL 的组装并提供给 component 完整的桢 /NAL, 则必须设置这个值为 false ，不支持部分桢会对性能造成很大的影响。

iOMXComponentUsesNALStartCode 这个值默认是 OMX_false ，这个标志位主要影响到 H264 的解码，主要是设计到 H264 NAL 格式的问题，就是说 PVMF 能够重构 H264 的 NAL ，不需要再让 omx component 来解些比特流，如果 OMX H264 component 要求解些比特流，需要提供 0x0001 NAL start codes ，则这个值必须设置为 true 。

iOMXComponentCanHandleIncompleteFrames 这个值默认为 OMX_TRUE ，与对 partial 的支持不同，不完整的桢的是指由于丢包或其他原因导致的桢 /NAL 不完整，即已经被破坏的桢， comopnent 是否能提供恰当的处理，如果 component 不能相应的处理则必须设置这个值为 false 。

iOMXComponentUsesFullAVCFrames 的值默认为 OMX_FALSE ，这个值定义了 PVMF 在使用 AVC 的情况下，以何种模式为 Component 提供数据。在 OMX_FALSE 情况下是采用 NAL mode ，即 PCMF 提供给 comonent 的数据是 NAL 单元，相反的在 OMX_TRUE 情况下采用的是 Frame. mode ，在 Frame. mode 情况下 PVMF 必须将 NAL 单元累在一起，然后为 component 提供完整的一桢数据。

OMX_GetHandle() 根据 component name 载入指定的 component 到内存，并根据 component 的方法来为其创建一个 component 的 instance 。

OMX_GetParameter() 这实际是一个宏，用来获得 component 的参数，根据第一个参数 handle pointer 的不同，可能返回值也是不同的。

具体过程如下：

3.3 完成对 omx core 和 omx component 的初始化之后，第三个过程就是对 omx component input/output buffer 的协商。

＠首先使用 OMX_GetParameter() 获得 input/output port buffer parameters ，然后对获得的 parameters 进行一个 verify ，最后调用 OMX_SetParameter() 对 input/output port 设置一些 buffer parameters 。

Component input/output port Buffer size 在很大程度上影响着 component 的性能，如果一个 buffer 能载入多个桢 /NAL 就不存在分割的问题， PVMF 在每个 full 桢 /NAL 后面添加一个“ OMX_BUFFERFLAG_ENDOFFRAME” 标记。如果一个 buffer 不够容纳一个桢 /NAL ，则不管是在输入还是输出都要把桢 /NAL 分割成多个 buffer ，并在最后一部分上打上一个 end flag 的标记。

看 OMX API 对 OMX_AllocateBuffer 和 OMX_UseBuffer 的定义后觉得，所谓分配 buffer 就是， component 每次都要自己分配一个新的 buffer 和 buffer 　 header ，而使用 buffer ，是指可以使用其他 component 或者 IL client 分配好的 buffer ，但必须自己分配一个相应的 buffer 　 header ，两种方式

具体过程如下：

3.4 完成初始化以及对交换区 buffer 的协商之后， OMX component 就被 loaded 了，载入后的 component 首先要进入 Idle 状态。

＠首先 PVMF 会通过 OMX_SendCommand 函数向 OMX component 发送状态改变命令 ，将其状态从 OMX_StateLoaded 变为 OMX_StateIdle 。

＠然后使用两种分配 buffer 方式 (use or allocate) 的任一种来为所有的 input/output port 分配 buffer ，分配 buffer 的函数会根据 NumInputBuffer 和 NumOutputBuffer 的值被调用多次 [ 这里有点小疑问，这个 Num 是不是就是 port 的数目？ ]

＠当 component 完成 state transition 以后，会通过 envenhandle callback 来通知 PVMF （ OMX_EventCmdComplete ）。

根据 OMX spec ，所有的标准 OMX component 必须支持 OMX_UseBuffer/Allocate 两种分配 buffer 的方式，如果由于内部限制等原因不支持的话， component 必须与 PVMF 进行协商。

一般来说 INPUT bufferes 一般分配在 component 外部，这样输入数据就可以省去不必要的 copy 操作。

具体过程如下：