GNOME Bugzilla – Bug 342494
[v4l] Query "device-name" even if device is not open
Last modified: 2006-07-19 14:59:31 UTC
Current v4l elements only have a non-NULL "device-name" property if the device is opened. This is problematic if applciations use the property probe interface to check all available v4l devices and read their hardware device name. 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. The "v4l/v4l2" elements do return "NULL" in such a case. 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. 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)
Created attachment 65943 [details] [review] Opens device if required to read "device-name" property Changes: * Return "device-name" property, not requiring the device to be opened Now displays a correct device name: http://www.sukimashita.com/temp/gstp-video.png
Created attachment 65944 [details] [review] [v4l2] Opens device if required to read "device-name" property Changes: * Return "device-name" property, not requiring the device to be opened (Applies to gst-plugins-bad, should I create a clone of this in that category?)
> 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.
(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. :)
Okay, committed these patches: 2006-07-19 Tim-Philipp Müller <tim at centricular dot net> Patch by: Martin Szulecki * sys/v4l/gstv4lelement.c: (gst_v4lelement_get_property): If "device-name" is requested and the device is not open, try to temporarily open it to obtain this information (#342494). 2006-07-19 Tim-Philipp Müller <tim at centricular dot net> Patch by: Martin Szulecki * sys/v4l2/gstv4l2object.c: (gst_v4l2_object_get_property_helper): If "device-name" is requested and the device is not open, try to temporarily open it to obtain this information (#342494). I'm not really entirely happy about this, since it doesn't work if the device is in use and because the whole thing is probably racy, but for the usual property probing/v4lsrc use case at least the latter doesn't matter too much and working in some cases is still better than in none. GstPropertyProbe having a sucky API doesn't make things easier, but can't be changed in the stable series unfortunately. IMHO it would be better if your application tried to obtain this kind of information from other sources, like HAL for example.