GNOME Bugzilla – Bug 732458
v4l2src: Caps failure on raspberry pi
Last modified: 2014-09-03 12:09:35 UTC
I would expect a simple command line such as: gst-launch-1.0 v4l2src ! video/x-raw,width=1280,height=720 ! glimagesink ...to work at least somewhat. Ideally it would work entirely smoothly but perhaps the v4l2src raw output to glimagesink stuff isn't tweaked to work as efficiently as it should. I would guess v4l2src should write directly into GL memory if it can. That would be great. What actually happens is a not-negotiated error is met. Looking at the v4l2src debug log, it probes for formats and resolutions, except it identifies the min/max width/height and step sizes and then only probes square resolutions within that range.
I had a vague memory that I had noticed this issue when I was testing back in February. I checked and indeed I did. I was trying to use 1.2.x back then and I noticed that I couldn't get raw video output from the camera with GStreamer v4l2src. I remember looking at the logs and seeing the same symptoms as above. A colleague was testing with older GStreamer, likely 1.0.10 plus cherry-picked patches, and he managed to get it working outputting directly to video/x-h264. I don't think I checked at the time to see if I could get h264 output but I cannot currently. I suspect the issue is in some of the v4l2 work between 1.0.10 and 1.2.x, if that helps at all.
Would be great if we could get this fixed for 1.4.0. Can you also provide a debug log with GST_DEBUG=v4l2*:6 and attach it here?
Created attachment 279578 [details] GST_DEBUG=v4l2*:6 Here you go.
Looks like the driver debs have been discussing it a bit here: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=62364&start=275
And they even reported bug #726521
I've added a possible patch to bug #724521, maybe you could give it a try.
Created attachment 279597 [details] glimagesink debug log GST_DEBUG="*v4l2*:6" gst-launch-1.0 -v v4l2src num-buffers=300 ! video/x-raw,width=1280,height=720 ! glimagesink > /home/pi/v4l2src-glimagesink.log 2>&1
Created attachment 279598 [details] fakesink debug log GST_DEBUG="*v4l2*:6" gst-launch-1.0 -v v4l2src num-buffers=300 ! video/x-raw,width=1280,height=720 ! fakesink > /home/pi/v4l2src-fakesink.log 2>&1
Created attachment 279599 [details] h264 debug log GST_DEBUG="*v4l2*:6" gst-launch-1.0 -v v4l2src ! video/x-h264,width=1280,height=720 ! h264parse ! mp4mux ! filesink location=test.mp4 > /home/pi/v4l2src-fakesink.log 2>&1
Debug logs attached with the patch from bug #724521
I notive this during probe: libv4l2: error setting pixformat: Invalid argument If this error is from libv4l2, it would mean FD value is wrong or not registered to libv4l2, if it's from driver, it would be nice to enable some kernel traces to help figure-out what argument is considered invalid.
Is this still an issue with latest changes ?
ping
(In reply to comment #13) > ping Apologies for the delayed response. I didn't get time to test it again yet but I will try to fit it in next week.
Created attachment 282451 [details] glimagesink debug log GST_DEBUG=*v4l2*:6 gst-launch-1.0 -v v4l2src num-buffers=300 ! video/x-raw,width=1280,height=720 ! glimagesink > v4l2src-glimagesink.log 2>&1
Created attachment 282452 [details] fakesink debug log GST_DEBUG=*v4l2*:6 gst-launch-1.0 -v v4l2src num-buffers=300 ! video/x-raw,width=1280,height=720 ! fakesink > v4l2src-fakesink.log 2>&1
Created attachment 282453 [details] h264 30 fps debug log GST_DEBUG=*v4l2*:6 gst-launch-1.0 -v v4l2src num-buffers=300 ! video/x-raw,width=1280,height=720,framerate=30/1 ! h264parse ! mp4mux ! filesink location=test.mp4 > v4l2src-mp4-30.log 2>&1
Created attachment 282454 [details] h264 30 fps debug log GST_DEBUG=*v4l2*:6 gst-launch-1.0 -v v4l2src num-buffers=300 ! video/x-h264,width=1280,height=720,framerate=30/1 ! h264parse ! mp4mux ! filesink location=test.mp4 > v4l2src-mp4-30.log 2>&1
So it now seems to work somewhat OK with glimagesink. It negotiates 90fps, spits messages about being too slow and the video looks very aliased as if it is being upscaled from some very low resolution. fakesink seems to work OK. H.264 does not work. See logs for details.
Sorry for the delay, so for H264 we get "Invalid Argument" when we set the format (S_FMT). Would be nice to search for a kernel trace that would give a bit more details. H264 works with Logitech C920 camera. This bug report was about raw, shall be split ? Also, for performance, it's clearly due to copies when uploading to GL, I'm not sure what we can do from v4l2 point of you to improve. rpicamsrc might be a better solution in that context, as it uses the media OS more directly. Would it be fine to mark as solve per the original commit message ?
Yes, I think so. rpicamsrc does seem to be a better option anyway as the V4L2 driver is just a wrapper on top.
Thanks.