I'm trying to get my webcam working in Gridflow 9.12 under Ubuntu 11.4. It works with GEM, not with Gridflow.
GEM gives the following output in the Pd window when I open pix_video: [pix_video]: video driver 0: video4linux2 v4l2 [pix_video]: video driver 1: video4linux v4l [pix_video]: video driver 2: ieee1394 dv4l dv
When I open the #camera help patch, I get the following output in the Pd window: print: symbol sdl error: constructor: ioctl VIDIOCGCAP: Invalid argument error: constructor: ioctl VIDIOCGPICT: Invalid argument camera supports palettes : error: _0_size: ioctl VIDIOCGWIN: Invalid argument error: _0_size: ioctl VIDIOCSWIN: Invalid argument error: _0_size: ioctl VIDIOCGWIN: Invalid argument error: _0_colorspace: ioctl VIDIOCGPICT: Invalid argument request use of palette 15 error: _0_colorspace: ioctl VIDIOCSPICT: Invalid argument error: _0_colorspace: ioctl VIDIOCGPICT: Invalid argument print: symbol videodev error: contrast: ioctl VIDIOCGPICT: Invalid argument error: colour: ioctl VIDIOCGPICT: Invalid argument error: brightness: ioctl VIDIOCGPICT: Invalid argument error: hue: ioctl VIDIOCGPICT: Invalid argument error: whiteness: ioctl VIDIOCGPICT: Invalid argument error: _0_size: ioctl VIDIOCGWIN: Invalid argument error: _0_size: ioctl VIDIOCSWIN: Invalid argument error: _0_size: ioctl VIDIOCGWIN: Invalid argument error: _0_size: ioctl VIDIOCGWIN: Invalid argument error: _0_size: ioctl VIDIOCSWIN: Invalid argument error: _0_size: ioctl VIDIOCGWIN: Invalid argument
Changing the settings for #camera does not help.
Does anyone have any suggestions what could keep the camera from working with Gridflow when it does work with GEM in the same installation of Pd?
Ste
Here is a little trick I use for getting webcams working in different linux programs :
you can do this:
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so pdextended
this starts pdextended, but first overloads some v4l2 functions with the ones in that library, which help in format conversion etc.
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so pdextended
these tricks work with many many programs ;)
-- Regards, buZz
-----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
On Tue, 28 Jun 2011, IOhannes m zmoelnig wrote:
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.
Even when you compile GF with libv4l1 support, it doesn't use it by default. The default is still plain v4l1. I think that it's because some old cameras' v4l1 extensions don't work in libv4l1 at all, but I don't recall for sure.
libv4l1 is going to be the default in the next release of GF.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC