Gstreamer Failed to allocated required memory

mzihlmann commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

[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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

interesting. single frame output is fixed by this commit https://github.com/umlaeute/v4l2loopback/commit/b92e9ce7cccd30cd28743a3fe57eb7827909aeab

umlaeute commented 1 year ago

single frame output is fixed by this commit https://github.com/umlaeute/v4l2loopback/commit/b92e9ce7cccd30cd28743a3fe57eb7827909aeab

yes, that's expected. see #535

mzihlmann commented 1 year ago

issue first appears here https://github.com/umlaeute/v4l2loopback/commit/d78f95bb2915ddedaccc87aa2e2fbdd1e0f502d9

mzihlmann commented 1 year ago

adding a tee fixes the issue

mzihlmann commented 1 year ago

ping @umlaeute

umlaeute commented 1 year ago

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

is that ok?

umlaeute / v4l2loopback