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
