GNOME Bugzilla – Bug 783945
v4l2src: gst-launch -e flag causes usb camera disconnection (Logitech C920)
Last modified: 2017-09-19 21:54:58 UTC
Created attachment 354015 [details] gst-launch & -e flag issue: command line output So far, this issue seems to be specific to the Logitech C920 USB camera when using gst-launch on the command line. After I use the "-e" flag in any pipeline, any subsequent pipeline that access the camera will fail and cause a camera disconnection, where it becomes necessary to re-plug the camera to make it usable again. Removing the -e flag, avoids the issue, but the video file is saved without an index and is not readily usable. Also, take the following pipeline: $ gst-launch-1.0 -e v4l2src device=/dev/video1 ! autovideosink It has different behaviors depending on how I stop it: - If I send SIGINT (Ctrl-C) on the terminal, the issue occurs. - If I close the window created by autovideosink, the issue _doesn't_ occur. These different behaviors make me thing this is not a driver issue, but something not being handled properly within gst-launch. This is my system configuration: $ uname -a Linux NUC02 4.4.0-79-generic #100-Ubuntu SMP Wed May 17 19:58:14 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux $ gst-launch-1.0 --version gst-launch-1.0 version 1.12.0 GStreamer 1.12.0 Unknown package origin - OS is Ubuntu 16.04 - Issue also happens with GStreamer 1.8.3 - Already asked in the mailing list, but didn't have any luck:http://gstreamer-devel.966125.n4.nabble.com/gst-launch-e-flag-causes-usb-camera-disconnection-tt4682150.html - Attached is the console output using the -v flag
For me it never starts streaming, even with videoconvert ! autovideosink, but says: libv4l2: error set_fmt gave us a different result then try_fmt! ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video1' cannot capture in the specified format Additional debug info: gstv4l2object.c(3623): gst_v4l2_object_set_format_full (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Tried to capture in YV12, but device returned format YUYV
(In reply to Tim-Philipp Müller from comment #1) > For me it never starts streaming, even with videoconvert ! autovideosink, > but says: > > libv4l2: error set_fmt gave us a different result then try_fmt! > ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device > '/dev/video1' cannot capture in the specified format > Additional debug info: > gstv4l2object.c(3623): gst_v4l2_object_set_format_full (): > /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: > Tried to capture in YV12, but device returned format YUYV That one is a bug in libv4l2, there is nothing in the spec that requires doing a matching TRY_FMT before doing S_FMT. YV12 (aka I420) is an emulated format for the C920. This should be reported to libv4l2. About the reported issue, was there anything reported by your kernel ? (dmesg output), otherwise please provide a trace with GST_DEBUG="v4l2*:7".
Note, I can reproduce in 1.10.4 (libv4l2 enabled), but not with master without libv4l2. When it fails, you can see: usb 3-1: device descriptor read/64, error -110 Which I bet means the camera firmware crashed, or the UVC driver had an issue, that I don't know. To me, this looks like Logitech, Kernel or libv4l2 bug. One thing that could trigger races though in GStreamer is that when EOS is sent from the application, we quickly stop streaming, free the buffers, allocator the buffer and start streaming again. That's something in GstBaseSrc and GstV4l2Src that we could address, as it stresses the driver. It make no sense to free and realloc buffers after EOS in BaseSrc, we should instead use gst_buffer_pool_set_flushing() method instead of set_active(). On GstV4l2Src side, we could remove the fact the the pool activation can trigger buffer allocation/free and STREAMON/STREAMOFF, this way it prevents baseclass or upstream element (for v4l2sink) of doing anything silly.
(In reply to Nicolas Dufresne (stormer) from comment #2) > About the reported issue, was there anything reported by your kernel ? > (dmesg output), otherwise please provide a trace with GST_DEBUG="v4l2*:7". I got this a few times: usb 2-2: device descriptor read/64, error -110 I've also captured the output with GST_DEBUG="v4l2*:7" which I'll try to attach or add as a comment instead.
Created attachment 354075 [details] dmesg & GST_DEBUG="v4l2*:7" output - dmesg output before and after pipeline fails - output with GST_DEBUG="v4l2*:7": pipeline run three times: 1. pipeline terminated by closing GUI window 2. pipeline terminated by Ctrl-C on the console 3. pipeline stuck
Unfortunatly, this is clearly not a GStreamer bug. As I said, there might be ways to workaround this, but it remains an external bug. If you feel like trying to propose a workaround let me know, otherwise I'll need to close this issue.
(In reply to Nicolas Dufresne (stormer) from comment #6) > Unfortunatly, this is clearly not a GStreamer bug. As I said, there might be > ways to workaround this, but it remains an external bug. If you feel like > trying to propose a workaround let me know, otherwise I'll need to close > this issue. Well, at least it's not a GStreamer bug. Please go ahead and close it. Given the camera firmware can't be updated (AFAIK), that leaves V4L2, I guess. Do you think it is proper to report the issue to them? As for a workaround, I'm a novice with GStreamer, and so far I have only used gst-launch. I don't think I can do much about this issue in the short term. Sorry. What I'll do is try to dissect what the autovideosink element is doing to avoid the issue, and mimic it on my own pipeline.
Ok, and I have filed this bug to improve basesrc and likely workaround this, https://bugzilla.gnome.org/show_bug.cgi?id=784044
(In reply to Nicolas Dufresne (stormer) from comment #8) > Ok, and I have filed this bug to improve basesrc and likely workaround this, > > https://bugzilla.gnome.org/show_bug.cgi?id=784044 Thanks. I've added myself to the CC list. If there is any patch you'd like me to test or any specific piece of code to update and verify, please let me know. Thank you.
For the record, the trigger to bug the driver or firmware is the flush operation that happens on flush_stop(). If you comment this out of testing, the camera keeps working. Note, this patch breaks random stuff in GstV4l2, I only wrote this to demonstrate where the driver/firmware race is triggered: https://paste.fedoraproject.org/paste/7pZyurPJ-eTdIVLqc5w2YA
Reopening the bug 784044 didn't workaround the issue. We need to split out flushing (streamon/off) from the bufferpool state.
Created attachment 357014 [details] [review] v4l2bufferpool: Don't stop streaming when pool is flushing This patch is only tested with cameras for now, I need to check if it works with M2M devices, specially decoder/encoder draining/flushing. Though, it is good progress as renegotiation seems to still work for capture and I didn't managed to crash by logitech camera. Now when you stop it will stop streaming, free the buffers and that's it, no more dancing.
Created attachment 360087 [details] [review] v4l2bufferpool: Don't stop streaming when pool is flushing UPDATE: This version adds manual flushing sequences required for M2M devices. The purpose of being able to flush the buffer pool is only to unlock any blocked operation. Doing streamoff/streamon had the side effect of turning off and on the camera. As we do a flush_start / flush_stop sequence when shutting down, that would cause a really quick sequence of streamoff/streamon/streamoff/close which was causing some cameras to stop working.
Attachment 360087 [details] pushed as 1f902e2 - v4l2bufferpool: Don't stop streaming when pool is flushing