[gst-devel] gstreamer and video device probing

[David Zeuthen]

Hi,

On Mon, 2009-06-01 at 14:05 +0300, Stefan Kost wrote:
> Filippo Argiolas schrieb:
> > Now that HAL is going away I'm looking for a good replacement for the
> > v4l device detection code in Cheese.
> > At the moment we ask HAL to give us a list of devices from the
> > video4linux subsystem and we do a couple of ioctls to see if the
> > device is a v4l2 or v4l1 one and if it supports the CAPTURE
> > capability. Those ioctls aren't really needed because HAL already does
> > that stuff for us but I found it out only yesterday :P
> > Anyway, the purpose of those ioctls is to exclude each non-webcam
> > device (tuners, radios, vbis, etc) before to start the gstreamer
> > pipeline.
> > This way we can reduce a lot the time needed for device probing
> > (starting a v4l*src pipeline can be quite slow) and we can avoid
> > "garbage" in the device list.
> > At first I thought I could just replace the HAL stuff with DeviceKit,
> > but DeviceKit is going away too in favor of plain libudev [1].
> >   
> Your patch needs to be applied by someone who can vaerify it. I have no
> libudev in my distro :/

For the record, libudev has been around since 8/27 2008 and it has been
LGPLv2.1 since 3/26 2009. FWIW, today I just added GObject bindings
(including GObject introspection support and a Javascript example)

 http://people.freedesktop.org/~david/gudev/

so it's very easy to use libudev from G applications. The grand plan is
that the bulk of device enumeration / notification in GNOME will switch
to using either libudev (through GUdev) or things like DeviceKit-disks
and DeviceKit-power.

Of course, it will take some time until this bubbles into released
distros; I don't have any good advice on how to handle that other than
telling people to use newer distros. FWIW, what we're doing in GIO/GVfs
is that we have a soft dependency on things like libgudev / DeviceKit-*.
If people have new enough software they get a new backend, if they don't
(e.g. enterprise distros, version updates for enterprise/stable
distros), we fall back to existing old code. In practice it works out
fine.

> > So the next step should be to port Cheese to libudev, but as David
> > suggested [2], why not to do the detection directly in Gstreamer?
> > As far as I can tell the current option with Gstreamer is to use the
> > PropertyProbe interface.
> > But as it is at the moment it's suboptimal for our needs:
> > - the device detection code in v4l?src just tries to open
> > /dev/v4l/video* and /dev/video* devices. It doesn't even check the V4L
> > api they support.
> > Wouldn't be better to use libudev to enumerate all the devices from
> > the video4linux subsystem?
> >   
> I commented in the bug, maybe we should use this for all kind of
> hardware sources and sinks.

Sorry, what bug is that?

     David