Unable to stream to v4l2 loopback device using stream_forward_mmap example

[filiphazardous]

I cloned master, and ran cargo build --examples, then ran ./target/debug/examples/stream_forward_mmap -d 4 -o 0 (and yes, my loopback is /dev/video/0 and my USB webcam is /dev/video/4 - i double checked).

The result is a panic with a message about slice lengths not matching:
thread 'main' panicked at 'source slice length (460800) does not match destination slice length (1228800)', /home/filip/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:2775:13

Complete output in enclosed text file.

Any idea what's wrong? I'm a bit of a beginner at both Rust and V4l2

output.txt

[raymanfx]

Could you debug the input format (width, height, pixelformat, stride) and the output format?

I can take a look at this tonight - it's been a while since I used v4l2loopback.

[raymanfx]

Sorry, I was on mobile and did not see the attachment. So it looks like the source format (that of /dev/video4) was not applied to the v4l2loopback device (/dev/video0). We normally enforce this in the example: https://github.com/raymanfx/libv4l-rs/blob/master/examples/stream_forward_mmap.rs#L95. But from your enclosed log I see that Active out format and New out format match, so the source format (Active cap format) is not applied.

Could you please print the source_fmt variable here: https://github.com/raymanfx/libv4l-rs/blob/master/examples/stream_forward_mmap.rs#L94 just to be sure?

[ghost]

I'm having the same issue here.
When I run the example with a v4l2loopback device the output (including source_fmt) looks like this:

Using device: /dev/video0

Using sink device: /dev/video42

Active cap capabilities:
Driver      : uvcvideo
Card        : HP Wide Vision HD Camera: HP Wi
Bus         : usb-0000:00:14.0-4
Version     : 5.11.13
Capabilites : VIDEO_CAPTURE | EXT_PIX_FORMAT | STREAMING

Active cap format:
width          : 1280
height         : 720
fourcc         : MJPG
field          : progressive
stride         : 0
size           : 1843200
colorspace     : sRGB
quantization   : default
transfer       : Rec. 709 transfer function

Active cap parameters:
capabilities : TIME_PER_FRAME
modes        : (empty)
interval     : 1/30 [s]

Active out capabilities:
Driver      : v4l2 loopback
Card        : Screen
Bus         : platform:v4l2loopback-000
Version     : 5.11.13
Capabilites : VIDEO_CAPTURE | VIDEO_OUTPUT | VIDEO_M2M | EXT_PIX_FORMAT | READ_WRITE | STREAMING

Active out format:
width          : 1280
height         : 720
fourcc         : MJPG
field          : progressive
stride         : 0
size           : 3686400
colorspace     : sRGB
quantization   : default
transfer       : default transfer function

Active out parameters:
capabilities : (empty)
interval     : 1/30 [s]

source_fmt:
width          : 1280
height         : 720
fourcc         : MJPG
field          : progressive
stride         : 0
size           : 1843200
colorspace     : sRGB
quantization   : default
transfer       : Rec. 709 transfer function

New out format:
width          : 1280
height         : 720
fourcc         : MJPG
field          : progressive
stride         : 0
size           : 3686400
colorspace     : sRGB
quantization   : default
transfer       : default transfer function

[raymanfx]

Okay, I need some kernel logs to get more insight here.
Could you please provide a dmesg log after trying to run the example?
I'm particularly interested in this line: https://github.com/umlaeute/v4l2loopback/blob/main/v4l2loopback.c#L1087.

[filiphazardous]

I'm not sure how to turn on kernel logging for the file in question (I have tried googling, and found some answers, but can't make it work on my end). I'll try some more, and respond with dmesg output as soon as I have something.

What I can see in both mine and pi-type's output is that the size and the transfer function differ, though width, height, fourcc, field, stride, colorspace, and quantization match. In the example, the only comparisons are for width, height, and fourcc. So I guess the comparison should be extended to more parameters? (In this case it is the size mismatch that leads to the copy_from_slice failure, I think.)

Then again, I'd love to solve the underlying problem behind the difference in size as well.

[raymanfx]

Yes, the mismatch of the size field is the cause for the issues. I was hinting at that in my comment from yesterday - sorry if that was not clear enough.

Perhaps whatever debugging is there by default could suffice. Would you mind dumping the (last few) lines of dmesg for me? I'll see whether they contain anything useful.

[raymanfx]

I just tested this myself on Fedora 34 and it appears to be working fine on master and 0.12. What OS are you using?

My log:

Using device: /dev/video0

Using sink device: /dev/video2

Active cap capabilities:
Driver      : uvcvideo
Card        : C922 Pro Stream Webcam
Bus         : usb-0000:0a:00.3-2.2
Version     : 5.11.12
Capabilites : VIDEO_CAPTURE | EXT_PIX_FORMAT | STREAMING

Active cap format:
width          : 640
height         : 480
fourcc         : YUYV
field          : progressive
stride         : 1280
size           : 614400
colorspace     : sRGB
quantization   : default
transfer       : Rec. 709 transfer function

