hi all
i've run into big troubles trying to use an usb cam with either gridflow or pdp, but it doesn't want to work in both. i wonder if i am doing big mistakes or what combination of drivers and cams work with gridflow.
history: # i tried two different models yet: -philips spc900nc -logitech quickcam pro 4000 both are supported by pwc-driver from http://saillard.org/linux/pwc/ . # together with that driver, there is also a usefull tool available 'setpwc', that is used to set some camera-specific settings, that are noth supported by 'dov4l', to commandline tool used to set general web-cam and tv-card settings. # both tools work fine here and i can test the various settings with the program 'camorama'. with camorama i have no troubles to display the picture from the cam and different options work fine (e.g. 320x240/30fps or 640x480/15ps). # but with neither pdp nor gridflow i had luck. for me it is more important that it works with gridflow, also because it is still maintained. that's why i post here only what i tried with gridflow # note: it seems that the according objects in gridflow and pdp [#in] and [pdp_v4l] overwrite some settings in the cam when instantiated. that makes it even more difficult to find a set of settings that just works. #
my steps to get a picture with the logitech quickcam pro 4000 and pd/gridflow:
-i plug the cam into the usb-plug
-'setpwc -d /dev/video1 -p' tells me all actual settings of the cam: <- setpwc v1.1, (C) 2003-2005 by folkert@vanheusden.com Current device: Logitech QuickCam Pro 4000 VIDIOCPWCPROBE returns: Logitech QuickCam Pro 4000 - 740 Serial number: Resolution (x, y): 320, 240 Offset: 0, 0 Framerate: 10 Brightness: 32256 Hue: 65535 Colour: 32768 Contrast: 0 Whiteness: 0 Palette: YUV 4:2:0 Planar Compression preference: 1 Automatic gain control: -1275 Whitebalance mode: auto Blinking of LED is not supported by the combination of your webcam and the driver. Sharpness: -1 Backlight compensation mode: off Anti-flicker mode: off Noise reduction mode: 1 Pan/tilt range is not supported by the combination of your webcam and the driver. Get pan/tilt position is not supported by the combination of your webcam and the driver. ->
-i test with 'camorama -d /dev/video1', if these settings work and they work-> i get a picture
-i send a message [open videodev /dev/video1, get( to [#in] <- [gf] [:VideoCapability, "Logitech QuickCam Pro 4000", 1, 1, 1, 480, 640, 120, 160] [gf] [:VideoWindow, 0, 0, 240, 320, 0, 655360, -1072189566] [gf] [:VideoWindow, 0, 0, 480, 640, 0, 0, 0] [gf] [:VideoWindow, 0, 0, 480, 640, 0, 655360, 0] [gf] [:VideoPicture, 32256, 0, 32768, 65535, 0, 24, 15] [gf] This card supports palettes: 12, 15 [gf] ioctl VIDIOCSPICT: Invalid argument [gf] [:VideoChannel, 0, "Webcam", 0, 0, 2, 16384] [gf] getting colour=32768 [gf] getting contrast=64512 [gf] ioctl VIDIOCGFREQ: Invalid argument [gf] getting hue=65535 [gf] getting brightness=32256 [gf] getting whiteness=65535 -> suddenly i don't know what VIDIOCSPICT and VIDIOCGFREQ mean, but it seems that gridflow tries some invalid settings here.
-i send [bang( to [#in] and i get: <- [gf] ioctl VIDIOCMCAPTURE: Invalid argument error: ArgumentError: ioctl error format/videodev.c.fcs:358:in `void FormatVideoDev::frame_ask(int, Ruby*)' [#in] ... you might be able to track this down from the Find menu. -> obviously gridflow still tries to send invalid settings to the cam and i get no picture.
- i try various colorspaces. when i send [colorspace YUV420P( to [#in],
i get: <- error: ArgumentError: can't handle palette 15 format/videodev.c.fcs:536:in `void FormatVideoDev::_0_colorspace(int, Ruby*, Symbol)' [#io:videodev in ] ->
-when i send [colorspace RGB24( to [#in], i get: <- [gf] ioctl VIDIOCSPICT: Invalid argument ->
-when i try any other colorspace, i get: <- error: ArgumentError: supported: RGB24, YUV420P format/videodev.c.fcs:523:in `void FormatVideoDev::_0_colorspace(int, Ruby*, Symbol)' [#io:videodev in ] -> which is at least a clear humanunderstandable message.
-when i send a [bang( again now, i get a different error: <- [gf] ioctl VIDIOCSYNC: Invalid argument error: ArgumentError: ioctl error format/videodev.c.fcs:423:in `void FormatVideoDev::frame(int, Ruby*)' [#in] ->
anyway, i'd really like to know what these codes like VIDIOCSYNC and such stand for. and why it is so easy to use a webcam with 'camorama' but so hard with pdp or gridflow. what models of cams do other people use?
any hints appreciated.
cheers roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hi Roman,
On 11/8/06, Roman Haefeli reduzierer@yahoo.de wrote:
i've run into big troubles trying to use an usb cam with either gridflow or pdp, but it doesn't want to work in both. i wonder if i am doing big mistakes or what combination of drivers and cams work with gridflow.
There are problems with pdp and the pwc driver. pdp was designed with the old closed-source driver and does not work properly with latest open source version. The solution is to remove the pwc-specific code from the pdp source and then it will be treated like any other webcam. Details in this post: http://elists.resynthesize.com/pd-list/2005/07/1505225/
I have a Quickcam Pro 4000 myself and had great success using it with pdp after making this change.
I have never used Gridflow, so can't help you there. Perhaps it is a similar issue?
Also, for general help on the pwc driver, make sure you check the pwc mailing list. http://www.mail-archive.com/pwc@lists.saillard.org/
Regards,
Andrew.
-- Andrew Cavers andrewcavers.com
On Wed, 2006-11-08 at 15:26 +0000, Andrew Cavers wrote:
Hi Roman,
On 11/8/06, Roman Haefeli reduzierer@yahoo.de wrote:
i've run into big troubles trying to use an usb cam with either gridflow or pdp, but it doesn't want to work in both. i wonder if i am doing big mistakes or what combination of drivers and cams work with gridflow.
There are problems with pdp and the pwc driver. pdp was designed with the old closed-source driver and does not work properly with latest open source version. The solution is to remove the pwc-specific code from the pdp source and then it will be treated like any other webcam. Details in this post: http://elists.resynthesize.com/pd-list/2005/07/1505225/
I have a Quickcam Pro 4000 myself and had great success using it with pdp after making this change.
thank you very much. you helped me a lot. it is working now in pdp. for me it wasn't necessary to change the code. i just downloaded the newest release of pdp (0.12.5-test-7) and i used the option '--disable-pwc' when configuring.
cheers roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Wed, 8 Nov 2006, Roman Haefeli wrote:
-logitech quickcam pro 4000
This camera is known to work. Vidéographe-PARC just bought 10 of them for the big pd workshop.
You have to select colorspace YUV420P (even though it complains a bit). You also have to select "transfer read". GridFlow is a little less automatic than I'd like to.
Then you can optionally click the [radio] that enables YUV->RGB conversion, depending on whether you want to work in RGB or in YUV.
Note that GridFlow's YUV is not faster than RGB, supposing that you have to convert to RGB anyway for displaying: selecting YUV420P still feeds you with YUV444 (same data rate as plain RGB) because that's what easy to work with.
I think everybody just uses RGB.
it seems that the according objects in gridflow [#in] overwrite some settings in the cam when instantiated.
If you're using [#in videodev] directly, you may want to have a look in [#camera]; most people use [#camera]. You can do everything with [#in videodev] as [#camera] is just an abstraction around it.
I don't think that [#camera] overwrites settings. [#in videodev] overwrites the minimum possible.
suddenly i don't know what VIDIOCSPICT and VIDIOCGFREQ mean, but it seems that gridflow tries some invalid settings here.
If I recall, VIDIOCSPICT is for setting the colorspace, width, height, etc. GridFlow might be trying RGB even though it's invalid. VIDIOCGFREQ is reserved for devices that have a television input.
anyway, i'd really like to know what these codes like VIDIOCSYNC and such stand for.
They come from /usr/include/linux/videodev.h
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
hi matju
thanks a lot for that info. i get a picture also in gridflow now. a bit confusing is, that if you select [colorspace YUV420P(, you get an error, but you already mentioned that in your post.
without knowing the principles behind the programming of gridflow, it is a pain, that the colorspace conversion ([#yuv_to_rgb]-[#clip]) eats quite a huge amount of cpu without any further processing. here on my pentium m 1.7GHz it is about 30% with 'dim 240 320' and a framerate of 30. again, i don't know the technical details behind the objects i work with, but it seems strange in my eyes, that having to do a conversion in gridflow is the only available option to get a 'normal' looking picture. for many applications it might not be absolutely necassary to do such a conversion. but on the other hand - as far as i can understand - it is not always easy to work in the 'wrong' colorspace, depending on what one wants to do, since a change in the brightness results in a change of the color, is that right?
if only YUV420P is a 'valid' colorspace, why are there others available?
anyway, it works now, so i will stop moaning around...
cheers roman
On Wed, 2006-11-08 at 10:40 -0500, Mathieu Bouchard wrote:
On Wed, 8 Nov 2006, Roman Haefeli wrote:
-logitech quickcam pro 4000
This camera is known to work. Vidéographe-PARC just bought 10 of them for the big pd workshop.
You have to select colorspace YUV420P (even though it complains a bit). You also have to select "transfer read". GridFlow is a little less automatic than I'd like to.
Then you can optionally click the [radio] that enables YUV->RGB conversion, depending on whether you want to work in RGB or in YUV.
Note that GridFlow's YUV is not faster than RGB, supposing that you have to convert to RGB anyway for displaying: selecting YUV420P still feeds you with YUV444 (same data rate as plain RGB) because that's what easy to work with.
I think everybody just uses RGB.
it seems that the according objects in gridflow [#in] overwrite some settings in the cam when instantiated.
If you're using [#in videodev] directly, you may want to have a look in [#camera]; most people use [#camera]. You can do everything with [#in videodev] as [#camera] is just an abstraction around it.
I don't think that [#camera] overwrites settings. [#in videodev] overwrites the minimum possible.
suddenly i don't know what VIDIOCSPICT and VIDIOCGFREQ mean, but it seems that gridflow tries some invalid settings here.
If I recall, VIDIOCSPICT is for setting the colorspace, width, height, etc. GridFlow might be trying RGB even though it's invalid. VIDIOCGFREQ is reserved for devices that have a television input.
anyway, i'd really like to know what these codes like VIDIOCSYNC and such stand for.
They come from /usr/include/linux/videodev.h
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Wed, 8 Nov 2006, Roman Haefeli wrote:
without knowing the principles behind the programming of gridflow, it is a pain, that the colorspace conversion ([#yuv_to_rgb]-[#clip]) eats quite a huge amount of cpu without any further processing. here on my pentium m 1.7GHz it is about 30% with 'dim 240 320' and a framerate of 30. again, i don't know the technical details behind the objects i work with, but it seems strange in my eyes, that having to do a conversion in gridflow is the only available option to get a 'normal' looking picture.
That's because I don't use webcams, and kernel developers don't want driver developers to include color conversions in drivers, and webcams don't transmit as RGB, and I prefer to use pd abstractions than code more C++, and [#inner] isn't as fast as it could be, and no-one really made me work on making it faster.
In my daily use of GridFlow there are only bt878 PCI cards, which all support RGB in hardware.
it is not always easy to work in the 'wrong' colorspace, depending on what one wants to do, since a change in the brightness results in a change of the color, is that right?
If you change the contrast or brightness of a picture as if were RGB, you'll get wrong results. [# + (42 42 42)] on RGB has to become [# + (42 0 0)] on YUV, and so on.
However if you mean sending YUV data directly to a [#out window]... well, GridFlow doesn't allow any object to know whether data passed along is in RGB or YUV.
if only YUV420P is a 'valid' colorspace, why are there others available?
The "colorspace" message's argument has two possible values, but some devices only allow one of them, and the error message doesn't say this.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
Andrew Cavers -
Mathieu Bouchard -
Roman Haefeli