[gst-devel] Indifference is not an argument!

[Ronald Bultje]

Hi Tuukka,

On Mon, 2003-02-24 at 14:26, Tuukka Toivonen wrote:
> Basically the qc-usb supports Bayer CFA-encoded frames, for which there is
> not support in V4L(2). A format definition could be added, but it wouldn't
> help, if no application would support it (and really it would need to be
> supported by _every_ application). So, what's the point using V4L(2) API if
> only special applications can use it anyway... unless there's a plugin for
> Gstreamer which would understand the Bayer format. To summarize: yes, I'm
> planning to use V4L(2) API but add a compilation time option to remove
> format conversions, which sets the driver to output Bayer format which will
> be supported only via gstreamer plugins, thus rendering the driver
> V4L API practically useless for general applications.

OK, that's what I was hoping for. This is exactly what I meant.

> >only offer the fourcc 'JPEG' (V4L2_PIX_FMT_JPEG), which means 'JFIF-like
> >JPEG', as opposed to Motion-JPEG (YUY2), which is 'MJPG'
> 
> With some rare cameras, qc-usb actually supports compressed MJPEG-alike
> format (decompressing in the kernel space, ugh). But I'm not quite sure
> about this format, I just copied the code from other people. Looks like
> it's 4:2:0 YUV sampled, isn't it more MJPEG than JPEG/JFIF style?

"Official" MJPEG video is 4:2:2 packed-pixel Y'Cb'Cr (YUY2). Yours
sounds like IYUV/I420 (4:2:0 planar Y'Cb'Cr). I don't think JFIF/JPEG
defines anything specifically about colorspace, it's just a generic
compression scheme.

> [A link to MJPEG/JPEG format specs would be great... but I think they
> are available only for $$$ so it's difficult to know if the camera is
> sending conforming bistream]

There's quite some documentation on http://www.ijg.org/. Since JPEG is
an official ISO standard, I'd expect the ISO specs to be there too, or
on http://www.jpeg.org/. Can't find it at first sight, though. There are
some (MS Word) JPEG docs in /usr/share/doc/libjpeg-devel-6b/ too (part
of the libjpeg-devel package).

> Uh.. the application programmer's API, when using Gstreamer's V4L(2)
> plugin, is not V4L(2), correct? That was my original point: I'm planning to
> deprecate the direct use of the driver V4L(2) API, but recommend to use it
> via Gstreamer API. As soon as I get the Bayer->RGB conversion plugin
> written.

Sounds great! I'm all in for it.

Ronald

-- 
Ronald Bultje <rbultje at ronald.bitfreak.net>
Linux Video/Multimedia developer