[gst-devel] Indifference is not an argument!

[Ronald Bultje]

Hi Tuukka,

I've seen earlier of your postings on the v4l mailinglist, welcome to
this list!

On Mon, 2003-02-24 at 10:03, Tuukka Toivonen wrote:
> [Some words of myself since this is my first post to the list: I'm qc-usb
> camera driver developer but the problem is that the camera doesn't
> deliver any format that is supported by V4L(2), and as you can see from my
> signature, it isn't exactly recommended to do format conversions in the
> 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,
> though, but I just started investigating it anyway. Nevertheless, if
> Gstreamer API is as good as I hope, I'm confident it will be one of the
> most important things that have happened to Linux recently]

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
used extensions for basic things like timestamps, hardware-encoded
frames, etc. In v4l2, I've made sure that all this is possible in the
standard API, so that we wouldn't need any extensions. This has
succeeded, causing our v4l2 driver to be fully integrated in the v4l2
API, no extensions needed. I personally feel that v4l2 is extendible
enough to not need to dive away from it for hardware that isn't
'standard-like'.

I'm assuming the qc-usb cam delivers JPEG-like frames (quite some cams
do this, *ugh*! But yes, it gives nice images at low datarates, which is
good ;-) ). I'd suggest to try to use standard V4L in your driver, and
only offer the fourcc 'JPEG' (V4L2_PIX_FMT_JPEG), which means 'JFIF-like
JPEG', as opposed to Motion-JPEG (YUY2), which is 'MJPG'
(V4L2_PIX_FMT_MJPEG). The current GStreamer v4l2 plugin will attach a
mimetype of 'video/jpeg' to this, so you only need to place a JPEG
header in front of it (this is something the driver is supposed to do),
and jpegdec (libjpeg decoder) will happily decode the JPEG frames.
ffmpeg's optimized JPEG decoder (ffmpegdec) and mjpegtools' MMX/SSE JPEG
decoder (jpegmmxdec) will also work here. This would all integrate
perfectly in GStreamer, and you'd still be v4l2 compliant. Isn't that a
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
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).

If anything doesn't work, feel free to hop on in #gstreamer @
irc.freenode.net, I'll be mostly online during the days (I'm at work
though, so I might not respond) - I'll be happy to help in helping out
to make both the driver and the v4l2 plugin work with your cam. That's
how I tested the v4l2 parts of the zoran driver too. ;-).

Ronald

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