Are you sure that the simple byte flip is actually costing you a lot of time ? Have you thought about separating out your disk i/o thread from the capture/byte flip thread and seeing which thread can't keep up ? There's not guarantee that even if your v4l driver produced RGB rather than BGR that it wouldn't just be doing the swap in the kernel driver, and not actually gaining you anything. Is there some reason you couldn't store BGR on the disk, and fix it during playback ? If you use xvideo for the final output, you might get away without the byte-flipping if the graphics card can directly overlay a BGR input. One thing that might help your performance is doing some compression before writing to disk. Uncompressed RGB at 25fps is quite a hefty i/o load if you capture at full PAL resultion, for instance (around 30MB/second sustained). Are you sure your I/O subsystem can cope with that anyway, and you're not losing most of your time waiting for the write() to return (when you could be doing other work in your test program) ? Mark On Tue, 2002-11-26 at 16:24, Georgios Kapetanakis wrote: > > No, there isn't. v4l has only BGR order. v4l2 has format #defines for > > both byte orders (RGB + BGR), but there still is no guaranty that the > > format you want to use is supported by the driver. You have to be > > prepared to do some conversion in software if needed. > > I understand, but still the overhead of such a conversion can have > significant effects on the performance of user applications. Ultimately, I > want to develop a high-throughput, real-time capturing application for a > project I'm doing, but my aim seems (near) impossible, without making > sacrifices, especially when it comes to performance considerations. > > /G -- Mark Cooke <mpc@xxxxxxxxxxxxxxxxxx>
