In message <1046202526.15012.21.camel@xxxxxxxxxxxxxxxxxxxxx>
Ronald Bultje <rbultje@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, 2003-02-25 at 18:43, luca_ing@xxxxxxxxx wrote:
> > Hello, i am searching for a jpeg decompressor ( better someone
> > who wants to write it :-) ) to include in my kernel driver for a
> > webcam/chip which supports standard jpeg compression with yuv422/0
> > planar 8/16 bit encoding, non-interleaved scan.
> Don't do that, it's evil. JPEG decompression shouldn't be done
> in-kernel. Use v4l2, identify as V4L2_PIX_FMT_JPEG and let userspace
> applications decode that.
Absolutely right, if you have v4l2 available. Unfortunately, if you want
to provide backwards compatibility, there are very few options available
to you. It's not feasible to change all the existing v4l applications to
support an unofficial 'this is jpeg' type. That's one of the very reasons
why there is a new v4l API being developed.
We've had to do the above in the spca50x (spca50x.sourceforge.net) driver.
In summary, yes, it's evil. Yes, it should be done in userspace, but in
some situations, there is no realistic alternative.
[I don't want this to turn into a flame war or anything, I'm well aware of
the issues involved with doing this evil stuff.]
> (Don't tell me this JPEG decompression code is really in the kernel)
It's in a non-standard kernel, possibly redhat, not sure offhand.
--
Miah Gregory
