GNOME Bugzilla – Bug 638300
v4l2src: make this work more than once in a row
Last modified: 2011-08-26 08:35:47 UTC
I have a USB camera on a Thinkpad T410 laptop, detected as: uvcvideo: Found UVC 1.00 device Integrated Camera (17ef:480f) Without this patch, v4l2src will fail to output anything the second time it's used, unless different parameters are requested. I guess some kind of way to make this optional has to be decided, as applying this patch as is will revert to the 'slow setup' behavior this skip was supposed to avoid (see f06b105058e73162275b50bdba89c6791e218d03). For a log of that second-time-wedges with GST_DEBUG=v4l2src:5: Setting pipeline to PAUSED ... 0:00:00.100190064 13521 0x24ec0a0 INFO v4l2src gstv4l2src.c:604:gst_v4l2src_get_caps:<v4l2src0> probed caps: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)1600, height=( 0:00:00.104554710 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:442:gst_v4l2src_negotiate:<v4l2src0> caps of src: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)1600, height= 0:00:00.105263978 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:443:gst_v4l2src_negotiate:<v4l2src0> thiscaps: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)1600, height=(in 0:00:00.112320210 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:451:gst_v4l2src_negotiate:<v4l2src0> caps of peer: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)640, height= 0:00:00.112386694 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:452:gst_v4l2src_negotiate:<v4l2src0> peercaps: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)640, height=(int 0:00:00.112441939 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:462:gst_v4l2src_negotiate:<v4l2src0> peer: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)640, height=(int)480 0:00:00.112465517 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:463:gst_v4l2src_negotiate:<v4l2src0> ipcaps: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)640, height=(int)4 0:00:00.112528035 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:475:gst_v4l2src_negotiate:<v4l2src0> intersect: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)640, height=(in 0:00:00.112563235 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:476:gst_v4l2src_negotiate:<v4l2src0> icaps: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)640, height=(int)48 0:00:00.112655682 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:530:gst_v4l2src_negotiate:<v4l2src0> fixated to: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)640, height=(i 0:00:00.112683884 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:531:gst_v4l2src_negotiate:<v4l2src0> caps: video/x-raw-yuv, format=(fourcc)YUY2, width=(int)640, height=(int)480 0:00:00.112717171 13521 0x24ec0a0 DEBUG v4l2src gstv4l2src.c:642:gst_v4l2src_set_caps:<v4l2src0> trying to set_capture 640x480 at 30/1 fps, format YUV 4:2:2 (YUYV) 0:00:00.112736696 13521 0x24ec0a0 DEBUG v4l2src v4l2src_calls.c:232:gst_v4l2src_set_capture:<v4l2src0> Desired framerate: 30/1 0:00:00.112755935 13521 0x24ec0a0 DEBUG v4l2src v4l2src_calls.c:246:gst_v4l2src_set_capture:<v4l2src0> Desired framerate already set 0:00:00.112768248 13521 0x24ec0a0 INFO v4l2src v4l2src_calls.c:285:gst_v4l2src_set_capture:<v4l2src0> Set framerate to 30/1 and duration to 0:00:00.033333333 0:00:00.112781742 13521 0x24ec0a0 DEBUG v4l2src v4l2src_calls.c:299:gst_v4l2src_capture_init:<v4l2src0> initializing the capture system 0:00:00.112793369 13521 0x24ec0a0 LOG v4l2src v4l2src_calls.c:307:gst_v4l2src_capture_init:<v4l2src0> initiating buffer pool 0:00:00.113401067 13521 0x24ec0a0 INFO v4l2src v4l2src_calls.c:314:gst_v4l2src_capture_init:<v4l2src0> capturing buffers via mmap() 0:00:00.113420878 13521 0x24ec0a0 DEBUG v4l2src v4l2src_calls.c:361:gst_v4l2src_capture_start:<v4l2src0> starting the capturing /GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)YUY2, width=(int)640, height=(int)480, interlaced=(boolean)false, framerate=(fraction)30/1 0:00:00.114397748 13521 0x24ec0a0 LOG v4l2src gstv4l2src.c:756:gst_v4l2src_unlock_stop:<v4l2src0> No longer flushing Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... 0:00:00.115094038 13521 0x24ec0a0 LOG v4l2src gstv4l2src.c:756:gst_v4l2src_unlock_stop:<v4l2src0> No longer flushing 0:00:00.115152020 13521 0x264b4a0 DEBUG v4l2src v4l2src_calls.c:110:gst_v4l2src_grab_frame:<v4l2src0> grab frame Caught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... Execution ended after 4242922372 ns. Setting pipeline to PAUSED ... 0:00:04.358147486 13521 0x24ec0a0 LOG v4l2src gstv4l2src.c:745:gst_v4l2src_unlock:<v4l2src0> Flushing 0:00:04.358251658 13521 0x264b4a0 DEBUG v4l2src v4l2src_calls.c:191:gst_v4l2src_grab_frame: stop called Setting pipeline to READY ... 0:00:04.358531593 13521 0x24ec0a0 LOG v4l2src gstv4l2src.c:745:gst_v4l2src_unlock:<v4l2src0> Flushing 0:00:04.358550519 13521 0x24ec0a0 LOG v4l2src gstv4l2src.c:756:gst_v4l2src_unlock_stop:<v4l2src0> No longer flushing 0:00:04.358682347 13521 0x24ec0a0 DEBUG v4l2src v4l2src_calls.c:390:gst_v4l2src_capture_stop:<v4l2src0> stopping capturing 0:00:04.383784158 13521 0x24ec0a0 DEBUG v4l2src v4l2src_calls.c:424:gst_v4l2src_capture_deinit:<v4l2src0> deinitting capture system /GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = NULL Setting pipeline to NULL ... Freeing pipeline ...
Created attachment 177209 [details] [review] v4l2src: make this work more than once in a row
*** Bug 638299 has been marked as a duplicate of this bug. ***
wonder if it is a driver bug or if we indeed have to call VIDIOC_S_PARM everytime. Maybe there is a bug in v4l2src also and it should reset fps_n/d.
I get this too on a Thinkpad X201: uvcvideo: Found UVC 1.00 device Integrated Camera (17ef:4816)
I don't see a bit downside in re-setting the framerate every time? And it does fix stuff for many people.
Works for me too on x201 dmesg trace: uvcvideo: Found UVC 1.00 device Integrated Camera (17ef:4816)
Created attachment 194759 [details] [review] v4l2src: make this work more than once in a row We used to skip frame rate setup if the camera was already setup with the requested frame rate. This breaks some cameras though, causing them to not output data (several models of Thinkpad cameras have this problem at least). So, don't skip.
Add comment in the code about why we don't skip.
Just some digging. This commit had added the framerate comparison: commit e605a94e4093e1304b153ab1baf3e5ccef7562e8 Author: William M. Brack <wbrack@mmm.com.hk> Date: Tue Mar 25 12:33:09 2008 +0000 sys/v4l2/v4l2src_calls.c: Check whether the device supports setting the framerate before trying to set it and then po... Original commit message from CVS: Based on patch by: William M. Brack <wbrack at mmm com hk> * sys/v4l2/v4l2src_calls.c: (fractions_are_equal), (gst_v4l2src_set_capture): Check whether the device supports setting the framerate before trying to set it and then posting a warning or error if it doesn't work (#516649, #520092). Also compare fractions more correctly.
commit 3968dc7688021cdf1d1c52e6d7838668bdccb2e1 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Thu Aug 25 23:37:47 2011 +0100 v4l2src: make this work more than once in a row We used to skip frame rate setup if the camera was already setup with the requested frame rate. This breaks some cameras though, causing them to not output data (several models of Thinkpad cameras have this problem at least). So, don't skip. https://bugzilla.gnome.org/show_bug.cgi?id=638300