標籤：
轉載請把頭部出處連結和尾部二維碼一起轉載，本文出自逆流的魚yuiop：http://blog.csdn.net/hejjunlin/article/details/52629598
前言：上篇中介紹OMX事件回調，從今天開始，走入Codec部分之OpenMAX架構裡。看下今天的Agenda如下：
- 一張圖回顧音視頻同步
- 一張圖看清OpenMAX在Android系統中位置
- OpenMAX是什麼
- OpenMax IL簡介
- OpenMax IL結構
- Android中OpenMax的使用方式
- OpenMax的介面與實現
- Android中OpenMax的適配層
- mp3,aac解碼時序圖
一張圖回顧音視頻同步
一張圖看清OpenMAX在Android系統中位置：
OpenMAX是什嗎？
以下是官網翻譯：
- OpenMAX? 是無授權費的,跨平台的應用程式介面API，通過使媒體加速組件能夠在開發、整合和編程環節中實現跨多作業系統和處理器硬體平台，提供全面的流媒體轉碼器和應用程式便攜化。
- OpenMAX API將會與處理器一同提供，以使庫和轉碼器開發人員能夠高速有效地利用新器件的完整加速潛能 - 無需擔心其底層的硬體結構。
OpenMAX分為3層：
- 第一層：OpenMax DL（Development Layer，開發層）
- OpenMax DL定義了一個API，它是音頻、視頻和映像功能的集合。供應商能夠在一個新的處理器上實現並最佳化，然後編解碼供應商使用它來編寫更廣泛的轉碼器功能。它包括音頻訊號的處理功能，如FFT和filter，映像原始處理，如色彩空間轉換、視頻原始處理，以實現例如MPEG-4、H.264、MP3、AAC和JPEG等轉碼器的最佳化。
- 第二層：OpenMax IL（Integration Layer，整合層）
- OpenMax IL作為音頻、視頻和影像轉碼器能與多媒體轉碼器互動，並以統一的行為支援組件（例如，資源和皮膚）。這些轉碼器或許是軟硬體的混合體，對使用者是透明的底層介面應用於嵌入式、行動裝置。它提供了應用程式和媒體架構，透明的。S轉碼器供應商必須寫私人的或者封閉的介面，整合進行動裝置。IL的主要目的是使用特徵集合為轉碼器提供一個系統抽象，為解決多個不同媒體系統之間輕便性的問題。
- 第三層：OpenMax AL（Appliction Layer，應用程式層）
- OpenMax AL API在應用程式和多媒體中介軟體之間提供了一個標準化介面，多媒體中介軟體提供服務以實現被期待的API功能。
本文出自逆流的魚yuiop：http://blog.csdn.net/hejjunlin/article/details/52629598
OpenMax的三個層次(來自OpenMax官網):
提示：在實際的應用中，OpenMax的三個層次中使用較多的是OpenMax IL整合層，由於作業系統到硬體的差異和多媒體應用的差異，OpenMax的DL和AL層使用相對較少。
OpenMax IL簡介
OpenMax IL 處在中介層的位置，OpenMAX IL 作為音頻，視頻和影像轉碼器 能與多媒體轉碼器互動，並以統一的行為支援組件（例如資源和皮膚）。這些轉碼器或許是軟硬體的混合體，對使用者是的底層介面應用於嵌入式或 / 和行動裝置。它提供了應用程式和媒體架構， 透明的。本質上不存在這種標準化的介面，轉碼器供 應商必須寫私人的或者封閉的介面，整合進行動裝置。 IL 的主要目的 是使用特徵集合為轉碼器提供一個系統抽象，為解決多個不同媒體系統之間輕便性的問題。
OpenMax IL 的目的就是為硬體平台的圖形及音視頻提供一個抽象層，可以為上層的應用提供一個可跨平台的支撐。這一點對於跨平台的媒體應用來說十分重要。不同廠商的晶片底層的音視頻介面雖然功能上大致相同，但是介面設計及用法上各有不同，而且相差很多。你要想讓自己開發的媒體 應用完美的運行在不同的硬體廠商平台上，就得適應不同晶片的底層解碼介面。這個對於應用開發來說十分繁瑣。所以就需要類似於OpenMax IL 這種介面規範。應用假如涉及到音視頻相關功能時，只需調用這些標準的介面，而不需要關心介面下方硬體相關的實現。假如換了硬體平台時，只需要把介面層與硬體適配好了就行了。上層應用不需要頻繁改動。你可以把OpenMax IL看作是中介軟體中的porting層介面，但是現在中介軟體大部分都是自家定義自己的。
本文出自逆流的魚yuiop：http://blog.csdn.net/hejjunlin/article/details/52629598
OpenMax IL結構
OpenMax IL的階層:
- 虛線中的內容是OpenMax IL層的內容，其主要實現了OpenMax IL中的各個組件（Component）。對下層，OpenMax IL可以調用OpenMax DL層的介面，也可以直接調用各種Codec實現。對上層，OpenMax IL可以給OpenMax AL 層等架構層（Middleware）調用，也可以給應用程式直接調用。
OpenMax IL主要內容如下所示。
- 用戶端（Client）：OpenMax IL的調用者
- 組件（Component）：OpenMax IL的單元，每一個組件實現一種功能
- 連接埠（Port）：組件的輸入輸出介面
- 隧道化（Tunneled）：讓兩個組件直接連接的方式
組件、連接埠、隧道化思想和GStreamer (一種多媒體架構)中的 pipeline 十分類似。
Component實現單一功能、或是Source、Host、Accelerator和Sink。
Port 是 Component對外的輸入輸出口。
通過Tunneled 將單一Component串聯起來形成一個完整功能。
OpenMax Core是輔助各個組件啟動並執行部分
OpenMax IL 的基本運作過程
，openMAX IL的用戶端，通過調用四個OpenMAX IL組件，實現了一個功能。四個組件分別是Source組件、Host組件、Accelerator組件和Sink組件。Source組件只有一個輸出連接埠；而Host組件有一個輸入連接埠和一個輸出連接埠；Accelerator組件具有一個輸入連接埠，調用了硬體的轉碼器，加速主要體現在這個環節上。Accelerator組件和Sink組件通過私人通訊方式在內部進行串連，沒有經過明確的組件連接埠。
OpenMAL IL在使用的時候，其資料流也有不同的處理方式：
- 既可以經由用戶端，也可以不經由用戶端。
- 圖中，Source組件到Host組件的資料流就是經過用戶端的；
- 而Host組件到Accelerator組件的資料流就沒有經過用戶端，使用了隧道化的方式；
- Accelerator組件和Sink組件甚至可以使用私人的通訊方式。
OpenMax Core是輔助各個組件啟動並執行部分，它通常需要完成各個組件的初始化等工作，在真正運行過程中，重點是各個OpenMax IL的組件，OpenMax Core不是重點，也不是標準。
- OpenMAL IL的組件是OpenMax IL實現的核心內容，一個組件以輸入、輸出連接埠為介面，連接埠可以被串連到另一個組件上。外部對組件可以發送命令，還進行設定/擷取參數、配置等內容。組件的連接埠可以包含緩衝區（Buffer）的隊列。
- 組件的處理的核心內容是：通過輸入連接埠消耗Buffer，通過輸出連接埠填充Buffer，由此多組件相聯結可以構成流式的處理。
本文出自逆流的魚yuiop：http://blog.csdn.net/hejjunlin/article/details/52629598
OpenMAL IL中一個組件的結構:
組件的功能和其定義的連接埠類型密切相關，通常情況下：
- 只有一個輸出連接埠的，為Source組件；
- 只有一個輸入連接埠的，為Sink組件；
- 有多個輸入連接埠，一個輸出連接埠的為Mux組件；
- 有一個輸入連接埠，多個輸出連接埠的為DeMux組件；
- 輸入輸出連接埠各一個組件的為中間處理環節，這是最常見的組件。
- 連接埠具體支援的資料也有不同的類型。例如，對於一個輸入、輸出連接埠各一個組件，其輸入連接埠使用MP3格式的資料，輸出連接埠使用PCM格式的資料，那麼這個組件就是一個MP3解碼組件。
- 隧道化（Tunneled）是一個關於元件連線方式的概念。通過隧道化可以將不同的組件的一個輸入連接埠和一個輸出連接埠串連到一起，在這種情況下，兩個組件的處理過程合并，共同處理。尤其對於單輸入和單輸出的組件，兩個組件將作為類似一個使用。
Android中OpenMax的使用方式
- Android系統的一些部分對OpenMax IL層進行使用，基本使用的是標準OpenMax IL層的介面，只是進行了簡單的封裝。標準的OpenMax IL實現很容易以外掛程式的形式加入到Android系統中。
- Android的多媒體引擎OpenCore和StageFright都可以使用OpenMax作為多媒體編解碼的外掛程式，只是沒有直接使用OpenMax IL層提供的純C介面，而是對其進行了一定的封裝(C++封裝)。
- 在Android2.x版本之後，Android的架構層也對OpenMax IL層的介面進行了封裝定義，甚至使用Android中的Binder IPC機制。Stagefright使用了這個層次的介面，OpenCore沒有使用。
- OpenCore使用OpenMax IL層作為編解碼外掛程式在前，Android架構層封裝OpenMax介面在後面的版本中才引入。
Android OpenMax實現的內容
- Android中使用的主要是OpenMax的編解碼功能。雖然OpenMax也可以產生輸入、輸出、檔案解析-構建等組件，但是在各個系統（不僅是Android）中使用的最多的還是編解碼組件。媒體的輸入、輸出環節和系統的關係很大，引入OpenMax標準比較麻煩；檔案解析-構建環節一般不需要使用硬體加速。編解碼組件也是最能體現硬體加速的環節，因此最常使用。
- 在Android中實現OpenMax IL層和標準的OpenMax IL層的方式基本，一般需要實現以下兩個環節。
- 編解碼驅動程式：位於Linux核心空間，需要通過Linux核心調用驅動程式，通常使用非標準的驅動程式。
- OpenMax IL層：根據OpenMax IL層的標準標頭檔實現不同功能的組件。
Android中還提供了OpenMax的適配層介面（對OpenMax IL的標準組件進行封裝適配），它作為Android本地層的介面，可以被Android的多媒體引擎調用。
OpenMax的介面與實現OpenMax IL層的介面（1）
OpenMax IL層的介面定義由若干個標頭檔組成，這也是實現它需要實現的內容，它們的基本描述如下所示。
提示：OpenMax標準只有標頭檔，沒有標準的庫，設定沒有定義函數介面。對於實現者，需要實現的主要是包含函數指標的結構體。
其中，OMX_Component.h中定義的OMX_COMPONENTTYPE結構體是OpenMax IL層的核心內容，表示一個組件，其內容如下所示：
OpenMax IL層的介面（2）
- OMX_COMPONENTTYPE結構體實現後，其中的各個函數指標就是調用者可以使用的內容。各個函數指標和OMX_core.h中定義的內容相對應。
EmptyThisBuffer和FillThisBuffer是驅動組件啟動並執行基本的機制，前者表示讓組件消耗緩衝區，表示對應組件輸入的內容；後者表示讓組件填充緩衝區，表示對應組件輸出的內容。
- UseBuffer，AllocateBuffer，FreeBuffer為和連接埠相關的緩衝區管理函數，對於組件的連接埠有些可以自己分配緩衝區，有些可以使用外部的緩衝區，因此有不同的介面對其進行操作。
- SendCommand表示向組件發送控制類的命令。GetParameter，SetParameter，GetConfig，SetConfig幾個介面用於輔助的參數和配置的設定和擷取。
ComponentTunnelRequest用於組件之間的隧道化串連，其中需要制定兩個組件及其相連的連接埠。
- ComponentDeInit用於組件的反初始化。
提示：OpenMax函數的參數中，經常包含OMX_IN和OMX_OUT等宏，它們的實際內容為空白，只是為了標記參數的方向是輸入還是輸出。
OMX_Component.h中連接埠類型的定義為OMX_PORTDOMAINTYPE枚舉類型，內容如下所示：
音訊類型，視頻類型，映像類型，其他類型是OpenMax IL層此所定義的四種連接埠的類型。
連接埠具體內容的定義使用OMX_PARAM_PORTDEFINITIONTYPE類（也在OMX_Component.h中定義）來表示，其內容如下所示：
對於一個連接埠，其重點的內容如下：
- 連接埠的方向（OMX_DIRTYPE）：包含OMX_DirInput（輸入）和- -OMX_DirOutput（輸出）兩種
- 連接埠分配的緩衝區數目和最小緩衝區數目
- 連接埠的類型（OMX_PORTDOMAINTYPE）：可以是四種類型
- 連接埠格式的資料結構：使用format聯合體來表示，具體由四種不同類型來表示，與連接埠的類型相對應
OMX_AUDIO_PORTDEFINITIONTYPE，OMX_VIDEO_PORTDEFINITIONTYPE，OMX_IMAGE_PORTDEFINITIONTYPE和OMX_OTHER_PORTDEFINITIONTYPE等幾個具體的格式類型，分別在OMX_Audio.h，OMX_Video.h，OMX_Image.h和OMX_Other.h這四個標頭檔中定義。
OMX_BUFFERHEADERTYPE是在OMX_Core.h中定義的，表示一個緩衝區的頭部結構。
OMX_Core.h中定義的枚舉類型OMX_STATETYPE命令表示OpenMax的狀態機器，內容如下所示：
OpenMax組件的狀態機器可以由外部的命令改變，也可以由內部發生的情況改變。OpenMax IL組件的狀態機器的遷移關係：
OMX_Core.h中定義的枚舉類型OMX_COMMANDTYPE表示對組件的命令類型，內容如下所示：
OMX_COMMANDTYPE類型在SendCommand調用中作為參數被使用，其中OMX_CommandStateSet就是改變狀態機器的命令。
OpenMax IL實現的內容
對於OpenMax IL層的實現，一般的方式並不調用OpenMax DL層。具體實現的內容就是各個不同的組件。OpenMax IL組件的實現包含以下兩個步驟。
- 組件的初始化函數：硬體和OpenMax資料結構的初始化，一般分成函數指標初始化、私人資料結構的初始化、連接埠的初始化等幾個步驟，使用其中的pComponentPrivate成員保留本組件的私人資料為上下文，最後獲得填充完成OMX_COMPONENTTYPE類型的結構體。
- OMX_COMPONENTTYPE類型結構體的各個指標實現：實現其中的各個函數指標，需要使用私人資料的時候，從其中的pComponentPrivate得到指標，轉化成實際的資料結構使用。連接埠的定義是OpenMax IL組件對外部的介面。OpenMax IL常用的組件大都是輸入和輸出連接埠各一個。對於最常用的編解碼（Codec）組件，通常需要在每個組件的實現過程中，調用硬體的編解碼介面來實現。在組件的內部處理中，可以建立線程來處理。OpenMax的組件的連接埠有預設參數，但也可以在運行時設定，因此一個連接埠也可以支援不同的編碼格式。音頻編碼組件的輸出和音頻編碼組件的輸入通常是未經處理資料格式（PCM格式），視頻編碼組件的輸出和視頻編碼組件的輸入通常是未經處理資料格式（YUV格式）。
提示：在一種特定的硬體實現中，編解碼部分具有相似性，因此通常可以構建一個OpenMax組件的”基類”或者公用函數，來完成公用性的操作。
Android中OpenMax的適配層
Android中的OpenMax適配層的介面在frameworks/base/include/media/目錄中的IOMX.h檔案定義，其內容如下所示：
- IOMX表示的是OpenMax的一個組件，根據Android的Binder IPC機制，BnOMX繼承IOMX，實現者需要繼承實現BnOMX。IOMX類中，除了和標準的OpenMax的GetParameter，SetParameter，GetConfig，SetConfig，SendCommand，UseBuffer，AllocateBuffer，FreeBuffer，FillThisBuffer和EmptyThisBuffer等介面之外，還包含了創造渲染器的介面createRenderer()，建立的介面為IOMXRenderer類型。
- IOMX中只有第一個createRenderer()函數是純虛函數，第二個的createRenderer()函數和createRendererFromJavaSurface()通過調用第一個createRenderer()函數實現。
IOMXRenderer類表示一個OpenMax的渲染器，其定義如下所示：
- IOMXRenderer只包含了一個render介面，其參數類型IOMX::buffer_id實際上是void*，根據不同渲染器使用不同的類型。
- 在IOMX.h檔案中，另有表示觀察器類的IOMXObserver，這個類表示OpenMax的觀察者，其中只包含一個onMessage()函數，其參數為omx_message介面體，其中包含Event事件類型、FillThisBuffer完成和EmptyThisBuffer完成幾種類型。
提示：Android中OpenMax的適配層是OpenMAX IL層至上的封裝層，在Android系統中被StageFright調用，也可以被其他部分調用。
mp3 aac格式解碼時序圖
第一時間獲得部落格更新提醒，以及更多android乾貨，源碼分析，歡迎關注我的公眾號，掃一掃下方二維碼或者長按識別二維碼，即可關注。
如果你覺得好，隨手點贊，也是對筆者的肯定，也可以分享此公眾號給你更多的人，原創不易
Android Multimedia架構總結（十三）CodeC部分之OpenMAX架構初識及介面與適配層實現
