|Summary:||multimedia/gstreamer1-plugins-good 1.14.4: problem with v4l2src|
|Product:||Ports & Packages||Reporter:||Per Gunnarsson <per.gunnarsson>|
|Component:||Individual Port(s)||Assignee:||Christoph Moench-Tegeder <cmt>|
|Severity:||Affects Only Me||CC:||cmt, hselasky, javashin1986|
Description Per Gunnarsson 2019-03-20 20:03:08 UTC
I tried a gst-launch-1.0 which used to work, and which works if I use ximagesrc instead of v4l2src. I got the error message below. ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate required memory. Additional debug info: gstv4l2src.c(658): gst_v4l2src_decide_allocation (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Buffer pool activation failed I had problems with cheese too which mentioned v4l2src. The wencam works fine with obs-studio
Comment 1 JavaShin 2019-07-18 01:26:37 UTC
Im having the same problem on 13-current with cheese the webcam works on firefox but not on cheese cheese libGL: pci id for fd 16: 8086:0416, driver i965 libGL: OpenDriver: trying /usr/local/lib/dri/i965_dri.so libGL: Using DRI3 for screen 0 (cheese:58465): Gtk-WARNING **: 21:25:41.380: Theme parsing error: cheese.css:7:35: The style property GtkScrollbar:min-slider-length is deprecated and shouldn't be used anymore. It will be removed in a future version (cheese:58465): cheese-WARNING **: 21:25:42.168: Failed to allocate required memory.: gstv4l2src.c(658): gst_v4l2src_decide_allocation (): /GstCameraBin:camerabin/GstWrapperCameraBinSrc:camera_source/GstBin:bin35/GstV4l2Src:v4l2src1: Buffer pool activation failed
Comment 2 Christoph Moench-Tegeder 2020-04-06 19:37:08 UTC
Created attachment 213136 [details] catch EINVAL errno when probing DMA capabilities to be dropped into multimedia/gstreamer1-plugins-good/files/ (bump PORTREVISION on multimedia/gstreamer1-plugins-v4l2). poking at an old-ish Logitech C270 cam, I noticed the same problem ("Buffer pool activation failed" and camera not working in gstreamer-based applications). Working backwards through gstreamer and cuse) it became obvious that gstreamer probes the DMA capabilities of the device using ioctls, expecting ENOTTY (as it is customary when the request is not applicable to the object in question) in case DMA capabilities are not available. Unfortunately, FreeBSD's cuse returns EINVAL for this ioctl. As it's easier to fix the port than to fix the kernel: Here's the workaround, catching both ENOTTY and EINVAL on the DMA probing. With that, my camery works with gstreamer.
Comment 3 Christoph Moench-Tegeder 2020-04-06 19:39:32 UTC
hselasky: as the author of cuse, can you give some input on the ioctls here?
Comment 4 commit-hook 2020-05-06 13:53:54 UTC
A commit references this bug: Author: cmt Date: Wed May 6 13:53:34 UTC 2020 New revision: 534176 URL: https://svnweb.freebsd.org/changeset/ports/534176 Log: gstreamer1-plugins-v4l2: fix for (some) webcams The gstreamer v4l2 plugin probes the DMA capabilities of the webcam device via ioctl VIDIOC_EXPBUF, expecting ENOTTY in case that's not implemented (and will act accordingly). On our cuse, we get EINVAL for that case (which, from my reading of ioctl(2) woulndn't be correct here), which gstreamer neither expects nor handles and thus cannot use this device as a video source. As we cannot fix the kernel on short notice (cuse is part of the base system), the workaround is to handle EINVAL like ENOTTY in this specific place. (Tested with an old Logitech camera). PR: 236673 Approved by: maintainer-timeout (multimedia) Changes: head/multimedia/gstreamer1-plugins-good/files/patch-sys_v4l2_gstv4l2object.c head/multimedia/gstreamer1-plugins-v4l2/Makefile