Follow-up: found a third independent issue.
Even with correct caps, GStreamer pipelines writing to the loopback die after
two frames: "v4l2bufferpool: failed to allocate buffer" / error (-5).
GST_DEBUG shows "allocated 2 mmap buffers out of 3 requested". v4l2loopback
(0.15.3) provides 2 buffers by default, GStreamer's v4l2sink needs 3+.
Reproducible with plain videotestsrc ! v4l2sink; ffmpeg works (copes with 2).
v4l2-relayd's output stage is v4l2sink, so it is presumably affected too.
Workaround, e.g. in /etc/modprobe.d/v4l2loopback.conf:
options v4l2loopback devices=1 video_nr=32 exclusive_caps=0 \
card_label="Virtual Camera" max_buffers=8
then reload (sudo modprobe -r v4l2loopback && sudo modprobe
v4l2loopback).
With that, the mainline stack works end to end without the relay:
gst-launch-1.0 -e libcamerasrc ! videoconvert !
video/x-raw,format=YUY2,width=1280,height=800 ! queue !
v4l2sink device=/dev/video32
Note exclusive_caps=0 is needed for the device to appear in Zoom's startup
enumeration, since the relay's on-demand activation never triggered on this
system (no v4l2-relayd@ instance was ever started).
So three issues total: (1) sandbox blocks SoftISP dma-buf access, (2) YUY2
caps can't negotiate with libcamerasrc (SoftISP outputs RGB only), (3) default
loopback buffer count below v4l2sink's minimum. All three need fixing for
v4l2-relayd to work on this hardware.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166611
Title:
v4l2-relayd unusable with libcamerasrc/SoftISP: sandbox blocks dma-buf
allocator, and YUY2 caps never negotiate (black frames)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/v4l2-relayd/+bug/2166611/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
