在討論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，高通，三星，都是開源的，但是其中關於各個解碼器組件的實現，沒有廠商釋放出來，這里者真金白銀，其他的，只是一些看着熱鬧的垃圾代碼而已。呵呵，所以呢？真正有技術實力的東西，永遠不在方案廠商這里，只會在芯片廠商那。