Control flow of the OMX codec component under Android4.2.2 stagefright

This article is the source code of their own reading a bit of summary. Please specify the source for the transfer.

Welcome to communicate with you.

qq:1037701636 Email:[email protected]

Android source code version number version:4.2.2; Hardware platform Full Chi A31

The reason why this piece of content is extracted separately is that it has a certain level, the structure is unified, the API function design needs to implement the interface unique to OMX architecture.

1. In the previous post Android4.2.2 stagefright the A31 in the multimedia architecture of OMX plugins and codec components we mentioned. With the binder architecture, a node:node_id is obtained after creating an actual codec node on the MPS thread. For example, the following will create a OMXCODEC structure on the MPs side based on the associated node information as a similar local codec.

.....            Sp<omxcodec> codec = new Omxcodec (                    OMX, node, quirks, flags,                    Createencoder, mime, componentname,                    source, NativeWindow);//Create a local OMXCODEC decoder. Node becomes a possible operation of the key IOMX::NODE_ID//OMX for Master            Observer->setcodec (codec);//The decoder is given observer            err = codec-> Configurecodec (meta);//Configure the local decoder based on the data source ...

In the CONFIGURECODEC configuration of this decoder. We are able to see some control operations on previously assigned decoder nodes.

We use one of its function calls as an example to perform a layer-by-layer analysis of the control flow:

Setvideooutputformat (mmime, meta);//Set Video output format

Momx->getparameter (Mnode, omx_indexparamportdefinition, &def, sizeof (DEF))

Here we see that MOMX is an anonymous Bpomx object that was obtained when Awesomeplayer was created.

Finally, the Mediaplayerservice is now in the middle of the OMX object to achieve getparameter.

Operation under the 2.OMX object.

status_t omx::getparameter (        node_id node, omx_indextype index,        void *params, size_t size) {    return Findinstance (node)->getparameter (            index, params, size);}

Findinstance (node) Here is an example of a Omxnodeinstance object that is based on this node_id to obtain a previous note:

Omxnodeinstance *omx::findinstance (node_id node) {    Mutex::autolock autolock (mLock);    ssize_t index = mnodeidtoinstance.indexofkey (node);    Return Index < 0? NULL:mNodeIDToInstance.valueAt (index);}

Finally, it becomes a call such as the following:

status_t omxnodeinstance::setparameter (        omx_indextype index, const void *params, size_t size) {    Mutex:: Autolock Autolock (mLock);    Omx_errortype err = Omx_setparameter (            mhandle, index, const_cast<void *> (params));    return Statusfromomxerror (ERR);}

The realization of 3.OMX_XXX

#define Omx_getparameter (                                           hcomponent,                                                 nparamindex,                                                componentparameterstructure)                            ((omx_ componenttype*) hcomponent)->getparameter (                 hcomponent,                                                 nparamindex,                                                componentparameterstructure) /    * Macro End */

Omx_setparameter and other macro functions are the core of Omx_core. It is also the embodiment of the OMX il layer in the original OPENOMX. Look at the type of mhandle, as a member variable of a Omxnodeinstance object. He maintains a handle to the underlying codec component library that was previously returned by Makecomponentinstance. This looks like a OMX node instance, a handle that operates on the lowest-level decoding component. Can see handle to Omx_componenttype type.

To see its structure type:

