This comment isn't quite right either: > I've been faced to a similar issue. Check that the parameters structure exist > as long the Engine run (not allocated on the stack). The TI routine will > simply keep the pointer and use it. It will not copy it.
As far as create params go (specifically for _remote_ codecs, like DM644x/OMAP3), these structs are copied (based on the .size field) out of the user-provided struct into a DSP Link-based MSGQ and sent to the remote processor - all in the context of the <VISA>_create() call. >From the sources (and you can see this call stack via "CE_DEBUG" trace as >well), this happens in >VIDENC1_create()->VISA_create()->VISA_create2()->Engine_createNode2() - here's >the code with the memcpy(), where the user-supplied params ptr is named >"nodeAttrs" and the .size field is in "nodeAttrsSize": Engine_createNode2(...) { ... if (nodeAttrs == NULL) { msg->cmdBuf.data.createNodeIn.argLength = 0; } else { assert(nodeAttrsSize <= (sizeof (RMS_Word) * RMS_MAXARGSLENGTH)); msg->cmdBuf.data.createNodeIn.argLength = nodeAttrsSize; memcpy(msg->cmdBuf.data.createNodeIn.argBuffer, nodeAttrs, nodeAttrsSize); } ... } You can see that the data is _copied_ into the MSGQ before it's sent to the remote DSP. One final notable - the algorithm/codec should also make a copy of these params(!) for its internal use, if it needs to them later. It's true that, after the codec is created/initialized, the MSGQ-based memory holding these params will be re-used. If the _codec_ is [incorrectly] just keeping a reference to these params - rather than [correctly] making a copy of them - I can see that the reference would go out of scope and the codec would get in trouble. Chris > -----Original Message----- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com > ] On Behalf Of eric Debief > Sent: Thursday, February 26, 2009 8:35 AM > To: davinci-linux-open-source@linux.davincidsp.com > Subject: Re: using extended params for MPEG4 encoding > > Hi, > > I've been faced to a similar issue. Check that the > parameters structure exist > as long the Engine run (not allocated on the stack). The TI > routine will > simply keep the pointer and use it. It will not copy it. > Hope this help. > Sorry if I 've missed the target, but i'm very very loaded this times. > > Eric. > > Le Thursday 26 February 2009 15:47:22 Stephen Berry, vous avez écrit : > > Vladimir Pantelic wrote: > > > Stephen Berry wrote: > > >> Vladimir Pantelic wrote: > > >>> Stephen Berry wrote: > > >>>> the routine follows. The call to VIDENC1_control is > the routine that > > >>>> segfaults. I'm not using the ividEncfxns->algControl call... > > >>>> > > >>>> #if 1 > > >>>> ext_params.videncParams.size = sizeof(IMP4VENC_Params); > > >>>> > > >>>> hEncode = (VIDENC1_Handle) ALG_create(1, (IALG_Fxns *)& > > >>>> MP4VENC_TI_IMP4VENC, > > >>>> (IALG_Handle) NULL, > > >>>> (IALG_Params *) > & ext_params); > > >>> > > >>> can you tell me why you use ALG_create and not VIDENC1_create()? > > >> > > >> because that is what the example did in the sdk. Is > there another way? > > > > > > yes, but your own code has VIDENC1_create() just below in > the #else > > > section, > > > so I was wondering why you did not use it. Actually, I > have no idea > > > what ALG_create actually does, > > > all I ever used where the VIDEENC_xyz functions. > > > > > > Also, all the CE exmaple I saw so did not use ALG_create etc.. > > > > I would be more than happy to use VIDENC1_create - but it > takes a param > > structure of VIDENC1_Params - which doesn't support the extended > > arguments that I'm trying to change. > > > > The code that Ti supplies in the demo uses VIDENC1_create, and that > > works just fine - its only when I use the ALG_create that > things go bad... > > > > There are several examples in the SDK that use the > ALG_create method, > > but they are so different from what I do now that it will take some > > effort to figure out what I need to change... and I need to get this > > unit out to a customer. > > > > Steve > > > > _______________________________________________ > > Davinci-linux-open-source mailing list > > Davinci-linux-open-source@linux.davincidsp.com > > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > > _______________________________________________ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source