On Thu, 6 Aug 2009, IOhannes m zmoelnig wrote:
as matju has stated several times (in this thread), all drivers that speak v4l (aka: v4l1) are supported by gridflow.
Unfortunately, this is not true, in the end. Only some of the most common image formats are supported: YUV420P, RGB32, RGB24, RGB565. I don't have any camera that is supported by a driver that outputs YUYV (some kind of "422"). Unfortunately, no format is supported by all cams, and the kernel dudes removed all format conversion code. This leads directly to the use of a user-space conversion library that didn't exist when I last rewrote gridflow/format/videodev.c (libv4l 0.1 was over a year after that, iirc).
all drivers that only speak v4l2 are not natively supported by gf.however (as said before) you can use libv4l to add v4l2 support to v4l1 applications at runtime.
Supporting libv4l instead of v4l1 (and hypothetically v4l2), I will be able to support all formats (colour models + other variations) without any fuss... plus all v4l2 cameras. So, what's coming next with cams in GF is not v4l2 support, it is libv4l support.
other than that, it is hard to make any anwers (as matju has pointed out): gf (and any other video-application) does not directly communicate with a driver (pwc, qc-usb,...) but with a middleware (the v4l*-protocol).
I'd say that gf and other video-applications directly communicate with a driver, because the protocol is not middleware. However if you have a protocol conversion library such libv4l, ... that is what middleware is. AFAIK, *.h don't count as middleware, *.c does. (unless you put a real lot of stuff in the *.h... but you get my point).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
