TERRIBLE performance using DM6446 MPEG4 encoder test app

Issues where the expected performance is several orders of magnitude away from what was expected are frequently due to the cache not being properly configured.  I expect this is likely your issue since I've seen with my own eyes that the codec can operate in real time!  This wiki article might help:

http://processors.wiki.ti.com/index.php?title=Enabling_64x%2B_Cache

Thanks for the good idea (first, I thought about some cache problem too).
Test application contains the appropriate cache initialization process (it uses BCACHE module of DSP/BIOS):

...

#define EXT_MEM_BASE (0x80000000)
#define EXT_MEM_SIZE (0x10000000)

  /* Cache Settings */
  XDAS_Void TestApp_EnableCache(void)
  {
#ifdef C6000
 BCACHE_Size size;

 size.l1psize  = BCACHE_L1_32K; /* L1P cache size */
 size.l1dsize  = BCACHE_L1_16K; /* L1D cache size */
 size.l2size   = BCACHE_L2_64K; /* L2  cache size */

 /* Set L1P, L1D and L2 cache sizes */
    BCACHE_setSize(&size);

    /* Cache Enable External Memory Space */
 /* BaseAddr, length, MAR enable/disable */
    /* Cache 0x80000000 --- 0x8FFFFFFF   */
    BCACHE_setMar((Ptr *)EXT_MEM_BASE, EXT_MEM_SIZE, BCACHE_MAR_ENABLE);
    BCACHE_wbInvAll(); /* No need to call BCACHE_wait() */
#endif /* C6000 */
  } /* TestApp_EnableCache */
                     

I've checked: this function is really called because C6000 is defined in project file (-d"C6000").

Peter Ladanyi said:

The file dman3.lib has another name and is placed another folder (".../dman3/lib/debug/dman3d.a64P" instead of ".../dman3/lib/dman3.a64P").

You're using a debug version of DMAN3.  Perhaps it is bogging things down with printf's or some other kind of instrumentation?

Are you using Codec Engine?

What versions of everything?

I'll try the release version of DMAN3 but I think, it wouldn't justify such this big delay.
Of course, I can accept some delay due to printf or other debugging thing (e.g. a few seconds) but I think, 5-6 minutes/frame is too long for that.
We'll see...

I built and ran test application according to codec's user's guide (SPRUEA2C).
Chapter 2.4. describes necessary steps and system requirements ("2.4. Building and Running the Sample Test Application").
It doesn't say about codec engine using test application.
Of course, using this codec in an application I'll have to use Codec Engine.
So the aswer is: I don't use Codec Engine running codec's test application.
Should I? How? (I have to block booting process of Davinci in DVEVM if I want to debug anything.)

Environment: DM6446EVM, XDS560R: v3.03.30, CCS: v3.3.82.13, Code Generation Tools: v6.0.25, DSP/BIOS: v5.32.04, Framework Components: v2.20.01, Windows 2000 Prof SP4
What versions do you think for?

Hi Peter,

Did you resolve the problem?

My problem is more worse, test app will hang at process function call.

-Xiaoyong Peng

"Hanging during a process() call" may be the result of a mis-configured DMAN3.  Some details here:

http://processors.wiki.ti.com/index.php/Framework_Components_FAQ#Why_does_my_alg_hang_in_ACPY3_wait.28.29.3F

Chris

From the list of components, I guess you are running the codec on the DSP and doing file I/O via JTAG to CCS on the PC to read video frames and write encoded bits? Transferring video frames over JTAG is going to be the main hold-up in this scenario, so I would attribute much of the "slowness" to this I/O mechanism. If you are measuring memory-encode-memory scenario, then ignore this comment.

Mark

Hello.
Just started working with MPEG4_Encoder_DM6446 (simulation mode (not on the processor itself)). I can not get the output bitstream. I do everything in accordance with the description MPEG4_Encoder_DM6446_UserGuide, located in the folder C: \ CCStudio_v3.3 \ c64xplus_mpeg4enc_02_02_04_production \ c64xplus_mpeg4enc_02_02_04_production \ packages \ ti \ sdo \ codecs \ mpeg4enc \ docs. The result appears in the folder Output file davincieffect_qcif_ref.bits 0 KB. Tell my how you got the output file! Maybe I'm not as something to do?

Dear Xiaoyong Peng,

I am sorry about delay.

Unfortunately, the problem has not been solved but the test application never hang at me.
It always finish without error (but its performance unacceptable).

Otherwise, recently we purchased another emulator (Blackhawk LAN560).
This gives much better results than earlier (Spectrum Digital XDS-560R).
Using LAN560 the test application's performance is 54-60 s / frame.

Summary: the result is 5-6 times better than earlier and about 60-100 times worse than I expect (in testing phase).

Peter

Dear Mark,

This could be the explanation of the measured performances.
(I would have not thought that file I/O via JTAG can such slow)
I will check.

Thanks.

Peter

Dear Alexsander,

I tried the codec you use (MPEG4EC64XPLUX) first.
I can compile and run its test application without any problem.
Output file was also correct.

Otherwise, the output file size is zero until file is written.
Size is correct after close the file only.

