Hi Gerd,
On Wed, 2002-10-16 at 22:05, Gerd Knorr wrote:
> gstreamer accepts _every_ format a v4l2 device provides, even if it
> doesn't know what this is? How does it handle the frames then?
Yes. gstreamer is element-based. If it's not-compressed, we simply
create a video/raw mime type with fourcc code which is equal to the v4l2
fourcc. We move this on to the sink element (i.e. a displayer, or a
colorspace convertor), which recognizes it (or not) and displays it. The
v4l2 element doesn't necessarily know what formats are supported,
though. In case of compressed, we create video/<fourcc>. So for
v4l2_fourcc('M','J','P','G'), this'd be video/mjpg. For MPEG, this'd be
video/mpeg. this is send to a plugger, which selects (based on this) the
mpeg or jpeg decoder. And for unrecognized formats, one could write a
new decoder. But v4l2's element wouldn't have to be changed then. So
it's kind of useful for gst.
> > The other solution (which I like too, but you probably don't ;-) ) is to
> > add CODECIN/OUT as v4l2_buf_type, like it as in the old v4l2.
> Codec in/out was meant for a device which accepts frames from the
> application and returns them compressed to the appliaction as I
> understood it. That is something different than a grabber card doing
> compression in real time.
Hm, I guess I misunderstood this all the time. ;-). Bad me.
> > > #define V4L2_CAP_TUNER 0x00010000 /* Has a tuner */
> > I'd like to see V4L2_CAP_AUDIO be added here, is that possible?
> Sounds reasonable. Same as with TUNER, would be somewhat redundant, but
> likely useful for a quick check whenever a device does audio too (usb
> cams often don't).
It's just intended as a quick check of no real importance. capabilities
aren't that informative anyway. ;-). They're just some general
information about the device.
Ronald
