ximagesink works, v4l2loopback doesn't, kernel regression between 6.0.0-rc7 and 6.2.8

[potuz]

v4l2loopback driver version 0.12.7 (0.12.7-321-gfb410fc) 

Built against custom Kernel 6.2.8 on Arch Linux.

1. Run gst-launch-1.0 videotestsrc ! videoconvert ! ximagesink watch a test image window
2. Run gst-launch-1.0 videotestsrc ! videoconvert ! v4l2sink device=/dev/video1 on a terminal, see no errors:

   Setting pipeline to PAUSED ...
   Pipeline is PREROLLING ...
   Pipeline is PREROLLED ...
   Setting pipeline to PLAYING ...
   Redistribute latency...
   New clock: GstSystemClock
   0:00:35.0 / 99:99:99.

   And the clock is ticking

3. Launch on a different terminal

   $ mpv av://v4l2:/dev/video1
   [ffmpeg/demuxer] video4linux2,v4l2: Dequeued v4l2 buffer contains 155648 bytes, but 153600 were expected. Flags: 0x00000001.
   (+) Video --vid=1 (rawvideo 320x240 30.000fps)

   But no video appears. If instead of the conversion being made by gstreamer you pipe directly as in gst-launch-1.0 videotestsrc ! video/x-raw,format=YV12,width=1920,height=1080 ! v4l2sink device=/dev/video1

You get

$ mpv av://v4l2:/dev/video1
 (+) Video --vid=1 (rawvideo 1920x1080 30.000fps)

So mpv is getting the right dimensions for example but no video is shown. The module is loaded with exclusive_caps=1

EDIT: Same setup worked on kernel 6.0.0-rc7

[umlaeute]

cannot reproduce with linux-6.1.7

[sanbrother]

After running

gst-launch-1.0 videotestsrc  ! videoconvert ! v4l2sink device=/dev/video1

I noticed the size 155648 is PAGE_ALIGN(dev->pix_format.sizeimage)

Perhaps it is not a real problem even if buffer size is larger than needed.

And, maybe it is mpv's bug, it should use bytesused instead of length.

[umlaeute]

Could you try again with https://github.com/umlaeute/v4l2loopback/commit/1d01a4156cd22ff25d015079cbb731078fa89ead ?

[potuz]

@umlaeute nope, same problem with current main on the second option I get

$ mpv av://v4l2:/dev/video1
 (+) Video --vid=1 (rawvideo 1920x1080 30.000fps)
[ffmpeg/demuxer] video4linux2,v4l2: Dequeued v4l2 buffer contains 3112960 bytes, but 3110400 were expected. Flags: 0x00000001.

And the first with gstreamer conversion I get

$  mpv av://v4l2:/dev/video1
 (+) Video --vid=1 (rawvideo 320x240 30.000fps)
[ffmpeg/demuxer] video4linux2,v4l2: Dequeued v4l2 buffer contains 155648 bytes, but 153600 were expected. Flags: 0x00000001.
[autoconvert] Converting yuyv422 -> yuv422p
[ffmpeg/demuxer] video4linux2,v4l2: Dequeued v4l2 buffer contains 155648 bytes, but 153600 were expected. Flags: 0x00000001.

[umlaeute]

that's a pity. thanks for checking

[umlaeute]

in any case, the issue ffmpeg and buffersizes has been reported multiple times in the past (making this a duplicate).

i don't see how this can possibly be related to a kernel-upgrade (as it is simply that buffers are page-aligned, but the payload is not necessarily so), maybe other things changed as well.

it the issue is now deflated to a buffersize-problem only, i would like to close it as a duplicate.

[potuz]

Oh I get those messages but I see no video, so definitely not only buffer size. I am not sure how to help diagnose this, but If I roll back to my previous kernel I can use the camera and with 6.2.8 I can't. I have an XPS-9320 that depends on v4l2loopback to be able to use the camera and I narrowed the issue to v4l2loopback not being able to reproduce even from videotestsrc. Not sure if I am on the right track though. I'm happy if this issue is closed now as a duplicate and I can try reopening it when I have more info to give you.

[waptaff]

One more data point: I got dysfunctional v4l2loopback too, with kernel 6.2.9, with v4l2loopback revision fb410fc7af40e972058809a191fae9517b9313af (v4l2loopback driver version 0.12.7 (0.12.7-321-gfb410fc))

But now with revision 2c9b67072b15d903fecde67c7f269abeafee4c25 (v4l2loopback driver version 0.12.7 (0.12.7-387-g2c9b670)) problem is gone at least for me.

v4l2loopback had worked without a hitch for previous kernels.

My setup was/is: copying frames from the real device (an uvcvideo device) to the loopback device using ffmpeg.

My symptoms were:

• With mplayer I got many v4l2: select timeout error messages, a single image from the webcam showed, then I got blinking between that image and a solid green image.
• With mpv I got a single still image from the webcam, then mpv half-froze (I could not quit the application without force-killing it).

[potuz]

@umlaeute you can close the original issue AFAIC, I recompiled the kernel without changes to your tip and it works fine now.