Nvv4l2decoder plugin is not shutting down cleanly and leaking memory

I had raised similar issue in different post Memory Leak observed when nvgstplayer runs in –loop-forever mode
After a lot of debug using valgrind/gdb I traced the issue to the fact that the decoder is not releasing buffer pools for v4l2capture object, and due to that the devices are not closing properly (The method v4l2_close in libv4l2.c always returns 0 because device count is not zero
if (result) {
return 0;
}
)
To give more details: in gst_v4l2_video_dec_stop calls are made for gst_v4l2_object_stop (self->v4l2output); and gst_v4l2_object_stop (self->v4l2capture);. The first call for v4l2output cleans up the bufferpool by calling gst_v4l2_buffer_pool_finalize in gstv4l2bufferpool.c, but the second call for v4l2capture never ever calls gst_v4l2_buffer_pool_finalize and so the resources remain held up. Can you please provide the fix for this asap? This issue has never been resolved.

Hi,
Please make sure you have applied:
Memory Leak observed when nvgstplayer runs in --loop-forever mode - #7 by DaneLLL

If the issue is still present, please share steps for replicating the issue on Jetson Nano developer kit. So that we can set up and try.

Hello Dane, I am the same person who raised the previous post and and applied the patches, but with no luck. The issue was still there. You had suggested since nvv4l2decoder is an open source implementation, I should take a look at it myself, so i went in depth in the implementation and found the root cause. Can you please ask the relevant development team to take a look? I cannot waste anymore time. I will provide simple steps to reproduce and the complete api call traces to the set of libraries. Thanks

Hi,
Form the description, it looks like EoS is not sent to decoder in the condition. But we would need to replicate it first and then do further investigation. Please help share the steps.

