GNOME Bugzilla – Bug 448278
[v4l2src] several issues in cvs
Last modified: 2008-03-25 14:58:27 UTC
if I try to get tuner interface from v4l2src with following code I get these messages: (glotze:9811): GStreamer-CRITICAL **: gst_implements_interface_cast: assertion `gst_element_implements_interface (GST_ELEMENT (from), iface_type)' failed ** (glotze:9811): CRITICAL **: gst_tuner_list_channels: assertion `GST_IS_TUNER (tuner)' failed (glotze:9811): GStreamer-CRITICAL **: gst_implements_interface_cast: assertion `gst_element_implements_interface (GST_ELEMENT (from), iface_type)' failed ** (glotze:9811): CRITICAL **: gst_tuner_get_channel: assertion `GST_IS_TUNER (tuner)' failed Code: tuner_list = gst_tuner_list_channels(GST_TUNER(vid_src)); this only happens if I'm using current cvs snapshot from gstreamer, gst-plugins-base and gst-plugins-good. It works with gstreamer version 0.10.12, gst-plugins-base version 0.10.12 and gst-plugins-good 0.10.5 The system is Ubuntu Feisty Fawn.
Created attachment 90087 [details] the function in which the error happens this is the complete function from my program in which the errors from comment #1 happen
Looks like a duplicate of bug #340338.
I found out that the problem is a complete different (sorry for the misinformation). I do not check if gst_element_set_state is successful which gives this error afterwards. If I try ./gst-launch-0.10 v4l2src ! xvimagesink with current cvs gstreamer i get following error: Setting pipeline to PAUSED ... (gst-launch-0.10:6597): GLib-GObject-WARNING **: IA__g_object_notify: object class `GstV4l2Src' has no property named `frequency' ERROR: Pipeline doesn't want to pause. ERROR: from element /pipeline0/v4l2src0: Could not negotiate format Additional debug info: gstbasesrc.c(2056): gst_base_src_start (): /pipeline0/v4l2src0: Check your filtered caps, if any Setting pipeline to NULL ... FREEING pipeline ... However ./gst-launch-0.10 videotestsrc ! xvimagesink works with cvs gstreamer and gst-launch-0.10 v4l2src ! xvimagesink with Ubuntu packages (version info in original report) works too.
I updated the description because it doesn't describe the real problem. The attached patch solves these issues for me. Description of the patch: 1. v4l2src->num_buffers is initialized with zero but the property has a minimum value of GST_V4L2_MIN_BUFFERS. If the queue-size is not changed by the application this would give an invalid argument error. The patch fixes this: v4l2src->num-buffers is initialized to GST_V4L2_MIN_BUFFERS 2. the first ioctl call in gst_v4l2src_probe_caps_for_format (v4l2src_calls.c) fails with a invalid argument error though VIDIOC_ENUM_FRAMESIZES is defined the actual patch undefines these. But maybe the return value should checked and if this is an error we should fallback to the old version? 3. The code for kernels < 2.6.19 in gst_v4l2src_probe_caps_for_format (v4l2src_calls.c) sets the property range from 1 to GST_V4L2_MAX_SIZE. The command ./gst-launch-0.10 v4l2src ! xvimagesink exits with an error because the maximum texture size from xvimagesink is chosen but in my case this is 2046x2046 and this is to big for the saa7134 driver. The patch checks the size with gst_v4l2src_get_size_limits
Created attachment 90301 [details] [review] the described patch
Created attachment 99033 [details] [review] proposed patch: fall back to range caps if frame size query fails with new frame size enum ioctl Thanks for your patch. I think most of these issues (#1 and #3 at least) have been fixed in v4l2src CVS already. I guess #2 could still happen, attached a patch to fall back to the old code if that happens. Would be great if you could give it a try.
Can't think of a reason why that might do any harm, so committed: 2007-11-13 Tim-Philipp Müller <tim at centricular dot net> * sys/v4l2/v4l2src_calls.c: (gst_v4l2src_probe_caps_for_format): If VIDIOC_ENUM_FRAMESIZES is defined (= recent kernel), but the corresponding ioctl() call fails even though the driver claims to support this format, just fall back to the pre-2.6.19 kernel routine that creates caps with suitable height and width ranges (see #448278). Would still be good if you could give it a spin though.
*** Bug 484463 has been marked as a duplicate of this bug. ***