GNOME Bugzilla – Bug 730775
Error on Fedora 20 - 64bit: "There was an error playing video from the webcam"
Last modified: 2019-09-28 21:35:43 UTC
The following error occurs, when trying to record video from WebCam. Worked in previous versions of Fedora, and is only a recent mishap in Fedora 20. (Screenshot attached with error message.) ----------------------------------------------------------------------------- (cheese:2674): GLib-GObject-WARNING **: value "5.000000" of type 'gdouble' is invalid or out of range for property 'delaytime' of type 'gdouble' (cheese:2674): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed (cheese:2674): cheese-WARNING **: Filter caps do not completely specify the output format: gstcapsfilter.c(348): gst_capsfilter_prepare_buf (): /GstCameraBin:camerabin/GstCapsFilter:videobin-capsfilter: Output caps are unfixed: video/x-raw, width=(int)640, height=(int)480, format=(string)I420, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, framerate=(fraction)[ 0/1, 30/1 ]
Created attachment 277237 [details] This is the attachment, as the previous one did not appear to upload. Last upload, unless by request.
Attempted making adjustments using dconf-editor, but that didn't make a difference. Furthermore, the webcam microphone is no longer listed as an audio device. More information about the WebCam: Bus 003 Device 003: ID 045e:00f5 Microsoft Corp. LifeCam VX-3000 Device is seen as "video0" but no audio input device is listed.
Let's move this to cheese for now, since it looks like an app problem.
And also, consider updating your F20 too, works for me here (tested with 5 different cameras) with up to date packages.
(small correction, actually fails with git master of gstreamer, but works with F20)
I don't see any question here; hence removing NEEDINFO.
Would it be possible to provide a stack trace of the point the critical is hit ? That requires running this with git master of Cheese, of cource. Use G_DEBUG=fatal_criticals and run cheeze into gdb to produce that backtrace. Make sure you have all debug and dbg packages installed, and then put into a file the result of "thread apply all bt" in GDB and attach to this bug.
Is this still an issue ? All cams I got works in Fedora 20, and also works with GST 1.4.
Hi octopus81, I am closing this bug report as no updated information has been provided. Please feel free to reopen this bug if you can provide the information that was asked for in a previous comment.
And should be fixed in 1.4 / Fedora 21 anyway.
Sorry for the delay. This has been tried on Fedora 21, CentOS 7, Debian 7, and Ubuntu 14.04 with the same webcam. Same error occurred in all but CentOS. I have yet to try a stack trace, as I'm still very new to this arena.
Are you sure you webcam works on Linux ?
Try resetting the dconf configuration - dconf reset -f /org/gnome/cheese
*** Bug 743706 has been marked as a duplicate of this bug. ***
to be precise, in order to properly have cheese working, I must first run it, then close it, then run it again. From the second run it will work properly.
^ Correction - the third time. I use Arch Linux 64-bit. Cheese 3.14.2 and gstreamer 1.4.5 Whenever I shut down the machine and/or restart, when I use Cheese for the first time to take a photo, the message pops up. I must close Cheese, then take a photo, the message pops up again. From the third time on, everything is OK.
Same here (Fedora 21, 64-bit). I get this error: (cheese:13584): cheese-WARNING **: Failed to allocate a buffer: gstv4l2src.c(749): gst_v4l2src_create (): /GstCameraBin:camerabin/GstWrapperCameraBinSrc:camera_source/GstBin:bin35/GstV4l2Src:video_source The first time I run Cheese; after a couple of tries, it works fine. If I use `gst-launch-1.0 v4l2src ! xvimagesink` it always works. My webcam is: ID 046d:082b Logitech, Inc. Webcam C170 The webcam works reliably in the Google Hangout plugin.
Emmanuele, did you check your kernel logs at that moment ? Usually when I get that, it matches a uvcvideo driver failure (it recover by itself after a second). Would be nice to clarify if you are running from jhbuild or from a specific version.
When I saw that the issue persisted in Fedora 21, I gave up on it. Thanks for all the help, but I'm moving on. :(
Why are you closing the bug report? If you have moved on and are not interested in the issue any more you should remove yourself from the Cc list; you also probably want to change the options for mail delivery in Bugzilla.
(In reply to Nicolas Dufresne (stormer) from comment #19) > Emmanuele, did you check your kernel logs at that moment ? Usually when I > get that, it matches a uvcvideo driver failure (it recover by itself after a > second). Would be nice to clarify if you are running from jhbuild or from a > specific version. I don't have any uvcvideo related lines in the journal, but I do get a reset from the xHCI USB controller: Mar 02 17:44:09 marie kernel: restoring control 00000000-0000-0000-0000-000000000101/10/5 Mar 02 17:44:09 marie kernel: xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88000a969b40 Mar 02 17:44:09 marie kernel: usb 1-1.4: reset high-speed USB device number 25 using xhci_hcd Mar 02 17:44:09 marie kernel: usb 1-1.4: hub failed to enable device, error -22 Mar 02 17:44:09 marie kernel: xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 11. Mar 02 17:44:09 marie kernel: usb 1-1.4: reset high-speed USB device number 25 using xhci_hcd Mar 02 17:44:09 marie kernel: usb 1-1.4: hub failed to enable device, error -22 Mar 02 17:44:09 marie kernel: xhci_hcd 0000:00:14.0: Setup ERROR: setup context command for slot 11. Mar 02 17:44:09 marie kernel: usb 1-1.4: reset high-speed USB device number 25 using xhci_hcd and this trace from the kernel side: Mar 02 17:44:11 marie kernel: ---[ end trace 3339674856b4648f ]--- Mar 02 17:44:11 marie kernel: [<ffffffff810b5220>] ? kthread_create_on_node+0x1a0/0x1a0 Mar 02 17:44:11 marie kernel: [<ffffffff817472fc>] ret_from_fork+0x7c/0xb0 Mar 02 17:44:11 marie kernel: [<ffffffff810b5220>] ? kthread_create_on_node+0x1a0/0x1a0 Mar 02 17:44:11 marie kernel: [<ffffffff810b530a>] kthread+0xea/0x100 Mar 02 17:44:11 marie kernel: [<ffffffff810b01c0>] ? rescuer_thread+0x2a0/0x2a0 Mar 02 17:44:11 marie kernel: [<ffffffff810b022b>] worker_thread+0x6b/0x4a0 Mar 02 17:44:11 marie kernel: [<ffffffff810af89d>] process_one_work+0x14d/0x400 Mar 02 17:44:11 marie kernel: [<ffffffffa011ea74>] edp_panel_vdd_work+0x34/0x50 [i915] Mar 02 17:44:11 marie kernel: [<ffffffffa011e924>] edp_panel_vdd_off_sync+0xf4/0x1e0 [i915] Mar 02 17:44:11 marie kernel: [<ffffffffa00b32ec>] intel_display_power_put+0x14c/0x160 [i915] Mar 02 17:44:11 marie kernel: [<ffffffff810971ea>] warn_slowpath_null+0x1a/0x20 Mar 02 17:44:11 marie kernel: [<ffffffff810970bd>] warn_slowpath_common+0x7d/0xa0 Mar 02 17:44:11 marie kernel: [<ffffffff817401ea>] dump_stack+0x45/0x56 Mar 02 17:44:11 marie kernel: Call Trace: Mar 02 17:44:11 marie kernel: 000000000000000b ffff8802609c8610 ffff880260e6a000 ffff8802609c0000 Mar 02 17:44:11 marie kernel: 0000000000000000 ffff880241aa3d70 ffffffff810970bd ffff8802609c002c Mar 02 17:44:11 marie kernel: 0000000000000000 00000000b75deedf ffff880241aa3d38 ffffffff817401ea Mar 02 17:44:11 marie kernel: Workqueue: events edp_panel_vdd_work [i915] Mar 02 17:44:11 marie kernel: Hardware name: Apple Inc. MacBookAir6,2/Mac-7DF21CB3ED6977E5, BIOS MBA61.88Z.0099.B00.1305241529 05/24/2013 Mar 02 17:44:11 marie kernel: CPU: 1 PID: 13286 Comm: kworker/1:0 Tainted: P W OE 3.17.7-300.fc21.x86_64 #1 Mar 02 17:44:11 marie kernel: shpchp snd_timer snd sbs sbshc soundcore apple_bl binfmt_misc i915 i2c_algo_bit drm_kms_helper drm uas usb_storage video [last unloaded: btusb] Mar 02 17:44:11 marie kernel: Modules linked in: btusb uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common snd_usb_audio videodev snd_usbmidi_lib snd_rawmidi me Mar 02 17:44:11 marie kernel: WARNING: CPU: 1 PID: 13286 at drivers/gpu/drm/i915/intel_pm.c:6312 intel_display_power_put+0x14c/0x160 [i915]() So I guess it's kernel-related, but I still think it's something in the GStreamer pipeline that Cheese uses; after all, as I said, `gst-launch-1.0` works reliably without an hitch, whereas Cheese works (roughly) one in three times. I'm using the packaged version of Cheese in Fedora 21, but I'll try to use Cheese from jhbuild next.
Thanks for reopening, it's obviously not right to simply close bugs base on "lost interest". It's not a feature request. Camerabin (cheese) might be causing a quick sequence of actions leading to this error. It's a much more complex case. That the kernel fails is a kernel bugs, though it does not always mean Gst is completly right. What we can do, is trace the device calls and compare. cho 0xff > /sys/class/video4linux/video0/debug The trace will show in kernel log (so in journal too).
Truncated command-> "echo 0xff > /sys/class/video4linux/video0/debug"
With the debugging enabled, I only get these additional messages: Mar 02 18:13:34 marie kernel: video0: release Mar 02 18:13:33 marie kernel: video0: poll: 00000041 Mar 02 18:13:33 marie kernel: video0: poll: 00000000 Mar 02 18:13:33 marie kernel: video0: mmap (0) Mar 02 18:13:33 marie kernel: video0: mmap (0) Mar 02 18:13:33 marie kernel: video0: open (0) Mar 02 18:13:33 marie kernel: video0: release Mar 02 18:13:33 marie kernel: video0: open (0) Mar 02 18:13:33 marie kernel: video0: release Mar 02 18:13:33 marie kernel: video0: open (0) Mar 02 18:13:33 marie kernel: video0: release Mar 02 18:13:33 marie kernel: video0: open (0)
You mean this is the delta, or all you get ? (does not seem very verbose)
(In reply to Nicolas Dufresne (stormer) from comment #26) > You mean this is the delta, or all you get ? (does not seem very verbose) It's the additional output I get in the journal, alongside with the traceback and the xhci/usb module spew of comment #22.
Could you try if patch in https://bugzilla.gnome.org/show_bug.cgi?id=745377 helps ? Looks like something fails on quick reset, removing that quick reset could help.
With Cheese 3.16, now the exact same error of https://bugzilla.gnome.org/show_bug.cgi?id=721277 is happening. The difference is that the solution found there - remove the file ~/.cache/gstreamer-1.0/registry.x86_64.bin - is *not* working this time.
I've experienced the exact same symptoms on Linux Mint 17.1 Rebecca, which ships Cheese 3.10.2 and found a work-around (and this should likely also give a good idea where to look for the root cause...) The output is very similar to the initial report: jbl@Tatanka ~ $ cheese ERROR: Could not load classifier cascade /usr/share/opencv/haarcascades/haarcascade_frontalface_alt2.xml (cheese:29538): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed (cheese:29538): cheese-WARNING **: Filter caps do not completely specify the output format: gstcapsfilter.c(348): gst_capsfilter_prepare_buf (): /GstCameraBin:camerabin/GstCapsFilter:videobin-capsfilter: Output caps are unfixed: video/x-raw, width=(int)640, height=(int)480, format=(string)I420, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, framerate=(fraction)[ 0/1, 30/1 ] This i what I get if I attempt to record a video right after starting Cheese. Now, the workaround: Start Cheese, select the video recording mode, click the "effects" and select any effect *other* than "No effect" and record a video (that should work, it works on my setup). Then selecting "No effect" (i.e. the default when you just want to record a video when starting Cheese) and then recording now works (again, on my setup). So I think the effect plugins perform some extra (and correct/required!) initialization of the Gstreamer pipeline that is not done correctly in the "No effect" plugin... My 2 cents
Emmanuele, let me know if you have time to test apply patch from bug 745377, I'm quite sure not doing the quick start/stop/start dance would help, but I can't reproduce it here. Also, have you reported this to kernel dev yet ?
Can someone run: GST_DEBUG=*:8 cheese 2>debug.log Then cause the problem, ctrl-C this line, gzip the debug.log and attach here.
Even gzipped, the log is 3.8 megs, so it's too big for Bugzilla. I put it here: https://www.bassi.io/~ebassi/cheese-debug.log.gz
(In reply to Nicolas Dufresne (stormer) from comment #31) > Emmanuele, let me know if you have time to test apply patch from bug 745377, > I'm quite sure not doing the quick start/stop/start dance would help, but I > can't reproduce it here. Also, have you reported this to kernel dev yet ? Sorry, didn't have time up until now. I'm currently on Fedora 22 with GStreamer 1.4.5, and I can still reproduce it. I'll try and build GStreamer 1.5 as soon as possible.
comment 33: libv4l2: error got 4 consecutive frame decode errors, last error: v4l-convert: libjpeg error: End Of Image This is an error from libv4l2 that transparently does jpeg decoding for us (but seems to fail at it)
I do wonder why using `gst-launch-1.0 v4l2src ! xvimagesink` and the Google Hangout plugin still work reliably, though.
For comparison: https://www.bassi.io/~ebassi/gst-launch-debug.log.gz
I think it depends on the natively supported formats, try this: gst-launch-1.0 v4l2src ! video/x-raw,format=YUY2 ! xvimagesink and: gst-launch-1.0 v4l2src ! video/x-raw,format=I420 ! xvimagesink I420 is emulated and I suspect it's going to decode jpeg for that (and hopefully cause the same failure)
Indeed, I420 fails.
The I420 pipeline fails for me with 1.4.5 (debian sid), but works with the 1.4 branch, so one of the patches that got cherry-picked seem to fix it (both link against libv4lconvert.so.0 fwiw).
could you try this: gst-launch-1.0 v4l2src ! image/jpeg ! filesink location=dump.mjpeg To see if we can capture those bad jpeg images...
Tim: there are not so many patches on top of 1.4.5, I can only see 2 or 3 that might be relevant: 6c43b983fecd1c46f895e8cf7b106f62de059ce2 bca79b41713909b3f4e252599d6d15713d8e87e2 and maybe: efc5332f1e9b456d7a0032bee4dbd104235582f5 Could you cherry pick and see which one of these fixes makes it work for you?
Seems I spoke too soon and my failure was spurious and not related to the branch, sorry for the noise.
Base on the information in that bug, the USB stack get reset due to error, the camera produce bogus frames (it's not clear if the kernel recover by itself, probably not). Now the rest is a little more complicated. Most cameras don't support I420, but Cheese do hardcode I420 for all cameras (I remember filing a bug for that). That's one of the reason a converter is needed in libv4l2. What also happens, is that GStreamer wan't the highest framerate, and camera produce higher rate in JPEG. We already force I420 (conversion) forcing emulated format to be picked, and then from there picking the highest framerate lead to JPEG. Now that corruption seem to cause error in the libv42 decoding (quite normal), which lead to fatal error. This is very different to Skype, Chrome or your custom pipeline (which most likely don't depend on libv4l2 and don't force a libv4l2 emulation). The main point of regression from my testing is kernel side, since the USB and UVC driver seems to have increased failure rate (with low recovery ability). I think from Cheese and GStreamer point of view, there is very little we can do, unless there is some method that would allow transparently retrying.
Oh, and my point about the 1.5 patches from bug 745377, is that it removes a quick reconfigure of the device' which is known to be a good trigger for kernel bugs. I didn't backport it, as I thought this quick reocnfigure was only existent in 1.5 due to recent change in decodebin.
Hi, It appears this has been fixed here on Arch Linux. Don't know about Fedora tough. cheese 3.16.1 gstreamer 1.4.5 v4l-utils 1.6.3
Can anyone still reproduce this problem in recent versions?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!