Encode demo DM6467 Video duration mismatch

mmm, I am wondering if the playback is happening at a faster pace than the video capture.  Have you tried timing the video encode time to see if it matches the time specified via -t option.  If so, it may be that the decoding is happening as fast as the processing power would allow, which is likely shorter than encode time.  You can also do a quick test and encode a smaller resolution and see how fast it plays back...

Hi Juan,

I encode a "264" video using encode demo application, say for 2 minutes, and then I playback it using Elcard. Its duration is 10 seconds shorter than that specified with -t option ( -t 120).I don't use de decode application to check that. I've tried diferent durations (-t xxx) and the result is always the same. The video lacks 5 seconds (that is 150 frames) per minute.

ok,  just had a quick look at the demo, and it appears you are correct.  The time passed in via '-t' function is never used for the encoding, it simply serves to keep track how long the demo has been running and quits after the specified number of seconds.  During this time, encoding is where it spends most of its time, but it also spends time updating OSD, printing information and managing the flow of audio and video buffers... In other words, the -t variable used in the demos is not used to manage time stamps that may be placed on the encoded video stream.

I see what you mean. But I think there may be other issues involved. I checked the CPU load and it is always < 30%. I wrote a new program to test the encode process only, no OSD, and no user interface. Nothing changes, the output video is shorter than  expected.  And it always loses the same amount of frames per minute, no matter what I do.

I don't know how I'm supposed to playback the video file if the number of frames doesn't match the actual duration of the recording process.

I encode for a minute, and I just get 55 seconds of encode data (1650 frames instead of 1800). Should I repeat some frames every now and then to get the correct duration?

Thanks.

This is very interesting, I am wondering if the DSP simply cannot keep up with the encoding process @ 30 fps and is dropping frames ( I would hope not, especially with lower resolutions).  Another possibility is that DSP is only being called to encode 1650 frames, in which case the issue would lie with the way the linux application is coded.  Can you place a counter rigth before calls to VIDENC_process (the function that calls on DSP to encode a frame) and have the counter printed to the screen (printf) before the program exits completely?

Hi Juan,

I did what you suggest (frame counter/ printf). And you are right. The DSP can not cope with 720P60 input. (even if you discard half the frames when capturing, that is 720P30). I just checked it.

The maximum frame rate at which the DSP is able to work is, at the most, 40 fps., You can achieve that by doing the most basic and simple operation: Loopback (Capture_get -Display_put. No encoding, no user ineterface, no osd)

When encoding, the maximum frame rate I've been able to achieve is 29 fps. I'm working on the subject to get 30 fps.(cleaningup,  reomoving and reprogrammig some sections)

I know there is another chip -729Mhz (I think). Do you know if new development kits ship with  that part. Which one?

What about the 1Ghz part?

Thanks

I believe the current EVM has the 729 MHz part on it, so it should support both 594 MHz and 729 MHz modes; I believe the speed the chip is currently programmed at is printed by UBL when you boot the EVM; a UBL upgrade may be all you need to get to 729 MHz if it is not there already.  

Additionally, the 1 GHZ EVMs should be available 1Q10.

Thanks Juan,

Unfortunately, my development kit has the 594 part on it, so I don't know what I'm going to do right now. I will probably wait until next year to purchase the new development kit.

Thanks again for your help.