-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-28 00:15, Bastiaan van den Berg wrote:
Here is a little trick I use for getting webcams working in different linux programs :
- to get 'weird' v4l2 cameras working with 'normal v4l2 expecting' programs,
you can do this:
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so pdextended
that's not about "weirdness" but about the specificications of v4l2:
a few selected colorspaces.
unfortunately application programmers tend to prefer different colorspaces than hardware manufacturers (and what's more, app developers tend to stick to a few formats, whereas hw devs will want to use formats that match the sensor best, which basically results in a new format for every chip) since the v4l1 only specificies a few valid output formats, device drivers used to be stuffed with color conversion code.
it has been agreed, that color conversion is no task for the kernel space (where the drivers are executed) but really should be done in user space (at the application side)
v4l2 basdically implements this, meaning, that /dev/video might present the image data in any of a large number of different color formats. the application is expected to be able to decode all these formats.
since no sane application will go for the task of supporting all available color-spaces hw devs might come up with, some clever people created a library that is able to deal with converting all those formats into a handful "standard" ones. this library is libv4l.
the v4l2convert trick mentioned above, is a workaround to make applications not using libv4l to still be able to benefit from libv4l's color conversion routines. but really, the application (e.g. GF or Gem) should use libv4l natively.
as far as i know, both do so, if they can find libv4l (+headers!) during configure/compile time. it seems however, that your version of Gem has found libv4l while it was built, whereas GF has not. if you compiled GF yourself, try installing libv4l-dev and then re-configure & re-compile GF.
fgamsdr IOhannes