r32.7.2/Linux_for_Tegra/source/public/nvgstapps_src/nvgst_sample_apps/nvgstplayer-1.0$ ./nvgstplayer-1.0 --uri rtsp://192.168.71.56:5540/ch0 --window-x=0 --window-y=0 --window-width=1920 --window-height=1080
Runtime Commands:
q quit the application
h print help
Up Key, ] goto next track
c restart current track
Down Key, [ goto previous track
spos query for position
sdur query for duration
s seek to position in seconds, eg “s5.120”
v seek to percent of the duration, eg “v54”
f seek by seconds, relative to current position eg “f23.901”
Left Key, < seek backwards by 10 seconds
Right Key, > seek forward by 10 seconds
p pause playback
r start/resume the playback
z stop the playback
i: enter a single URI

1 r

Assigned instance_init as gst_v4l2_video_dec_subinstance_init
gst_v4l2_video_dec_subinstance_init calling gst_v4l2_object_new for v4l2output
gst_v4l2_object_new called
gst_v4l2_video_dec_subinstance_init calling gst_v4l2_object_new for v4l2capture
gst_v4l2_object_new called
v4l2_video_dec_open is called
gst_v4l2_object_open Else Calling gst_v4l2_open
gst_v4l2_open Trying to open device /dev/nvhost-nvdec
gst_v4l2_open: Opened /dev/nvhost-nvdec
gst_v4l2_open: Calling fd_open
v4l2_plugin_init is called
Opening in BLOCKING MODE
v4l2_fd_open open: 35 devices used 1
Opened device ‘’ (/dev/nvhost-nvdec) successfully
gst_v4l2_dup called: Trying to dup device /dev/nvhost-nvdec
v4l2_dup incr open count to 2
gst_v4l2_dup Cloned device ‘’ (/dev/nvhost-nvdec) successfully
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261
gst_v4l2_object_setup_pool initializing the output system
gst_v4l2_object_setup_pool initiating buffer pool
v4l2_dup incr open count to 3
gst_v4l2_object_setup_pool initializing the capture system
gst_v4l2_object_setup_pool initiating buffer pool
v4l2_dup incr open count to 4

q (input from keyboard to quit the app)
gst_v4l2_video_dec_stop calling gst_v4l2_object_stop for v4l2capture
gst_v4l2_object_stop called
gst_v4l2_object_stop deactivating pool
gst_v4l2_video_dec_stop calling gst_v4l2_object_stop for v4l2output
gst_v4l2_object_stop called
gst_v4l2_object_stop deactivating pool
gst_v4l2_buffer_pool_stop Stopping Buffer Pool
g_object_unref : old_ref count 1
g_object_unref : old_ref count 1
gst_v4l2_buffer_pool_finalize is called with video fd 35
v4l2_close close: 35 is called
v4l2_close index 0 open_count 4
v4l2_close: result 1 return 0
v4l2_video_dec_close is called
gst_v4l2_object_close called
gst_v4l2_close Trying to close /dev/nvhost-nvdec
v4l2_close close: 35 is called
v4l2_close index 0 open_count 3
v4l2_close: result 1 return 0
gst_v4l2_object_close called
gst_v4l2_close Trying to close /dev/nvhost-nvdec
v4l2_close close: 35 is called
v4l2_close index 0 open_count 2
v4l2_close: result 1 return 0

Playback completed!
Application will now exit!

I just put my traces inside the libraries to obtain chain of calls to the api’s

Hi,
Please try the attached python sample with your rtsp source and see if the issue is present. We can run the sample and pass overnight test. Please give it a try.

gstreamer_rtsp.py (961 Bytes)

Running longterm is not an issue for me too, but connecting to rtsp source and then tearing down the connection repeatedly is causing the decoder to not release resources and hold up the memory, and if yo do this several times, the memory is lost and the process is killed by the OS, which does not support the used case i am trying to implement. Anyways, I will try your python script and let you know. Thanks.

Hi,
If the source is disconnected, you would need to destroy and re-initialize the pipeline. Do you recevie EoS or error message in the condition? It yes, please check if the message is handled properly. In normal video playback, there is EoS signal to let decoder know there is no further compressed stream and after last frame is decoded, decoder goes into termination.

I am disconnecting from the source, the source is still alive. The trace I sent exhibits that behavior, when i press q to exit from nvgstplayer, it should gracefully release all the resources (buffer pool, memory mapped io, close the fd etc. etc… ) which it is not doing. I will also send you the valgrind output which points to this anomaly

r32.7.2/Linux_for_Tegra/source/public/nvgstapps_src/nvgst_sample_apps/nvgstplayer-1.0$ valgrind --tool=memcheck --leak-check=full --leak-resolution=high --trace-children=yes --num-callers=20 --show-leak-kinds=all --track-origins=yes --verbose ./nvgstplayer-1.0 --uri rtsp://192.168.71.56:5540/ch0 --window-x=0 --window-y=0 --window-width=1920 --window-height=1080
==10620== Memcheck, a memory error detector
==10620== Copyright (C) 2002-2022, and GNU GPL’d, by Julian Seward et al.
==10620== Using Valgrind-3.21.0.GIT- and LibVEX; rerun with -h for copyright info
==10620== Command: ./nvgstplayer-1.0 --uri rtsp://192.168.71.56:5540/ch0 --window-x=0 --window-y=0 --window-width=1920 --window-height=1080
==10620==
–10620-- Valgrind options:
–10620-- --tool=memcheck
–10620-- --leak-check=full
–10620-- --leak-resolution=high
–10620-- --trace-children=yes
–10620-- --num-callers=20
–10620-- --show-leak-kinds=all
–10620-- --track-origins=yes
–10620-- --verbose
–10620-- Contents of /proc/version:
–10620-- Linux version 4.9.299-tegra (buildbrain@mobile-u64-5333-d8000) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Tue Nov 22 09:24:39 PST 2022
–10620–

==10728== 56 bytes in 1 blocks are definitely lost in loss record 4,565 of 7,507
==10728== at 0x48479F0: operator new(unsigned long) (vg_replace_malloc.c:434)
==10728== by 0x2689F7AF: ???
==10728== by 0x400DA33: call_init.part.0 (dl-init.c:72)
==10728== by 0x400DB37: call_init (dl-init.c:118)
==10728== by 0x400DB37: _dl_init (dl-init.c:119)
==10728== by 0x4011CD7: dl_open_worker (dl-open.c:522)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4011417: _dl_open (dl-open.c:605)
==10728== by 0x4F97013: dlopen_doit (dlopen.c:66)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4F48837: _dl_catch_error (dl-error-skeleton.c:215)
==10728== by 0x4F9877F: _dlerror_run (dlerror.c:162)
==10728== by 0x4F970E7: dlopen@@GLIBC_2.17 (dlopen.c:87)
==10728== by 0x160A5CF7: v4l2_plugin_init (v4l2-plugin.c:76)
==10728== by 0x1609E9B7: v4l2_fd_open (libv4l2.c:665)
==10728== by 0xA39F477: gst_v4l2_open (v4l2_calls.c:574)
==10728== by 0xA38EA7B: gst_v4l2_object_open (gstv4l2object.c:973)
==10728== by 0xA36F443: gst_v4l2_video_dec_open (gstv4l2videodec.c:613)
==10728== by 0x48E410B: gst_video_decoder_change_state (gstvideodecoder.c:2486)
==10728== by 0xA3736BB: gst_v4l2_video_dec_change_state (gstv4l2videodec.c:1956)
==10728== by 0x4998F2F: gst_element_change_state (gstelement.c:2952)
==10728==
==10728== 56 bytes in 1 blocks are definitely lost in loss record 4,566 of 7,507
==10728== at 0x48479F0: operator new(unsigned long) (vg_replace_malloc.c:434)
==10728== by 0x2689F7F7: ???
==10728== by 0x400DA33: call_init.part.0 (dl-init.c:72)
==10728== by 0x400DB37: call_init (dl-init.c:118)
==10728== by 0x400DB37: _dl_init (dl-init.c:119)
==10728== by 0x4011CD7: dl_open_worker (dl-open.c:522)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4011417: _dl_open (dl-open.c:605)
==10728== by 0x4F97013: dlopen_doit (dlopen.c:66)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4F48837: _dl_catch_error (dl-error-skeleton.c:215)
==10728== by 0x4F9877F: _dlerror_run (dlerror.c:162)
==10728== by 0x4F970E7: dlopen@@GLIBC_2.17 (dlopen.c:87)
==10728== by 0x160A5CF7: v4l2_plugin_init (v4l2-plugin.c:76)
==10728== by 0x1609E9B7: v4l2_fd_open (libv4l2.c:665)
==10728== by 0xA39F477: gst_v4l2_open (v4l2_calls.c:574)
==10728== by 0xA38EA7B: gst_v4l2_object_open (gstv4l2object.c:973)
==10728== by 0xA36F443: gst_v4l2_video_dec_open (gstv4l2videodec.c:613)
==10728== by 0x48E410B: gst_video_decoder_change_state (gstvideodecoder.c:2486)
==10728== by 0xA3736BB: gst_v4l2_video_dec_change_state (gstv4l2videodec.c:1956)
==10728== by 0x4998F2F: gst_element_change_state (gstelement.c:2952)
==10728==
==10728== 56 bytes in 1 blocks are definitely lost in loss record 4,567 of 7,507
==10728== at 0x48479F0: operator new(unsigned long) (vg_replace_malloc.c:434)
==10728== by 0x2689F857: ???
==10728== by 0x400DA33: call_init.part.0 (dl-init.c:72)
==10728== by 0x400DB37: call_init (dl-init.c:118)
==10728== by 0x400DB37: _dl_init (dl-init.c:119)
==10728== by 0x4011CD7: dl_open_worker (dl-open.c:522)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4011417: _dl_open (dl-open.c:605)
==10728== by 0x4F97013: dlopen_doit (dlopen.c:66)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4F48837: _dl_catch_error (dl-error-skeleton.c:215)
==10728== by 0x4F9877F: _dlerror_run (dlerror.c:162)
==10728== by 0x4F970E7: dlopen@@GLIBC_2.17 (dlopen.c:87)
==10728== by 0x160A5CF7: v4l2_plugin_init (v4l2-plugin.c:76)
==10728== by 0x1609E9B7: v4l2_fd_open (libv4l2.c:665)
==10728== by 0xA39F477: gst_v4l2_open (v4l2_calls.c:574)
==10728== by 0xA38EA7B: gst_v4l2_object_open (gstv4l2object.c:973)
==10728== by 0xA36F443: gst_v4l2_video_dec_open (gstv4l2videodec.c:613)
==10728== by 0x48E410B: gst_video_decoder_change_state (gstvideodecoder.c:2486)
==10728== by 0xA3736BB: gst_v4l2_video_dec_change_state (gstv4l2videodec.c:1956)
==10728== by 0x4998F2F: gst_element_change_state (gstelement.c:2952)
==10728==
==10728== 56 bytes in 1 blocks are definitely lost in loss record 4,568 of 7,507
==10728== at 0x48479F0: operator new(unsigned long) (vg_replace_malloc.c:434)
==10728== by 0x268A681F: ???
==10728== by 0x400DA33: call_init.part.0 (dl-init.c:72)
==10728== by 0x400DB37: call_init (dl-init.c:118)
==10728== by 0x400DB37: _dl_init (dl-init.c:119)
==10728== by 0x4011CD7: dl_open_worker (dl-open.c:522)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4011417: _dl_open (dl-open.c:605)
==10728== by 0x4F97013: dlopen_doit (dlopen.c:66)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4F48837: _dl_catch_error (dl-error-skeleton.c:215)
==10728== by 0x4F9877F: _dlerror_run (dlerror.c:162)
==10728== by 0x4F970E7: dlopen@@GLIBC_2.17 (dlopen.c:87)
==10728== by 0x160A5CF7: v4l2_plugin_init (v4l2-plugin.c:76)
==10728== by 0x1609E9B7: v4l2_fd_open (libv4l2.c:665)
==10728== by 0xA39F477: gst_v4l2_open (v4l2_calls.c:574)
==10728== by 0xA38EA7B: gst_v4l2_object_open (gstv4l2object.c:973)
==10728== by 0xA36F443: gst_v4l2_video_dec_open (gstv4l2videodec.c:613)
==10728== by 0x48E410B: gst_video_decoder_change_state (gstvideodecoder.c:2486)
==10728== by 0xA3736BB: gst_v4l2_video_dec_change_state (gstv4l2videodec.c:1956)
==10728== by 0x4998F2F: gst_element_change_state (gstelement.c:2952)
==10728==
==10728== 56 bytes in 1 blocks are definitely lost in loss record 4,569 of 7,507
==10728== at 0x48479F0: operator new(unsigned long) (vg_replace_malloc.c:434)
==10728== by 0x268A6837: ???
==10728== by 0x400DA33: call_init.part.0 (dl-init.c:72)
==10728== by 0x400DB37: call_init (dl-init.c:118)
==10728== by 0x400DB37: _dl_init (dl-init.c:119)
==10728== by 0x4011CD7: dl_open_worker (dl-open.c:522)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4011417: _dl_open (dl-open.c:605)
==10728== by 0x4F97013: dlopen_doit (dlopen.c:66)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4F48837: _dl_catch_error (dl-error-skeleton.c:215)
==10728== by 0x4F9877F: _dlerror_run (dlerror.c:162)
==10728== by 0x4F970E7: dlopen@@GLIBC_2.17 (dlopen.c:87)
==10728== by 0x160A5CF7: v4l2_plugin_init (v4l2-plugin.c:76)
==10728== by 0x1609E9B7: v4l2_fd_open (libv4l2.c:665)
==10728== by 0xA39F477: gst_v4l2_open (v4l2_calls.c:574)
==10728== by 0xA38EA7B: gst_v4l2_object_open (gstv4l2object.c:973)
==10728== by 0xA36F443: gst_v4l2_video_dec_open (gstv4l2videodec.c:613)
==10728== by 0x48E410B: gst_video_decoder_change_state (gstvideodecoder.c:2486)
==10728== by 0xA3736BB: gst_v4l2_video_dec_change_state (gstv4l2videodec.c:1956)
==10728== by 0x4998F2F: gst_element_change_state (gstelement.c:2952)

==10728== 136 (56 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 6,987 of 7,507
==10728== at 0x48479F0: operator new(unsigned long) (vg_replace_malloc.c:434)
==10728== by 0x26892973: ???
==10728== by 0x400DA33: call_init.part.0 (dl-init.c:72)
==10728== by 0x400DB37: call_init (dl-init.c:118)
==10728== by 0x400DB37: _dl_init (dl-init.c:119)
==10728== by 0x4011CD7: dl_open_worker (dl-open.c:522)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4011417: _dl_open (dl-open.c:605)
==10728== by 0x4F97013: dlopen_doit (dlopen.c:66)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4F48837: _dl_catch_error (dl-error-skeleton.c:215)
==10728== by 0x4F9877F: _dlerror_run (dlerror.c:162)
==10728== by 0x4F970E7: dlopen@@GLIBC_2.17 (dlopen.c:87)
==10728== by 0x160A5CF7: v4l2_plugin_init (v4l2-plugin.c:76)
==10728== by 0x1609E9B7: v4l2_fd_open (libv4l2.c:665)
==10728== by 0xA39F477: gst_v4l2_open (v4l2_calls.c:574)
==10728== by 0xA38EA7B: gst_v4l2_object_open (gstv4l2object.c:973)
==10728== by 0xA36F443: gst_v4l2_video_dec_open (gstv4l2videodec.c:613)
==10728== by 0x48E410B: gst_video_decoder_change_state (gstvideodecoder.c:2486)
==10728== by 0xA3736BB: gst_v4l2_video_dec_change_state (gstv4l2videodec.c:1956)
==10728== by 0x4998F2F: gst_element_change_state (gstelement.c:2952)

==10728== 136 bytes in 1 blocks are definitely lost in loss record 6,988 of 7,507
==10728== at 0x48479F0: operator new(unsigned long) (vg_replace_malloc.c:434)
==10728== by 0x268C843B: ???
==10728== by 0x400DA33: call_init.part.0 (dl-init.c:72)
==10728== by 0x400DB37: call_init (dl-init.c:118)
==10728== by 0x400DB37: _dl_init (dl-init.c:119)
==10728== by 0x4011CD7: dl_open_worker (dl-open.c:522)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4011417: _dl_open (dl-open.c:605)
==10728== by 0x4F97013: dlopen_doit (dlopen.c:66)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4F48837: _dl_catch_error (dl-error-skeleton.c:215)
==10728== by 0x4F9877F: _dlerror_run (dlerror.c:162)
==10728== by 0x4F970E7: dlopen@@GLIBC_2.17 (dlopen.c:87)
==10728== by 0x160A5CF7: v4l2_plugin_init (v4l2-plugin.c:76)
==10728== by 0x1609E9B7: v4l2_fd_open (libv4l2.c:665)
==10728== by 0xA39F477: gst_v4l2_open (v4l2_calls.c:574)
==10728== by 0xA38EA7B: gst_v4l2_object_open (gstv4l2object.c:973)
==10728== by 0xA36F443: gst_v4l2_video_dec_open (gstv4l2videodec.c:613)
==10728== by 0x48E410B: gst_video_decoder_change_state (gstvideodecoder.c:2486)
==10728== by 0xA3736BB: gst_v4l2_video_dec_change_state (gstv4l2videodec.c:1956)
==10728== by 0x4998F2F: gst_element_change_state (gstelement.c:2952)
==10728==
==10728== 137 (72 direct, 65 indirect) bytes in 1 blocks are definitely lost in loss record 6,989 of 7,507
==10728== at 0x484C230: calloc (vg_replace_malloc.c:1340)
==10728== by 0x2DC202F7: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libGLX_nvidia.so.0)
==10728== by 0x2DC1919F: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libGLX_nvidia.so.0)
==10728== by 0x2DB9FE4F: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libGLX_nvidia.so.0)
==10728== by 0x400D9E7: call_init.part.0 (dl-init.c:58)
==10728== by 0x400DB37: call_init (dl-init.c:118)
==10728== by 0x400DB37: _dl_init (dl-init.c:119)
==10728== by 0x4011CD7: dl_open_worker (dl-open.c:522)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4011417: _dl_open (dl-open.c:605)
==10728== by 0x4F97013: dlopen_doit (dlopen.c:66)
==10728== by 0x4F48793: _dl_catch_exception (dl-error-skeleton.c:196)
==10728== by 0x4F48837: _dl_catch_error (dl-error-skeleton.c:215)
==10728== by 0x4F9877F: _dlerror_run (dlerror.c:162)
==10728== by 0x4F970E7: dlopen@@GLIBC_2.17 (dlopen.c:87)
==10728== by 0x24BD36E3: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libcuda.so.1.1)
==10728== by 0x24BD38E3: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libcuda.so.1.1)
==10728== by 0x24B4CD2B: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libcuda.so.1.1)
==10728== by 0x24C7B95B: cuGraphicsGLRegisterImage (in /usr/lib/aarch64-linux-gnu/tegra/libcuda.so.1.1)
==10728== by 0xA3E72E7: gst_nv_video_renderer_gl_cuda_init (renderer_gl.c:747)
==10728== by 0xA3E515F: gst_nv_video_renderer_cuda_init (renderer.c:84)

