GNOME Bugzilla – Bug 737521
v4l2src: fails to allocate memory in RGB
Last modified: 2014-09-30 14:15:28 UTC
Created attachment 287286 [details] env GST_DEBUG=v4l2\*:6 gst-launch-1.0 [...] $ gst-launch-1.0 v4l2src ! "video/x-raw,format=RGB" ! fakesink Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate required memory. Additional debug info: gstv4l2src.c(478): gst_v4l2src_decide_allocation (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Buffer pool activation failed Execution ended after 0:00:00.261828647 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... $
xRGB instead of RGB gives a better error message: $ gst-launch-1.0 v4l2src ! "video/x-raw,format=xRGB" ! fakesinkSetting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data flow error. Additional debug info: gstbasesrc.c(2933): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: streaming task paused, reason not-negotiated (-4) Execution ended after 0:00:00.228498601 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... $
Thanks for the report, though this isn't a bug. The no-negotiated error is appropriate since most camera cannot do xRGB. The difference with 1.2 is that xRGB is now part of the template caps, but when ready state is reached, get_caps will return the probed caps (most likely without xRGB). So instead of having a link error like before (1.2 and early), you endup with a negotiation error.
Ok, it seems I have miss-read, the second trace is confusing. The first pipeline with libv4l2, works for me. Please GST version, libv4l2 version.
I can reproduce it here too with the Thinkpad camera: Bus 003 Device 004: ID 04f2:b217 Chicony Electronics Co., Ltd Lenovo Integrated Camera (0.3MP) libv4l 1.4.0, GStreamer 1.4.3 and GIT master
I am running GStreamer 1.4.3 (Debian Unstable packages) with libv4l2 1.4.0.
Btw, I never seen a webcam that produce 24bit RGB, and the log confirms it's being color-converted by libv4l2: <v4l2src0>[00m RGB3 (emulated) Then later S_FMT leads to size 2764800 (match 1280*3*720). But QUERYBUF returned a size of 0, hence: buffer size 0 is smaller then negotiated size 2764800 I'm currently running libv4l2 1.0.0, and this just works. It looks like a regression in libv4l2, and not in GStreamer.
Also happens with I420 or YV12 btw, which are also emulated. YUY2 which is not works
(In reply to comment #7) > Also happens with I420 or YV12 btw, which are also emulated. YUY2 which is not > works This is major regression then, is 1.4.0 shipped by a specific distro ? I have written a small program to report issue gainst v4l2loopback driver, might be useful to reproduce this issue: https://github.com/umlaeute/v4l2loopback/issues/60 https://gist.github.com/ndufresne/5daab2e51d79b0d63519
(In reply to comment #8) > (In reply to comment #7) > > Also happens with I420 or YV12 btw, which are also emulated. YUY2 which is not > > works > > This is major regression then, is 1.4.0 shipped by a specific distro ? I have > written a small program to report issue gainst v4l2loopback driver, might be > useful to reproduce this issue: > > https://github.com/umlaeute/v4l2loopback/issues/60 > https://gist.github.com/ndufresne/5daab2e51d79b0d63519 I have an Archlinux at home which shipped 1.4.x, so I can give a try if there is no need of an hardare device.
(In reply to comment #9) > (In reply to comment #8) > > > > This is major regression then, is 1.4.0 shipped by a specific distro ? I have > > written a small program to report issue gainst v4l2loopback driver, might be > > useful to reproduce this issue: > > > > https://github.com/umlaeute/v4l2loopback/issues/60 > > https://gist.github.com/ndufresne/5daab2e51d79b0d63519 > > I have an Archlinux at home which shipped 1.4.x, so I can give a try if there > is no need of an hardare device. Just in case, I mean libv4l 1.4.0 (might have been confused with gstreamer).
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > > > > This is major regression then, is 1.4.0 shipped by a specific distro ? I have > > > written a small program to report issue gainst v4l2loopback driver, might be > > > useful to reproduce this issue: > > > > > > https://github.com/umlaeute/v4l2loopback/issues/60 > > > https://gist.github.com/ndufresne/5daab2e51d79b0d63519 > > > > I have an Archlinux at home which shipped 1.4.x, so I can give a try if there > > is no need of an hardare device. > > Just in case, I mean libv4l 1.4.0 (might have been confused with gstreamer). Oops, I read too quickly... For libv4l I have 1.2.1, so I think it won't help much.
(In reply to comment #11) > > For libv4l I have 1.2.1, so I think it won't help much. Actually it could be useful, is 1.2 also affected ? I'm running 1.0 that works.
For the reference: <krad> krad: well vanilla 1.4.0 fails, I revert commit you pointed out and it works Commit in question is: http://git.linuxtv.org/cgit.cgi/v4l-utils.git/commit/?id=10213c975afdfcc90aa7de39e66c40cd7e8a57f7
A report has been posted on the LinuxTV mailing-list.
Patches has been posted to the ML. [PATCH 2/3] libv4l2: Set convert_mmap_frame_size as soon as we've a dest_fmt https://patchwork.kernel.org/patch/5003141/ The rest of the patchset is also slightly relate, but this one fixed the issue.