Hi Chris, I thank you a lot for this input - especially regarding the .cfg file. Now I'm able to do a mpeg4 and a parallel jpeg too.
This input has saved me from a 3 day debug session without a clue. Cheers, Deepak Shankar V -----Original Message----- From: Ring, Chris [mailto:[email protected]] Sent: Friday, March 27, 2009 8:46 PM To: Deepak Shankar-TLS,Chennai.; Vladimir Pantelic; [email protected] Cc: [email protected] Subject: RE: Suspend MPEG and do JPEG and vice versa on the fly "Server" is only relevant for "remote" codecs. Remote codecs exist on processors with full-blown DSP's (e.g. OMAP3, DM644x, etc) and "significant" hardware accelerators (e.g. DM357). The DM355 does _not_ have a DSP, and therefore does not have remote codecs. So there is no "server" in the system. It may be that the first codec consumes a scarce resource (like the MJCP) and therefore, when creating the second codec that wants it, that resource is not available. To get a better look at what's going on, you could set CE_DEBUG=2 during your second codec create, and you should get more details about what failed. http://tiexpressdsp.com/index.php?title=CE_DEBUG To see if it's _really_ a resource issue, you may have to configure RMAN.trace = true; in your app's .cfg script. Something like this: RMAN = xdc.useModule('ti.sdo.fc.rman.RMAN'); RMAN.trace = true; RMAN is the "Resource Manager" for many of the codec resources. By enabling the RMAN trace, and especially running at CE_DEBUG=2 or =3, you can get further insight into what resources each codec is asking for, and whether it's "persistent" (non-shareable) or "scratch" (shareable, but with a context save/restore overhead). Chris > -----Original Message----- > From: [email protected] > [mailto:[email protected] > ] On Behalf Of Deepak Shankar-TLS,Chennai. > Sent: Friday, March 27, 2009 5:56 AM > To: Vladimir Pantelic; [email protected] > Cc: [email protected] > Subject: RE: Suspend MPEG and do JPEG and vice versa on the fly > > > Hi, > > Thanks a lot for the inputs. > > I think the codecs are running in the same server - for if I > dynamically kill the MPEG application and do a JPEG its working very > well. Just that I'm trying to do it in parallel. However is it > possible to program where the codec should run- by server I was > thinking the MJCP can work only as a single server(DSP server??) in > the DM355 for the ARM. Or is there a mechanism I could run 2 servers > on the same DSP... Please provide you inputs. > > Is there any other option in the DM355 to make it work in parallel. > Further Could you please suggest me a point to dig in the > DVSDK/(documentation or code) if its ever possible to make the JPEG > and MPEG run in parallel or is it a HW limitation? > > Thank you > > Cheers, > Deepak Shankar V > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Vladimir Pantelic > Sent: Friday, March 27, 2009 12:36 PM > To: [email protected] > Cc: [email protected] > Subject: Re: Suspend MPEG and do JPEG and vice versa on the fly > > Deepak Shankar-TLS,Chennai. wrote: > > Hello all, > > > > I'm using the dm355-DVSDK, Montavista Linux and trying the demos - > > encode and JPEG. All those are working very well when run > as separate > > processes. > > > > However, Now I'm trying to build a custom application which > can do a > > MPEG or JPEG based on some external events. > > Something like when the GPIO is high dump an MPEG file. > When it is low > > > capture a jpeg image every 1 second. > > > > The problem is I'm not able to use both the JPEG and the > MPEG codecs > > simultaneously. When the MPEG compression is in progress, a call to > > the 'IMGENC1_create(ce, encoderName, &encParams)' is > failing. Is this > > a inherent nature of MJCP. Should I have to deinit the MPEG > resources > > when I want to do a JPEG, or is there a better way to do that. > > are the two codecs in the same server? if not, it cannot work. you > will > have to unload one to load the other I think. Even if they are in > the same server, there could be system resources that cannot be > shared, so a gain they would not work in parallel. > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > DISCLAIMER: > -------------------------------------------------------------- > --------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its > affiliates. Any views or opinions presented in this email are solely > those of the author and may not necessarily reflect the opinions of > HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, > modification, distribution and / or publication of this message > without the prior written consent of the author of this e-mail is > strictly prohibited. If you have received this email in error please > delete it and notify the sender immediately. Before opening any mail > and attachments please check them for viruses and defect. > > -------------------------------------------------------------- > --------------------------------------------------------- > > _______________________________________________ > 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
