Hi, I?m on Ubuntu Intrepid with Pd-extended 0.41.4-rc3 and I want to work with a Logitech webcam in Gem. Well in PDP erverything works fine withe the video4linux driver.- Trying to do the sam in Gem by choosing the correct device and the video4linus driver, I get a blank video window but no error messages.- Does anybody have a solution for this problem.- thanks so far! fraenk
Fränk Zimmer wrote:
Hi, I?m on Ubuntu Intrepid with Pd-extended 0.41.4-rc3 and I want to work with a Logitech webcam in Gem. Well in PDP erverything works fine withe the video4linux driver.- Trying
i think you are mistaken here: your webcam works fine with [pdp_v4l2] which uses the video4linux2 drivers.
to do the sam in Gem by choosing the correct device and the video4linus driver, I get a blank video
try choosing "V4L2" as the driver in Gem.
fgmasdr IOhannes
Hm. Taking the pix_video-help patch: I can switch from driver 0 to driver 1 by sending a message to pix_video. How do I switch to the V4L2 driver ? vg,fr
IOhannes m zmoelnig schrieb:
Fränk Zimmer wrote:
Hi, I?m on Ubuntu Intrepid with Pd-extended 0.41.4-rc3 and I want to work with a Logitech webcam in Gem. Well in PDP erverything works fine withe the video4linux driver.- Trying
i think you are mistaken here: your webcam works fine with [pdp_v4l2] which uses the video4linux2 drivers.
to do the sam in Gem by choosing the correct device and the video4linus driver, I get a blank video
try choosing "V4L2" as the driver in Gem.
fgmasdr IOhannes
Fränk Zimmer wrote:
Hm. Taking the pix_video-help patch: I can switch from driver 0 to driver 1 by sending a message to pix_video. How do I switch to the V4L2 driver ?
when instantiating the first [pix_video] object, you should see (on the pd-console) a list of available drivers. e.g. here i see: video driver 0: video4linux2 video driver 1: video4linux video driver 2: ieee1394 for linux
if you don't have a line with "video4linux2", then you don't have v4l2 support compiled into your version of Gem.
in this case you have to possibilities, both of them include using libv4l (apt-get install libv4l-dev)
should autodetect everything for you
it's functionality to applications compiled without it. just do % export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so % pd -lib Gem
in the latter case, Gemwill still use v4l1 ("video4linux"), but the wrapper should transparently translate this to v4l2
tell us whether this works.
mfgasdr IOhannes
IOhannes m zmoelnig wrote:
Fränk Zimmer wrote:
Hm. Taking the pix_video-help patch: I can switch from driver 0 to driver 1 by sending a message to pix_video. How do I switch to the V4L2 driver ?
when instantiating the first [pix_video] object, you should see (on the pd-console) a list of available drivers. e.g. here i see: video driver 0: video4linux2 video driver 1: video4linux video driver 2: ieee1394 for linux
and to answer your question more precisely: the number you see right after the "video driver", is the number you should use in the [driver $1( message to activate the said backend.
fgmasdr IOhannes
The Gem version in the recent pd-ectended does not suppoert video4linux2. I tried your workaround.-
installed the libv4l-dev with synaptics
% export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so % pd -lib Gem
It works. So I`ll have to start pd-ext everytime with this 2 lines. BUT the image quality is quiete bad. Is this because of the new driver ? Can I get a better quality? (the same as in winXP or in PDP on Ubuntu)
thanks .-
fraenk
IOhannes m zmoelnig schrieb:
Fränk Zimmer wrote:
Hm. Taking the pix_video-help patch: I can switch from driver 0 to driver 1 by sending a message to pix_video. How do I switch to the V4L2 driver ?
when instantiating the first [pix_video] object, you should see (on the pd-console) a list of available drivers. e.g. here i see: video driver 0: video4linux2 video driver 1: video4linux video driver 2: ieee1394 for linux
if you don't have a line with "video4linux2", then you don't have v4l2 support compiled into your version of Gem.
in this case you have to possibilities, both of them include using libv4l (apt-get install libv4l-dev)
- compile yourself a recent verson of Gem (after installing libv4l);
it should autodetect everything for you
- libv4l also supports a wrapper (read the README of libv4l) to bring
it's functionality to applications compiled without it. just do % export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so % pd -lib Gem
in the latter case, Gemwill still use v4l1 ("video4linux"), but the wrapper should transparently translate this to v4l2
tell us whether this works.
mfgasdr IOhannes
Fränk Zimmer wrote:
The Gem version in the recent pd-ectended does not suppoert video4linux2. I tried your workaround.-
installed the libv4l-dev with synaptics
% export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so % pd -lib Gem
It works. So I`ll have to start pd-ext everytime with this 2 lines.
BUT the image quality is quiete bad. Is this because of the new driver ? Can I get a better quality? (the same as in winXP or in PDP on Ubuntu)
the default resolution is 64x64 (which _is_ bad), send a [dimen 640 480( to [pix_video] to change it (probably your cam doesn't like 640x480 so try other known-to-work values)
fgamdsr IOhannes
ok.- thanks a lot for the help.-
Played a bit with different dimensions.- The image quality is OK
now - at least for a webcam.
vg, fraenk
IOhannes m zmoelnig schrieb:
Fränk Zimmer wrote:
The Gem version in the recent pd-ectended does not suppoert video4linux2. I tried your workaround.-
installed the libv4l-dev with synaptics
% export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so % pd -lib Gem
It works. So I`ll have to start pd-ext everytime with this 2 lines.
BUT the image quality is quiete bad. Is this because of the new driver ? Can I get a better quality? (the same as in winXP or in PDP on Ubuntu)
the default resolution is 64x64 (which _is_ bad), send a [dimen 640 480( to [pix_video] to change it (probably your cam doesn't like 640x480 so try other known-to-work values)
fgamdsr IOhannes
Is there something that can be done in Pd-extended to make this work?
Should all of the build farm machines have libv4l-dev installed?
.hc
On May 28, 2009, at 6:09 AM, Fränk Zimmer wrote:
The Gem version in the recent pd-ectended does not suppoert
video4linux2. I tried your workaround.-
installed the libv4l-dev with synaptics
% export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so % pd -lib Gem
It works. So I`ll have to start pd-ext everytime with this 2 lines. BUT the image quality is quiete bad. Is this because of the new
driver ? Can I get a better quality? (the same as in winXP or in PDP on Ubuntu)thanks .-
fraenk
IOhannes m zmoelnig schrieb:
Fränk Zimmer wrote:
Hm. Taking the pix_video-help patch: I can switch from driver 0
to driver 1 by sending a message to pix_video. How do I switch to the V4L2 driver ?when instantiating the first [pix_video] object, you should see (on
the pd-console) a list of available drivers. e.g. here i see: video driver 0: video4linux2 video driver 1: video4linux video driver 2: ieee1394 for linuxif you don't have a line with "video4linux2", then you don't have
v4l2 support compiled into your version of Gem.in this case you have to possibilities, both of them include using
libv4l (apt-get install libv4l-dev)
- compile yourself a recent verson of Gem (after installing
libv4l); it should autodetect everything for you
- libv4l also supports a wrapper (read the README of libv4l) to
bring it's functionality to applications compiled without it. just do % export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so % pd -lib Gem
in the latter case, Gemwill still use v4l1 ("video4linux"), but the
wrapper should transparently translate this to v4l2tell us whether this works.
mfgasdr IOhannes
--
Fränk Zimmer
visit: http://fz.mur.at
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hans-Christoph Steiner wrote:
Is there something that can be done in Pd-extended to make this work?
Should all of the build farm machines have libv4l-dev installed?
yep. though i seem to remember that there were some problems with older versions of libv4l (no idea, which exact version though; might be very early versions, like 0.1).
for the future, libv4l is definitely the way to go on linux.
fmgasdr IOhannes
On May 28, 2009, at 10:08 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Is there something that can be done in Pd-extended to make this
work? Should all of the build farm machines have libv4l-dev
installed?yep. though i seem to remember that there were some problems with older
versions of libv4l (no idea, which exact version though; might be
very early versions, like 0.1).for the future, libv4l is definitely the way to go on linux.
Ok I installed libv4l-dev(el) on Debian/testing, Ubuntu/Intrepid,
Ubuntu/Jaunty, and Fedora 9. The other distros didn't have it. It
was version 0.5.[789]
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On jeu, 2009-05-28 at 10:40 -0400, Hans-Christoph Steiner wrote:
On May 28, 2009, at 10:08 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Is there something that can be done in Pd-extended to make this
work? Should all of the build farm machines have libv4l-dev
installed?yep. though i seem to remember that there were some problems with older
versions of libv4l (no idea, which exact version though; might be
very early versions, like 0.1).for the future, libv4l is definitely the way to go on linux.
Ok I installed libv4l-dev(el) on Debian/testing, Ubuntu/Intrepid,
Ubuntu/Jaunty, and Fedora 9. The other distros didn't have it. It
was version 0.5.[789]
Hello,
I just managed to install v4l on Ubuntu Hardy
I downloaded libv4l-0.5.98.tar.gz from this URL http://people.atrpms.net/~hdegoede/
tar xvzf libv4l-0.5.98.tar.gz make
then I copied the libs to /usr/local/lib
and redefined the variable
export LD_PRELOAD=/usr/local/lib/libv4l.0.5.98/libv4l1/v4l1compat.so
and for the next session echo "export LD_PRELOAD=/usr/local/lib/libv4l1/v4l1compat.so" >> ~/.bashrc
Works fine with a Logitech Quickcam Communicate STX
++ OH
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
abonnements-olivier wrote:
and for the next session echo "export LD_PRELOAD=/usr/local/lib/libv4l1/v4l1compat.so" >> ~/.bashrc
actually i would not recommend this. LD_PRELOAD seriously interferes with how application linking works (and is therefore usually discouraged); the sole purpose of it is to allow library calls be intercepted and provided by a different backend, something useful when doing debugging or swapping a backend for a single application (like chromium does with openGL apps; or libv4l-compat in our case).
otoh, the only thing that libv4l compat can actually intercept is calls to ioctl(), which is deep on the kernel-side. overriding ioctl for each and every application is probably really not what you want. apart from slowing everything down (as it wraps a system call!), you might turn otu seeing your harddisk as a webcam. probably nice pictures, but bad data. (surely libv4l-devs are trying to do everything to not do any harm when wrapping system calls; but they will most likely have bugs in their code as everybody)
thus the way to go, is to compile an application with native libv4l support.
anyhow, i just wanted to point out, that people here are lately suggesting a log of brute force "solutions", which might work fine but nevertheless i think it would be proper to warn anybody that they might just grill their cat.
fgmasdr IOhannes
Thank you Iohannes for pointing out the low-level side-effects and glitches/potentiality eg. hard-disk instead of a webcam. Once again, an experimental system (jaunty with libv4l-dev) against a stable one (hardy) is a hard choice.
Havent grilled any cat yet, but must be tasty! ++ OH
On lun, 2009-06-01 at 17:10 +0200, IOhannes m zmölnig wrote:
abonnements-olivier wrote:
and for the next session echo "export LD_PRELOAD=/usr/local/lib/libv4l1/v4l1compat.so" >> ~/.bashrc
actually i would not recommend this. LD_PRELOAD seriously interferes with how application linking works (and is therefore usually discouraged); the sole purpose of it is to allow library calls be intercepted and provided by a different backend, something useful when doing debugging or swapping a backend for a single application (like chromium does with openGL apps; or libv4l-compat in our case).
otoh, the only thing that libv4l compat can actually intercept is calls to ioctl(), which is deep on the kernel-side. overriding ioctl for each and every application is probably really not what you want. apart from slowing everything down (as it wraps a system call!), you might turn otu seeing your harddisk as a webcam. probably nice pictures, but bad data. (surely libv4l-devs are trying to do everything to not do any harm when wrapping system calls; but they will most likely have bugs in their code as everybody)
thus the way to go, is to compile an application with native libv4l support.
anyhow, i just wanted to point out, that people here are lately suggesting a log of brute force "solutions", which might work fine but nevertheless i think it would be proper to warn anybody that they might just grill their cat.
fgmasdr IOhannes