Hi,
It is not easy to identify what the issue is from the prints. What is the failure you hit in the case? Do you trigger OOM killer and the process is killed?

I just invoked the valgrind and it is the stack trace to the memory leak. You just need to use that tool. That’s it.

rgb-sig_cf239d59-26b3-4557-9a4a-6738028cd1b8.png

Hi,
We try the command for overweekend and it can pass:

$ /usr/bin/nvgstplayer-1.0 --uri rtsp://10.19.107.92:8554/test --window-x=0 --window-y=0 --window-width=1920 --window-height=1080 --svs="fakesink" --loop-forever

The RTSP server is launched by running test-launch, following steps in Jetson Nano FAQ

No significant leak is obsered:

[2+ hours]
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
10739 nvidia    20   0 29.108g 304428  46412 S  12.8  1.1  10:40.63 nvgstplaye+

[over weekend]
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
10739 nvidia    20   0 29.107g 478628  46136 S  15.1  1.7 568:17.51 nvgstplaye+

I tried your command using the nvgstplayer-1.0 release from public_source.tgz that you had provided for r32.7.2. I installed jetpack 4.6.2, and then upgraded it to 32.7.3.My rtsp source is wowza stream that plays a short movie clip and generates End Of Stream, and compels the nvgstplayer to reconnect and this continues in loop-forever mode. The memory consumptions keeps increasing for every loop playback. I cannot keep repeating myself again and again. Your source is a video test pattern generator which is alive all the time, and is not the case I am looking. Kindly try to understand the problem I am trying to explain. This is really frustrating. Do we have access to the libv4l2_nvvideocodec.so source? I would like to take a look at it and put some traces to get to the bottom of it.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8028 rgb 20 0 2298636 158180 44328 S 53.9 2.2 23:24.87 nvgstplayer-1.0

