Using nvv4l2h264enc encoder memory increases when releasing pipeline and setting up a new one

Hi,
You may also try omxh264enc.

I forgot to mention, but I tried omxh264enc also prior to post this request.

It behaves the same from the memory perspective and starts the misbehavior during the same iteration (122) of the test (the exact same way). The only difference is that it does not hang, so the NvRmChannelSubmit error keeps repeating and memory consomption keeps building up until the oom-killer kicks in.

Hi,
We have tried simple pipeline launch and do not observe the issue:
https://devtalk.nvidia.com/default/topic/1026106/jetson-tx1/usage-of-nvbuffer-apis/post/5219225/#5219225

Please check if you miss to unref certain objects in your sample.

I tested using the simple pipeline launch sample code you suggested (modifying the pipeline description…) and reproduced the problem in there as well (it takes about 246 iterations).

Further investigations revealed that the leak occurs when using the nvvidconv element.
The leak involves memory and also shows up as one dmabuf not released each time the pipeline is setup and tear down.

I also understood that there is no way to avoid using this converter when using the appsrc to feed the nvv4l2h264enc or feeding the appsink from the nvv4l2decoder.

Using omxh264enc/omxh264dec does not require to use the nvvidconv, but therefore using videoconvert instead ends up obviously to load the CPU.

I confirm there is no unref missing in my sample, by code inspection for one thing, but also using GST_TRACERS=“leaks” GST_DEBUG=“GST_TRACER:7” when executing the sample code.

Hi,
Please share the modified cpp so that we can build/run to reproduce the issue.

Here it is.

Running this sample code, the memory usage of my device goes from 3.9 to 10 Gb, and hangs during LOOP iteration #124.
TestNvidiaSampleMain.cpp (4.6 KB)

Hi,
Thank you. We will try to reproduce the issue.

Hi,
We can reproduce the issue and are checking further. Will update once there is new finding. Thanks.

Hi,
We have fixed a leak in running:

video/x-raw,format=RGBA ! nvvidconv ! 'video/x-raw(memory:NVMM),format=I420'

Please try the attachment on r32.2.x.
r32_2_x_TEST_libgstnvvidconv.zip (22.8 KB)

Hello, is this fix rolled into Jetpack 4.3?

Hi,
It does not catch Jetpack4.3(r32.3.1). We will provide a prebuilt lib for r32.3.1.

Hi,
For Jetpack4.3(r32.3.1), please use the attachment.
r32_3_libgstnvvidconv.zip (23.1 KB)

Will this be made available in the new Jetson package repo?

Hi,
It will be in next r32.4. Since r32.3.1 is just released, there may be an interval of few months.

video/x-raw,format=RGBA ! nvvidconv ! 'video/x-raw(memory:NVMM),format=I420'

Is this the only use case that was fixed and tested? We don’t use RGBA in our pipeline but we do use the nvvidconv and nvv4l2h264enc elements. Is it worth replacing our .so with the new .so if we don’t use RGBA?

Hi,
The fix is for all video/x-raw -> video/x-raw(memory:NVMM) conversion.

Hi,

I’m experiencing similar issues for conversion from “video/x-raw(memory:NVMM),format=I420” to “video/x-raw,format=RGBA” after decoding using nvv4l2decoder. I have errors like these ones when using “nvvideoconvert”:

NvRmPrivFlush: NvRmChannelSubmit failed (err = 196623, SyncPointIdx = 22, SyncPointValue = 0)

and errors like these ones when using “nvvidconv” (with the patch available here applied):

NvRmPrivFlush: NvRmChannelSubmit failed (err = 196623, SyncPointIdx = 12,

is there a patch for this too? thanks

Hi,
Please start a new post and share steps to reproduce the issue. Would like to keep this for nvvidconv for clearness. Thanks.

Done:

thanks

Is this fix applied in 32.4 ?
Or will you provide patch for this version ?