Mauro Carvalho Chehab wrote:
On Thu, 12 Jun 2008 10:03:11 +0200 Hans de Goede j.w.r.degoede@hhs.nl wrote:
libv4l1:
This offers functions like v4l1_open, v4l1_ioctl, etc. These functions work exactly like the normal open/close/etc, except that the lib will do v4l1 emulation on v4l2 drivers. This can by used to quickly make v4l1 applications work with v4l2 devices, this will contain most of the current wrapper code. This will do full emulation of the v4l1 api on top of v4l2 drivers (*), in case of v4l1 drivers it will just pass things through.
Then the to be preloaded v4l1_compat.so just becomes a number of shims calling the v4l1_foo functions in libv4l1, and a v4l2_convert.so can be made which will be just a number of shims calling the v4l2_foo functions in libv4l2, which can be used to add support for more v4l2-source formats to existing apps without changes and recompiling.
I have some doubts if libv4l1 is something interesting and, in the case, we can depreciate v4l1_compat, or if it would be better to fix v4l1_compat. Both strategies have advantages. AFAIK, the major issue at v4l1_compat is the lack of support for applications that starts stream then decides to send a command that changes video format (like vlc v4l1 support).
This is also what camorama does, and my wrapper / libv4l1 already handles this (tested with camorama).
Also, since it doesn't keep an history of a request, if you set certain video formats (MJPEG, if my memories aren't failing), a get can return a different format (since there are namespace duplication on V4L1 api).
This is another thing my wrapper already handles (otherwise ekiga in v4l1 mode would not work with yuv, as we have both VIDEO_PALETTE_YUV420 and VIDEO_PALETTE_YUV420P in v4l1 and only V4L2_PIX_FMT_YUV420 in v4l2.
It is not that hard to fix the first issue. It is just a matter of allocating memory for the max resolution, for the streaming compat ioctl. This way, you may dynamically change the size. Extra care should be taken, since this might not be supported by a few devices.
Correct, this is what libv4l1 currently does, doing this at the driver level though (where with v4l2 the buffer allocation is done) requires changes to many drivers. Also many webcam drivers do currently not implement v4l1 mmap mode compatibility at all.
Also keep in mind that with cameras which produce bayer, or other exotic formats v4l1 compatibility requires doing conversion. The same seems to go for jpeg, (headerless jpeg versus fill jpeg problems) atleast spcaview would not work in mjpeg mode with an mjpeg producing uvc cam until I did mjpeg -> rgb conversion in the wrapper.
All in all I believe that much better v4l1 compatibility can be achieved in userspace. Splitting this into a lib and an ld_preload wrapper then becomes trivial and is worth it as then apps can easily be modified to use v4l1lib instead of requiring an LD_PRELOAD hack.
Regards,
Hans