PS:
TI says the on DM6446 the MPEG4E644X (dm6446_mpeg4enc_2_00_004_production) is suggested.
Project file of this codec's test application was

faulty (e.g. path of dman3d library was bad) but after recovery it also works fine.

Peter

Dear Peter,

Thank you for your reply, at least I know LAN560 is better.

Xiaoyong Peng

Hello, Xiaoyong Peng

Did you resolve the problem?

 I have the same problem as you. In implementing the simulation program hangs MPEG4 codec. The sequential passage of the code realized that the application under test crashes in the function Process (). It is needed to encode one frame of information.
 Here it is:

BCACHE_wbInvAll (); / * No need to call BCACHE_wait () * /

handle-> fxns-> algActivate (handle);
outArgs_ext.videncOutArgs = outArgs;
/ * Basic Algorithm process () call * /
retVal = ividEncfxns-> process ((IVIDENC1_Handle) handle,
(IVIDEO1_BufDescIn *) & inputBufDesc,
(XDM_BufDesc *) & outputBufDesc,
(IVIDENC1_InArgs *) & inArgs,
(IVIDENC1_OutArgs *) & outArgs_ext);

Did you find the answer to this question?
 

Hi Alexsander,

The problem was gone when I changed board, so it should be caused by some hardware issues.

-Xiaoyong Peng

Hello, Xiaoyong Peng

Thank you for your reply. Tell me what platform you use?
In the description of the codec (Hardware), which I use indicated any TI's C64x + based platforms. But treatment does not work when using the DM6446 CycLe Accurate Simulator and DM6443 CycLe Accurate Simulator.

Thank you.

Hello, Chris Ring.
You refer to http://processors.wiki.ti.com/index.php/Framework_Components_FAQ # Why_does_my_alg_hang_in_ACPY3_wait.28.29.3F.
The article says that when using a simulator can occur sim bug. "If you are running on the simulator, you might be hitting a known simulator bug, that causes any transfer with ACNT> 16 to hang. CCS version 3.3.56 has fixed the issue." How can it be avoided?

What else can be errors if the algorithm does not return from the function process ()?

Peter Ladanyi said:

Remark:
I had to modify the project file TestAppEncoder.pjt because it couldn`t compile.
The file dman3.lib has another name and is placed another folder (".../dman3/lib/debug/dman3d.a64P" instead of ".../dman3/lib/dman3.a64P").

I have met the same thing ~

without dman3d.a64P,how can you build it?OR U just use dman3.a64h instead?

Hello, Wang Ke

There was no dman3d.a64P in our development environment.
Instead, linking with library dman3.a64P was success.

Peter

Dear Peter

How did you solve the problem on the terrible performance? Now I'm facing the same problem while running the H264_ENC on DM6437, the output stream is completely right but it costs 1min to encode 1 frame.

Best Regards!

cedar sun

Dear cedar sun,

I think, the slow file I/O via JTAG emulator was the reason for terrible performance of DM6446 MPEG4 encoder (in a debug environment).
Although, I didn't try a memory-to-memory method to check this, but the encoder reached the specified real-time performance in my application (in a real environment).

Best regards,
Peter

Thanks a lot Peter!

Finally I realized the problem that the I/O operation costs most of the time. Did you plant the MPEG4 encoder in the DM6446 or another C64x+ based platform?

I have built the H264 encoder of DM6446 which is called valid in any C64x+ based platform, but when encoding in PAL D1, the encoder could not reach the real time

performance. The time consumption is 70ms more or less. What do you think about it Peter? Did you met this problem?

Best regards!

Cedar 

Dear Cedar,

I used MPEG4 encoder in DM6446 only, but I did not really test DM6446 H.264 encoder.
Although, MPEG4 encoder is working real-time on D1 resolution video (25fps, PAL, 720x576) in my application, I could not reach the specified MHz performance of DM6446 MPEG4 encoder.

I think, the performance which is specified by Texas was tested under a direct test program (linked with the static library of codec) on DSP without any ARM-DSP data transfer nor using any framework (e.g. Codec Engine).
Of course, it is a theoretically (ideal or maximum) performance. So, you probably will never reach it in a real life.

Best regards,
Peter

Hello everyone,

I'm trying to implement mpeg4 encoder/dekoder on c6748 using 64x+ lib. I have some problems, I stuck on process() function, I use ccs 5.3. Maybe can somebody send me working program that I can use as pattern? I can send some of my project in return. It is very important for me to run this coding. H264 also can be.

Kind regards,

I don't excacly know if I do wright in cfg file:

var MPEG4ENC = xdc.useModule('ti.sdo.codecs.mpeg4enc.ce.MPEG4ENC');

var Engine = xdc.useModule('ti.sdo.ce.Engine');

var FCEngine = Engine.create("encode", [{name: "mpeg4enc", mod: MPEG4ENC, local: true, groupId: 1},]);

xdc.loadPackage("ti.sdo.ce.video");

var videnc   = xdc.module('ti.sdo.ce.video1.IVIDENC1');

var osalGlobal = xdc.useModule('ti.sdo.ce.osal.Global');

osalGlobal.runtimeEnv = osalGlobal.DSPLINK_BIOS;

should I do something else?? can somebody help me here? I stucked for a week already in this.