How to control maximum frame rate with DM355?

The best way to get an approximation is to look at the corresponding MPEG4 and JPEG  data-sheets included with the DVSDK software; by giving a quick glance at these documents, it appears to take about 16 msec for MPEG4 D1 frame and 4 msec for JPEG; these are rough estimates.  The codec data sheet have much more information including DDR usage, memory resources needed.... which may also be important when evaluating your overall system.

re: 16ms for MPEG4 and 4 ms for Jpeg

Can you tell me which documents those are? I can not locate them.

Thanks!

I got this information from the codec data-sheets; I do not have my DVSDK installation in front of me right now, but there should be a folder similar to

dvsdk_1_30_01_41/dm355_codecs_1_12_003/packages/ti/sdo/codecs

Let me knoe if this helps.  Otherwise, I will look up the exact location when I get to the office tomorrow.

That helps. I found them all tucked neatly away down there!

thanks!

I am trying to compare the jpeg decode timing with the mpeg4 decode timings.

In SPRS489.pdf  ( MPEG4 DECODER SPEC)  I see the peak time for a 720x480 frame for mpeg is around 12.4 ms. (MPEG4_DEC_003) and around 14 ms for the DEC_002 decoder. As far as the ARM loads and the MJCP loads .. how are they calculated into determining the real decode frame time worst case?

In SPRS487 ( JPEG Decoder) the Total Process time for a D1 frame came out to just under ten seconds.

AM I reading the proper data here. Is the Jpeg decoder capable of 4ms  D1 decodes?

Thanks!

Jona

Jona,

I believe the numbers in the data-sheet are obtained via an ARM application calling on MJCP to do most of the work (in a similar fashion as our encode and decode demos).  The ARM load is primarily the buffer allocations and calling into the codec engine functions, the MJCP load is primarily the time spent as encoding or decoding (as a result of process call by ARM).  As you can imagine, it is difficult to predict what a customer's complete integrated system will look like; therefore, these numbers are obtained by when the test App is essentially the only thing running on the system.  If you have many other tasks running on the ARM that compete for resources (e.g. DDR bandwidth), these numbers may differ slightly.

With regards to MPEG4, as you probrably know, we have many types of frames, I, P, B... typically, I frames take the longest to decode and account for the peak time numbers.

With regards to JPEG, I believe you mean total process time for D1 is under 10 msec (instead of seconds).  Not sure where you got 4 msec from, but I would probrably stick to the total processing numbers (worst case), which is slightly under 10 msec for JPEG D1 frame.

Not sure where you got 4 msec from, but I would probrably stick to the total processing numbers (worst case), which is slightly under 10 msec for JPEG D1 frame.

The 4ms number was posted in the first post in this thread. Thanks for your answer. I will look into this a bit more this morning.

now I see where you got the 4 msec from (me). :)  I likely looked at the highest (worst case) MJCP number in the data-sheet and rounded up (this is the time actually spent on the decoding).