Re: buggy v4l apps (was: VIDIOCSYNC and bad data)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Tuukka Toivonen <tuukkat@xxxxxxxxxx> writes:

> >IMHO it would be better to put that into a small library which has
> >just the conversion functions and nothing else.
> 
> I don't think so: in a generic plugin system, parts of the driver could be
> moved into userspace plugins.

gstreamer IMHO isn't the solution through.  I doubt making gstreamer a
requirement to talk to v4l devices would be accepted by the users and
developers.  gstreamer does to much (it is more that libasound for
video) and has to much dependencies (glib, xml, ...).

> It's not just format conversion: there certainly is/will be hardware that
> needs complex image processing and filtering for the incoming video, and
> likely some features computed from the video image need to be fed back to
> the driver to control the camera.

Such filters can be put into the library too.

> For example, I get mjpeg-compressed video from the camera that I need to
> uncompress and compute the image brightness. The brightness then controls
> the camera exposure time. Another example: automatic focus control.

I don't want to have such stuff as some magic happening somewhere in a
plugin system.

I want a documented ioctl interface between kernel and userspace, like
it is now.  Having an (optional) library which helps applications
doing format conversions and other fancy stuff like autofocus /
exposure control / whatever is fine, so that not everybody has to
reimplement that.

> Besides, users have asked me to implement things like flipping image upside
> down in the driver, because they have mounted the camera into ceiling or
> something. With a proper plugin system, this should be possible with all
> video applications by just editing ~/.gstreamer.conf or something to tell
> the pipeline that "insert somewhere a flip plugin".

Every software filter is a performance hit, so this is IMHO a bad idea
to just take a software filter for everything.  Maybe it isn't that a
big issue with the data rates a usb cam can handle.  But there are
other drivers and other hardware.

bt878 chips for example produce much more data.  And they can do the
upside-down flip completely in hardware ...

> So I think that a big complex plugin system is needed, hopefully
> Gstreamer.

IMHO gstreamer isn't the solution.

  Gerd

-- 
sigfault




[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux