GNOME Bugzilla – Bug 505799
iSight camera does not work in gstreamer
Last modified: 2008-01-06 10:59:25 UTC
Steps to reproduce: 1. Start the application 2. Application segfaults Stack trace:
+ Trace 183149
Other information: If you need to have a detailed backtrace for gstreamer, I would compile gstreamer with debug symbols activated.
The cam part from lshal: udi = '/org/freedesktop/Hal/devices/usb_device_5ac_8501_noserial' info.bus = 'usb_device' (string) info.linux.driver = 'usb' (string) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_7' (string) info.product = 'Built-in iSight' (string) info.subsystem = 'usb_device' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_5ac_8501_noserial' (string) info.vendor = 'Apple Computer, Inc.' (string) linux.device_file = '/dev/bus/usb/005/009' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'usb' (string) linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-4' (string) usb_device.bus_number = 5 (0x5) (int) usb_device.can_wake_up = false (bool) usb_device.configuration_value = 1 (0x1) (int) usb_device.device_class = 255 (0xff) (int) usb_device.device_protocol = 255 (0xff) (int) usb_device.device_revision_bcd = 388 (0x184) (int) usb_device.device_subclass = 255 (0xff) (int) usb_device.is_self_powered = false (bool) usb_device.linux.device_number = 9 (0x9) (int) usb_device.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-4' (string) usb_device.max_power = 100 (0x64) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.num_interfaces = 2 (0x2) (int) usb_device.num_ports = 0 (0x0) (int) usb_device.product = 'Built-in iSight' (string) usb_device.product_id = 34049 (0x8501) (int) usb_device.speed = 480.0 (480) (double) usb_device.speed_bcd = 294912 (0x48000) (int) usb_device.vendor = 'Apple Computer, Inc.' (string) usb_device.vendor_id = 1452 (0x5ac) (int) usb_device.version = 2.0 (2) (double) usb_device.version_bcd = 512 (0x200) (int) /dev/v4l/video0 is present, driver is uvc-linux (http://linux-uvc.berlios.de/), SVN version behaves the same.
are you sure that you are using gstreamer 0.10.15? does it work with a simple gstreamer pipeline, like: gst-launch v4l2src ! ffmpegcolorspace ! ximagesink
Yes, gstreamer is 0.10.15. Pipe does also not work. So I guess I have to file that bug to the gstreamer guys. $ gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. FEHLER: Von Element /pipeline0/v4l2src0: Could not negotiate format Zusätzliche Debugginginformation: gstbasesrc.c(2293): gst_base_src_start (): /pipeline0/v4l2src0: Check your filtered caps, if any Setting pipeline to NULL ... FREEING pipeline ...
ah ok. i had the same problem here with some older kernels and the wrong isight drivers. please refer to this page http://i-nz.net/projects/linux-kernel/
Oh, I'm using the latest driver from SVN. I'm a bit confused now. It works pretty fine with mplayer tv://.
well, this is either a gstreamer or an isight driver bug
(gdb) bt
+ Trace 183715
I cannot change to component GStreamer but this is likely a Gstreamer or driver bug. Can someone do that with the appropriate rights?
Changing to gstreamer
*** Bug 506643 has been marked as a duplicate of this bug. ***
The crasher is because the framerate cannot be detected, causing gstreamer to do fancy stuff with an empty framerate list. See Bug #506643.
What needs to be done in order to detect the frame rate?
Created attachment 102189 [details] [review] proposed fix I've created a short patch which seems to fix the problems for me. I'm not sure if the V4L2 spec allows stepwise frame-rate settings with lower bound equal to the upper bound, but this fix enables gstreamer to work under such conditions. BTW, the code for stepwise frame-rate settings looks like it's never been tested, It's obvious that it couldn't have worked correctly as it is attempting to use the same name (frac) to refer to two differently-scoped variables.
Thanks for you patch Andrzej, however it does not fix the problem here. When executing the pipe I know get the following: $ gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... FEHLER: Von Element /pipeline0/v4l2src0: Could not get enough buffers from device '/dev/video0'. Zusätzliche Debugginginformation: v4l2src_calls.c(1034): gst_v4l2src_capture_init (): /pipeline0/v4l2src0: we received 0 from device '/dev/video0', we want at least 2 ERROR: pipeline doesn't want to preroll. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ...
Please ignore my comment above. I've found #467214 which addresses the issue with receiving too less buffers from the device. The suggested workaround works fine (setting queue-size explicitly). So your fix addressed the problem just fine, thanks Andrzej.
Andrzej: have you tried the v4l2src version from CVS? I think this problem has already been fixed (things work fine with my iSight at least).
Right, I didn't notice that the CVS version was fixed already. It works fine for me, and also fixes the unspecified queue-size problem.
Great, thanks for confirming.