faster way to get the image

You might benefit from using EDMA to pass video data between DDR2 and CPU (ARM or DSP); with regards to any of the VPSS blocks (for capture, display, resize...), VPSS has its own DMA engine which is always enabled.

If you are not doing any unnecessary copies (and with shared memory you should not have to) than the image handling slowness must be coming from somewhere else in the system, I am not very familiar with Windows CE tools but if there are any analysis abilities associated with it like the SOC Analyzer tool we use for Linux, that would probably be a good way to try to debug this and find what is slowing you down.

For a more general analysis, how fast do you measure your algorithm at, and how slow are your frames being serviced in total, perhaps most importantly what is the difference between the two?

When you say the image handling is slow do you mean that you are dropping frames or that there is just a latency between when you capture a frame and it is displayed (or the processing is complete)?

Sometimes I'm loosing frames, but not always, it depends on the motion into the movie. And that looks terrible in a movie.

what do you mean by: "how fast do you measure your algorithm at, and how slow are your frames being serviced in total" ??

Peter Brandstetter said:

what do you mean by: "how fast do you measure your algorithm at, and how slow are your frames being serviced in total" ??

I was interested in how long your algorighm takes to complete a frame, probably measured in miliseconds or cycles, and the total time for a frame to be serviced would be relative to your actual frame rate (at 30fps this would be 33ms, if you are dropping frames it will be >33ms). The idea being to narrow down if the problem is at the system level servicing the video drivers and the algorithm or if it is the algorithm itself.

If you are loosing frames depending on motion in the movie that sounds like an algorithm level issue, since the video drivers and framework should not care about the content of the frame, on the other hand it could be that you only percieve the frame drops during certain motion within a movie in which case you could have your code print a message every frame or every few frames to figure out if the frame rate is constantly slow or really varying by video motion. What kind of algorithm are you running in this case? Typically video compression algorithms can vary in performance depending on the motion within the video so I would guess some sort of MPEG or h.264?

One frame can need 40ms (25fps PAL). Most of the time, this limit is not reached, but sometimes it is reached.

I use a selfmade deinterlacing algorithm. This detect for every pixel if there is motion in it, if there is one, it calculates a blending, else it's a static pixel and it keeps its value.

I know that i have not a lot of time for calculation, because it needs so long time to get the image and put it to the displaybuffer.

But now i will use the EDMA to solve the image handling problem, than i have more time for the algorithm, so i will not lose frames depending on motion, or i can use a better algorithm.

Thx

Peter

It sounds like you could benefit from double buffering, with a double buffering scheme the capture and display times should not matter, only the time the algorithm takes to finish will. This can add latency between your input and your output, but will allow more time for any processing algorithms to complete.