OpenMAX IL架構
OpenMAX
是一個多媒體應用程式的标準。由NVIDIA公司和Khronos™在2006年推出。
它是無授權費的、跨平台的C語言程式接口序列，這些接口對音頻、視訊、靜态圖檔的常用操作進行封裝。它包括三層，分别：
應用層（AI）、內建層（IL）和開發層（DL）
其中IL層已經成為了事實上的多媒體架構标準。嵌入式處理器或者多媒體編解碼子產品的硬體生産者，通常提供标準的OpenMax IL層的軟體接口，這樣軟體的開發者就可以基于這個層次的标準化接口進行多媒體程式的開發
OpenCore StageFright OpenMax架構:
OpenMax IL層，通常可以用于多媒體引擎的插件
Android的多媒體引擎OpenCore和StageFright都可以使用OpenMax作為插件，主要用于編解碼（Codec）處理。在Android的架構層，也定義了由Android封裝的OpenMax接口，和标準的接口概念基本相同，但是使用C++類型的接口，并且使用了Android的Binder IPC機制。Android封裝OpenMax的接口被StageFright使用，OpenCore沒有使用這個接口，而是使用其他形式對OpenMax IL層接口進行封裝
主要的功能和優點
OpenMAX IL API 能夠在應用程式、多媒體架構和編解碼庫，以及其支援的元件（比如，sources 和 sinks）之間建立統一的接口。對于使用者來說，元件自身及其内部的軟硬體結合情況都是完全透明的。其主要功能如下：
• A flexible component-based API core;
• Ability to easily plug in new components ;
• Coverage of targeted domains (audio, video, and imaging) while remaining easily extensible by both the Khronos Group and individual vendors;
• Capable of being implemented as either static or dynamic libraries;
• Retention of key features and configuration options needed by parent software (such as media frameworks);
• Ease of communication between the client and the components and between components themselves;
• Standardized definition of key components so all implementations of such “standard components” expose the same external interface (i.e. same inputs, outputs, and controls).
OpenMAX IL 軟體結構一
OpenMAX IL 軟體結構二
用戶端（Client）:
通路IL core或IL component的軟體層，可能是位于GUI應用程式的下層，如GStreamer。IL client是一個典型的功能塊，如filter graph multimedia framework, OpenMAX AL, 或application都可以調用它。IL client與OpenMAX IL core進行互動，利用IL core加載和解除安裝元件、在元件間建立直接通信以及獲得元件方法的入口。
core:
相關平台的代碼， 負責動态加載和解除安裝元件，協助元件間通信。一旦加載元件，API 允許使用者直接與元件進行通信，類似的，core API 允許使用者在元件之間建立tunnel通信通道，一旦建立，core API 不再被需要，其通信直接發生在兩個元件之間
端口（Port）:
元件的輸入輸出接口
元件（Component）:
OpenMax IL的單元，每一個元件實作一種功能。元件按照端口可分類為：
Source（隻有一個輸出端口）、
Sink（隻有一個輸入端口）、
Host元件（一個輸入端口和一個輸出端口），
Accelerator元件，它具有一個輸入端口，調用了硬體的編解碼器，加速主要展現在這個環節上。元件間的tunnel通道也是通過将一個元件的輸出端口連接配接到另一個元件的輸入端口來建立的。
隧道化（Tunneled）：
讓兩個元件直接連接配接的方式。通過隧道化可以将不同的元件的一個輸入端口和一個輸出端口連接配接到一起，在這種情況下，兩個元件的處理過程合并，共同處理。尤其對于單輸入和單輸出的元件，兩個元件将作為類似一個使用
OpenMAX IL 定義了三種通信方式：
1）Non-tunneled：
用于client 與 component 之間交換data buffers；
2）Tunneling：
用于元件之間互相交換data buffers的标準機制；
3）Proprietary communication：
用于兩個元件之間直接資料交換的專屬機制，并且可以作為tunneling的備選機制。
Component profiles：OpenMAX IL 元件的功能被分成兩種profiles
1、base profiles
2、 interop profiles。
Component states
1、無效的資料會導緻元件進入invalid狀态；
2、在IDEL狀态，元件應該擷取了所有所需的靜态資源；
3、executing狀态:
元件不再接收buffer，而是進行處理資料；
4、paused狀态:
元件維護一個buffer context，且不再處理資料和交換buffers；
Component architecture
Client與component之間的通信：
1、client通過OMX_EmptyThisBuffer來調用component的輸入端口；
2、client通過OMX_FillThisBuffer來調用component的輸出端口。
Tunneled buffer allocation
對于tunnel的兩個端口，
supplier端口會調用UseBuffer函數來要求鄰接的端口來處理buffers；
non-supplier端口會接受UseBuffer調用。
Component需要遵循以下規則：
1、supplier端口都要提供buffers；
2、在端口上可靠的傳輸buffer配置；
3、通過OMX_EmptyThisBuffer調用将buffer從輸出端口傳遞到另一component的輸入端口；
4、通過OMX_Fill_This_Buffer調用将buffer從輸入端口傳回給component的輸出端口。
Buffer payload
一般情況下，buffer中可用資料的起始點和範圍由定義在buffer頭中的 pBuffer，nOffset 和 nFilledLen 三個參數來決定:
pBuffer: 指向buffer的起始位址；
nOffset: 代表了buffer起始位址與實際可用資料位址之間的偏移量；
nFilledLen: 表示buffer中連續可用的資料的大小。
是以，buffer中可用資料的起始範圍分别為:
pBuffer + nOffset 和
pBuffer + nOffset + nFilledLen
在buffer中資料的存放方式有三種：
1、buffer要麼填滿，要麼部分填滿；
2、buffer中存放的壓縮資料都是以完整的幀為機關的；
3、buffer中隻存放一幀的壓縮資料。
前兩種都要求解碼器在解碼的之前對每幀資料進行解析，第三種情況則不需要解析。
Buffer flags and timestamps
Buffer flags 是存放在buffer中的表示特定屬性的資料，比如資料流結束；
Timestamps 是以微秒為機關的存放在buffer中的資料，用來在播放時确定各buffer的播放時刻。