Hello Mark, > Since it only takes about 40 ms for a 176x144 YUV420 frame to get across > the USB bus, 60 to 85 ms is not too unreasonable. Because the driver has > to wait for a frame start before it can capture, there will be an > average latency of 20 ms added on to the 40 ms. However, this does not > account for the fact that you never get better than 60 ms. I can't > imagine that the remaining 20 ms is being consumed by context and mode > switches, or by calling ioctl(). Not even under heavy cpu load? I mean a real time video encoder and decoder, plus XPutImge and related stuff. > On a reasonably fast CPU (such as yours), compression support should > increase frame rates significantly. This should improve your numbers > somewhat. However, compression support is in the experimental stage and > will take a little while longer to complete. Compression in my 1.34 > driver is unreliable, but should work well enough for you to determine > whether it will help or not. > Yes it does! Average 45ms, Min 36ms and Max 57ms. But how does this compression work. I´m feeding an H263 encoder with QCIF YUV420 frames and when I turn compression on it does not understand a single byte from the frame sequence (head and shoulder images). Is this the experimental sideor Iam just missing something? I used to capture CIF frames and cut around once in the buffer to make it QCIF. It was slow but images were just fine. When I started using QCIF things became faster but I´m getting greenish frames. I know QCIF is still experimental, but has anybody else reported this behaviour? Matias.
