GNOME Bugzilla – Bug 424839
expose parts of GstTuner as properties
Last modified: 2011-05-18 13:04:05 UTC
Please describe the problem: you commented out a part of 'gstv4l2object.c'. This made it impossible to select the proper v4l2 videosource ( Tuner, Composite1 or S-Video ) from my usb videograbber (WinTV USB2) because you made the 'channel property inaccessible. I uncommented the affected lines and it worked like a charm. affected code: /* FIXME norm, channel, frequency are part of the tuner interface, so they should be removed from the properties g_object_class_install_property (gobject_class, PROP_NORM, g_param_spec_string ("norm", "Norm", "Standard norm to use", DEFAULT_PROP_NORM, G_PARAM_READWRITE)); g_object_class_install_property (gobject_class, PROP_CHANNEL, g_param_spec_string ("channel", "Channel", "Input/output channel to switch to", DEFAULT_PROP_CHANNEL, G_PARAM_READWRITE)); g_object_class_install_property (gobject_class, PROP_FREQUENCY, g_param_spec_ulong ("frequency", "Frequency", "Frequency to tune to (in Hz)", 0, G_MAXULONG, DEFAULT_PROP_FREQUENCY, G_PARAM_READWRITE)); */ Steps to reproduce: 1. connect v4l2 device with more than one video sources (e.g. WinTV USB2) 2. do something like e.g.: 'gst-launch v4l2src channel=S-Video ! xvimagesink' 3. watch for the error message Actual results: WARNING: erroneous pipeline: no property "channel" in element "v4l2src0" Expected results: have the video playing in a window Does this happen every time? yes Other information: after uncommenting the affected code it works again
This is not a bug (provided that the element implements the tuner interface correctly). gst-launch is not a real application. Having these parameters as properties in addition to the interface serves no purpose and is redundant.
I do not agree with that. Interfaces declare Methods at compile time which can be called by other code being aware of the exact semantics of the interface. Properties on the other hand are resolved during run time through a generic api which can be accessed by 'dumb' code (like the gst_parse_launch() method, the gst_launch command or gst-editor). So it is left up to the user to know about the properties (which he could enumerate using introspection techniques e.g. gst_inspect or using a gui like gst-editor). So properties exist on another abstraction layer than the interface paradigm and thus cannot be implemented within it without breaking the model and therefore this functionality must be defined in the class implementing the interface (although it should be possible to define some kind of higher level interface model... but this is worth a discussion for its own...)
... and also some 'real applications' like flumotion depend on having these settings exposed as object properties because they construct pipelines from text strings. That may be the reason while flumotion still uses v4lsrc instead of v4l2src in its bttv and webcam components (v4lsrc still exposes the needed properties). I just patched it to use my (back-)modified version of v4l2src and it works. So I really consider this a bug.
Sorry, this is not a bug. v4lsrc doesn't have these properties either. It's not possible to do everything that is necessary for tuning using properties, which is why we created the GstTuner interface.
you are right with respect to v4lsrc. I accidently looked into gstreamer-0.8 where these properties are available. But I do not understand why you can't put (or better 'leave') important functionality implemented as properties to make it accessible through bindings (e.g . the gst-launch interface, which is used e.g within flumotion or other software that is quite happy with building pipes out of textual descriptions) that depend on properties. In my understanding of the OO paradigm and the property pattern it is perfectly valid to expose functionality which is implemented through interfaces as properties of the implementing class without violating the underlying model. Properties serve (among other things like the signaling of data changes in gtkmm) the purpose of adding generic accessibility to the (statically compiled) functionality of classes and thus they do not present an unnecessary redundancy. Quite the contrary, not consequently following the property pattern throughout the whole gst framework only cripples it's usability when using other than statically bound (language) interfaces. I'm perfectly aware, that not every functionality can easily implemented using the property pattern, but in case of selecting different input channels and TV Standards of v4l(2) input devices this should not be a problem (given this functionality was already available) and this is the bare minimum of making it usable through gst-launch.
These properties could be added to the GstTuner interface itself, but they do not belong in v4l2src or any other class that implements GstTuner. Feel free to provide a patch. Make sure to review all the bug reports in the 0.8 series related to v4lsrc properties that led to the GstTuner interface, especially the intractable ones. gst-launch is not a binding. It's a test tool. Moreover, it's an *internal* test tool that we allow others to use. Also, just because something happens to work for you does not mean that it works in general. The fact that the properties were removed from v4lsrc (which is in -base) is a good clue that it was probably unmaintainable.
As no patch for GstTuner appeared yet it doesn't seem to be urgent and IMHO using properties for this is not very useful either if there are functions already. Adding two ways to do the same thing is not a good API.