nvcompositor seems to leak at 50 fps

Hi,

I am combining multiple videostreams in nvcompositor and displaying in nvdrmvideosink.

… nvvidconv (NVMM) → nvcompositor → nvdrmvideosink

All is fine up to 30 fps per videostream and memory RSS is stable.

If I input a stream with framerate of eg. 50, visualization is still ok, but I got continously increasing RSS memory usage. It seems that somebody in the pipeline is not “freeing” correctly buffers.

I investigated all components in pipeline by ending pipeline with fakesink. Up to nvvidconv memory is stable. Once I activate compositor, memory is increasing.

Is it possible that nvcompositor does not handle correctly framerates higher than 30 fps?

ps. i am using latest compositor from : R32 (release), REVISION: 2.0,

By adding a queue and setting “leaky” != 0, memory leak is fixed.
But, this means that compositor is not able to handle more than x fps in time.
In fact it slows the pipeline down producing the undesired memory leak.

Can nvcompositor be configured to drop in some way frames and not introduce this undesired behaviour?

Thanks

Hi,
Please apply the prebuilt lib and try again.
https://elinux.org/L4T_Jetson/r32.2.1_patch
[GSTREAMER]High CPU loading in nvcompositor

Hi DaneeLLL,

thanks for suggestion, but my use case is not fixed with new compositor.
I am still not able to fix following scenario:

My pipeline is as follows:

video(h-264) > queue(1) > nvv4l2decoder > queue(2) > nvvidconv > |
video(h-264) > queue(1) > nvv4l2decoder > queue(2) > nvvidconv > |

video(h-264) > queue(1) > nvv4l2decoder > queue(2) > nvvidconv > |
video(h-264) > queue(1) > nvv4l2decoder > queue(2) > nvvidconv > | > nvcompositor > nvdrmvideosink

Having a grid of 2x2 in nvcompositor:

  • If I activate 4 streams @ 50fps, all is fine.
  • If I activate 2 streams @ 50fps (hence only 2 cells are feed with data), then queue(1) is growing continuesly by 20 frames every second. It seems that compositor is accepting only 30fps and slowing down pipeline? Putting fakesink instead of nvcompositor all is fine. Can you help me to understand how to fix this ?

Another problem/issue I have is to find out the limit of nvv4l2decoder + nvcompositor. Reading datasheet and docs (NVIDIA Tegra Linux Driver Package Development Guide) it is not quite clear. I cannot find correct limits in order to handle flow control.

Example:

  • Decoding 9 streams 2048x1536@40fps 5.5Mbps each in a grid 3x3 (50Mbps @ 360 fps total) works OK
  • Decoding 12 streams 2048x1536@40fps 5.5Mbps each in a grid 4x3 (66Mbps @ 480 fps total) does NOT work, queue(1) is growing. This happens also replacing nvcompositor with fakesink.

But datasheet tells that TX2 decoder (Pascal) can handle up to 658 fps and much higher Bitrates. So can you please help me understand the real capacity of decoder. Is it maybe related also to number of streams?

Thanks.

Hi,
nvvidconv and nvcompositor use same hardware engine. It is possible to hit performance limitation if you construct the pipeline with lots of the two plugins. Is it possible to eliminate some nvvidconv in the pipeline?

In nvv4l2decoder, there is a property:

enable-max-performance: Set to enable max performance
                    flags: readable, writable
                    Boolean. Default: false

Please configure it and check if there is improvement.

Hi,

thanks for suggestion, but unfortunately I need all configured nvvidconv in pipelines.
I already configuring system for max performance, so no improvment.

I will add flow control strategy in case of overrun scenario.

Regards

Hi,

Looks like our pipeline is also suffering from the same leaks you describe, using three inputs the first few frames out of the nvcompositor seem to be fine but after that there is significant slowdown and latency. Setting the leaky attribute to either 1 or 2 did not fix the problem, do you have any other suggestions?

Thanks for the help.

Hi itaidagan,
Please start a new post and share information about release version( head -1 /etc/nv_tegra_release ), steps of reproducing your issue.

Hi Dane, please see: https://devtalk.nvidia.com/default/topic/1071101/jetson-tx2/nvcompositor-lags-progressively-behind/