Spamming message: Buffer without the memory tag has maxsize (0) that is smaller than the configured buffer pool size

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi,
With gstreamer 1.18, I am having message spamming with a H264 pipeline:
default_reset_buffer:nvv4l2decoder0:pool:sink Buffer 0x7f7c0415a0 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

Source pipeline
gst-launch-1.0 videotestsrc pattern=“ball” ! video/x-raw,width=1920,height=1080,framerate=60/1 ! nvvidconv ! nvv4l2h264enc ! mpegtsmux ! udpsink port=14005 host=127.0.0.1

Recv pipeline
GST_DEBUG=3
GST_DEBUG_COLOR_MODE=off
gst-launch-1.0 udpsrc port=14005 ! tsdemux latency=1 ignore-pcr=true ! h264parse ! queue ! nvv4l2decoder disable-dpb=true ! nvvidconv ! nvoverlaysink overlay=1 sync=false

Console
0:00:00.078212576 3189 0x55b1a47c30 WARN omx gstomx.c:2822:plugin_init: Failed to load configuration file: Valid key file could not be found in search dirs (searched in: /home/rhc/.config:/etc/xdg as per GST_OMX_CONFIG_DIR environment variable, the xdg user config directory (or XDG_CONFIG_HOME) and the system config directory (or XDG_CONFIG_DIRS)
Setting pipeline to PAUSED …
Opening in BLOCKING MODE
Opening in BLOCKING MODE
0:00:00.225679296 3189 0x55b1a47c30 WARN v4l2 gstv4l2object.c:4432:gst_v4l2_object_probe_caps:nvv4l2decoder0:src Failed to probe pixel aspect ratio with VIDIOC_CROPCAP: Unknown error -1
0:00:00.225776512 3189 0x55b1a47c30 WARN v4l2 gstv4l2object.c:2375:gst_v4l2_object_add_interlace_mode:0x55b1a42e40 Failed to determine interlace mode
0:00:00.225845056 3189 0x55b1a47c30 WARN v4l2 gstv4l2object.c:2375:gst_v4l2_object_add_interlace_mode:0x55b1a42e40 Failed to determine interlace mode
Pipeline is live and does not need PREROLL …
Pipeline is PREROLLED …
Setting pipeline to PLAYING …
New clock: GstSystemClock
0:00:00.266419232 3189 0x55b1a64400 WARN mpegtspacketizer mpegtspacketizer.c:2376:mpegts_packetizer_pts_to_ts: Not enough information to calculate proper timestamp
0:00:00.285960640 3189 0x55b1a64400 WARN h264parse gsth264parse.c:1490:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 537 will be dropped
0:00:00.305513408 3189 0x55b1a64400 WARN h264parse gsth264parse.c:1490:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 619 will be dropped
(…)
0:00:03.747748768 3189 0x55b1a64400 WARN h264parse gsth264parse.c:1490:gst_h264_parse_handle_frame: broken/invalid nal Type: 1 Slice, Size: 526 will be dropped
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261
0:00:03.791443232 3189 0x55b1a4c240 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:nvv4l2decoder0:pool:sink Buffer 0x7f7c005c60 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
0:00:03.892310016 3189 0x55b1a4c240 WARN v4l2 gstv4l2object.c:4432:gst_v4l2_object_probe_caps:nvv4l2decoder0:src Failed to probe pixel aspect ratio with VIDIOC_CROPCAP: Unknown error -1
0:00:03.892990048 3189 0x55b1a4c240 WARN v4l2 gstv4l2object.c:2375:gst_v4l2_object_add_interlace_mode:0x55b1a42e40 Failed to determine interlace mode
0:00:03.893560576 3189 0x55b1a4c240 WARN v4l2 gstv4l2object.c:2375:gst_v4l2_object_add_interlace_mode:0x55b1a42e40 Failed to determine interlace mode
0:00:03.907340672 3189 0x55b1a4c240 WARN v4l2videodec gstv4l2videodec.c:1677:gst_v4l2_video_dec_decide_allocation: Duration invalid, not setting latency
0:00:03.909224640 3189 0x55b1a4c240 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:nvv4l2decoder0:pool:sink Buffer 0x7f7808dd80 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
0:00:03.909296512 3189 0x55b1a4c240 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:nvv4l2decoder0:pool:sink Buffer 0x7f7809b000 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
0:00:03.909380576 3189 0x55b1a4c240 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:nvv4l2decoder0:pool:sink Buffer 0x7f7809b240 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
0:00:03.909504512 3189 0x55b1a4c240 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:nvv4l2decoder0:pool:sink Buffer 0x7f7809b480 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
0:00:03.909560160 3189 0x55b1a4c240 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:nvv4l2decoder0:pool:sink Buffer 0x7f7809b6c0 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
0:00:03.909607904 3189 0x55b1a4c240 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:nvv4l2decoder0:pool:sink Buffer 0x7f7809b900 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
0:00:03.913236640 3189 0x55b1a64c60 WARN v4l2bufferpool gstv4l2bufferpool.c:1511:gst_v4l2_buffer_pool_dqbuf:nvv4l2decoder0:pool:src Driver should never set v4l2_buffer.field to ANY
0:00:03.920957344 3189 0x55b1a4c240 WARN bufferpool gstbufferpool.c:1235:default_reset_buffer:nvv4l2decoder0:pool:sink Buffer 0x7f7809bb40 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

3

Hi,
We would suggest use default 1.14.5 since it is tested and shall be stable. If you have to upgrade to 1.18, the source code of gst-v4l2 is open source. You may build the plugin manually.

4

Hi DaneLLL,
I needs 1.18 to get latency improvement made by gstreamer. I built the gst-v4l2 plugin.
Now, I am facing the message:
Buffer 0x7f7809bb40 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

5

Hi,
It is uncertain if the plugins work with 1.18. We suggest rebuild all plugins and try. The source code is in
https://developer.nvidia.com/embedded/l4t/r32_release_v7.1/sources/t186/public_sources.tbz2

The nvoverlaysink is not open source. You may use nv3dsink.

6

Hi DaneLLL
Thank you for the reply.
We already successfully build a gstreamer 1.18 from the source.
We are using L4T 32.5.2 to do it so we have no issue with ‘nvoverlaysink’.

For a little bit of history, we need a very high performance H264 decode (in latency point of view).
With gst 1.14 we had difficulty to go below 2 seconds.
Now, with gst 1.18, we have some new option in tsdemux and with nvv4l2decoder, we reach 180 ms.
It’s a lot better but still not impressing.
And over that, we have this warning coming from gst about gstbufferpool that not reusing buffer (the object of this thread)…
Some more information, if we use omxh264dec, we don’t have the warning anymore, but with more latency…
This seems to demonstrate that the issue is coming from nvv4l2decoder.

So is somebody knows where this warning is coming? Is it something in 1.18 that is fixed in 1.20?
Or any other cue on how to properly allocate buffer?

Thanks,

PS here the call stack whene we got that message:

Thread 5 “queue0:src” hit Breakpoint 3, default_reset_buffer (pool=0x7fa40800d0 [GstNvV4l2BufferPool|nvv4l2decoder0:pool:sink], buffer=0x7fa409eb40 [GstBuffer]) at …/gstreamer-1.18.6/gst/gstbufferpool.c:1235
1235 in …/gstreamer-1.18.6/gst/gstbufferpool.c
(gdb) bt
#0 default_reset_buffer (pool=0x7fa40800d0 [GstNvV4l2BufferPool|nvv4l2decoder0:pool:sink], buffer=0x7fa409eb40 [GstBuffer]) at …/gstreamer-1.18.6/gst/gstbufferpool.c:1235
#1 0x0000007fb7eaba58 in gst_buffer_pool_release_buffer (pool=0x7fa40800d0 [GstNvV4l2BufferPool|nvv4l2decoder0:pool:sink], buffer=0x7fa409eb40 [GstBuffer]) at …/gstreamer-1.18.6/gst/gstbufferpool.c:1374
#2 0x0000007fb7ea8064 in _gst_buffer_dispose (buffer=0x7fa409eb40 [GstBuffer]) at …/gstreamer-1.18.6/gst/gstbuffer.c:762
#3 0x0000007fb7ee146c in gst_mini_object_unref (mini_object=0x7fa409eb40 [GstBuffer]) at …/gstreamer-1.18.6/gst/gstminiobject.c:656
#4 0x0000007fb7137128 in gst_buffer_unref (buf=) at /usr/include/gstreamer-1.0/gst/gstbuffer.h:423
#5 gst_v4l2_buffer_pool_process (pool=0x7fa40800d0 [GstNvV4l2BufferPool|nvv4l2decoder0:pool:sink], buf=buf@entry=0x7fa4085148) at gstv4l2bufferpool.c:2288
#6 0x0000007fb712e260 in gst_v4l2_video_dec_handle_frame (decoder=0x555587bdd0 [nvv4l2decoder|nvv4l2decoder0], frame=0x7fa4085110) at gstv4l2videodec.c:1581
#7 0x0000007fb72f62e4 in gst_video_decoder_decode_frame (decoder=decoder@entry=0x555587bdd0 [nvv4l2decoder|nvv4l2decoder0], frame=0x7fa4085110) at …/gst-plugins-base-1.18.6/gst-libs/gst/video/gstvideodecoder.c:3567
#8 0x0000007fb72fc1c4 in gst_video_decoder_chain_forward (decoder=decoder@entry=0x555587bdd0 [nvv4l2decoder|nvv4l2decoder0], buf=buf@entry=0x7f88005480 [GstBuffer], at_eos=at_eos@entry=0)
at …/gst-plugins-base-1.18.6/gst-libs/gst/video/gstvideodecoder.c:2273
#9 0x0000007fb72fc948 in gst_video_decoder_chain (pad=, parent=0x555587bdd0 [nvv4l2decoder|nvv4l2decoder0], buf=0x7f88005480 [GstBuffer]) at …/gst-plugins-base-1.18.6/gst-libs/gst/video/gstvideodecoder.c:2588
#10 0x0000007fb7ee51b8 in gst_pad_chain_data_unchecked (pad=pad@entry=0x555580efc0 [GstPad|sink], type=type@entry=4112, data=, data@entry=0x7f88005480) at …/gstreamer-1.18.6/gst/gstpad.c:4404
#11 0x0000007fb7ee7018 in gst_pad_push_data (pad=pad@entry=0x555580ed70 [GstPad|src], type=type@entry=4112, data=data@entry=0x7f88005480) at …/gstreamer-1.18.6/gst/gstpad.c:4668
#12 0x0000007fb7eeeafc in gst_pad_push (pad=0x555580ed70 [GstPad|src], buffer=buffer@entry=0x7f88005480 [GstBuffer]) at …/gstreamer-1.18.6/gst/gstpad.c:4787
#13 0x0000007fb71b36bc in gst_queue_push_one (queue=0x5555838180 [GstQueue|queue0]) at …/gstreamer-1.18.6/plugins/elements/gstqueue.c:1386
#14 gst_queue_loop (pad=) at …/gstreamer-1.18.6/plugins/elements/gstqueue.c:1539
#15 0x0000007fb7f2129c in gst_task_func (task=0x55558175f0 [GstTask|queue0:src]) at …/gstreamer-1.18.6/gst/gsttask.c:384
#16 0x0000007fb7d96008 in g_thread_pool_thread_proxy (data=) at …/glib-2.66.7/glib/gthreadpool.c:354
#17 0x0000007fb7d95554 in g_thread_proxy (data=0x5555888e40) at …/glib-2.66.7/glib/gthread.c:826
#18 0x0000007fb7c83d18 in start_thread (arg=0x7fffffec6f) at pthread_create.c:481
#19 0x0000007fb7bd8a9c in thread_start () at …/sysdeps/unix/sysv/linux/aarch64/clone.S:79

7

Hi,
We don’t use 1.18, so are not able to comment on the print. Do you see the warning print with default 1.14.5?

9

Hi DaneLLL,

Sorry for the delay, it’s summer vacation here.
But the issue is still open and I don’t want this topic to close.
I am Micheal’s colleague.

No, this warning was not in the 1.14 version.
But unfortunately, the H264dec + mpeg2TS latency of version 1.14 is not usable for us (near 2 secondes).
Do you use any other / newer version that would be better for you (1.20) ?
Do you know a better way to reduce our decoding / presenting latency?

In the meantime, I will try Gst 1.20

Thanks,

Stéphane Germain

10

Hi DaneLLL,
The print cannot be there in 1.14 since this check was add only 2 year ago: gst/bufferpool: only resize in reset when maxsize is larger (a1b41b2b) · Commits · GStreamer / gstreamer · GitLab

But I guess the “bug” already exist in 1.14.

Michaël

11

Hi DaneLLL,

I install the gstreamer 1.20 from Jetpack 4.6.2. I have the same error message.

13

Hi,
If the h264 stream can be well decoded into valid frame data, we think you may take it as warning message. Since gst-v4l2 is open source, you can look at the source code and find out where it is printed and then remove the print.

We have test cases performed in each release with 1.14.5, still suggest stay on the default version for better stability.

15

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