Environment:
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.
Hi,
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
Hi,
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.
Hi,
Please share how to replicate the issue. We will set up and give it a try.
Hi,@DaneLLL,
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
1220fornvidia.tar (462.5 KB)
Hi,
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?
Hi,@DaneLLL
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)
Hi,
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
Gst.init(None)
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
pipeline.set_state(Gst.State.PLAYING)
pipeline.get_state(Gst.CLOCK_TIME_NONE)
time.sleep(65536)
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)
pipeline.set_state(Gst.State.NULL)
pipeline.get_state(Gst.CLOCK_TIME_NONE)
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.
Hi，@DaneLLL
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:
Hi,
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.
Hi,
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.
Hi,
Please try to use the libs of r32.7.3 to r32.6.1:
/usr/lib/aarch64-linux-gnu/tegra/libnvbufsurface.so.1.0.0
/usr/lib/aarch64-linux-gnu/tegra/libnvbufsurftransform.so.1.0.0
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.
Hi，
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.