Active cap parameters:
capabilities : TIME_PER_FRAME
modes        : (empty)
interval     : 1/30 [s]

Active out capabilities:
Driver      : v4l2 loopback
Card        : OBS Virtual Camera
Bus         : platform:v4l2loopback-000
Version     : 5.11.12
Capabilites : VIDEO_OUTPUT | VIDEO_M2M | EXT_PIX_FORMAT | READ_WRITE | STREAMING

Active out format:
width          : 0
height         : 0
fourcc         : BGR4
field          : progressive
stride         : 0
size           : 0
colorspace     : sRGB
quantization   : default
transfer       : default transfer function

Active out parameters:
capabilities : (empty)
interval     : 1/30 [s]

New out format:
width          : 640
height         : 480
fourcc         : YUYV
field          : progressive
stride         : 1280
size           : 614400
colorspace     : sRGB
quantization   : default
transfer       : default transfer function

Buffer
  sequence   [in] : 1
  sequence  [out] : 0
  timestamp  [in] : 4954.870506 [s]
  timestamp [out] : 0 [s]
  flags      [in] : MAPPED | TIMESTAMP_MONOTONIC | TSTAMP_SRC_SOE
  flags     [out] : TIMESTAMP_UNKNOWN | TSTAMP_SRC_EOF
  length     [in] : 614400
  length    [out] : 614400
Buffer
  sequence   [in] : 2
  sequence  [out] : 0
  timestamp  [in] : 4954.902503 [s]
  timestamp [out] : 4954.934493 [s]
  flags      [in] : MAPPED | TIMESTAMP_MONOTONIC | TSTAMP_SRC_SOE
  flags     [out] : MAPPED
  length     [in] : 614400
  length    [out] : 614400
Buffer
  sequence   [in] : 3
  sequence  [out] : 0
  timestamp  [in] : 4954.938506 [s]
  timestamp [out] : 4954.966501 [s]
  flags      [in] : MAPPED | TIMESTAMP_MONOTONIC | TSTAMP_SRC_SOE
  flags     [out] : MAPPED
  length     [in] : 614400
  length    [out] : 614400
Buffer
  sequence   [in] : 4
  sequence  [out] : 0
  timestamp  [in] : 4954.970511 [s]
  timestamp [out] : 4954.998509 [s]
  flags      [in] : MAPPED | TIMESTAMP_MONOTONIC | TSTAMP_SRC_SOE
  flags     [out] : MAPPED
  length     [in] : 614400
  length    [out] : 614400

FPS: 30.286524147369988
MB/s: 17.800489704921464

EDIT: Okay, so if I enforce the MJPG pixelformat on the source device (thus it will be enforced on the output device by the example), I'm seeing the same issue. I'll have to dig more into the v4l2loopback code.

[filiphazardous]

I'm on Pop OS (a fork of Ubuntu 20.10), and I've tried compiling v4l2loopback myself as well as using the one provided. Currently the tail end of my dmesg has the lines:

[194694.766888] ipheth 3-2:4.2: Apple iPhone USB Ethernet device attached
[194694.766938] usbcore: registered new interface driver ipheth
[194694.772394] ipheth 3-2:4.2 enx067295a7feff: renamed from eth0
[200221.947101] v4l2loopback driver version 0.12.5 loaded
[200636.716693] v4l2loopback driver version 0.12.5 loaded
[201117.156090] v4l2loopback driver version 0.12.5 loaded
[201833.802474] v4l2loopback driver version 0.12.5 loaded

I've been running the example code once after each reload of the v4l2loopback module, so there's no output at all. I've added dyndbg to the parameters in /etc/modprobe.d/v4l2loopback.conf and I've also tried a couple of variants of echo 'module v4l2loopback +p' > /sys/kernel/debug/dynamic_debug/control (also using 'file v4l2loopback.c +p' among others). I'll be happy to proceed further down the rabbit hole tomorrow, but at this late hour (European time) - I have to give up and get some sleep.

Thanks for helping out!

[raymanfx]

Should be fixed now. I would appreciate if you could give that commit (in the next branch) a shot. Some comments about the source of the issue have been added in the code and the commit message - if you have any further questions please feel free to ask :)

[filiphazardous]

I can confirm that it works on my end. Thanks!

[raymanfx]

FYI we found some more issues related to compressed frame forwarding, which hopefully should be fixed in the next branch now. I updated the stream forward example in ede0210 accordingly. I just tested MJPG frame forwarding using a GUI app written in druid which uses eye-rs (which in turn used this crate on Linux).

Thanks to @reyapo for spotting and fixing those other issues.

[filiphazardous]

Cool! I found the eye-rs project the other day, that's how I came up with the enumeration code in the other bug report. As I'm muddling along learning Rust, I hope I'll be able to contribute fixes as well as reports in the future.

Cheers!