2011/4/24 Paulo Costa <p...@fe.up.pt>: > Probably you are right. Let me know how does it works for you.
I have further studied the entire v4l thing and there is something that could be improved in the SdpoVideo4L2 component: There exists a library libv4l2 that is an official part of the Linux V4l2 project. It implements the format conversions that were part of each individual V4L1 driver but are not allowed to be done in kernel-space anymore with V4L2 and have all been moved into one user space library and should be used by all applications using the V4L API. This library exports functions that wrap open/close/ioctl/mmap/munmap and work like their native counterparts except that they intercept certain ioctls and make the cameras all magically support not only their native pixel formats but also at least BGR24 and YUV420p as a common denominator. The decompression and/or format conversion will happen transparently on the fly, it will be as if the driver itself natively supports this format. http://hansdegoede.livejournal.com/3636.html This means the only change that is needed to SdpoVideo4L2 would be to replace all calls to FpOpen(), FpIoctl(), FpMmap() etc... with calls to v4l2_open(), v4l2_ioctl(), v4l2_mmap() etc. and all existing (known) V4L2 cameras could then be set to BGR24 and would deliver uncompressed 24bit BGR video. If I have some time next weekend I will make a patch against SdpoVideo4L2 (with an ifdef) that allows enabling this functionality. Bernd _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal