opencore內部調度

1 引言
多媒體架構是非常重要而又令人關心的模組，尤其在android的系統上，多媒體播放效果如何，對其架構瞭解是非常必要的。
多媒體中的調度問題，是個背後的故事，但卻對效能影響至關重要，本文並非全面分析多媒體架構，旨在探討媒體架構調度方面與傳統的多線程應用間的差異。 
2 基本知識
1 多媒體架構
    宏觀上看多媒體架構一般包含：engine、parser、codec、output，engine為控制部分，parser為檔案解析及讀取部分，codec就是音視頻編解碼，output包含音視頻輸出。針對不同檔案類型及轉碼器，會有多種parser及codec。
2 Linux線程
    一般來講linux都會定義最大線程為1024，不過還沒有看到哪個系統運行起來有如此之多的線程存在，也有網評說建立到382個線程時返回失敗。最大線程數目會受到系統資源的影響。
    多線程在管理調度上也會影響系統效能，影響的是kernel部分。
    多線程應用設計中，資料共用是個問題，線程A和線程B間共用資料，為確保資料訪問有效，會引入鎖，比如訊號量。多個線程中，訊號量等待是很重要的，有時線程A的資料準備OK了，但線程B沒有用完，那麼接下來線程A只能死等或是空轉。
    多線程中，還要避免線程死結。 
3 調度對比
    在此我們拿傳統while迴圈、多線程模式、opencore調度模式作對比，如示。
模式一：
    順序執行，有新模組加入就挨著添加。
模式二：
    不論有限與否，ABCD四個模組都在獨立運行，即使浪費也要空轉。
模式三：
    由統一調度器調度，優先者優先調度，ABCD四個模組都註冊到調度器上，通過狀態機器切換觸發下一次調度，誰著急被再次調用誰就去觸發調度器執行，相對公平。Opencore採用該模式，PlayerDriver建立後進入OSCL線程來處理訊息，engine建立完各個node節點並將其串連起來，剩下的就是node間的通訊問題，各node狀態變化會觸發oscl對其下一次調度，參與到oscl調度中的模組都必須提供一個Run函數，oscl會去call這個函數。

4 opencore為何不用多線程
因為有人曾疑問，為什麼opencore不去建立大量線程來調度，那樣不是更快，事實上opencore是採用上述模式三來解決調度問題的。附上一張oscl調度相關的類圖。

opencore中為何不大量去建立線程來完成各個模組，暫時沒有看到opencore的官方設計文檔來講述其設計思路，只能通過代碼去分析，下述也僅一家之言供參考。
1 從模組化去看，opencore有很多模組，包含engine、player、author、parser、omx、codec、output、audio、video等，並且opencore抽象出來個概念叫node，parser/codec/omx都被封裝成node，engine負責把各個node節點建立並串連起來後，剩下的就是各個node節點之間的通訊，它們由統一調度器來調度。試想，如果每個node（或者說模組）都去建立一個線程去執行，如何管理是個問題，也有悖軟體工程的模組化思想。
2 從模組化再看，假如把多媒體縮減到engine、parser、decoder三個模組，如果多線程去做，會有三個線程，這是其一，其二，檔案類型識別及解碼器識別需要事先完成，必然由engine去完成，從而決定用哪個parser和decoder。Opencore裡分的很清楚，各個模組幹各自的事情，一個線程統一調度完成。
3 從CS模型去看，android中多媒體採用伺服器用戶端架構來實現，用戶端是jiava程式，僅用於一些API的封裝、控制指令的下放等；核心的媒體播放控制都在伺服器端實現，它們之間通過binder調用銜接。當有用戶端發起媒體請求時，伺服器就建立一個client去對應它，如果有第二個媒體請求，就會建立第二個client來對應。如此一來，伺服器端可能會存在多個client，每個client都是一個媒體引擎的執行個體，假如opencore採用了多線程模式，又假如引擎總共涉及6個線程，倘若有五個用戶端發起請求，系統就會增加30個線程，如此一來顯然增加kernel的調度時間，影響系統效能。而採用opencore的統一調度，五個用戶端也就呼起五個線程，這是可以接受的。
4 從多媒體的應用情境來看，視頻播放、簡訊鈴聲、多媒體訊息鈴聲、電話鈴聲、鬧鐘鈴聲是會同時出現的，這樣就觸發了上述多種用戶端的情況。
5 從可移植看，opencore採用的統一調度器叫oscl，它是一個抽象封裝，基於oscl之上可以看做純軟體模組，如此一來opencore可以很容易的移植到各個平台，且保持一致性。
6 從擴充性看，opencore現有架構添加一個模組很容易，比如添加rmvb的支援，只要添加一個rmvb的parser-node即可，對系統架構沒有任何影響。如果採用多線程，rmvb的parser肯定要實現，engine中要添加rmvb識別部分，也會添加建立rmvb-parser線程部分。
7 多線程肯定是最快的，但複雜系統考慮自身架構設計及可擴充性，勢必在多線程的應用上採取謹慎態度。關鍵的問題，應該還是落在系統效能上，拿200M主頻和1G主頻作對比，在200M主頻處理器上再怎麼最佳化，也趕不上1G處理器，換句話說，1G處理器上即使架構再爛，系統啟動並執行也不會太差。
8 DirectX中也有一個filter的概念（類似opencore中的node節點），應用directx開發中，只要把各個filter串連起來即可，剩下的是filter間的事情。 
5 附錄
附錄兩張圖，均來自網路。

一張opencore的架構圖。
下面是程式碼片段

http://blogold.chinaunix.net/u2/61880/showart_2330325.html