same here.

 Can't try it for the time being but it's high on my todo list.

(of course, there's no tuner interface implemented until the device is open)

Andy, that's correct! 

If I understand this correctly, the device (/dev/video0 in this case) will be opened when the source element is put in READY state (or higher). I can't try it out right now, but I'm pretty sure I tried this:

import gst
import gobject

source = gst.element_factory_make("v4l2src")
source.set_state(READY)
print source.get_channel()

... which gave the same result as I've shown above. I'll test this and get back here.

Ok, now I've confirmed that the following script:

import gst
import gobject

source = gst.element_factory_make("v4l2src")
source.set_state(gst.STATE_READY)
print source.get_channel()

... produces the exakt same result as you can see in comment #1.

I also tried with gst.STATE_PLAYING, same result.

I also must say that I'm not 100% sure putting the v4l2src element in these states actually opens the /dev/video0 device. That's just what I've heard.

Oops! Of course, I don't mean comment #1 in comment #4, I mean my original bug report, above. Sorry.

Any progress on this one?

I confirm this problem with v4lsrc.  Even when v4lsrc is playing inside a pipeline, get_channel() segfaults.

+ Trace 72979

The problem is that v4l2src doesn't implement GstImplementsInterface interface properly. It should implement the ->supported method (just like v4lsrc does).

Changing title accordingly

Fredrik, could you give me some backtraces:

_ with G_DEBUG=fatal_warnings
_ with G_DEBUG=""

make them with:
> ulimit -c unlimited
> G_DEBUG=... python yourtest.py
> gdb python <corefile>
> bt full

Thanks

With G_DEBUG=fatal_warnings:

(gdb) bt full

+ Trace 72997

Changing the script from:

import gst
import gobject

source = gst.element_factory_make("v4l2src")
print source.get_channel()

... to...

import gst
import gobject

source = gst.element_factory_make("v4l2src")
source.set_property("device","/dev/video0")
source.set_state(gst.STATE_PLAYING)
channel = source.get_channel()
print channel.label

... fixed the problem.

Yes, Since v4l2src inherts from GstPushSrc it will be ok just in PLAYING state.

Hi Edward,

v4l2src implements gst_v4l2src_iface_supported (in gstv4l2src.c:145) just like v4lsrc.
Please let me know if I am missing something here.

BR,
Edgard

I double-checked this; the first application still makes both vl4src and v4l2src segfault.  It doesn't matter that they both do the same thing - they should not segfault because of this code.  This needs to be fixed.

ping?

I just tried the script that triggered this error on a Ubuntu Feisty machine, which seems to run -good 0.10.5. 

It no longer segfaults, but instead returns "None".

This is the printout:

frepe@lovin:~$ python simple_segfault.py 

(simple_segfault.py:18318): GStreamer-CRITICAL **: gst_implements_interface_cast: assertion `gst_element_implements_interface (GST_ELEMENT (from), iface_type)' failed

** (simple_segfault.py:18318): CRITICAL **: gst_tuner_get_channel: assertion `GST_IS_TUNER (tuner)' failed
None

Mind you, I have no device attached to this computer. So I don't know what happens in that case. But it does look promising! I'll try it with a grabber device and see what happens, as soon as possible.

Thomas: can you attach a small test app that triggers the crash (python?)

Created attachment 97232 [details]
simple C program to show when Tuner interface is available

this is the output:

(a.out:9402): GStreamer-CRITICAL **: gst_implements_interface_cast: assertion `gst_element_implements_interface (GST_ELEMENT (from), iface_type)' failed
  v4l2src just created
    debug 1: tuner is still NULL
    debug 1: channel is still NULL
  v4l2src just added to pipeline and linked

(a.out:9402): GStreamer-CRITICAL **: gst_implements_interface_cast: assertion `gst_element_implements_interface (GST_ELEMENT (from), iface_type)' failed
    debug 2: tuner is still NULL
    debug 2: channel still NULL
  v4l2src just put in playing state
    debug 3: tuner and channel not nil

ok, so please let me know what is the expected output from that C program.

As far as I can see, this has been fixed ages ago, in gst-plugins-base 0.10.11 (feisty shipped 0.10.12), by this commit:

 2006-10-17  Tim-Philipp Müller  <tim at centricular dot net>

        * gst-libs/gst/interfaces/tuner.c: (gst_tuner_list_channels),
        (gst_tuner_set_channel), (gst_tuner_get_channel),
        (gst_tuner_list_norms), (gst_tuner_set_norm), (gst_tuner_get_norm),
        (gst_tuner_set_frequency), (gst_tuner_get_frequency),
        (gst_tuner_signal_strength), (gst_tuner_find_norm_by_name),
        (gst_tuner_find_channel_by_name):
          Fix some function guards, add some more function guards.

The way I read the comments so far:
 - the bug happens with edgy (shipping core/base 0.10.10)
 - the bug report has confirmed it does not happen any longer
   with feisty (shipping core/base 0.10.12) (or rather: you
   only get those assertion failures, which is what is expected
   here given the wrong state; same as with the C API in any case)
 - no one claims they can reproduce the bug with anything > -base 0.10.11

If I'm missing something, please re-open (or preferably file a new bug).