Gstreamer Failed to allocated required memory

[mzihlmann]

Hey there,
I'm very happy to see that there was a lot of traffic here in the last week. I'm now testing whether the newest master fixes the two issues we had so far.

• the kernel issue seems good. i saw that the additional mutex lock was implemented as suggested
• the other one we had with the single-frame output is also fixed for us, im not sure which commit did the trick though.

However, now i run into a new issue i have not yet seen before. I have not yet tested/analyzed it further. But if you would like to i could help you in binary-search the culprit. our current "good version" that we run in production is here. its based on the last release (to avoid the single frame issue) and patched to avoid the kernel issue mentioned above.

Environment

• v4l2loopback version: 0.12.7-357-g845cea0 (current HEAD)
• kernel version: Linux ci4 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
• Distribution (+version): Debian GNU/Linux 11 (bullseye)

Step 3: Describe the problem:

Observed Results:

[08:59:42] Used mapping /dev/video0: webcam0
[08:59:42] Setting pipeline to PAUSED ...
[08:59:42] Create Android Virtual Device (AVD)
[08:59:42] Pipeline is PREROLLING ...
[08:59:42] Pipeline is PREROLLED ...
[08:59:42] Setting pipeline to PLAYING ...
[08:59:42] New clock: GstSystemClock
[08:59:42] ERROR: from element /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0: Failed to allocated required memory.
[08:59:42] Additional debug info:
[08:59:42] ../sys/v4l2/gstv4l2sink.c(631): gst_v4l2sink_show_frame (): /GstPipeline:pipeline0/GstV4l2Sink:v4l2sink0:
[08:59:42] Buffer pool activation failed
[08:59:42] ERROR: from element /GstPipeline:pipeline0/GstImageFreeze:imagefreeze0: Internal data stream error.
[08:59:42] Additional debug info:
[08:59:42] ../gst/imagefreeze/gstimagefreeze.c(1158): gst_image_freeze_src_loop (): /GstPipeline:pipeline0/GstImageFreeze:imagefreeze0:
[08:59:42] streaming stopped, reason error (-5)
[08:59:42] Execution ended after 0:00:00.007378918
[08:59:42] Setting pipeline to NULL ...
[08:59:42] Freeing pipeline ...

Expected Results:

[12:33:44] Setting pipeline to PAUSED ...
[12:33:44] Pipeline is PREROLLING ...
[12:33:44] Pipeline is PREROLLED ...
[12:33:44] Setting pipeline to PLAYING ...
[12:33:44] New clock: GstSystemClock
[12:33:45] Getting the camera device mappings
[12:33:45] List of web cameras connected to the computer:
[12:33:45] Camera 'webcam0' is connected to device '/dev/video0' on channel 0 using pixel format 'RGB3'

[umlaeute]

However, now i run into a new issue i have not yet seen before. I have not yet tested/analyzed it further. But if you would like to i could help you in binary-search the culprit.

that would be fantastic.

[umlaeute]

[08:59:42] ../gst/imagefreeze/gstimagefreeze.c(1158): gst_image_freeze_src_loop (): /GstPipeline:pipeline0/GstImageFreeze:imagefreeze0:

is that by any chance trying to set a timeout image?

[mzihlmann]

We have an android emulator that uses the loopback device as a camera-input. pytest+gstreamer+selenium are used to run end-to-end tests against the android app. To my understanding only static images are fed into the loopback device. The command that is used for generating the feed should be this one here:

gst-launch-1.0 uridecodebin uri="file://{image_path}" ! videoconvert  ! videoscale  ! imagefreeze  ! v4l2sink show-preroll-frame=false device=/dev/video{self.dev_id}

Note that this setup is now running inside a kubernetes pod and uses generic-device-plugin to expose the loopback device to the pod.

[umlaeute]

i'm not exactly sure why, but inserting a tee element just before the v4l2sink seems to fix that issue (at least for me):

gst-launch-1.0 uridecodebin uri="file://{image_path}" ! videoconvert  ! videoscale  ! imagefreeze  ! tee ! v4l2sink show-preroll-frame=false device=/dev/video{self.dev_id}

[mzihlmann]

interesting. single frame output is fixed by this commit b92e9ce

[umlaeute]

single frame output is fixed by this commit b92e9ce

yes, that's expected. see #535

[mzihlmann]

issue first appears here d78f95b

[mzihlmann]

adding a tee fixes the issue

[mzihlmann]

ping @umlaeute

[umlaeute]

given that there's an easy fix (adding tee), this currently has no high priority for me.

is that ok?