A bug about memory leak of the nvvideoconvert plugin by using GPU


As shown in the figure below, nvvideoconvert works properly in VIC mode,

But if you set nvvideoconvert to work in GPU mode(gobject nvvideoconvert compute-hw=1),It will trigger a memory leak.

What can I do to solve this problem? I have a lot of business running on nvvideoconvert , and need to transfer some of the work pressure from VIC to GPU.

Could you use VIC mode on Jetson platforms? This is the default mode we use on Jetson platforms. You can enable the engine always at maximum clock to get maximum throughput, by executing the steps:
Nvvideoconvert issue, nvvideoconvert in DS4 is better than Ds5? - #3 by DaneLLL

Hello, @DaneLLL
I need a way to make nvvideoconvert work on the gpu.Even if I increase the VIC working frequency, vic’s resources are not enough for my business

Which DeepStream SDK release you are using? Can you try latest version?

I’m using deepstream-6.0.And i haven’t seen any updates to the nvvideoconvert plugin in the latest version.

Please share how to replicate the issue. We will set up and give it a try.

I wrote a simple test program for you.You can use instructions(cat /proc/pid/status) to observe the slow leakage of his physical existence


  • If you comment out these two lines of code,It will not leak memory

    In fact, in some deepstream examples, setting nvvideoconvert to work on the gpu also reappeared the memory leak problem

1220fornvidia.tar (462.5 KB)

It seems like your sample is not a real use-case. Generally we will run

video/x-raw ! nvvideoconvert ! video/x-raw(memory:NVMM)
video/x-raw(memory:NVMM) ! nvvideoconvert ! video/x-raw
video/x-raw(memory:NVMM) ! nvvideoconvert ! video/x-raw(memory:NVMM)

to convert CPU buffers to NVMM buffers, NVMM buffers to CPU buffers, or NVMM buffers to NVMM buffers. But you run it like:

video/x-raw ! nvvideoconvert ! video/x-raw

For utilizing hardware acceleration we would like to have data in NVMM buffers but somehow you use CPU buffers in you ruse-case. This may not be an optimal solution. Do you observe the issue if using NVMM buffers?

Making nvvideoconvert work on GPU can trigger memory leaks, whether using cpu memory or NVMM.This bug is very easy to repeat,you can refer to the code I set up the nvmm type today.

1221fornvidia.tar (454 KB)

We run the sample:

#!/usr/bin/env python3

import gi
import time
gi.require_version('Gst', '1.0')
from gi.repository import Gst, GObject, GLib

pipeline = None

# initialize GStreamer
pipeline = Gst.parse_launch(
        "videotestsrc is-live=1 ! video/x-raw,width=640,height=512 ! nvvideoconvert compute-hw=1 ! video/x-raw(memory:NVMM) ! nvvideoconvert compute-hw=1 ! video/x-raw(memory:NVMM),width=960,height=768 ! nvvideoconvert compute-hw=1 ! video/x-raw(memory:NVMM),width=1920,height=1080 ! fakesink "

for i in range(1, 2):
    print("loop =",i," ")

    # start playing

    print("Send EoS")
    Gst.Element.send_event(pipeline, Gst.Event.new_eos())
    # wait until EOS or error
    bus = pipeline.get_bus()
    msg = bus.timed_pop_filtered(
        Gst.CLOCK_TIME_NONE, Gst.MessageType.EOS)


And execute top to check memory status. Don’t see increase in memory. Do you hit the issue in specific operation? In the pipeline there is upscale and downscale. These operations seem to work fine.

Please run the sample in terminal:
gst-launch-1.0 videotestsrc is-live=1 ! ‘video/x-raw,width=640,height=512’ ! nvvideoconvert compute-hw=1 ! ‘video/x-raw(memory:NVMM)’ ! nvvideoconvert compute-hw=1 ! ‘video/x-raw(memory:NVMM),width=960,height=768’ ! nvvideoconvert compute-hw=1 ! ‘video/x-raw(memory:NVMM),width=1920,height=1080’ ! fakesink

Here’s the result of my test:(1).Memory increased by 81.2M in 10 minutes; (2)The memory footprint in the top increased from 1.2 percent to 2.2percent

And if you’re not running on a gpu, processes don’t take up any more system memory:

gst-launch-1.0 videotestsrc is-live=1 ! ‘video/x-raw,width=640,height=512’ ! nvvideoconvert ! ‘video/x-raw(memory:NVMM)’ ! nvvideoconvert ! ‘video/x-raw(memory:NVMM),width=960,height=768’ ! nvvideoconvert ! ‘video/x-raw(memory:NVMM),width=1920,height=1080’ ! fakesink

And my test environment:

We try the gst-launch-1.0 command you shared on Jetpack 4.6.3(r32.7.3) and do not see the memory increase. So it probably is specific to r32.6.1. Do you observe the issue in both running gst-launch-1.0 command and the python sample?

This is a real problem. Our bulk products are deployed in c++, and our application scenarios don’t use python.
I have provided many methods of recurrence, please follow up to solve

The problem can also be reproduced using your python example.
Please observe with the “cat /proc/pid/status” command,If you use “top” it takes a while to see an increase,because it’s not leaking fast enough.

We don’t see the issue on latest release. It would be great if you can upgrade.

Can you help to determine what has been fixed compared with the latest version? Can you provide
a patches?

We have a batch of hundreds of products already deployed to the customer,we can only upgrade the software, we can’t recall the product and burn a new version.

Please try to use the libs of r32.7.3 to r32.6.1:


See if it works fine on r32.6.1. Please remove cache after the replacement:

$ rm .cache/gstreamer-1.0/registry.aarch64.bin

And please backup the original libs before the replacement.

1 Like

Thanks a lot,I successfully solved the problem according to the method you provided.

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