0:00:03.869798945 18491 0x5596d6e0a0 WARN v4l2bufferpool gstv4l2bufferpool.c:1483:gst_v4l...

When I use GST_DEBUG=3 all I see is this warning.

Jetson tx2, R32.1 with leporard imaging driver for thier imx334 camera.


Please share the print in

The warning message should be harmless. However, it is cut in topic title. Need a complete print to confirm this.

It should be


It is harmless and please ignore it.

1 Like

But it is making debugging impossible because it is filling the console with these worthless messages that need to be ignored. Please remove them from your distribution.


Try adding this to the end of the command you use to debug (the “…” is your command, but I’m unsure of your debug program):

..... 2>/dev/null 3>/dev/null

(“2” is stderr, “3” is similar but is buffered, “stdlog”…not many people use “3”, but I’ve seen it in at least one multimedia app and it might matter for your case)

Is there a way to have someone else discuss this question please?

gstreamer debugging requires at least adding some type of GST_DEBUG= and trying to find a message to help find a solution, but in my case turning on a reasonable level of debugging causes the endless message that I am suppose to ignore and only cover up any good or possible hints/debug messages.

How do I make requests for future software changes?


gst-v4l2 is open source in

Please remove the print in gstv4l2allocator.c and rebuild/replace libgstnvvideo4linux2.so

GST_WARNING_OBJECT (allocator, "V4L2 provided buffer has bytesused %"
    G_GUINT32_FORMAT " which is too small to include data_offset %"
    G_GUINT32_FORMAT, group->planes[i].bytesused,

libnvbufsurface.so missing in R32.1, or is it available in another source?

The source package for r32.1/TX2 is
Please check this package.

The link in #7 is for r32.3/Jetson Nano.

Thanks, new source did compile and I was able to install the library.

Still getting 0:00:05.541897907 9913 0x5577311800 WARN v4l2bufferpool gstv4l2bufferpool.c:1483:gst_v4l2_buffer_pool_dqbuf:nvv4l2h264enc0:pool:sink V4L2 provided buffer has bytesused 0 which is too small to include data_offset 0

So is nvv4l2h264enc0 needing rebuilding also?


Please check if you overwrite it successfully:

$ ls -all /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvvideo4linux2.so
-rwxr-xr-x 1 root root 246352 十一 20 16:20 /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvvideo4linux2.so

The time should be updated and different from other libs.

time shows new library built yesterday,

What next?


This is my command line that is running,
Three tee’s

  1. video camera to display
  2. video camera to picture on demand controlled by my stalkertakepicture filter,
  3. video camera to video on demand with 5 second prebuffer controlled by stalkerCreateVideo

So both nvarguscamerasrc and nvv4l2h264enc are running.Looks like both nvidia filters are having the warning problem

#define CMDLINE “nvarguscamerasrc
! video/x-raw(memory:NVMM),width=3840,height=2160,format=NV12
! nvvidconv
! clockoverlay time-format=”%D %H:%M:%S" halignment=right
! gdkpixbufoverlay location=/usr/local/stalker/crosshair-500x3.svg relative-x=.5 relative-y=.5
! gdkpixbufoverlay location=/usr/local/stalker/Logo-500x3.svg offset-x=0 offset-y=0
! queue
! tee name=t ! queue
t. ! queue
! nveglglessink name=displaySink sync=false window-width=960 window-height=540
t. ! queue
! stalkertakepicture ! nvjpegenc ! multifilesink name=stalkerPicture async=false location=/usr/local/sta
t. ! queue
! nvvidconv ! video/x-raw(memory:NVMM),width=(int)1920,height=(int)1080,format=(string)I420
! queue
! nvv4l2h264enc ! h264parse
! stalkercreatevideo name=stalkercreatevideo
! splitmuxsink name=stalkerVideoSink async-handling=true location=/tmp/tmpFile "

gstv4l2bufferpool.c also contains this same bit of GST_WARN, that’s probably why you still see this warning in your debug.

Interesting same bad WARNING in two different source code.

That fixed that problem, now I can use GST_DEBUG=4 to look for other possible problems,

Any pointers/help for a Gstreamer-CRITICAL assertion track down?


New problem, I think this is your code? Looks like libgstnvvideo4linux2.so gets criticals on setting debugging

Is there any clue how to fix this, I am seeing a bunch of CRITICALS when I run

clear;GST_DEBUG=4,GST_STATES:0,GST_EVENT:0,bin:0 G_DEBUG=fatal-criticals gdb ./VideoSystem.notStripped

(VideoSystem.notStripped:21462): GStreamer-CRITICAL **: 13:17:22.230: gst_debug_log_valist: assertion ‘category != NULL’ failed

Thread 1 “VideoSystem.not” received signal SIGTRAP, Trace/breakpoint trap.
raise (sig=5) at …/sysdeps/unix/sysv/linux/raise.c:51
51 …/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x0000007fb747f2f0 in raise (sig=5) at …/sysdeps/unix/sysv/linux/raise.c:51
#1 0x0000007fb73b4be0 in g_logv () at /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#2 0x0000007fb73b4de4 in g_log () at /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#3 0x0000007fb729eaac in gst_debug_log_valist () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#4 0x0000007fb729ebac in gst_debug_log () at /usr/lib/aarch64-linux-gnu/libgstreamer-1.0.so.0
#5 0x0000007fa80baedc in gst_v4l2_open () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvvideo4linux2.so
#6 0x0000007fa80aaaf0 in gst_v4l2_object_open () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvvideo4linux2.so
#7 0x0000007fa80a4f5c in gst_v4l2_video_enc_open () at /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvvideo4linux2.so
#8 0x0000007fb71871b4 in () at /usr/lib/aarch64-linux-gnu/libgstvideo-1.0.so.0
#9 0x0000000000000002 in ()
(gdb) q

This is in the way of getting to my CRITICAL later on in the program.

Is there a way to get and receive emails/info on a quicker basis.

I think I am finding things that need to be fixed in your low level code?


gst-v4l2 is open source code from gstreamer organization:

We have patches for enabling hardware acceleration. In general, we run ‘$ export GST_DEBUG=*:5’ for debugging. For more advanced debugging functions, you may see if other users can share experience.


Why is gstv4l2videoenc.c included in your tar ball.

Is it up to date?

Why are you recompiling gstreamer library modules, instead of linking to the correct libraries?

Appears to me that who ever built /usr/lib/aarch64-linux-gnu/gstreamer-1.0/libgstnvvideo4linux2.so is incorrect. You should never copy other libraries source code into your build area. If an update changes gstreamer libraries, you never see the benefits or changes.

Also I submitted this problem to gstreamer and they think it is a nvidia problem because of the library that appears in the back trace, but it is a gstreamer duplicate module you copy to your build area.

This is wrong on so many levels I hope nvidia gets their act together, otherwise you will continue to have random recurring problems in gstreamer.


How and when do you update/upgrade these libraries.

How do you know that nvidia libraries will be used instead of the gstreamer libraries?


Please check the license declaration in:


Hardware acceleration of TX1, TX2, Xavier, and Jetson Nano is enabled through gst-v4l2 based on