On 2001.05.26 02:00:38 +0200 Dmitri wrote:
> Quoting Jeroen Vreeken <[EMAIL PROTECTED]>:
>
> >
> > > 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.
> >
> > I took a quick look through the api document and would like to propose
> the
> > following:
> >
> > Two new fields are to be added to VIDIOCGCAP, namely 'sizes' and
> 'formats'.
> > If the hardware can scale between the max and min sizes it simply sets
> > sizes to zero.
> > (All bttv folks are happy now), if not it returns the number of sizes
> the
> > driver supports.
>
> Sometimes a device can deliver more than one format at different cost,
> cost here being either CPU cycles or the frame rate or whatever. Maybe
> we need to add this "preference" or "cost" factor too, so that the
> library will be able to choose the most appropriate format.
>
> As I mentioned earlier, sizes and formats often are mixed together - and
> that is logical because the cheap DSP inside most cameras can not do
> efficient processing at higher pixel counts, and then the device just
> starts dumping raw RGB - sometimes even not demosaiced at all - into
> the USB wire. So probably the device has to advertise not just a format
> that it may support now and then, but a complete list of all formats,
> image sizes, color depths, frame rates etc. (with wildcards, maybe):
>
> enum Formats {
> { rgb24, r/g/b, 8-8-8, 3-15 fps, {176x144, 352x288}, ... },
> { rgb15, b/g/r, 5-5-5, 10-15 fps, {176x144}, ... }, ...
> };
Aren't the first three all taken care of by the format type?
Isn't VIDEO_PALETTE_RGB24 enough (everybody should know its b/g/r
8-8-8)....
We should also be carefull to over speciffying for every hyphotetical
device out there, a device that has a completly different set of formats
for each size is always going to have problems.
> Some cameras have windowing capability where they can cut a portion
> of a bigger picture and deliver it to the user space. This feature
> must be accessible too.
It is, VIDEO_TYPE_SUBCAPTURE and VIDIOCCAPTURE
> Other cameras have the button (or several) on them. Currently V4L
> has no means of using the button, short of marrying the webcam
> driver with an input subsystem. This should be supported.
I don't know... It doesn't really have anything to do with videocapturing,
so why not marrying it with the input system? (Or at most offer a standard
peace of glue in videodev to call when the button state(s) change.
> As I said, the new V4L interface is not an easy thing to design.
> But 2.5.x is an appropriate place for that sort of hacking.
Agreed.
Jeroen
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
