GNOME Bugzilla – Bug 796789
v4l2 initialization fails with TRY_FMT call
Last modified: 2018-07-12 16:03:32 UTC
Created attachment 372995 [details] Log of cheese with GST_DEBUG=v4l2*:7 Cheese fails to initialize the v4l2 device with the error (cheese:866): cheese-WARNING **: 09:33:42.001: Device '/dev/video0' failed during initialization: gstv4l2object.c(3698): gst_v4l2_object_set_format_full (): /GstCameraBin:camerabin/GstWrapperCameraBinSrc:camera_source/GstBin:bin18/GstV4l2Src:v4l2src1: Call to TRY_FMT failed for YUYV @ 640x480: Input/output error This is reported in Ubuntu as https://bugs.launchpad.net/ubuntu/+source/cheese/+bug/1758994 I get a similar error with gst-launch-1.0 v4l2src ! videoconvert ! ximagesink : ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video0' failed during initialization Additional debug info: gstv4l2object.c(3698): gst_v4l2_object_set_format_full (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Call to TRY_FMT failed for YUYV @ 1280x720: Input/output error It works with gst-launch-1.0 v4l2src ! video/x-raw,width=640,height=480 ! videoconvert ! ximagesink It doesn't work with gst-launch-1.0 v4l2src ! video/x-raw,width=1280,height=720 ! videoconvert ! ximagesink Here is the output of v4l2-ctl -D -d /dev/video0 --list-formats-ext : Driver Info (not using libv4l2): Driver name : uvcvideo Card type : HP HD Webcam [Fixed]: HP HD Web Bus info : usb-0000:00:1d.0-1.4 Driver version: 4.15.18 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format ioctl: VIDIOC_ENUM_FMT Index : 0 Type : Video Capture Pixel Format: 'YUYV' Name : YUYV 4:2:2 Size: Discrete 640x480 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 176x144 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 320x240 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 352x288 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 640x400 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 1280x720 Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Index : 1 Type : Video Capture Pixel Format: 'MJPG' (compressed) Name : Motion-JPEG Size: Discrete 640x480 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 176x144 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 320x240 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 352x288 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 640x400 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps) Size: Discrete 1280x720 Interval: Discrete 0.033s (30.000 fps) Interval: Discrete 0.050s (20.000 fps) Interval: Discrete 0.067s (15.000 fps) Interval: Discrete 0.100s (10.000 fps) Interval: Discrete 0.200s (5.000 fps)
On the device I would reproduce using a decodebin element: gst-launch-1.0 v4l2src ! decodebin ! videoconvert ! ximagesink When downstream is link, it will renegotiate, but the format should not change, so something must be broken in the code that tries and ignore the change. Only thing I'm worried is this kernel trace, but I do hope avoiding the renego will avoid this firmware issue: uvcvideo: Failed to query (130) UVC probe control : -32 (exp. 26).
Created attachment 372998 [details] [review] v4l2src: Try to avoid TRY_FMT when camera is streaming Some camera firmware crash is TRY_FMT is called during streaming. As a side effect. This try and detect that the same format as currently running is about to be tried, and skip renegotiation.
Jeremy, I have replaced the v4l2 plugin on test-HP-EliteBook-2560p with one that has the fix. As you have faster access to it, could you play a little with it and report if you still see issues in some corner case ? This specific issue is a camera firmware bug, not the first one we workaround in GStreamer.
Thanks! I played a bit with gst-launch and cheese with different resolutions and everything works fine with this fix as far as I can tell. Let me know if you'd like me to do further tests.
Thanks a lot of letting me access this hardware. I've tried various other approach, but this is the one that works. This means though that changing resolution while your camera is running won't work, fortunately, cheese do stop and start the HW completely. If you are lucky, a firmware/bios or other type of system upgrade may fix the issue. Googling about this camera showed a lot of report of users also have problem on Windows. Notably it fails on skype, but works in the browser. I know that SKype do dynamic resolution changes, while your browser don't (for now ;-P). If the problem persist and become an issue, let me know, we could probably implement some workaround, like just taking a guess on the output format (pick the first one) and skip the TRY_FMT. This should work since your camera do report all the format/resolution/framerate correctly (not always the case).
Attachment 372998 [details] pushed as b12b8b0 - v4l2src: Try to avoid TRY_FMT when camera is streaming
Also queued for 1.14.2 as commit 8839c5a4942c2f9f23dac138cd5c4d9b406824fa
It's already great that it works now for cases such as in Cheese, thanks for the quick fix!