Hi all, Hans de Goede had the great idea to make something like we can find for arts, a library that traps open/close/ioctl and mmap calls, see his last message about it: http://marc.info/?l=linux-video&m=121296318123763&w=2
The idea is simple: - it works without modification of the application. The library traps the standard system calls to see if the application accesses a v4l device, intercepts compressed frames coming from the driver and uncompresses in userspace before transmitting them to the application. - it works without modification of the v4l driver. All the conversion job is masked by the library.
You call the application using: LD_PRELOAD=v4l1-compat.so camorama for example. The code is working and can be adapted to any device that need some userspace frame decompression/conversion.
The only disadvantage I saw is that an application that already uses the LD_PRELOAD mechanism for trapping these syscalls, this library will trap again these syscalls but in this case, it should link with a part of this library. Currently, this library does v4l2 driver to v4l1 application translation but the idea is here.
I don't know if you share my point of view but this idea is simple and has a long-term existence as opposed as the initial one.
Cheers, Thierry
On Wed, 11 Jun 2008, Thierry Merle wrote:
Hans de Goede had the great idea to make something like we can find for arts, a library that traps open/close/ioctl and mmap calls, see his last message about it: http://marc.info/?l=linux-video&m=121296318123763&w=2
Hi Thierry,
I liked Hans idea. Yet, I would offer two alternatives: 1) the LD_PRELOAD helper application; 2) a normal c library with the de-compressing algorithms.
The c library seems nice to app developers that want to insert V4L decompressing algorithms, without the need of an external helper application. There's no need for any special kernel support for such library.
Just my $2 cents.
Cheers, Mauro.
Hi Thierry & Mauro,
Thierry thanks for the interest in my work and starting this discussion.
Mauro Carvalho Chehab wrote:
On Wed, 11 Jun 2008, Thierry Merle wrote:
Hans de Goede had the great idea to make something like we can find for arts, a library that traps open/close/ioctl and mmap calls, see his last message about it: http://marc.info/?l=linux-video&m=121296318123763&w=2
Hi Thierry,
I liked Hans idea. Yet, I would offer two alternatives: 1) the LD_PRELOAD helper application; 2) a normal c library with the de-compressing algorithms.
The c library seems nice to app developers that want to insert V4L decompressing algorithms, without the need of an external helper application. There's no need for any special kernel support for such library.
That is almost exactly what I suggested in my initial mail, my plan is to move all the wrapper code to 2 libs and a new 3th lib.
libv4lconvert:
Offers a convert function with the following prototype: int v4l_compat_convert(unsigned int src_format, unsigned int dest_format, unsigned char *src, int src_size, unsigned char *dest, int dest_size, int width, int height); Where src_format and dst_format are V4l2_PIX_FMT_XXXXX defines.
This can be used by applications which want to keep everything in their own hand.
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.
libv4l2:
This offers functions like v4l2_open, v4l2_ioctl, etc. This can by used to quickly make v4l2 applications work with v4l2 devices with weird formats, this will mostly pass calls directly through to the v4l2 driver. When the app does a S_FMT with a not supported format this lib will get in the middle and emulate the format (if an app wants to know which formats the hardware can _really_ do it should use ENUM_FMT, not randomly try a bunch of S_FMT's). In the future this could be extended with v4l2 emulation on top of v4l1 devices.
The idea of giving these 2 libs the current userspace -> v4l1 / v4l2 api's is that applications can very easily be ported to these libs, just prefix v4l1_ / v4l2_ in front of open/close/read/ioctl/mmap when the open/close/read/ioctl/mmap is meant for a v4l device.
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.
Does this sound like a plan?
Regards,
Hans
On Thu, 12 Jun 2008 10:03:11 +0200 Hans de Goede j.w.r.degoede@hhs.nl wrote:
That is almost exactly what I suggested in my initial mail, my plan is to move all the wrapper code to 2 libs and a new 3th lib.
Seems an interesting plan.
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). 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).
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.
The second issue is more complex, since the compat should be capable of keeping some context. Resolving this issue at the library would be easier.
Cheers, Mauro
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
Hi Hans, Hans de Goede a écrit :
Hi Thierry & Mauro,
Thierry thanks for the interest in my work and starting this discussion.
Mauro Carvalho Chehab wrote:
On Wed, 11 Jun 2008, Thierry Merle wrote:
Hans de Goede had the great idea to make something like we can find for arts, a library that traps open/close/ioctl and mmap calls, see his last message about it: http://marc.info/?l=linux-video&m=121296318123763&w=2
Hi Thierry,
I liked Hans idea. Yet, I would offer two alternatives: 1) the LD_PRELOAD helper application; 2) a normal c library with the de-compressing algorithms.
The c library seems nice to app developers that want to insert V4L decompressing algorithms, without the need of an external helper application. There's no need for any special kernel support for such library.
That is almost exactly what I suggested in my initial mail, my plan is to move all the wrapper code to 2 libs and a new 3th lib.
libv4lconvert:
Offers a convert function with the following prototype: int v4l_compat_convert(unsigned int src_format, unsigned int dest_format, unsigned char *src, int src_size, unsigned char *dest, int dest_size, int width, int height); Where src_format and dst_format are V4l2_PIX_FMT_XXXXX defines.
This can be used by applications which want to keep everything in their own hand.
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.
libv4l2:
This offers functions like v4l2_open, v4l2_ioctl, etc. This can by used to quickly make v4l2 applications work with v4l2 devices with weird formats, this will mostly pass calls directly through to the v4l2 driver. When the app does a S_FMT with a not supported format this lib will get in the middle and emulate the format (if an app wants to know which formats the hardware can _really_ do it should use ENUM_FMT, not randomly try a bunch of S_FMT's). In the future this could be extended with v4l2 emulation on top of v4l1 devices.
The idea of giving these 2 libs the current userspace -> v4l1 / v4l2 api's is that applications can very easily be ported to these libs, just prefix v4l1_ / v4l2_ in front of open/close/read/ioctl/mmap when the open/close/read/ioctl/mmap is meant for a v4l device.
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.
Does this sound like a plan?
Regards,
Hans
Good plan, we could start to integrate your library in the v4l-dvb tree if you wish. v4l-apps/lib seems to be a good place. Your library will replace my solution, that can be reused for something else. I have a w9968cf webcam that needs an additional -vpp module to uncompress frames correctly. I will use your framework to port this -vpp module to userland.
Regards, Thierry
Thierry Merle wrote:
Hi Hans, Hans de Goede a écrit :
Hi Thierry & Mauro,
Thierry thanks for the interest in my work and starting this discussion.
Mauro Carvalho Chehab wrote:
On Wed, 11 Jun 2008, Thierry Merle wrote:
Hans de Goede had the great idea to make something like we can find for arts, a library that traps open/close/ioctl and mmap calls, see his last message about it: http://marc.info/?l=linux-video&m=121296318123763&w=2
Hi Thierry,
I liked Hans idea. Yet, I would offer two alternatives: 1) the LD_PRELOAD helper application; 2) a normal c library with the de-compressing algorithms.
The c library seems nice to app developers that want to insert V4L decompressing algorithms, without the need of an external helper application. There's no need for any special kernel support for such library.
That is almost exactly what I suggested in my initial mail, my plan is to move all the wrapper code to 2 libs and a new 3th lib.
libv4lconvert:
Offers a convert function with the following prototype: int v4l_compat_convert(unsigned int src_format, unsigned int dest_format, unsigned char *src, int src_size, unsigned char *dest, int dest_size, int width, int height); Where src_format and dst_format are V4l2_PIX_FMT_XXXXX defines.
This can be used by applications which want to keep everything in their own hand.
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.
libv4l2:
This offers functions like v4l2_open, v4l2_ioctl, etc. This can by used to quickly make v4l2 applications work with v4l2 devices with weird formats, this will mostly pass calls directly through to the v4l2 driver. When the app does a S_FMT with a not supported format this lib will get in the middle and emulate the format (if an app wants to know which formats the hardware can _really_ do it should use ENUM_FMT, not randomly try a bunch of S_FMT's). In the future this could be extended with v4l2 emulation on top of v4l1 devices.
The idea of giving these 2 libs the current userspace -> v4l1 / v4l2 api's is that applications can very easily be ported to these libs, just prefix v4l1_ / v4l2_ in front of open/close/read/ioctl/mmap when the open/close/read/ioctl/mmap is meant for a v4l device.
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.
Does this sound like a plan?
Regards,
Hans
Hi,
Work is progressing on this (splitting up the v4l1-compat wrapper as described above). I hope to have a first split release by the end of the week.
Good plan, we could start to integrate your library in the v4l-dvb tree if you wish.
Thanks for the offer! I definitely need a place to put this, I was thinking about a sf.net project, but being part of the dbv-tree would probably be better.
I say probably as I don't know what this means with regards to spinning tarbals for distribution consumption. Atleast in the beginning I would like to see seperate tarbals for v4l-lib, especially as once the split is done I want to get this into Fedora devel asap, as my main reason for working on this is: http://fedoraproject.org/wiki/Features/BetterWebcamSupport
Don't get me wrong Fedora's mantra is upstream upstream upstream, so I want this to be usable as widely as possible and integrated into the current v4l / dvb project both the sources and any docs.
But at the same time I also want to see this become available in F-10 and the first apps in F-10 start using it (Patches for apps will be send to their resp. upstreams).
v4l-apps/lib seems to be a good place.
Your library will replace my solution, that can be reused for something else. I have a w9968cf webcam that needs an additional -vpp module to uncompress frames correctly. I will use your framework to port this -vpp module to userland.
Moving stuff like that to userland sounds like a good plan!
Regards,
Hans
Hans de Goede a écrit :
Thierry Merle wrote:
Hi Hans, Hans de Goede a écrit :
Hi Thierry & Mauro,
Thierry thanks for the interest in my work and starting this discussion.
Mauro Carvalho Chehab wrote:
On Wed, 11 Jun 2008, Thierry Merle wrote:
Hans de Goede had the great idea to make something like we can find for arts, a library that traps open/close/ioctl and mmap calls, see his last message about it: http://marc.info/?l=linux-video&m=121296318123763&w=2
Hi Thierry,
I liked Hans idea. Yet, I would offer two alternatives: 1) the LD_PRELOAD helper application; 2) a normal c library with the de-compressing algorithms.
The c library seems nice to app developers that want to insert V4L decompressing algorithms, without the need of an external helper application. There's no need for any special kernel support for such library.
That is almost exactly what I suggested in my initial mail, my plan is to move all the wrapper code to 2 libs and a new 3th lib.
libv4lconvert:
Offers a convert function with the following prototype: int v4l_compat_convert(unsigned int src_format, unsigned int dest_format, unsigned char *src, int src_size, unsigned char *dest, int dest_size, int width, int height); Where src_format and dst_format are V4l2_PIX_FMT_XXXXX defines.
This can be used by applications which want to keep everything in their own hand.
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.
libv4l2:
This offers functions like v4l2_open, v4l2_ioctl, etc. This can by used to quickly make v4l2 applications work with v4l2 devices with weird formats, this will mostly pass calls directly through to the v4l2 driver. When the app does a S_FMT with a not supported format this lib will get in the middle and emulate the format (if an app wants to know which formats the hardware can _really_ do it should use ENUM_FMT, not randomly try a bunch of S_FMT's). In the future this could be extended with v4l2 emulation on top of v4l1 devices.
The idea of giving these 2 libs the current userspace -> v4l1 / v4l2 api's is that applications can very easily be ported to these libs, just prefix v4l1_ / v4l2_ in front of open/close/read/ioctl/mmap when the open/close/read/ioctl/mmap is meant for a v4l device.
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.
Does this sound like a plan?
Regards,
Hans
Hi,
Work is progressing on this (splitting up the v4l1-compat wrapper as described above). I hope to have a first split release by the end of the week.
Good plan, we could start to integrate your library in the v4l-dvb tree if you wish.
Thanks for the offer! I definitely need a place to put this, I was thinking about a sf.net project, but being part of the dbv-tree would probably be better.
I say probably as I don't know what this means with regards to spinning tarbals for distribution consumption. Atleast in the beginning I would like to see seperate tarbals for v4l-lib, especially as once the split is done I want to get this into Fedora devel asap, as my main reason for working on this is: http://fedoraproject.org/wiki/Features/BetterWebcamSupport
Don't get me wrong Fedora's mantra is upstream upstream upstream, so I want this to be usable as widely as possible and integrated into the current v4l / dvb project both the sources and any docs.
But at the same time I also want to see this become available in F-10 and the first apps in F-10 start using it (Patches for apps will be send to their resp. upstreams).
All is OK, no problem if Fedora users help you debug the code before v4l-dvb inclusion :)
v4l-apps/lib seems to be a good place.
Your library will replace my solution, that can be reused for something else. I have a w9968cf webcam that needs an additional -vpp module to uncompress frames correctly. I will use your framework to port this -vpp module to userland.
Moving stuff like that to userland sounds like a good plan!
Regards,
Hans
Thanks for all Nevertheless, I will follow your work on F-10 and try to help you if I can.
Thierry
Thierry Merle wrote:
Hans de Goede a écrit :
Thierry Merle wrote:
Hi Hans, Hans de Goede a écrit :
Hi Thierry & Mauro,
Thierry thanks for the interest in my work and starting this discussion.
Mauro Carvalho Chehab wrote:
On Wed, 11 Jun 2008, Thierry Merle wrote:
Hans de Goede had the great idea to make something like we can find for arts, a library that traps open/close/ioctl and mmap calls, see his last message about it: http://marc.info/?l=linux-video&m=121296318123763&w=2
Hi Thierry,
I liked Hans idea. Yet, I would offer two alternatives: 1) the LD_PRELOAD helper application; 2) a normal c library with the de-compressing algorithms.
The c library seems nice to app developers that want to insert V4L decompressing algorithms, without the need of an external helper application. There's no need for any special kernel support for such library.
That is almost exactly what I suggested in my initial mail, my plan is to move all the wrapper code to 2 libs and a new 3th lib.
libv4lconvert:
Offers a convert function with the following prototype: int v4l_compat_convert(unsigned int src_format, unsigned int dest_format, unsigned char *src, int src_size, unsigned char *dest, int dest_size, int width, int height); Where src_format and dst_format are V4l2_PIX_FMT_XXXXX defines.
This can be used by applications which want to keep everything in their own hand.
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.
libv4l2:
This offers functions like v4l2_open, v4l2_ioctl, etc. This can by used to quickly make v4l2 applications work with v4l2 devices with weird formats, this will mostly pass calls directly through to the v4l2 driver. When the app does a S_FMT with a not supported format this lib will get in the middle and emulate the format (if an app wants to know which formats the hardware can _really_ do it should use ENUM_FMT, not randomly try a bunch of S_FMT's). In the future this could be extended with v4l2 emulation on top of v4l1 devices.
The idea of giving these 2 libs the current userspace -> v4l1 / v4l2 api's is that applications can very easily be ported to these libs, just prefix v4l1_ / v4l2_ in front of open/close/read/ioctl/mmap when the open/close/read/ioctl/mmap is meant for a v4l device.
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.
Does this sound like a plan?
Regards,
Hans
Hi,
Work is progressing on this (splitting up the v4l1-compat wrapper as described above). I hope to have a first split release by the end of the week.
Good plan, we could start to integrate your library in the v4l-dvb tree if you wish.
Thanks for the offer! I definitely need a place to put this, I was thinking about a sf.net project, but being part of the dbv-tree would probably be better.
I say probably as I don't know what this means with regards to spinning tarbals for distribution consumption. Atleast in the beginning I would like to see seperate tarbals for v4l-lib, especially as once the split is done I want to get this into Fedora devel asap, as my main reason for working on this is: http://fedoraproject.org/wiki/Features/BetterWebcamSupport
Don't get me wrong Fedora's mantra is upstream upstream upstream, so I want this to be usable as widely as possible and integrated into the current v4l / dvb project both the sources and any docs.
But at the same time I also want to see this become available in F-10 and the first apps in F-10 start using it (Patches for apps will be send to their resp. upstreams).
All is OK, no problem if Fedora users help you debug the code before v4l-dvb inclusion :)
v4l-apps/lib seems to be a good place.
Your library will replace my solution, that can be reused for something else. I have a w9968cf webcam that needs an additional -vpp module to uncompress frames correctly. I will use your framework to port this -vpp module to userland.
Moving stuff like that to userland sounds like a good plan!
Regards,
Hans
Thanks for all Nevertheless, I will follow your work on F-10 and try to help you if I can.
I think you've misunderstood me, I would love for my v4l lib to be poart of the v4l-dvb tree as soon as the split discussed before is done, but I would like to see a mechanism to create separate tarballs for it for easy testing in the begin fase.
Regards,
Hans
Hans de Goede a écrit :
Thierry Merle wrote:
Hans de Goede a écrit :
Thierry Merle wrote:
Hi Hans, Hans de Goede a écrit :
Hi Thierry & Mauro,
Thierry thanks for the interest in my work and starting this discussion.
Mauro Carvalho Chehab wrote:
On Wed, 11 Jun 2008, Thierry Merle wrote: > Hans de Goede had the great idea to make something like we can > find for > arts, a library that traps open/close/ioctl and mmap calls, see his > last > message about it: > http://marc.info/?l=linux-video&m=121296318123763&w=2 Hi Thierry,
I liked Hans idea. Yet, I would offer two alternatives: 1) the LD_PRELOAD helper application; 2) a normal c library with the de-compressing algorithms.
The c library seems nice to app developers that want to insert V4L decompressing algorithms, without the need of an external helper application. There's no need for any special kernel support for such library.
That is almost exactly what I suggested in my initial mail, my plan is to move all the wrapper code to 2 libs and a new 3th lib.
libv4lconvert:
Offers a convert function with the following prototype: int v4l_compat_convert(unsigned int src_format, unsigned int dest_format, unsigned char *src, int src_size, unsigned char *dest, int dest_size, int width, int height); Where src_format and dst_format are V4l2_PIX_FMT_XXXXX defines.
This can be used by applications which want to keep everything in their own hand.
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.
libv4l2:
This offers functions like v4l2_open, v4l2_ioctl, etc. This can by used to quickly make v4l2 applications work with v4l2 devices with weird formats, this will mostly pass calls directly through to the v4l2 driver. When the app does a S_FMT with a not supported format this lib will get in the middle and emulate the format (if an app wants to know which formats the hardware can _really_ do it should use ENUM_FMT, not randomly try a bunch of S_FMT's). In the future this could be extended with v4l2 emulation on top of v4l1 devices.
The idea of giving these 2 libs the current userspace -> v4l1 / v4l2 api's is that applications can very easily be ported to these libs, just prefix v4l1_ / v4l2_ in front of open/close/read/ioctl/mmap when the open/close/read/ioctl/mmap is meant for a v4l device.
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.
Does this sound like a plan?
Regards,
Hans
Hi,
Work is progressing on this (splitting up the v4l1-compat wrapper as described above). I hope to have a first split release by the end of the week.
Good plan, we could start to integrate your library in the v4l-dvb tree if you wish.
Thanks for the offer! I definitely need a place to put this, I was thinking about a sf.net project, but being part of the dbv-tree would probably be better.
I say probably as I don't know what this means with regards to spinning tarbals for distribution consumption. Atleast in the beginning I would like to see seperate tarbals for v4l-lib, especially as once the split is done I want to get this into Fedora devel asap, as my main reason for working on this is: http://fedoraproject.org/wiki/Features/BetterWebcamSupport
Don't get me wrong Fedora's mantra is upstream upstream upstream, so I want this to be usable as widely as possible and integrated into the current v4l / dvb project both the sources and any docs.
But at the same time I also want to see this become available in F-10 and the first apps in F-10 start using it (Patches for apps will be send to their resp. upstreams).
All is OK, no problem if Fedora users help you debug the code before v4l-dvb inclusion :)
v4l-apps/lib seems to be a good place.
Your library will replace my solution, that can be reused for something else. I have a w9968cf webcam that needs an additional -vpp module to uncompress frames correctly. I will use your framework to port this -vpp module to userland.
Moving stuff like that to userland sounds like a good plan!
Regards,
Hans
Thanks for all Nevertheless, I will follow your work on F-10 and try to help you if I can.
I think you've misunderstood me, I would love for my v4l lib to be poart of the v4l-dvb tree as soon as the split discussed before is done, but I would like to see a mechanism to create separate tarballs for it for easy testing in the begin fase.
Regards,
Hans
Oops, sorry. You can add a rule in the makefile for that: tar: clean tar cvf /tmp/archive.tar * $(include_files_and_other_stuff_that_makes_an_independent_build)
Cheers, Thierry
Thierry Merle wrote:
Hans de Goede a écrit :
I think you've misunderstood me, I would love for my v4l lib to be poart of the v4l-dvb tree as soon as the split discussed before is done, but I would like to see a mechanism to create separate tarballs for it for easy testing in the begin fase.
Regards,
Hans
Oops, sorry. You can add a rule in the makefile for that: tar: clean tar cvf /tmp/archive.tar * $(include_files_and_other_stuff_that_makes_an_independent_build)
Yes something like that should work just fine, a seen in my announcement post, I now have a split (and cleaned up) version of the code ready.
I would very much like this code to get included into the v4l-dvb tree, what steps are necessary for that?
Thanks & Regards,
Hans
Thierry Merle wrote:
Hans de Goede a écrit :
I think you've misunderstood me, I would love for my v4l lib to be poart of the v4l-dvb tree as soon as the split discussed before is done, but I would like to see a mechanism to create separate tarballs for it for easy testing in the begin fase.
Regards,
Hans
Oops, sorry. You can add a rule in the makefile for that: tar: clean tar cvf /tmp/archive.tar * $(include_files_and_other_stuff_that_makes_an_independent_build)
Yes something like that should work just fine, a seen in my announcement post, I now have a split (and cleaned up) version of the code ready.
Great, I will review and try it this evening.
I would very much like this code to get included into the v4l-dvb tree, what steps are necessary for that?
Simple (refer to http://linuxtv.org/v4lwiki/index.php/How_to_submit_patches) for each part, - add the sources in the v4l-dvb tree - use hg add on all files you added - make commit, correct codestyle problems - hg export tip >patch_to_send.patch - send an email to this ML with [PATCH] in subject without forgetting the Signed-off-by line. We prefer little cumulative patches rather than a big one patch so that we are able to understand and review your code. As an example, you will see how the "old" v4l2 userspace infrastructure has been split into many patches at http://linuxtv.org/hg/~tmerle/v4l2_extension
I can help you at any step of course. I will create a separate repository to store your patches.
Thanks Thierry
-
Hans de Goede -
Mauro Carvalho Chehab -
Thierry Merle