Memory leak use Gstreamer nvv4l2decoder with opencv VideoCaputer

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU) Jetson Xavier NX
• DeepStream Version 5.0
• JetPack Version (valid for Jetson only) 4.6[L4T 32.6.1]
• TensorRT Version 7.1.3
• NVIDIA GPU Driver Version (valid for GPU only)
• Issue Type( questions, new requirements, bugs) questions
• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)
• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)

Hi ,I have Memory leak use Gstreamer decode H264 and I find the solution with rebuild/replace the nvv4l2decoder plugin.But when I download the source code from https://developer.nvidia.com/embedded/l4t/r32_release_v6.1/sources/t186/public_sources.tbz2 and modified base Syncpts and threads leak using gstreamer plugin nvv4l2decoder and rebuild, memory leak is still exist.

My c++ code is below:
int main()
{
int n=10;
VideoCapture cap(“rtspsrc location=rtsp://admin:Aa111111@10.200.44.38:554/h264/ch1/main/av_stream latency = 5 ! rtph264depay ! h264parse ! nvv4l2decoder! nvvidconv ! video/x-raw,format=(string)BGRx ! videoconvert ! appsink sync = false”);
Mat frame;

while(n>0)
{
    n--;
    cap>>frame;
}

cap.release();

return 0;

}

And my debug command is:
valgrind --log-file=valgrind1_1.log --tool7=memcheck --leak-check=full --show-reachable=no ./main

The valgrind1_1.log is:
==20463== LEAK SUMMARY:
==20463== definitely lost: 16,520 bytes in 3 blocks
==20463== indirectly lost: 59 bytes in 1 blocks
==20463== possibly lost: 6,764 bytes in 65 blocks
==20463== still reachable: 2,353,999 bytes in 30,181 blocks
==20463== of which reachable via heuristic:
==20463== length64 : 3,152 bytes in 68 blocks
==20463== newarray : 1,936 bytes in 41 blocks
==20463== suppressed: 0 bytes in 0 blocks
==20463== Reachable blocks (those to which a pointer was found) are not shown.
==20463== To see them, rerun with: --leak-check=full --show-leak-kinds=all

4

Could you just change the nvv4l2decoder to avdec_h264 and see the result?

5

Hi, I change nvv4l2decoder to avdec_h264 and it does not work.
I finally change the pipleline string is:
rtspsrc location=rtsp://admin:Aa111111@10.200.44.38:554/h264/ch1/main/av_stream latency = 5 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! appsink sync = false

And the valgrind log is below:
Memcheck, a memory error detector
==6855== Copyright (C) 2002-2017, and GNU GPL’d, by Julian Seward et al.
==6855== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==6855== Command: ./main
==6855== Parent PID: 10283
==6855==
==6855==
==6855== HEAP SUMMARY:
==6855== in use at exit: 2,834,984 bytes in 33,480 blocks
==6855== total heap usage: 85,763 allocs, 52,283 frees, 98,319,248 bytes allocated
==6855==
==6855== 216 bytes in 14 blocks are possibly lost in loss record 2 of 15
==6855== at 0x4845B3C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==6855==
==6855== 1,664 bytes in 4 blocks are possibly lost in loss record 3 of 15
==6855== at 0x4847D10: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==6855==
==6855== 1,728 bytes in 54 blocks are possibly lost in loss record 4 of 15
==6855== at 0x4845BFC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==6855==
==6855== 11,324 bytes in 110 blocks are possibly lost in loss record 8 of 15
==6855== at 0x4847B0C: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==6855==
==6855== 16,635 (16,576 direct, 59 indirect) bytes in 3 blocks are definitely lost in loss record 9 of 15
==6855== at 0x4845BFC: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==6855==
==6855== LEAK SUMMARY:
==6855== definitely lost: 16,576 bytes in 3 blocks
==6855== indirectly lost: 59 bytes in 1 blocks
==6855== possibly lost: 14,932 bytes in 182 blocks
==6855== still reachable: 2,646,529 bytes in 32,480 blocks
==6855== of which reachable via heuristic:
==6855== length64 : 9,952 bytes in 238 blocks
==6855== newarray : 1,952 bytes in 42 blocks
==6855== suppressed: 0 bytes in 0 blocks
==6855== Reachable blocks (those to which a pointer was found) are not shown.
==6855== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6855==
==6855== For counts of detected and suppressed errors, rerun with: -v
==6855== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)

6

Hi @yangqun , From your test, it’s not the nvv4l2decoder that lost memory. Also we are not sure whether it is opencv or your own code did. You can use the valgrand to test our demo or gst-luanch-1.0 cli without any change and see if it still exist.

7

Thanks for reply.
Which demo to test with valgrind, deepstream or multimedia demo?

8

You can just test the gst-launch-1.0 cli like below:

gst-launch-1.0 rtspsrc location=rtsp://xxx latency=200 ! rtph264depay ! h264parse ! nvv4l2decoder .............
9

Thanks for reply.
I do test with gst-launch-1.0 in half hour and check memory with top.
The memory used is from 2626484 to 2658580.
gst-launch-1.0 VIRT from 1829956 to1830468.

I do not know where is the problem, NV or gstreamer?

10

===> I do not know where is the problem, NV or gstreamer?
You can make a comparison. First, run the pipeline with all gstreamer’s own plugins and see the change of the memory. Then, replace gstreamer’s own plugin with NV’s plugin, such as avdec_h264 to nvv4l2decoder. Also, you need to compare the memory of the start and the end.

11

Thanks for reply.
I do 2 tests at the same time. One is gstreamer plugins [gst-launch-1.0 -v rtspsrc location=rtsp://admin:Aa111111@10.200.44.38:554/h264/ch1/main/av_stream latency = 5 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! ximagesink]. The other one is gstreamer and NV plugins [gst-launch-1.0 -v rtspsrc location=rtsp://admin:Aa111111@10.200.44.38:554/h264/ch1/main/av_stream latency = 5 ! rtph264depay ! h264parse ! nvv4l2decoder ! nvvidconv ! video/x-raw,format=BGRx ! videoconvert ! nveglglessink].
The memory used keeps growing. I think there is something wrong with gstreamer and nv plugins to get rtsp video in opencv. Is there other method to get rtsp video to image in opencv with hard decoder?

12

There is no update from you for a period, assuming this is not an issue anymore.
Hence we are closing this topic. If need further support, please open a new one.
Thanks

We don’t have opencv demo code about this. You can directly implement it through our demo code without opencv. Please refer the deepstream-test app.

14

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