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: [email protected]
> [mailto:[email protected]
> ] On Behalf Of eric Debief
> Sent: Thursday, February 26, 2009 8:35 AM
> To: [email protected]
> 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
> > [email protected]
> >
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
>
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> [email protected]
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> _______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
