在討論stagefright如何調用硬件解碼以前,咱們要先清楚幾個問題。android
我不展開這幾個結論是如何得來的,由於這部分屬於進程間通訊binder的理解,和多媒體自己無關。c++
一.問題空間瀏覽器
這個有點像方法學上的東西了,呵呵。其實咱們討論一個問題,首先要觀注的就是,什麼是咱們應該關心的,什麼是咱們在這個問題空間裏不用解決的。服務器
上次咱們說到,awesomeplayer全部codec,包括軟解與硬解的,都是由omx封裝的。函數
個人第一個結論就是:OMX是一個server,等同於surfaceflinger,audioflinger的server。spa
既然是server,那麼,確定存在客戶端與服務器兩個方面,另外,server是爲提供service而存在的,那麼,sevice有哪些?code
這是咱們要探討的問題。server
二.交互過程對象
咱們知道,在互聯網的概念裏,server都是有域名的,瀏覽器經過dns從域名解析到ip,經過路由器,進而進行通訊。blog
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,高通,三星,都是開源的,可是其中關於各個解碼器組件的實現,沒有廠商釋放出來,這裏者真金白銀,其餘的,只是一些看着熱鬧的垃圾代碼而已。呵呵,因此呢?真正有技術實力的東西,永遠不在方案廠商這裏,只會在芯片廠商那。