Sorry, had to be more specific in my question i guess. What i meant to ask was (in the "replace" query), should I replace the code in PVMF files to redirect it to my IL core (obviously this is not the best practice, but a desperate one!!).
Anyways, I got this RESOLVED. The issue was that in trying to be different, I was using a unique ROLE string and things were going haywire!! Once I changed it to video_decoder.mpeg4 (instead of video_decoder.hvmp4), my OMX_GetHandle function got a call. I now see that in every core function, I am getting the 1st call before the s/w ones. This is tune with what the spec says (vendor cores will have higher priority over s/w). Eventually, I'm now a happy camper :-) HV On May 18, 4:47 pm, Deva R <[email protected]> wrote: > >We are NOT supposed to replace the software MP4 component with our > >vendor specific version rt? > > Default arm based codecs (PV s/w OMX components) with android 2.1 - are good > for most of the codec types., > but when it involves huge clips (higher resolution like D1, 720p, 1080p, and > higher bit rate 12 or 20Mbps., upto 40Mbps), throughtput of s/w codecs > becomes limitation factor., > we need to develop h/w codecs and replace.. > > >I am assuming that both (software and > >vendor specific) the cores need to be present with their respective > >components (like the s/w & h/w enabled MPEG-4 decoders). Is that a > >correct assumption? > > True., both s/w codecs, and h/w codecs can co-exist. > i remember we even have modified code to chose appropriate components based > on component capabilities and source clip parameters.., > > > > > > On Mon, May 17, 2010 at 9:11 PM, HV <[email protected]> wrote: > > Hey guys, > > > Anybody who's developed their own component, could you please > > respond? After looking @ some more code, I'm all the more confused!! > > We are NOT supposed to replace the software MP4 component with our > > vendor specific version rt? I am assuming that both (software and > > vendor specific) the cores need to be present with their respective > > components (like the s/w & h/w enabled MPEG-4 decoders). Is that a > > correct assumption? > > > Thanks > > HV > > > On May 16, 6:30 pm, HV <[email protected]> wrote: > > > Hi Folks, > > > > I'm working on adding my own MPEG-4 decoder and currently stuck with > > > the OMX_GetHandle (basically, my component is NOT getting a call into > > > this function). After going thru the code, I figured out that > > > PVMFOMXBaseDecNode::DoPrepare (in ~nodes/pvomxbasedecnode/src/ > > > pvmf_omx_basedec_node.cpp) is where I need to start off. > > > > Looking deeper into the code, it seems that a MIME type is sent in > > > for which this function sets up the ComponentRole (in input params) > > > and calls: > > > > * OMX_MasterGetComponentsOfRole( ) twice (however this doesn't call > > > the component's GetComponentsOfRole) > > > * OMX_MasterConfigParser > > > * OMX_MasterGetHandle which eventually calls the component's > > > OMX_GetHandle( ) > > > > My question is, is the above sequence specific to PV's software > > > decoders or even hardware vendors need to go thru the same? If so, it > > > doesn't seem to match up to what the OpenMAX call sequences PDF says. > > > Would appreciate your responses. > > > > Best regards > > > HV > > > > -- > > > unsubscribe: > > > [email protected]<android-porting%2Bunsubscribe@ > > > googlegroups.com> > > > website:http://groups.google.com/group/android-porting > > > -- > > unsubscribe: > > [email protected]<android-porting%2Bunsubscribe@ > > googlegroups.com> > > website:http://groups.google.com/group/android-porting > > -- > unsubscribe: [email protected] > website:http://groups.google.com/group/android-porting -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
