OpenMAX
From DaphneWiki
(Created page with "==OpenMAX== ===Core=== Dynamically loads/unloads components. Sets up tunnels between two components. API is probably the same across platforms. ===Component=== Individual blo...") |
(→OpenMAX) |
||
Line 1: | Line 1: | ||
- | ==OpenMAX== | + | ==OpenMAX IL== |
===Core=== | ===Core=== | ||
Dynamically loads/unloads components. | Dynamically loads/unloads components. | ||
Sets up tunnels between two components. | Sets up tunnels between two components. | ||
+ | |||
+ | Accesses component's methods. | ||
API is probably the same across platforms. | API is probably the same across platforms. | ||
Line 10: | Line 12: | ||
Individual blocks of functionality, including "sources, sinks, codecs, filters, splitters, mixers, or any other data operator." | Individual blocks of functionality, including "sources, sinks, codecs, filters, splitters, mixers, or any other data operator." | ||
+ | |||
+ | Types of components: | ||
+ | Source: component with single output port | ||
+ | Sink: component with single input port | ||
+ | Host: run entirely on host processor | ||
+ | |||
+ | Component provider defines functionality of given component. | ||
+ | |||
+ | Operate on four types of data: audio, video, image, and other (time data for sync). | ||
+ | |||
+ | Provides access to standard set of component functions via component handle. | ||
+ | |||
+ | Must have at least one port to conform to official standard. | ||
+ | |||
+ | Data communication calls to components are non-blocking. | ||
====Ports==== | ====Ports==== | ||
Line 18: | Line 35: | ||
between two components can be established by connecting the output port of one | between two components can be established by connecting the output port of one | ||
component to a similarly formatted input port of another component." | component to a similarly formatted input port of another component." | ||
+ | |||
+ | Ports must support callbacks to the IL client. | ||
+ | |||
+ | ====Communication==== | ||
+ | #Non-tunneled communication: buffer exchange between IL client and component. | ||
+ | #Tunneled communication: direct buffer exchange between two components. | ||
+ | #Proprietary: we don't want to deal with this nonsense. | ||
+ | |||
+ | ====Profiles==== | ||
+ | #Base: does not need to implement tunneling | ||
+ | #Interop: must implement tunneling | ||
+ | |||
+ | ====States==== | ||
+ | All components start in the "unloaded" state and must be "loaded" via a call to the core. All other state transitions may then be achieved by communicating directly with the component. On error, the component automatically reverts to the "unloaded" state. | ||
+ | |||
+ | #WAIT FOR RESOURCES: waiting for initialization to finish | ||
+ | #IDLE: component has all static resources but is not processing data ("stopped") | ||
+ | #EXECUTING: pending reception of buffers to process data, will make callbacks | ||
+ | #PAUSED: won't process any data, can resume where it left off (idle cannot) | ||
+ | |||
+ | |||
+ | ===IL client=== | ||
+ | Your application, some third-party framework, or OpenMAX AL. | ||
+ | |||
+ | Always communicates to components via core. |
Revision as of 21:53, 20 August 2012
Contents |
OpenMAX IL
Core
Dynamically loads/unloads components.
Sets up tunnels between two components.
Accesses component's methods.
API is probably the same across platforms.
Component
Individual blocks of functionality, including "sources, sinks, codecs, filters, splitters, mixers, or any other data operator."
Types of components: Source: component with single output port Sink: component with single input port Host: run entirely on host processor
Component provider defines functionality of given component.
Operate on four types of data: audio, video, image, and other (time data for sync).
Provides access to standard set of component functions via component handle.
Must have at least one port to conform to official standard.
Data communication calls to components are non-blocking.
Ports
"Data communication to and from a component is conducted through interfaces called ports. Ports represent both the connection for components to the data stream and the buffers needed to maintain the connection. Users may send data to components through input ports or receive data through output ports. Similarly, a communication tunnel between two components can be established by connecting the output port of one component to a similarly formatted input port of another component."
Ports must support callbacks to the IL client.
Communication
- Non-tunneled communication: buffer exchange between IL client and component.
- Tunneled communication: direct buffer exchange between two components.
- Proprietary: we don't want to deal with this nonsense.
Profiles
- Base: does not need to implement tunneling
- Interop: must implement tunneling
States
All components start in the "unloaded" state and must be "loaded" via a call to the core. All other state transitions may then be achieved by communicating directly with the component. On error, the component automatically reverts to the "unloaded" state.
- WAIT FOR RESOURCES: waiting for initialization to finish
- IDLE: component has all static resources but is not processing data ("stopped")
- EXECUTING: pending reception of buffers to process data, will make callbacks
- PAUSED: won't process any data, can resume where it left off (idle cannot)
IL client
Your application, some third-party framework, or OpenMAX AL.
Always communicates to components via core.