Processing and rendering media (e.g., audio or video) is a very popular application on computers, cellular phones, and embedded computing devices. Many different software applications exist to perform the media processing and rendering, some specific to one type of computing device, some which exist on multiple platforms. Underlying the software is typically a media framework application programming interface (API), which provides access to the media capabilities of the computing device. A media framework additionally has an associated set of functionality that may be used with the framework to build new media applications, referred to variously as components or plug-ins. These components may be authored by the framework authors and included along with the framework, or they may be authored by a third party and distributed separately. There exist several media frameworks, e.g., DirectShow, OpenMAX, GStreamer, QuickTime, Helix DNA, Xine, etc. Some of these media frameworks (e.g., DirectShow, QuickTime) are authored by a software company and distributed as closed-source software. Some of the media frameworks (e.g., OpenMAX) have functionality specified by a central organization, but implementation of the functionality left to outside developers, for distribution as either open or closed-source software.
Many software components exist for the OpenMAX framework, and many can be used together to form a single application. OpenMAX components forming an application communicate both with OpenMAX framework and with each other. Communication between OpenMAX components can be directly from one component to the next, referred to as communication in tunnel mode, or it can pass through and be controlled by the OpenMAX framework, referred to as communication in non-tunnel mode. Some OpenMAX components support communication in either tunnel mode or non-tunnel mode, and some OpenMAX components support communication only in non-tunnel mode. Controlling and keeping track of non-tunnel mode communications can be significant overhead for OpenMAX framework, but is necessary to support communications involving components that do not implement tunnel mode communication. Building a non-tunnel mode communication handler that is efficient even when there is a large, complex network of components can be significant work for the software developer implementing OpenMAX framework.