numpy_where element does not negoitate cap correctly about webcam-filters HOT 6 CLOSED

Very interesting. 🤔
Definitely need to improve the logging, but it looks like a buffer coming into the last element (that merges the foreground and blurred background) was not the expected size.

• What happens if you just run it in pass-through mode? (i.e. omit --background-blur)
• Can you post GST_DEBUG=4 output?

from webcam-filters.

Very interesting. thinking
Definitely need to improve the logging, but it looks like a buffer coming into the last element (that merges the foreground and blurred background) was not the expected size.

* What happens if you just run it in pass-through mode? (i.e. omit `--background-blur`)

$ webcam-filters --input-dev /dev/video0 --output-dev /dev/video3
Selectd input: media-type=image/jpeg, width=1280 height=720 framerate=30/1
gst-stream-error-quark: Internal data stream error. (1): ../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src1:
streaming stopped, reason not-negotiated (-4)

* Can you post `GST_DEBUG=4` output?

This is a big one, I've pasted it here.

from webcam-filters.

Initial thoughts -- I think there are two problems:

• Your v4l2sink reports it only supports 1920x1080, while the input we've selected is 1080x720. Which is why the pass-thorugh mode fails to link. Seems like the v4l2loopback device is stuck at 1920x1080. Did you by any chance set keep_format to 1, as described in https://github.com/umlaeute/v4l2loopback#attributes or force a format https://github.com/umlaeute/v4l2loopback#forcing-format ?
• Thanks to the above problem, we know there's a bug in how I'm negotiating caps with v4l2sink, which causes the pipeline to run and then fail when it comes across a buffer that's smaller than what v4l2sink expects. It should actually fail at the caps negotiation part.

from webcam-filters.

No, I haven't set any control, they are all at default values:

$ v4l2-ctl -d /dev/video3 -l

User Controls

                    keep_format 0x0098f900 (bool)   : default=0 value=0
              sustain_framerate 0x0098f901 (bool)   : default=0 value=0
                        timeout 0x0098f902 (int)    : min=0 max=100000 step=1 default=0 value=0
               timeout_image_io 0x0098f903 (bool)   : default=0 value=0

I haven't forced any format neither, but I don't know how to query the caps on the v4l2loopback device.

from webcam-filters.

OK, forget it... I found the culprit.
FTR, I had a dead (?) process guvcview holding an instance of /dev/video3 open. I found it using, being root, lsof /dev/video3.
After killing it I could modprobe -r v4l2loopback then modprobe v4l2loopback again and now it is OK.
Sorry for the noise but maybe this noise can help someone else. Also, you're right, it could be great to get more error handling and caps negotiation could be better. But thanks a lot for your work.

from webcam-filters.

OK, forget it... I found the culprit.
FTR, I had a dead (?) process guvcview holding an instance of /dev/video3 open. I found it using, being root, lsof /dev/video3.
After killing it I could modprobe -r v4l2loopback then modprobe v4l2loopback again and now it is OK.
Sorry for the noise but maybe this noise can help someone else. Also, you're right, it could be great to get more error handling and caps negotiation could be better. But thanks a lot for your work.

Ah, nice catch!

No worries, without this "noise" probably wouldn't have run into the bug of the numpy_where element doing incorrect caps negotiation. I'm gonna leave this issue open to track that.

from webcam-filters.