After hour of playback:

8028 rgb 20 0 2298636 158180 44328 S 53.9 3.9 24:24.87 nvgstplayer-1.0

Hi,
libv4l2_nvvideocodec.so is delivered in prebuilt lib and not open source. The low level samples are in

/usr/src/jetson_multimedia_api

And the lower software stacks are prebuilt libs.

Thanks, I will take a look. To easily reproduce in your set up, u need to stop the rtsp source and restart after say 30 - 50 secs, and let nvgstplayer keep trying and eventually reconnect, u will start seeing memory % going up for every restart.

rgb-sig_cf239d59-26b3-4557-9a4a-6738028cd1b8.png

I have the exact test setup as yours. The RTSP server is launched by running test-launch , following steps in Jetson Nano FAQ
Now i exit the test-launch and restart. The nvgstplayer reconnects the test-launch server whenever its back online, Everytime i do this sequence, memory consumption by nvgstplayer-1.0 keeps increasing. Here is the log on the jetson nano

./nvgstplayer-1.0 --uri rtsp://192.168.71.80:8554/test --window-x=0 --window-y=0 --window-width=1920 --window-height=1080 --svs=“fakesink” --loop-forever
At the start
27262 rgb 20 0 1287340 50864 23344 S 21.6 1.3 0:03.84 nvgstplayer-1.0

