在讨论stagefright如何调用硬件解码之前，我们要先清楚几个问题。
我不展开这几个结论是如何得来的，因为这部分属于进程间通信binder的理解，和多媒体本身无关。
一．问题空间
这个有点像方法学上的东西了，呵呵。其实我们讨论一个问题，首先要观注的就是，什么是我们应该关心的，什么是我们在这个问题空间里不用解决的。
上次我们说到，awesomeplayer所有codec，包括软解与硬解的，都是由omx封装的。
我的第一个结论就是：OMX是一个server，等同于surfaceflinger，audioflinger的server。
既然是server，那么，肯定存在客户端与服务器两个方面，另外，server是为提供service而存在的，那么，sevice有哪些？
这是我们要探讨的问题。
二．交互过程
我们知道，在互联网的概念里，server都是有域名的，浏览器通过dns从域名解析到ip，通过路由器，进而进行通信。
Binder里面其实也有类似的概念，比如surfaceflinger注册的服务名就是“SurfaceFlinger”。那么omx注册的叫什么？我找了n久，这是一个不和谐的存在：他是一个匿名服务。我只能得出这个结论了，因为OMX这个server实在不符合一般常规的方法。
在Awesomeplayer里面，有个成员叫mClient，在Awesomeplayer构造函数里面，这个成员去与服务器取得了联系，去获取服务都指着他呢，呵呵。
CHECK_EQ(mClient.connect(), (status_t)OK);
并且知道了omx能提供哪些服务，这些服务用IOMX这个类来标识。
好吧，IOMX是一个接口类，都是纯虚函数，那么我们看看这个类的实际实现在哪。
这个接口类，描述了一些功能，我不详细展开说接口的功能了。那样在太像spec了。因为iomx说白了就是把omx那几个c语言头文件，用c++重写了一遍。相当没意思。
OMX.cpp这个就是omx server真正的实现了。
三．OMX.cpp分析
上面说到了connect()，实际connect()时，发生了很多故事。一个有趣的故事就是
mOMX = service->getOMX()（omxclient.cpp)。
我们来看看getOMX()在哪里，又是binder，好麻烦。
sp<IOMX> MediaPlayerService::getOMX() （MediaPlayerService.cpp)。
一个getomx()，直接导致我们的OMX的构造函数被调用。
OMX的构造函数被调用还是小事，他同时又构造了一个对象。(OMXMaster.cpp)
OMXMaster::OMXMaster()
: mVendorLibHandle(NULL) {
addVendorPlugin();
addPlugin(new SoftOMXPlugin);
}
Add了两类plugin(）。软件一类，硬件一类。
先看软件那一类。又new一个softomxplugin()，进去看看。
又出来一个接口类，OMXPluginBase，又要实现4个接口。。。。看看softomxplugin如何实现他们。
全是字符串写好的，so库名都是写死的。支持哪种codec就加进来。
然后通过dlopen打开。
找这么_Z22createSoftOMXComponentPKcPK16OMX_CALLBACKTYPE一个怪名子的函数，都怪c++的重载机制了，好好的函数名，一修饰，看不懂了。
不过呢，其实就是他了。android::SoftOMXComponent *createSoftOMXComponent，我们可以看一个实例，softavc.cpp里面有。
这里先不展开，因为内容还够写两篇，呵呵。
再看硬件一类，也是这个文章的终极问题。
直接规定的一个库名。Libstagefrighthw.so这个就是硬解库了。
硬解库要实现些什么呢？先说几个基本的。
createOMXPlugin这个，但是这个只是创建一个OMXPluginBase对象。
实际要完成的关键，还是这个OMXPluginBase里面的四个函数。
其中的秘密，只有芯片厂商知道了。
Android的源代码里面关于libstagefrighthw..so的实现，ti，高通，三星，都是开源的，但是其中关于各个解码器组件的实现，没有厂商释放出来，这里者真金白银，其他的，只是一些看着热闹的垃圾代码而已。呵呵，所以呢？真正有技术实力的东西，永远不在方案厂商这里，只会在芯片厂商那。