typedef struct omx_componenttype{    omx_u32 nSize;    Omx_versiontype nversion;    Omx_componentnametype Ecompname;    Omx_ptr pcomponentprivate;    Omx_errortype (*getparameter) (            omx_in  omx_handletype hcomponent,             omx_in  omx_indextype NIndex,            omx_in  Omx_ptr componentparameterstructure), .........

This handle is obtained when the decoder node was created before, through the name of the decoder that needs to be created, through the OMX plugin library, and then into the libomxcore.so (OMX IL intrinsic structure) call Omx_ GetHandle to get the Platform decode Library libomxvdec.so under the corresponding component name. or libomxvenc.so and so on.

This handle is initialized with the following completion:

void* Aw_omx_create_component_wrapper (omx_ptr obj_ptr) {aw_omx_component *pthis = (aw_omx_component *) obj_ptr;// Omx_vdec Object omx_componenttype* component = & (PTHIS->M_CMP);//Initialize m_cmp memset (&pthis->m_cmp,0,sizeo    F (omx_componenttype));    component->nsize = sizeof (Omx_componenttype);    Component->nversion.nversion = omx_spec_version;    component->papplicationprivate = 0; Component->pcomponentprivate = obj_ptr;//holds omx_vdec This object component->allocatebuffer = &aw_omx_component    _allocate_buffer;    Component->freebuffer = &aw_omx_component_free_buffer;    Component->getparameter = &aw_omx_component_get_parameter;    Component->setparameter = &aw_omx_component_set_parameter;    Component->sendcommand = &aw_omx_component_send_command;    Component->fillthisbuffer = &aw_omx_component_fill_this_buffer; Component->emptythisbuffer = &aW_omx_component_empty_this_buffer;    Component->getstate = &aw_omx_component_get_state;    Component->getcomponentversion = &aw_omx_component_get_version;    Component->getconfig = &aw_omx_component_get_config;    Component->setconfig = &aw_omx_component_set_config;    Component->getextensionindex = &aw_omx_component_get_extension_index;    Component->componenttunnelrequest = &aw_omx_component_tunnel_request;    Component->usebuffer = &aw_omx_component_use_buffer;    Component->setcallbacks = &aw_omx_component_set_callbacks;    Component->useeglimage = &aw_omx_component_use_EGL_image;    Component->componentroleenum = &aw_omx_component_role_enum;    Component->componentdeinit = &aw_omx_component_deinit; return (void *) component;

With the above assignment, we focus on this component->pcomponentprivate = Obj_ptr, which maintains the decoder instance of the hardware platform into the handle structure. Because finally the operation must be back to the bottom of the decoder control.

This is the structure of OMX il that gives developers the convenience and planning. Through this we can summarize the need for the following files to connect to the lower level of the codec:

Xxx_omx_core.c and omx_core_cmp.c Two source files to complete. The former provides an upward interface for creating a codec instance. The latter provides implementations such as the above-mentioned XXX_OMX_COMPONENT_API interface, while the actual fact is now called the codec-related API to handle:

Omx_errortype aw_omx_component_get_parameter (omx_in omx_handletype     hcomp,                                             omx_in omx_indextype ParamIndex,                                             omx_inout omx_ptr     paramdata) {omx_errortype Eret = omx_errorbadparameter;aw_omx_component *pThis = (hComp)? (Aw_omx_component *) (((Omx_componenttype *) hcomp)->pcomponentprivate): Null;debug_print ("Omxcore:aw_omx_component_get_parameter%x ,%x,%d\n ", (unsigned) Hcomp, (unsigned) paramdata,paramindex); if (pThis) {Eret = Pthis->get_parameter (Hcomp, Paramindex,paramdata);} return Eret;}

Here the Pthis technology is currently the bottom of the control entry for the decoder component. That is, the so-called Aw_omx_component derived class object.

That is to say that we have to build the codec needs real aw_omx_component of the relevant interface functions, can see here our most basic decoder component is the implementation of these functions, speed up the definition of a new component type, the following are the definition and implementation of several interfaces:

Omx_errortype  omx_vdec::set_parameter (omx_in omx_handletype hcomp, omx_in omx_indextype paramIndex,  OMX_IN Omx_ptr paramdata)

Omx_errortype  omx_vdec::get_parameter (omx_in omx_handletype hcomp,                                       omx_in omx_indextype  ParamIndex,                                       omx_inout omx_ptr     paramdata)

Here we basically go through the omxcodec to the bottom of the codec components of the control, clear hierarchy. The interface specification gives us a high-speed development, the core of which we need to do is to implement the related business in our own codec components, which is very close to our own hardware platform.

4. Summarize what you need to do to create a new codec component belonging to the Stagefright OMX

The core work we have to do is the design of the two library files, libomxcore.so and libomxvdec.so.

But they all need to comply with OMX's agreement.

Having analyzed so many control flows, and already have so-called Omxcodec, perhaps the main content will be data flow processing.

Control flow of the OMX codec component under Android4.2.2 stagefright