On 2001.05.26 00:12:38 +0200 Dmitri wrote:
> Quoting Alan Cox <[EMAIL PROTECTED]>:
>
> > > routines, while (nearly) nothing has been said about other (USB)
> webcam
> > > drivers which have conversion routines.
> >
> > I have those in my firing line too. It has always been the policy that
> format
> > conversions go in user space.
>
> To accomplish this noble goal we need a new V4L API that has not one but
> two components. The kernel portion sits in kernel space (maybe) and
> sucks the data out of the camera. The userspace portion postprocesses
> the raw data and provides a standard interface to user apps.
>
> Currently, there is no such "bottom half" component, and there is not
> even a place to insert it. The V4L interface ends at /dev/videoX. Any
> attempts to insert (link) a device-dependent library into tens of
> video apps have to be based on very well documented new interface, and
> a shared library (or something else) to access raw devices, interrogate
> them in details, match formats etc.) Among that is the question
> how do we extend and maintain this library because the kernel driver and
> the decoding/converting portion of this new library are closely tied,
> and change in one will likely require change in another. But kernel and
> userspace stuff are maintained separately!
>
> As it stands now, V4L does not provide any means to move the conversion
> into userspace. Many cameras even have different "native" formats in
> different modes and on different image sizes. IBM cameras, for example,
> usually stream something resembling YUV but not exactly that. The
> conversion library will need to know most intimate details about the
> datastream being processed.
>
> If converters are removed from drivers before new V4L is created and
> tools migrated then everything breaks. A replacement V4L stack must
> be first agreed upon, created and all drivers rewritten for it; only
> then the old solution can be obsoleted. I can't see how removal of
> thousands of lines of code can help here. They are all modules, after
> all.
I don't think there need to be mutch changes, drivers still produce a
(limited by hardware) number of standard formats, yuv, rgb, etc.
And the library will have to know them, as will it have to know the
available sizes.
Secondly an app needs to be able to tell the library which common format(s)
it wishes to get (in a stream or snapshot or whatever) and the library
(using some magic lists) will determine what format to really capture and
then convert it.
So if the ibmcam driver only produces yuv its fine, if the se401 driver
only produces rgb its fine to, if a new driver produces something completly
different (so not a slightly modified or compressed existing format) we
should add a new standard format to the v4l spec.
So the only thing I would like to see added to the v4l spec is a way to
find out what sizes and formats a driver supports.
The library would simply ask a driver if it can scale or if it can't it
takes the nearest available format out a driver supplied list and scales it
itself.
Just my 2 cents....
Jeroen
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
