[gstreamer-bugs] [Bug 342494] [v4l] [patch] Query "device-name" even if device is not open

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=342494
 GStreamer | gst-plugins-base | Ver: HEAD CVS





------- Comment #3 from Tim-Philipp Müller  2006-05-21 18:35 UTC -------

> This behaviour is not consistent with other elements that implement the
> "device" property. The "alsa" elements return the "device-name" if a
> valid "device" property is set.

Really? As far as I can see the alsa* elements will only return a device-name
string when the device is open (ie. in READY state or higher), and NULL
otherwise.



> The patch below, additionally triggers an attempt to open the device, read the
> device-name and closing it again if it is not already opened. This makes 
> device probing work.

You could just as well set the device, set the element to READY state in your
app, then read the device-name, then set the element back to NULL state (which
is what the gnome mixer/volume control does). Your patch makes things more
convenient of course, I'm just not entirely sure whether we want to do 'hidden'
device opening like this (besides the hiddeness of it there might also be
threading issues to take into account).



> Aside of this, it might be time to think about a specification for elements
> and applications to query/get device(name) lists efficiently (cache) and
> consistent if implemented in new elements.
> 
> This is a side-effect of an attempt to add "device" option menus to the
> gstreamer-properties capplet. (Bug 341983)

If you have specific ideas how you'd want this to look like, why not send a
mail to the mailing list or suggest it in a new bug report? :)

API/ABI stability shouldn't get in your way in this case - after all we can
always add a new GstSpiffyDeviceProbeInterface and make elements implement that
in addition to the old GstPropertyProbe one.

The more important question is whether this is the Right Thing to Do in the
longer term or whether device probing isn't better left to HAL and friends.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.