On Sat, 1 Apr 2000, jamester wrote:
> I am trying to use a camera based on ov7610 and ov511 chips. It
> works very slowly(seems like less than 1 fps) with xawtv. However,
> touble comes when I try to use this camera with a
> video-conferencing tool. I notice that ov511 driver converts
> YUV420 format to RGB24 format.
I don't have ov511-based cameras and I don't work on ov511 code, but
I'd like to discuss your questions anyway - all cameras do these
things similarly.
> Q1. Is there any nice way to output YUV420 format? Grabber for the
> video-conferencing tool takes RGB24 and converts back to YUV420 -
> redundant work., which makes everything even slower.
We are talking about V4L (not V4L2) here, I suppose.
Indeed it could be possible to output any format - YUV or RGB, planar,
packed or whatever. But this adds code to the driver, and this code
generally can't be shared among drivers. All cameras produce different
native datastreams, and they may be slightly non-standard. For
example, IBM camera sends YUV packed, but voxilla (see
http://www.openh323.org) expects it to be planar. The order of U and V
bytes depends on format. Therefore even with this camera we would need
to do -some- conversion (though not so drastic as YUV -> RGB).
So this becomes a philosophical question - who does conversion from
native camera format to all (or many) standard formats? If we put
converters into each & every driver we would run out of memory (and
patience) pretty soon :) So at the moment cameras produce some common
format, reasonably acceptable to most V4L clients. This just happens
to be RGB24 - easy to understand, and it is overlayable (in theory).
ov511 also can do GREY palette. The choice of formats supported by the
driver is directly related to capabilities of hardware that this
driver controls.
V4L2 (which will be available RSN) does provide modules - converters
between formats, palettes and such. These modules have single purpose,
so they can be developed with only performance in mind, by developers
who know color theory very well.
V4L2 will also provide API for enumerating driver capabilities. V4L
does not allow you to list supported formats, so even if some camera
driver does support YUV and RGB you'd need to have some external
information to figure that out. You can't query V4L driver for -exact-
list of supported features.
> Q2. The grabber for video conferencing tool wants a CIF picture
> which is 352 x 288. However, ov511 sets 640x480 by default. Is
> there any way to configure size of a grabbed picture dynamically?
I believe most V4L clients can do that. The picture size is returned
via one of V4L ioctl calls; client can ask for a range of acceptable
sizes (VIDIOCGCAP), client can specify the desired size
(VIDIOCMCAPTURE). Camstream, I believe, has such option, and
xrealproducer does that too. However if camera driver does not like
the size that you asked it will return error or (as ov511 does) just
continues with previous size set in camera and -new- size set in
variables {Mark: could this be a bug in ov511.c line 1594 - ignored
return value of ov511_mode_init_regs()?}
ov511 supports subcapture (capture of portion of the frame), so this
can be used too.
Though V4L allows you to pass the size request to the driver it does
not guarantee that it will be done at all. USB cameras (and other
cameras too, as I understand) require complicated initialization
process where camera is instructed to produce certain video stream,
with certain picture size. If you want to change that at run time this
requires stopping the camera and reinitializing it with new settings.
ov511 driver does that if you change the picture size between frames.
The ov511 driver supports two sizes only: 640x480 and 320x240. So your
V4L client has to request 320x240. If this is too small... too bad.
Drivers return only "native" sizes, they can't be bothered with
convenience routines for translations, effects, software color
corrections and other things like that. Either V4L2 specialized driver
will do that, or the application must be designed to work with any
driver, any native size (and, preferrably, any format too!)
I am playing with voxilla (video) these days, and I had to develop a
patch (30 lines or so) to support some USB cameras (RGB -> YUV
conversion and subcapture). It works, though.
Thanks,
Dmitri
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
