From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2006-05-21 22:27:11
|
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=3D342494 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 t= he > > "device" property. The "alsa" elements return the "device-name" if a > > valid "device" property is set. >=20 > Really? As far as I can see the alsa* elements will only return a devic= e-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 ma= kes=20 > > device probing work. >=20 > You could just as well set the device, set the element to READY state i= n 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 m= ore > 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). >=20 Actually, that is absolutely and exactly what I am doing (which is not wo= rking and the reason I created this bug). ;) However in this case, the device does not remain in "open" state (at leas= t not to satisfy the GST_V4L_IS_OPEN macro). It only remains "open" when you ac= tually start capturing. I am also not very confident with this "open/close" and possible conseque= nces 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 cr= eate a seperate utility "get device name" method just for this issue. > > Aside of this, it might be time to think about a specification for el= ements > > and applications to query/get device(name) lists efficiently (cache) = and > > consistent if implemented in new elements. > >=20 > > This is a side-effect of an attempt to add "device" option menus to t= he > > gstreamer-properties capplet. (Bug 341983) >=20 > If you have specific ideas how you'd want this to look like, why not se= nd a > mail to the mailing list or suggest it in a new bug report? :) >=20 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 implem= ent that > in addition to the old GstPropertyProbe one. >=20 > 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 frie= nds. >=20 The stuff looks like a lot of effort, for a rather simple requirement. An= ways, topic for the mailing list. :) --=20 Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=3Demail ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. |