I think I have found a good workaround for this problem, but I decided to post about it anyway because I think there’s a bug in nveglglessink. I’m using JetPack 6.2.1 with an Orin NX 16 GB.
What I’ve found is that with this simple pipeline bringing in a 1080p30 video signal from a video capture card:
gst-launch-1.0 starts out at about 3% total CPU usage (measured with top, with irix mode disabled), but the longer I let it sit, the more CPU it uses. After a couple of hours it will be at 10%. This is also reproducible in my own C/C++ app that calls the GStreamer API. The exact same increasing CPU usage occurs.
I ended up solving the problem by switching to nv3dsink instead. That’s what I wanted to use anyway, but originally I could not get it working because nv3dsink would segfault as soon as I called gst_video_overlay_set_window_handle() in my app to tell it to render into a custom window. This is the same problem that was discussed several years ago here and never came to a conclusion.
I found a workaround for this segfault: nv3dsink is pickier than nveglglessink about when you are allowed to call gst_video_overlay_set_window_handle(). If you set up a synchronous bus callback with gst_bus_set_sync_handler() and call it from the callback function whenever gst_is_video_overlay_prepare_window_handle_message() returns true, nv3dsink works great with a custom window. That’s what I’m doing now and it’s working great. No more CPU usage bug like I was seeing with nveglglessink.
So, in summary, two issues to report and hopefully this info will help others who might run into the same problem I did.
nveglglessink has some kind of problem that causes it to use more and more CPU over time. I didn’t go into any more detail to track down why.
It might be nice if nv3dsink had some extra checks added to prevent it from segfaulting if you call gst_video_overlay_set_window_handle() before the pipeline is up and running. After all, nveglglessink doesn’t have this same crash.
Yes, that’s correct. I’m using JetPack 6.2.1 r36.4.4.
Thanks for the links to the source code. I had already found it, but I appreciate the link! Inspecting the source was how I figured out a way to use nv3dsink in a custom window without a segfault. I wasn’t able to determine what causes the rising CPU usage in nveglglessink though.
As far as I have been able to tell, nvidia-gstreamer-libs versions 36.4.4-20250616085344 and 36.4.7-20250918154033 both have the same problems.
Hi,
We are deprecating nveglglessink plugin and may not have further investigation. If you can use nv3dsink in the use-case and it works properly, please use it.
If you have no concern, please share us the patch to fix the segfault in nv3dsink.
Sounds good, and that makes sense. nv3dsink is clearly better.
There is no patch to nv3dsink – my workaround is to wait for a prepare-window-handle message as described here. It appears this is the intended use case in GStreamer so maybe the segfault doesn’t matter. Their Qt example code down below will segfault if used with nv3dsink though, because it’s calling gst_video_overlay_set_window_handle immediately instead of waiting for the message.
I just thought I’d mention it because regardless, it is a segfault, and other sinks don’t segfault the same way. I believe what’s happening is if gst_nv3dsink_set_window_handle gets called too early, things like nv3dsink->window haven’t been populated yet (because they are set up in gst_nv3dsink_start). So it tries to access a null pointer and crashes.
At the very least, hopefully if someone else runs into this same problem with nv3dsink in the future they might see this message to learn the workaround.