|
[DPRG] V4L capture loop timing constraints
Subject: [DPRG] V4L capture loop timing constraints
From: Chris Jang
cjang at ix.netcom.com
Date: Fri Jun 1 08:28:12 CDT 2007
I have a question about Video4Linux in practice. Below is the
canonical mmap video capture loop as documented in:
http://www.linuxtv.org/downloads/video4linux/API/V4L1_API.html
/* setup everything */
VIDIOCMCAPTURE(0)
while (whatever) {
VIDIOCMCAPTURE(1)
VIDIOCSYNC(0)
/* process frame 0 while the hardware captures frame 1 */
VIDIOCMCAPTURE(0)
VIDIOCSYNC(1)
/* process frame 1 while the hardware captures frame 0 */
}
My experience with this using the Michael Xhaard spca5xx driver
on a 200 MHz ARM9 PC104 SBC is tight timing constraints between
ioctl calls. In my application (Stella the robot), frame
processing must be between 70 to 80 ms or else most captured
images are corrupted. Unfortunately, I am stuck with a 2.4.x
kernel so can not provide timing resolution better than 10 ms
granularity.
I'm wondering if the timing constraint is due to device driver
limitations or something inherent in the USB or V4L subsystems,
perhaps exacerbated by a relatively slow CPU. The typical V4L
platform is a desktop or laptop computer running at several
gigahertz. Perhaps interrupt servicing can not keep up without
this excess of speed.
At 10 fps, 100 ms separates each frame. If 20 ms is spent in V4L
and OS overhead, then 80 ms remains for processing each frame.
I know some DPRG folks have worked on UAVs with video cameras
running Linux. There were similar frame corruption problems.
Was there a timing constraint in the capture loop of this kind?
More information about the DPRG mailing list
|
