[gst-devel] gstreamer and video device probing

[Filippo Argiolas]

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

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?

- there seems to be no way to get video device capabilities without
starting a pipeline, both v4lsrc and v4l2src implement (and not in a
good way) propertyprobe just for the "device" property. Would it be
possible to use propertyprobe for "flags" property too? is it possible
to fix a property (i.e. the device) and probe another one (i.e. the
flags)?
What I'd like to do is:
pspec = gst_property_probe_get_property (probe, "device");
GValueArray *array = gst_property_probe_probe_and_get_values (probe, pspec);
for (i = 0; i < array->n_values; i++) {
     g_object_set_property (G_OBJECT (element), "device", device);
     pspec = gst_property_probe_get_property (probe, "flags");
     /* get flags for the current device */
     ...
}
Linking and playing a simple pipeline for each device just for exclude
radios and tuners is not exactly optimal from my point of view.

- there is no way to monitor new devices attached. At the moment we
don't use such a thing but wouldn't be bad to have it. But does it fit
in gstreamer purpose?

A good solution would be a custom class for device detection, a bit
like the one David suggested [2], that supports several backends (a
libudev one for v4l devices, some win32 thing for win32 sources,
freebsd, opensolaris, etc...).
It could monitor new devices attached, retrieve supported capabilities
(or maybe just filter them by capability directly in the monitor code)
and maybe provide the best suited source element to access it.

What do you think about it? Are there other users for this kind of
stuff other than Cheese? Is Gstreamer the place for this probing?
Is there anyone willing to actually implement it or help to implement it?
Any suggestion or opinion welcome.

Cheers,
Filippo


1. http://lists.freedesktop.org/archives/devkit-devel/2009-April/000140.html
2. http://marc.info/?l=linux-hotplug&m=124181585125194&w=2