> 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.
General transformations are not going in kernel space. Period. If V4L2
decides to do that then V4L2 is not going to hit the kernel either.
You are right that the apps have to deal with a lot of formats, wrong to
think the kernel should be involved. Your modular transformations belong
in userspace as something like libvideotransform.a.
By putting it in userspace you make it swappable, you make it easily updated,
you make it expandable for new formats without work, and you get to use
MMX and SSE. A lot of format conversions you want MMX for - you cant get
that in kernel space.
> 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.
The conversions I've seen so far in the YUV space are byte re-ordering. Where
there are common YUVlike formats we need to define another format type and
you want the processing in user space. There are simply too many cases where
doing it outside of the app is wrong. With kiovec based direct I/O the number
of cases is vastly increased.
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
