> 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.
But they should, see Alans comments.
V4L2 might just provide an optimized userspace library for conversion
purposes.
> 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.
Since they usually have to scatter-gather the data anyway, they can create
the format matching best. But they should not do colorspace conversion or
rescaling in kernel space!
Ciao, Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
