Stagefright和codec的交互是通过OpenMAX IL来完成的。
OpenMAX IL的规范头文件位于
/path/to/aosp/frameworks/native/include/media/openmax
概述下OpenMAX IL，它包括客户端(Client)，组件(Component)，端口(Port)，隧道化(Tunneled)。
Client是调用Component的对象，Port和Tunneled是Component之间通信的方式，Component之间还可以存在私有的通信方式。
组件(Component)的功能和其定义的端口类型密切相关，通常情况下：只有一个输出端口的，为Source组件；只有一个输入端口的，为Sink组件；有多个输入端口，一个输出端口的为Mux组件；有一个输入端口，多个输出端口的为DeMux组件；输入输出端口各一个组件的为中间处理环节，这是最常见的组件。
在Android 2.2以及之后，Stagefright是作为OpenMAX IL的上层存在的，它跟OpenMAX IL对接，然后OpenMAX IL又封装了具体的codec。
之前我有在http://guoh.ai/lifelog/2013/06/android-mediarecorder-architecture/分析过StagefrightRecorder，当时跟codec的集成我没有仔细分析。
这篇文章会详细分析下这个逻辑过程。
首先我们会碰到几个关键的类，第一个就是OMX，并且它的构造方法当中会去创建一个OMXMaster，继续追踪下，发现OMXMaster正如其名字所示，是一个管理者角色。
OMXMaster作为管理者，每添加一个plugin进来，都会记录在
KeyedVector<String8, OMXPluginBase *> mPluginByComponentName; // 重复名字的codec不会再让其加进来，也就是它会去确定该plugin支持多少codec，然后记录下来 List<OMXPluginBase *> mPlugins; // 主要负责释放内存(不与业务相关，只管有添加进来的plugin)
OMXMaster到底会加多少个OMXPlugin进来？
以及到底会有多少个OMXMaster？
有多少个OMX就有多少个OMXMaster，那有多少个OMX呢？
只有一个，参见
sp<IOMX> MediaPlayerService::getOMX() {
Mutex::Autolock autoLock(mLock);
if (mOMX.get() == NULL) {
mOMX = new OMX;
}
return mOMX;
}
那会有多少个OMXPlugin呢？。
一个SoftOMXPlugin，当中可以加载很多codec(s)进来
/path/to/aosp/frameworks/av/media/libstagefright/codecs/
有多少soft codec(s)都在上面这个目录
这里需要说明的是真实的codec的类结构，以FLAC为例子(箭头的方向为类继承的方向)
SoftFlacEncoder -> SimpleSoftOMXComponent -> SoftOMXComponent，SoftOMXComponent把OpenMAX IL定义的组件封装成一个C++类，里面有绑定组件操作的方法，但是它实都是以stub方式实现的，也就是说具体的实现在其子类。
SimpleSoftOMXComponent提供一个用于消息传递的ALooper和AHandlerReflector，实现了比如sendCommand，emptyThisBuffer和fillThisBuffer这三个异步方法(为什么只有这三个是异步，因为OpenMAX IL的规范要求这三个是non-blocking的，在我们这里实现的也就是通过looper/handler发送处理消息)，以及useBuffer，allocateBuffer和freeBuffer等等一些其他方法。
这样OMXCodec当中针对OpenMAX IL组件的一个操作就会通过IOMX，进而到OMXNodeInstance，最终进入我们SoftOMXComponent里面，刚刚我们有讲过方法具体实现是在其子类，这样只要找到对应的地方就可以了。
下面的这一段实例代码很清晰，以sendCommand为例子
status_t OMXCodec::init() {
// mLock is held.
...
err = mOMX->sendCommand(mNode, OMX_CommandStateSet, OMX_StateIdle);
...
}
status_t OMX::sendCommand(
node_id node, OMX_COMMANDTYPE cmd, OMX_S32 param) {
return findInstance(node)->sendCommand(cmd, param);
}
status_t OMXNodeInstance::sendCommand(
OMX_COMMANDTYPE cmd, OMX_S32 param) {
Mutex::Autolock autoLock(mLock);
OMX_ERRORTYPE err = OMX_SendCommand(mHandle, cmd, param, NULL); // 注意这个宏的定义，实际就是去调用组件的SendCommand方法
return StatusFromOMXError(err);
}
/** Send a command to the component. This call is a non-blocking call.
The component should check the parameters and then queue the command
to the component thread to be executed. The component thread shall
send the EventHandler() callback at the conclusion of the command.
This macro will go directly from the application to the component (via
a core macro). The component will return from this call within 5 msec.
When the command is "OMX_CommandStateSet" the component will queue a
state transition to the new state idenfied in nParam.
When the command is "OMX_CommandFlush", to flush a port's buffer queues,
the command will force the component to return all buffers NOT CURRENTLY
BEING PROCESSED to the application, in the order in which the buffers
were received.
When the command is "OMX_CommandPortDisable" or
"OMX_CommandPortEnable", the component's port (given by the value of
nParam) will be stopped or restarted.
When the command "OMX_CommandMarkBuffer" is used to mark a buffer, the
pCmdData will point to a OMX_MARKTYPE structure containing the component
handle of the component to examine the buffer chain for the mark. nParam1
contains the index of the port on which the buffer mark is applied.
Specification text for more details.
@param [in] hComponent
handle of component to execute the command
@param [in] Cmd
Command for the component to execute
@param [in] nParam
Parameter for the command to be executed. When Cmd has the value
OMX_CommandStateSet, value is a member of OMX_STATETYPE. When Cmd has
the value OMX_CommandFlush, value of nParam indicates which port(s)
to flush. -1 is used to flush all ports a single port index will
only flush that port. When Cmd has the value "OMX_CommandPortDisable"
or "OMX_CommandPortEnable", the component's port is given by
the value of nParam. When Cmd has the value "OMX_CommandMarkBuffer"
the components pot is given by the value of nParam.
@param [in] pCmdData
Parameter pointing to the OMX_MARKTYPE structure when Cmd has the value
"OMX_CommandMarkBuffer".
@return OMX_ERRORTYPE
If the command successfully executes, the return code will be
OMX_ErrorNone. Otherwise the appropriate OMX error will be returned.
@ingroup comp
*/
#define OMX_SendCommand( \
hComponent, \
Cmd, \
nParam, \
pCmdData) \
((OMX_COMPONENTTYPE*)hComponent)->SendCommand( \
hComponent, \
Cmd, \
nParam, \
pCmdData) /* Macro End */
OMX_ERRORTYPE SimpleSoftOMXComponent::sendCommand(
OMX_COMMANDTYPE cmd, OMX_U32 param, OMX_PTR data) {
CHECK(data == NULL);
sp<AMessage> msg = new AMessage(kWhatSendCommand, mHandler->id());
msg->setInt32("cmd", cmd);
msg->setInt32("param", param);
msg->post();
return OMX_ErrorNone;
}
当然这是异步的话，就还会有需要异步执行的处理函数回来，比如在onMessageReceived方法当中就有类型为kWhatSendCommand，kWhatEmptyThisBuffer和kWhatFillThisBuffer的消息，分别会去调用自己的处理方法。
其他同步的方法调用过程类似，这里我们就不具体再说，对照代码看看应该就能理解！
还有一点需要提一下，就是具体codec被创建的方式和时间，soft codec是在SoftOMXPlugin::makeComponentInstance当中通过调用该codec的createSoftOMXComponent方法来创建出来的，换句话说我们的codec实现必须要包含这样名字的一个方法，对于FLAC就是
android::SoftOMXComponent *createSoftOMXComponent(
const char *name, const OMX_CALLBACKTYPE *callbacks,
OMX_PTR appData, OMX_COMPONENTTYPE **component) {
return new android::SoftFlacEncoder(name, callbacks, appData, component);
}
会有多少个Vendor plugin(即libstagefrighthw)?
答案也是一个，但是它同样也包含有很多个codec(s)进来，以TI的HW为例子：
TIOMXPlugin(即Vendor plugin)在/path/to/aosp/hardware/ti/omap4xxx/libstagefrighthw/这里
但是具体的实现在/path/to/aosp/hardware/ti/omap4xxx/domx/omx_core/(即libOMX_Core.so)当中
假设要实例化一个codec，就需要经过如下步骤：
TIOMXPlugin.cpp(makeComponentInstance) -> OMX_Core_Wrapper.c(TIOMX_GetHandle) -> OMX_Core.c(OMX_GetHandle) -> 动态去load指定的codec的so档案，然后调用它的初始化方法(OMX_ComponentInit)，至于这个方法名，应该是遵循规范得来的(规范上有写这么句话，有这么一个error msg code)。
/** The component specified did not have a "OMX_ComponentInit" or "OMX_ComponentDeInit entry point */ OMX_ErrorInvalidComponent = (OMX_S32) 0x80001004,
其支持的codec(s)在/path/to/aosp/hardware/ti/omap4xxx/domx/omx_proxy_component/
当然codec最终的实现可能还是在其他地方！
以下这些方法都是OpenMAX IL所定义的于OMX Core有关的标准方法，详见OMX_Core.h，TI在OMX_Core.c当中有去实现这些方法，这些可以说是管理OpenMAX IL这一层所封装的Component的接口，当然包括自身的生命周期的管理，以及Component之间的沟通。
OMX_API OMX_ERRORTYPE OMX_Init OMX_API OMX_ERRORTYPE OMX_Deinit OMX_API OMX_ERRORTYPE OMX_ComponentNameEnum OMX_API OMX_ERRORTYPE OMX_GetHandle OMX_API OMX_ERRORTYPE OMX_FreeHandle OMX_API OMX_ERRORTYPE OMX_SetupTunnel OMX_API OMX_ERRORTYPE OMX_GetContentPipe OMX_API OMX_ERRORTYPE OMX_GetComponentsOfRole OMX_API OMX_ERRORTYPE OMX_GetRolesOfComponent
也就是说OMX是操作所有codec的窗口，它透过OMXMaster来管理Soft/Vendor plugin，每个plugin当中有属于自己的codec(s)。
比如典型的，OMX有allocateNode这个方法，这是增加codec时需要的，当然它实质上是去调用OMXMaster -> OMXPlugin -> OMX_Core -> 特定的codec的实例化方法。
status_t OMX::allocateNode(
const char *name, const sp<IOMXObserver> &observer, node_id *node) {
Mutex::Autolock autoLock(mLock);
*node = 0;
OMXNodeInstance *instance = new OMXNodeInstance(this, observer);
OMX_COMPONENTTYPE *handle; // 声明一个OMX_COMPONENTTYPE指针
// 接着makeComponentInstance创建出来，双指针OUT传值
// 最终会发现在codec当中会去调用这样一个方法(对于TI的HW，这个方法位于omx_proxy_common.c当中)
// /*Calling Proxy Common Init() */
// eError = OMX_ProxyCommonInit(hComponent);
// 它会去初始化OMX_COMPONENTTYPE的各个属性，方法，例如OMX_COMPONENTTYPE::SetCallbacks等等
OMX_ERRORTYPE err = mMaster->makeComponentInstance(
name, &OMXNodeInstance::kCallbacks,
instance, &handle);
if (err != OMX_ErrorNone) {
ALOGV("FAILED to allocate omx component '%s'", name);
instance->onGetHandleFailed();
return UNKNOWN_ERROR;
}
*node = makeNodeID(instance);
mDispatchers.add(*node, new CallbackDispatcher(instance));
instance->setHandle(*node, handle);
mLiveNodes.add(observer->asBinder(), instance);
observer->asBinder()->linkToDeath(this);
return OK;
}
有两点值得注意的是
a)
status_t OMXClient::connect() {
sp<IServiceManager> sm = defaultServiceManager();
sp<IBinder> binder = sm->getService(String16("media.player"));
sp<IMediaPlayerService> service = interface_cast<IMediaPlayerService>(binder);
// defaultServiceManager(位于/path/to/aosp/frameworks/native/include/binder/IServiceManager.h)
// 这样调用就跟本地的一个service指针来调用getOMX是一样的，因为本来StatefrightRecorder是在MediaPlayerService当中new出来的
// 这个我们在之前的研究讨论中做过实验，详细参见http://guoh.ai/lifelog/2013/06/sample-of-customized-service-on-android-platform/怎样为Android添加一个系统级服务
CHECK(service.get() != NULL);
mOMX = service->getOMX(); // BnOMX
CHECK(mOMX.get() != NULL);
// 什么情况会有不是在本地，貌似OMX是在MediaPlayerService当中new出来的，
// OMXClient是在StagefrightRecorder当中new出来的，而StagefrightRecorder又是在MediaPlayerService当中new出来
// 所以什么情况下会走到如下的这个using client-side OMX mux当中去(MuxOMX位于OMXClient.cpp当中)？
if (!mOMX->livesLocally(NULL /* node */, getpid())) {
ALOGI("Using client-side OMX mux.");
mOMX = new MuxOMX(mOMX); // 继承自IOMX
}
return OK;
}
容易看出OMXClient是获取OMX的窗口
b)
sp<MediaSource> encoder = OMXCodec::Create(
client.interface(), enc_meta,
true /* createEncoder */, cameraSource,
NULL, encoder_flags);
那OMXCodec/
/path/to/aosp/frameworks/av/include/media/stagefright
/path/to/aosp/frameworks/av/media/libstagefright
OMXNodeInstance
/path/to/aosp/frameworks/av/media/libstagefright/include
/path/to/aosp/frameworks/av/media/libstagefright/omx
是做什么的？
OMXCodec，OMXCodecObserver和OMXNodeInstance是一一对应的，
简单的可以理解它们3个构成了OpenMAX IL的一个Component，每一个node就是一个codec在OMX服务端的标识。
当然还有CallbackDispatcher，用于处理codec过来的消息，通过它的post/loop/dispatch来发起接收，最终透过IOMX::onMessage -> OMXNodeInstance::onMessage -> OMXCodecObserver::onMessage -> OMXCodec::on_message一路往上，当然消息的来源是因为我们有向codec注册OMXNodeInstance::kCallbacks，请看
status_t OMX::allocateNode(
const char *name, const sp<IOMXObserver> &observer, node_id *node) {
...
OMX_ERRORTYPE err = mMaster->makeComponentInstance(
name, &OMXNodeInstance::kCallbacks,
instance, &handle);
...
return OK;
}
kCallbacks包含3种事件
OMX_CALLBACKTYPE OMXNodeInstance::kCallbacks = {
&OnEvent, &OnEmptyBufferDone, &OnFillBufferDone
};
它们分别都会调用到自己owner的OnEvent/OnEmptyBufferDone/OnFillBufferDone
// static
OMX_ERRORTYPE OMXNodeInstance::OnEvent(
OMX_IN OMX_HANDLETYPE hComponent,
OMX_IN OMX_PTR pAppData,
OMX_IN OMX_EVENTTYPE eEvent,
OMX_IN OMX_U32 nData1,
OMX_IN OMX_U32 nData2,
OMX_IN OMX_PTR pEventData) {
OMXNodeInstance *instance = static_cast<OMXNodeInstance *>(pAppData);
if (instance->mDying) {
return OMX_ErrorNone;
}
return instance->owner()->OnEvent(
instance->nodeID(), eEvent, nData1, nData2, pEventData);
}
而owner相应的又会调用自己dispatcher的post方法，如下：
OMX_ERRORTYPE OMX::OnEvent(
node_id node,
OMX_IN OMX_EVENTTYPE eEvent,
OMX_IN OMX_U32 nData1,
OMX_IN OMX_U32 nData2,
OMX_IN OMX_PTR pEventData) {
ALOGV("OnEvent(%d, %ld, %ld)", eEvent, nData1, nData2);
omx_message msg;
msg.type = omx_message::EVENT;
msg.node = node;
msg.u.event_data.event = eEvent;
msg.u.event_data.data1 = nData1;
msg.u.event_data.data2 = nData2;
findDispatcher(node)->post(msg);
return OMX_ErrorNone;
}
这样所有的事件都串起来了，消息有来源，有最终的去处！
结合这些信息所以我们就可以认为在这里是创建出了一个Component出来。
另外值得提一下的就是我们前面已经讲过Component之间也是可以有信息交互的，比如我们在录影的时候，CameraSource就作为数据的来源被OMXCodec持有，那么从OMXCodec读取的数据实际都是来自于CameraSource，然后就被MediaWriter，例如MPEG4Writer写到文件当中。
OMX_GetComponentVersion OMX_SendCommand OMX_GetParameter OMX_SetParameter OMX_GetConfig OMX_SetConfig OMX_GetExtensionIndex OMX_GetState OMX_UseBuffer OMX_AllocateBuffer OMX_FreeBuffer OMX_EmptyThisBuffer OMX_FillThisBuffer OMX_UseEGLImage
以上这些macro位于OMX_Core.h当中，这是OpenMax所定义的
针对每一个Component封装，他们负责与具体的codec进行沟通，对于TI的HW，这些方法都实现于omx_proxy_common.c当中
其他内容：
1、HardwareAPI.h
extern android::OMXPluginBase *createOMXPlugin();
定义一个实例化plugin的入口方法，在OMXMaster当中回去动态调用这个方法
2、对于Qualcomm的HW来说，它的libstagefrighthw实现位于如下位置：
libomxcore.so /path/to/aosp/hardware/qcom/media/mm-core/omxcore
3、还有比较关键的就是OpenMAX IL之间本身的原理，还有相互沟通是怎么样的，这个比较重要。
都知道OpenMAX IL最大的作用就是一个适配层作用，它封装了底层Vendor容易变化的部分(不同codec/不同Vendor，或者其他形式的变化)，对上层提供一个统一的接口(比如在这里就是Stagefright)。
一个Component的状态分为这么多种，这些定义在OMXCodec当中
enum State {
DEAD,
LOADED,
LOADED_TO_IDLE,
IDLE_TO_EXECUTING,
EXECUTING,
EXECUTING_TO_IDLE,
IDLE_TO_LOADED,
RECONFIGURING,
ERROR
};
Component之间的交互，比如Tunneled communication，是通过Component的ComponentTunnelRequest方法来完成的(TI的HW实现在omx_proxy_common.c当中)，但是从代码上看起来在Qualcomm或者TI的Camera这块都没有用到Tunneled communication，Qualcomm根本就没有去实现ComponentTunnelRequest方法。
Buffer的传输过程，这块初看很复杂，其实流程还是比较清楚的。在Camera录影这个场景中，MediaWriter会不断的请求MediaSource的read方法，从中间读取数据，但是在MediaSource内部会对其进行控制，用的就是signal(Condition mFrameAvailableCondition;)。OMXCodec的drainInputBuffer/fillOutputBuffer这两个方法最重要，排空input缓冲(source过来的数据)和填充output缓冲(准备给writer的数据)。drainInputBuffer把数据发到实际的codec，codec收完之后发送EMPTY_BUFFER_DONE消息过来，OMXCodec收到该消息继续发送数据到codec。另外同时OMXCodec还会执行fillOutputBuffer，即喂给codec一个空的buffer，codec编码完成之后会发送FILL_BUFFER_DONE过来，这个消息带有编码好的数据，即被填满的buffer，这样MediaWriter就收到编码完成的数据，然后保存就可以了。细节性的东西就需要自己追踪代码可能更好理解，聪明的你可能就想到了那这里是不是存在两个Buffer，是的，你是对的，请看List
这里再罗嗦的讲解一遍实际过程(MPEG4录影为例子)：
MPEG4Writer：
开始read之后，会调用drainInputBuffers()，它会从kPortIndexInput取出一组buffer出来，先把数据从CameraSource读取到这个buffer当中，然后调用IOMX的emptyBuffer把buffer交给实际的encoder，然后while loop等待encoder把output buffer(从kPortIndexOutput取出)填满(encoder的FILL_BUFFER_DONE回来会将通过msg带回来的数据放到output buffer，还会在mFilledBuffers当中记录下该buffer的index，并通过mBufferFilled.signal()广播出来)，也就是说OMXCodec的read方法是同步的，必须要等到从CameraSource读取数据，然后encoder编码完毕返回数据才算read结束，然后会MPEG4Writer会将该buffer拷贝一份出来，并且释放掉原来的buffer(这个buffer是大家共同可以访问的，所以MPEG4Writer不想或者不应该长期持有它，写文件所消耗的时间并不是一定的，所以这里应该算是以空间换时间的一种做法)。
buffer的分配：
input buffer的MediaBuffer是在CameraSource当中分配，OMXCodec当中release(EMPTY_BUFFER_DONE回来如果buffer没有被release掉就执行release过程)
output buffer的MediaBuffer分多种情况，有可能是在allocateBuffer的时候分配的，有可能是FILL_BUFFER_DONE回来的时候分配，在MediaWriter读取到处理好之后的数据自己拷贝该数据一份之后release。
End Of Stream：
一般情况decoder或encoder告诉我们EOS，但是有些时候不告诉我们的时候OMXCodec也有做workaround，通过计算不在OMX Component的buffer的个数，如果所有buffer都不被OMX Component所持有，就认为已经到EOS了。
