On Wed, 17 May 2000, Alan Cox wrote:
> > with this totally device-specific data stream. No client would be able (or
> > want) to understand device-dependent formats. V4L does not seem to have a
> > good place to insert such conversion code into. V4L2 does. In the mean
> > time all drivers produce RGB24 (or GRAY) output - not because they love it
> > but because they must.
>
> No. The API is intended to dump everything in user space. Doing conversions
> in kernel space is bad for applications
> > All (or most of) camera drivers are based on CPiA code. It did YUV -> RGB
> > conversion in USB interrupt thread. This is very bad performance-wise. I
>
> This is broken. They should be outputting YUV not RGB888 to user space.
> The application (or eventually once we have all the nice kiovec stuff in)
> the video card is responsible for things like YUV->RGB and scaling.
It is not -nice- to force -all- clients to understand -any- source format;
they already have their hands full handling displays and UI... That's why
I expect V4L2 to step in with its modularized drivers for all
transformations etc. We are just stuck with V4L for the moment.
HOWEVER. Cameras -do not- produce legitimate YUV formats! They produce
some sort of them - with variations; some are YUYV, some are YYYYUUVV,
some are in [16..240], some are +-120 ... this is not YCrCb that we would
want to transfer to the client. This device-dependent formats -must- be
converted to something standard, and it is not always easy.
Additionally, some OEMs want overlay support in the driver... I don't
think it is a good idea, however.
Thanks,
Dmitri
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
