高效多媒体嵌入式系统的omx HW本地支持

对高效多媒体嵌入式系统的OMX HW本地支持
---读书笔记陈矗
本文主要介绍了openmax组件的一个HW实现版本，我的理解是跟封装vpu成为一个组件是一个道理的。

在openmax中，core负责功能组件之间的通信，这对多媒体应用程序来说是至关重要的一个方面，因为从一个处理单元到另一个的数据传递方法的效率直接确定系统的处理能力。

论文中实现的HW omx支持tunneled和non-tunneled通信，端口的再连接，buffer和相关资源的动态管理。

本论文中提到一个OOCE（Object-Oriented Communication Engine），是针对Soc的一种HW/SW中间件的实现，利用OOCE可以很方便的完成omx标准定义的实体和通信方法到高效HW的映射。

图一omx IL组件结构
组件之间的通信时通过port来处理的，关于port可以分为输入port和输出port，这取决于该port是消耗媒体数据（buffer）还是产生媒体数据（buffer）。

组件之间的结构如图一所示。

从图中可以看出组件之间的通信方式有三种：
Non-tunneled通信：该通信方式通过应用程序控制端（IL client）来实现；
Tunneled通信：组件直接通信；
Proprietary通信：组件也是直接通信，但是与tunneled不同，该方式不属于omx标准。

IL层在OMX的软件体系中，承担一些很重要的功能，如组件的初始化和链接，资源的初始化，组件的通信和同步管理。

由此可见，主要OMX IL组件的HW实现可有助于提升
多媒体平台的处理能力。

为了验证本文提出的方法，作者在Xilinx XUP平台上实现了大部分OMX IL组件：
OMX HW 组件：实现OMX组件的标准接口和状态控制；
OMX HW Port：实现OMX Port的标准接口，目前仅支持tunneled和non-tunneled通信方式；
资源管理器（Resource Manager）：实现在DDR或BRAM中的buffer的分配和回收； Buffer迭代器：独立于实现buffer的内存技术，提出了一种处理buffer的方式。

支持一个简单的读写接口。

Port可以利用OMX HW组件持有的buffer头信息来获取正在被处理的buffer的相关信息。

图二OMX HW组件模板
图二描述了上述组件的链接交互。

组件之间的点对点通信是按照OOCE中关于本地交互（local interactions）的规定实现的，所以控制本地通信的FSM可以以一种自动地方式来获得。

Proxies和skeletons是由OOCE以一种高级语言实现的，他们用于解释总线上的传输并将OOCE的消息转化为响应操作。

OOCE异步处理消息，这与OMX的SW实现相符。

而Proxies和skeletons只有在组件挂载到总线上时才需要。

在本例中，使用c编写的OOCE接口实现的组件和port完全与omx SW实现兼容。

所以针对SW的应用程序无需更改就可以方便的使用OMX HW组件。