We get tons of this warning (one per frame): WARN bufferpool gstbufferpool.c:1250:default_reset_buffer:<nvv4l2decoder:pool:sink> Buffer 0x7e90217ea0 without the memory tag has maxsize (0) that is smaller than the configured buffer pool size (4194304). The buffer will be not be reused. This is most likely a bug in this GstBufferPool subclass
I saw this thread, so we faced the very same issue when using nvv4l2decoder and GStreamer 1.20.
The warning comes from a check that was introduced in GStreamer 1.18.1: gst/gstbufferpool.c · 1.18.1 · GStreamer / gstreamer · GitLab, most probably this is why it was not discovered yet (with GStreamer 1.14 [Ubuntu 18] and 1.16 [Ubuntu 20] the warning condition is not checked).
I analyzed the code of gstv4l2videodec.c, gstv4lbufferpool.c and gstv4l2allocator.c and the warning seems to be valid.
The warning’s condition seems to be quite simple, if GST_BUFFER_FLAG_TAG_MEMORY is not set (the underlying memory is not being attached/removed) AND the buffer’s maxsize is smaller than the pool’s size then the pool cannot reuse the buffer (that belongs to and was created by the very same pool).
The log indicates that the buffer has the size of 0. Based on the source code the size field of the allocated GstMemories are always filled well, so most probably the pool or the decoder allocates empty buffers during normal operation. This is all I was able to figure out. It would be great if you could have a look and fix this issue (as it is going to block introducing newer Ubuntu versions anyway). Any help would be appreciated a lot as we need to go with GStreamer 1.20 and cannot use 1.14.
Hi,
Thanks for the information. It the warning print present on default Jetpack 4.6.3(with gstreamer 1.14.5) or 5.0.2(with 1.16.3)? Would like to know if is is shown on default release or after manually upgrading gstreamer version.
No, GStreamer 1.18.1 introduced the warning so the default versions don’t log the mentioned warnings. But it doesn’t mean that the issue itself is not present with the default GStreamer versions (1.14.5 and 1.16.3) in Jetpack. The check was added with this commit in GStreamer 1.18. So the bug itself (there are zero sized buffers managed by the gstv4lbufferpool) is there, but is hidden with older GStreamer versions. You can cherry-pick the commit as a patch to GStreamer 1.14 or 1.16 and see the warning logs coming.
I think it would be beneficial to have a look as it blocks moving forward with GStreamer versions (on your end too). I know that it is advised to use the default GStreamer version of Jetpack, but we cannot do so (we need GStreamer 1.20 to support one of our custom GStreamer element).
Hi,
Does it work if you remove the patch in 1.18? The condition may be different for each release and it is uncertain if the patch is must-have for 1.16. If the warning disappears and the system is still working after you remove the patch from 1.18, it is probably fine to remove it.
And we have the plugins open source. These plugins are built with 1.16.3 and you may rebuild them with 1.18.
@DaneLLL it works even with the patch (it was integrated in GStreamer 1.18.1 so it is part of the official GStreamer release from that point), but we get the warnings.
All the patch does is to check if the GstBuffer (that belongs to the pool) has a size large enough to be reused by the pool. If this condition fails a warning is raised from 1.18.1, but everything works as before (with a degraded performance, as the pool will drop the buffer instead of reusing it).
Old GStreamers don’t raise the warning, but the buffer is reallocated with these versions as well (so the performance is degraded), but it is done silently, so we get no warnings with older versions.
We can remove these warnings again from GStreamer 1.20, but it wouldn’t solve the root cause of the issue, just hide the valid warnings.