Returning minimum of 1 fps causes some gstreamer pipelines to fail

[siyuan-nz]

Environment:

• v4l2loopback version: 0.12.7
• kernel version: 6.1.11-arch1-1
• Distribution (+version): Arch Linux

Steps:

1. Install and start IP Webcam on an Android phone, using 192.168.1.123 as an example of the IP address of the phone.
2. Run this on a PC: gst-launch-1.0 -v souphttpsrc location=http://192.168.1.123:8080/video ! multipartdemux ! queue ! jpegdec ! videoconvert ! v4l2sink device=/dev/video0

$ gst-launch-1.0 -v souphttpsrc location=http://192.168.1.123:8080/video ! multipartdemux ! queue ! jpegdec ! videoconvert ! v4l2sink device=/dev/video0
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Got context from element 'souphttpsrc0': gst.soup.session=context, session=(GstSoupSession)NULL;
/GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = image/jpeg
/GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = image/jpeg
/GstPipeline:pipeline0/GstJpegDec:jpegdec0.GstPad:sink: caps = image/jpeg
/GstPipeline:pipeline0/GstJpegDec:jpegdec0.GstPad:src: caps = video/x-raw, format=(string)I420, width=(int)1920, height=(int)1080, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)1:4:0:0, framerate=(fraction)0/1
ERROR: from element /GstPipeline:pipeline0/GstSoupHTTPSrc:souphttpsrc0: Internal data stream error.
Additional debug info:
../gstreamer/subprojects/gstreamer/libs/gst/base/gstbasesrc.c(3132): gst_base_src_loop (): /GstPipeline:pipeline0/GstSoupHTTPSrc:souphttpsrc0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
ERROR: from element /GstPipeline:pipeline0/GstQueue:queue0: Internal data stream error.
Additional debug info:
../gstreamer/subprojects/gstreamer/plugins/elements/gstqueue.c(992): gst_queue_handle_sink_event (): /GstPipeline:pipeline0/GstQueue:queue0:
streaming stopped, reason not-negotiated (-4)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

Commit that introduced the problem: 6a7bc5b

With the following change, the same gstreamer pipeline starts to work again:

diff --git a/v4l2loopback.c b/v4l2loopback.c
index 7e47a43..868d80d 100644
--- a/v4l2loopback.c
+++ b/v4l2loopback.c
@@ -254,7 +254,7 @@ module_param(max_height, int, S_IRUGO);
MODULE_PARM_DESC(max_height, "maximum frame height");

/* frame intervals */
-#define V4L2LOOPBACK_FPS_MIN 1
+#define V4L2LOOPBACK_FPS_MIN 0
#define V4L2LOOPBACK_FPS_MAX 1000

/* control IDs */

Not sure if the change above makes sense or the right thing to do, but it's the only way I've found to make the pipeline work again.

[umlaeute]

hmm, setting the minimum FPS to 0 doesn't sound right, given that v4l2loopback doesn't deal with framerates, but rather with intervals (1/fps).
i'm mainly afraid of introducing a division-by-zero in other clients of the module.

so i was going to suggest to just use a different minimum framerate like (1/1000), but I see that your caps explicitly uses framerate=(fraction)0/1, so this probably won't work.

anyhow, yould you try nevertheless:

diff --git a/v4l2loopback.c b/v4l2loopback.c
index 7e47a43..9c830e8 100644
--- a/v4l2loopback.c
+++ b/v4l2loopback.c
@@ -818,8 +818,8 @@ static int vidioc_enum_frameintervals(struct file *file, void *fh,
                argp->type = V4L2_FRMIVAL_TYPE_CONTINUOUS;
                argp->stepwise.min.numerator = 1;
                argp->stepwise.min.denominator = V4L2LOOPBACK_FPS_MAX;
-               argp->stepwise.max.numerator = 1;
-               argp->stepwise.max.denominator = V4L2LOOPBACK_FPS_MIN;
+               argp->stepwise.max.numerator = 1000;
+               argp->stepwise.max.denominator = 1;
                argp->stepwise.step.numerator = 1;
                argp->stepwise.step.denominator = 1;
        }

[siyuan-nz]

Unfortunately returning anything non-zero doesn't work, not sure what the best way forward is, perhaps the video source shouldn't have reported 0 fps?

[umlaeute]

thanks for testing. i guess i just have to accept 0 fps then (and i think the reason for using a numerator/denominator notation is (among other things) to allow for poles; so 3rd party clients should be fixed to hande these if they don't do so already)