Bufferpool Issue with V4L2 Elements JetPack 5.0.2

Hi everyone,

I’m using an Xavier AGX with Jetpack 5.0.2 and I’m getting the following warning when I use the V4L2 encoders:

0:00:00.867084209 17852 0xaaab1f215aa0 WARN              bufferpool gstbufferpool.c:1235:default_reset_buffer:<nvv4l2h264enc0:pool:sink> Buffer 0xffff580a3000 without the memory tag has maxsize (192) that is smaller than the configured buffer pool size (115200). The buffer will be not be reused. This is most likely a bug in this GstBufferPool subclass

This can be easily reproduced with this pipeline:

GST_DEBUG=2 gst-launch-1.0 videotestsrc is-live=true ! nvvidconv ! nvv4l2h264enc ! fakesink

I came across this other post: Nvv4l2decoder buffer reuse issue (and warning), and it says that the check that produces this warning was included in GStreamer 1.18, however, I’m using the default GStreamer 1.16.3 installation and still see the warning.

So I was taking a look at the gstreamer library that included the bufferpool warning with this command:

ls /usr/lib/aarch64-linux-gnu/libgstreamer* -l
lrwxrwxrwx 1 root root      28 ago  3  2022 /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so -> libgstreamer-1.0.so.0.1603.0
lrwxrwxrwx 1 root root      32 feb  1 09:14 /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0 -> libgstreamer-1.0.so.0.1603.99999
-rw-r--r-- 1 root root 1354096 ago  3  2022 /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0.1603.0
lrwxrwxrwx 1 root root      27 ago 25 12:38 /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0.1603.99999 -> tegra/libnvgstreamer-1.0.so

And found this modified libnvgstreamer-1.0.so which apparently is built with the source named libnvgstreamer_src.tbz2 included in the public sources of JP 5.0.2. After comparing these sources with the original ones of GStreamer 1.16.3 it seems the only difference is this:

git diff gstreamer/gst/gstbufferpool.c 1.16.3/gst/gstbufferpool.c
diff --git a/gstreamer/gst/gstbufferpool.c b/1.16.3/gst/gstbufferpool.c
index 619860e..addf45d 100644
--- a/gstreamer/gst/gstbufferpool.c
+++ b/1.16.3/gst/gstbufferpool.c
@@ -1223,9 +1223,21 @@ default_reset_buffer (GstBufferPool * pool, GstBuffer * buffer)
   /* if the memory is intact reset the size to the full size */
-    gsize offset;
-    gst_buffer_get_sizes (buffer, &offset, NULL);
-    gst_buffer_resize (buffer, -offset, pool->priv->size);
+    gsize offset, maxsize;
+    gst_buffer_get_sizes (buffer, &offset, &maxsize);
+    /* check if we can resize to at least the pool configured size.  If not,
+     * then this will fail internally in gst_buffer_resize().
+     * default_release_buffer() will drop the buffer from the pool if the
+     * sizes don't match */
+    if (maxsize >= pool->priv->size) {
+      gst_buffer_resize (buffer, -offset, pool->priv->size);
+    } else {
+      GST_WARNING_OBJECT (pool, "Buffer %p without the memory tag has "
+          "maxsize (%" G_GSIZE_FORMAT ") that is smaller than the "
+          "configured buffer pool size (%u). The buffer will be not be "
+          "reused. This is most likely a bug in this GstBufferPool subclass",
+          buffer, maxsize, pool->priv->size);
+    }
   /* remove all metadata without the POOLED flag */

Which would explain why I am seeing the warning introduced in Gst 1.18 while using Gst 1.16.3.

Given that, if I modify the symlink to point to the original GStreamer version like this:

sudo ln -sf libgstreamer-1.0.so.0.1603.0 /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0

When I run the pipeline I will get a lot of these CRITICAL messages:

(gst-launch-1.0:9993): GStreamer-CRITICAL **: 11:15:39.565: gst_buffer_resize_range: assertion 'bufmax >= bufoffs + offset + size' failed

So my questions are the following:

  1. I get that these modifications you did to the GStreamer code remove the CRITICAL message but it doesn’t fix the root cause of this issue right?
  2. If the buffers are not being reused, as the warning states, wouldn’t this cause a performance issue?

Thanks in advance!

The check looks not required for our encoder, since we send data structure of NvBufSurface in GstBuffer to encoder, so the size is expected to be smaller. The check should be for putting full frame data in GstBuffer.

We would expect it works fine without the check. Do you hit any issue?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.