We have a demo app running on our own hardware (based on a DM368) with an LCD attached to the VPBE and a image sensor attached to the VPFE.
We can measure a delay of ~120ms from capture to display by using a stopwatch. We take a picture of the stopwatch and the LCD screen, where the camera under test has the stopwatch within FOV so the LCD displays the stopwatch. Our frame time is 35ms, thus, we seem to be on a 3-frame latency within a margin of error.
We are following the DVSDK 3.1 imp-prev-rsz demo fairly closely. In terms of buffering, we are requesting 3 capture buffers and 3 display buffers (these seem to be the requested minimum of the drivers). We can change these minimums by modifying the drivers, but I'm assuming these minimums are present for a reason, and I'm not sure the allocation of 3 buffers necessarily means a three-buffer (or more) delay.
After the buffers are requested, we queue all of the capture buffers to the capture device, then start capture streaming. After that we queue all of the display buffers to the display device, then start streaming... It seems that perhaps queueing all of the buffers to each respective device might be causing a "prime-up" delay of several buffers. Is this true? Is there a better way to optimize latency within the confines of V4L2?
Regards,
Derek