After restarting test-launch 4 times

Error by /GstPipeline:player/GstRTSPSrc:rtspsrc6: Could not open resource for reading and writing.
debug info:
gstrtspsrc.c(7469): gst_rtspsrc_retrieve_sdp (): /GstPipeline:player/GstRTSPSrc:rtspsrc6:
Failed to connect. (Generic error)
Error by /GstPipeline:player/GstRTSPSrc:rtspsrc7: Could not open resource for reading and writing.
debug info:
gstrtspsrc.c(7469): gst_rtspsrc_retrieve_sdp (): /GstPipeline:player/GstRTSPSrc:rtspsrc7:
Failed to connect. (Generic error)
Opening in BLOCKING MODE
NvMMLiteOpen : Block : BlockType = 261
NVMEDIA: Reading vendor.tegra.display-size : status: 6
NvMMLiteBlockCreate : Block : BlockType = 261

27262 rgb 20 0 1343912 60488 23616 S 22.3 1.5 0:45.46 nvgstplayer-1.0

After restarting test-launch 5th time

27262 rgb 20 0 1343912 77476 23616 S 25.2 1.9 0:59.36 nvgstplayer-1.0

After about 5 restart of test-launch
27262 rgb 20 0 1343912 81236 23948 S 28.5 2.0 1:26.99 nvgstplayer-1.0

After about 3 restart of test-launch
27262 rgb 20 0 1343912 98520 23948 S 21.6 2.4 1:51.04 nvgstplayer-1.0

After about 7 restarts of test-launch
27262 rgb 20 0 1343912 107344 24276 S 24.7 2.6 2:20.68 nvgstplayer-1.0

After about 2 restarts of test-launch

27262 rgb 20 0 1343912 116600 23948 S 24.7 2.9 3:03.38 nvgstplayer-1.0

Hi,
This looks to be an error condition and we would suggest re-launch the decoding pipeline in the error case. Please check if you can detect the case that RTSP source is not stable, and then destroy the current pipeline and re-launch it.

In the normal case that EoS is sent to terminate the pipeline, it should work fine.

This output comes from your factory default nvgstplayer app when it tries to reconnect the rtsp source. I just showed you how to reproduce the issue using the factory default jetson nano. I think there is no motivation on your end to support the used case I am having problems with. I cannot waste anymore time with u guys. This is really pathetic.

rgb-sig_cf239d59-26b3-4557-9a4a-6738028cd1b8.png