[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 #4 from Martin Szulecki  2006-05-21 22:27 UTC -------
(In reply to comment #3)
> > 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.

It is the idea to set the device, go into READY state, read device-name, set
NULL state. Read below.

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

Actually, that is absolutely and exactly what I am doing (which is not working
and the reason I created this bug). ;)

However in this case, the device does not remain in "open" state (at least not
to satisfy the GST_V4L_IS_OPEN macro). It only remains "open" when you actually
start capturing.

I am also not very confident with this "open/close" and possible consequences
but as of now the only other implementation for this would be using some
"hacked" "cache device-name if ever opened before" kind of solution or create a
seperate utility "get device name" method just for this issue.

> > 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? :)
> 

Good idea actually.

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

The stuff looks like a lot of effort, for a rather simple requirement. Anways,
topic for the mailing list. :)


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