Hello all,
[hmm, maybe this should be crossposted to the video4linux list?]
On 17-May-00 Dmitri wrote:
> IBM camera (model 2) produces YUV format (packed) on sizes <= 176x144
> and RGB (sort of) on 352x288. The driver reports (and sets) its
> capability via VIDIOCGPICT, VIDIOCSPICT. Only one format is set at any
> given time, and V4L does not allow to enumerate supported formats.
...which is unfortunate, indeed. Would it be much of a problem to add an
ioctl() call to the current V4L API to retrieve a list or bitmask of the
available palettes? I'd prefer a list, and with each entry on the list I
would like to add a parameter that tells me if this format is costly (in
terms of internal conversions) or not.
> Then V4L client supplies desired format with every VIDIOCMCAPTURE
> request. However it can't know which format this driver prefers for
> the given frame size (which is also supplied in the request).
>
> This means that the client must magically know that driver XYZ sends
> format ABC under this circumstances and format DEF under another
> circumstances.
This is one of the weaknesses of the current V4L API, I think. Because it
was written for grabber cards that do all the transformation in hardware, it
doesn't matter if you select a different format for each frame you request
with MCAPTURE (it's not logical, but it's possible). There are two points
where you can set a palette in the current API, and it's unclear whether the
VIDIOSPICT palette should be global or be used just for read() calls.
> Then the client can instruct the driver to send most
> appropriate format in the frame (or even re-negotiate picture settings
> via VIDIOCGPICT, VIDIOCSPICT - though these ioctls don't deal with
> current frame size...)
#define most approriate? In my camstream application I tell my code which
format I prefer (YUV, RGB or both). It then tries to set a palette which
best suits the desired format, with a preference for YUV if both formats are
requested since this is native to most webcams anyway and because YUV->RGB
conversion is easier than the other way around.
> Since most clients are not written with specific devices in mind, they
> don't know that - and they will continue to request frames in old
> format (YUV) even if the camera switched its mode (to RGB) to
> accomodate for larger frame size.
I don't think one should allow for this to happen at all. I mean, the
program TELLS the driver which palette it wants (out of the available
ones), and should not be TOLD by the driver what format it decided to like
today.
> To change the desired frame size
> user simply resizes the V4L client window (as done by xawtv) or can
> use buttons (as camstream does). To complicate things even further,
> some cameras have snapshot feature which can be programmed to emit
> -one frame- with completely different format and size each time the
> button is pressed.
Yes, but usually you have to send a command to the cam to send this one
frame (that is, the button itself does not change the output format; but
that could be different on some cams).
> So the question is: how do we avoid conversion of YUV into RGB or RGB
> into YUV if camera can produce either of them at will, and the client
> doesn't really know which is which when?
The client shouldn't "know" this. It should either set the palette, or at
least get it and act accordingly. Unfortunately, there are a lot of tools
that don't pay attention at all to the palette; they blindly assume a
certain format. Since these programs are easily patched, I wouldn't worry
too much about breaking them; inconvenient, but that's what you get for not
reading the spec. :)
However, there's another issue... In case my webcam is able to produce
various formats, I would like to be able to choose the one that matches my
application best.
For example: a simple webcam grabber tool probably wants a RGB format, since
that's easiest to display and/or save to an image. But a videoconferencing
tool (H.320 et all) is much better off starting with YUV-planar format.
Therefor, an application should query the available formats and pick the
best match (xawtv does that, as does camstream). However, if we were to
allow ONLY YUV formats, we might have a situation where the native format
from the cam is RGB, converted in kernel space to YUV and back to RGB again
in the program. That's a waste of time if I could have requested RGB right
away.
Something similar with the various YUV formats; the Philips cams produce a
format that can be converted very effeciently to YUVplanar and somewhat
less effecient to YUYVinterlace. If I want planar format I'd like that right
away, in stead of internal -> YUVi -> YUVp. But if the native format of the
cam is YUYV, then simply don't offer the planar format and the program would
have to deal with YUVi -> YUVp.
> Additionally, how many clients are written "correctly" if the solution
> exists? How many clients are capable of handling any of several
> supported V4L formats, and what if most of them can deal with only one
> or two?
I'd say 40% is badly broken, 50% gets it halfway right and 10% does it
completely right.
> The change in drivers will be very simple. But I have no idea what
> impact will it have on installed base of clients. I don't mind
> deleting YUV->RGB math, but I am worried that this will render USB
> cameras mostly unusable. Opinions?
Agreed. It will break a LOT of tools (as I experienced with my drivers when
I served RGB in stead of BGR format). I agree we have to clean out this
somewhat messy situation; also I don't mind breaking a few badly written
applications, but not for the somewhat dogmatic reason: "we should be
serving YUV and nothing else, because conversions in kernel space are bad".
I don't think format conversions in the kernel are necessarely bad, but they
should be done at the right place (e.g. not in an interrupt routine), and if
code is shared among drivers I wouldn't mind (make it a module :)).
Consider this: it's a lot easier to patch 1 linux kernel than get 22
different tools in line.
- Nemosoft
-----------------------------------------------------------------------------
Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000
URL: never IRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft
>> Never mind the daylight <<
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
