[gst-devel] Indifference is not an argument!

[Tuukka Toivonen]

On Mon, 24 Feb 2003, Ronald Bultje wrote:

>> kernel... so my plan is to abandon V4L(2) api partially in the longer run
>> and support Gstreamer API instead. Didn't get gstreamer video yet to work,

>Being one of the persons really in *favour* of v4l2, I'd strongly advice
>against this. I'm developer of the zoran v4l/v4l2 driver. In v4l1, we

>good ;-) ). I'd suggest to try to use standard V4L in your driver, and

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.

[But to users reading this: don't be afraid, I'll keep format conversions
as long as there are significant applications around which don't support
gstreamer. This is a _very_long_ run plan]

>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?

[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]

>good thing? This is basically the goal of GStreamer's v4l2 plugin:
>support as many weird color formats in v4l2 as possible, while still
>being 100% v4l2 compliant. I'm against doing format/colorspace

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.

>conversions in kernelspace, and GStreamer gives perfect solutions for
>problems that this might cause in userspace (by automatic colorspace
>conversion or format decoding, all integrated in compatible pipelines).

Really great!