Hi,
It looks like the default .cfg file is defining the codecs that could be
available in an engine.
The default encode demo seems to have an 'engine' consisting of a
mpeg4enc, g711, mpeg4dec - 3nos.
Now, the problem I faced was it was not able to 'Engine_open' a 2nd
codec-engine(having the JPEG) when another engine is already running.
Now, to bring the jpeg into the engine, I just removed the mpeg4dec and
the g711. Or, it looks like an engine can have any number of codecs- I
tried with 2 nos and it worked.
Donno clearly what is happening in the other side(MJCP).
May be Chris could give us an idea on what exactly is happening- Thank
you again for the inputs.
And the CE_DEBUG was just a too good feature. It show every piece of
transaction happening in the system.
Here is an excerpt from the configuration I'm using - I've commented out
the MPEG4DEC as you could see.
/*
* ======== Engine Configuration ========
*/
var JPEGENC = xdc.useModule('ti.sdo.codecs.jpegenc.dm355.ce.JPEGENC');
var MPEG4ENC =
xdc.useModule('ti.sdo.codecs.mpeg4enc.dm355.ce.MPEG4ENC');
/*
var MPEG4DEC =
xdc.useModule('ti.sdo.codecs.mpeg4dec.dm355.ce.MPEG4DEC');
var G711ENC = xdc.useModule('ti.xdais.dm.examples.g711.ce.G711ENC');
*/
var Engine = xdc.useModule('ti.sdo.ce.Engine');
var myEngine = Engine.create("encode", [
{name: "mpeg4enc", mod: MPEG4ENC, local: true, groupId: 1},
{name: "jpegenc", mod: JPEGENC, local: true, groupId: 1},
]);
/*
{name: "mpeg4dec", mod: MPEG4DEC, local: true, groupId: 1},
{name: "g711enc", mod: G711ENC, local: true},
*/
Cheers,
Deepak Shankar V
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On
Behalf Of Vladimir Pantelic
Sent: Saturday, March 28, 2009 8:19 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:
> 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.
so, what was the solution to the problem?
> This input has saved me from a 3 day debug session without a clue.
enlighten us :-)
>
> 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-sourc
>> e
>>
>> 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-sourc
>> e
>>
>
_______________________________________________
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
