Multiple nvv4l2decoder gstreamer pipelines slow down when in the same process

[merwin]

This problem started happening with the 32.6.1 release. It was ok with 32.5.

If I run the following 2 gstreamer pipelines at the same time as separate processes they both run at 60 fps each:
$ gst-launch-1.0 -v videotestsrc ! video/x-raw,framerate=60/1 ! nvvidconv ! nvv4l2h264enc ! nvv4l2decoder ! fpsdisplaysink video-sink=nv3dsink &
$ gst-launch-1.0 -v videotestsrc ! video/x-raw,framerate=60/1 ! nvvidconv ! nvv4l2h264enc ! nvv4l2decoder ! fpsdisplaysink video-sink=nv3dsink &

If I run both in the same process they only run at about 30 fps each:
gst-launch-1.0 -v videotestsrc ! video/x-raw,framerate=60/1 ! nvvidconv ! nvv4l2h264enc ! tee name=t t. ! nvv4l2decoder ! fpsdisplaysink video-sink=nv3dsink t. ! nvv4l2decoder ! fpsdisplaysink video-sink=nv3dsink

This problem is similar to Multiple gstreamer pipelines slow down when in the same process (which was fixed) but with the decoder causing the slowdown instead of the sink.

[DaneLLL]

Hi,
On r32.6.1, this is an expected behavior. For this this-case, we would suggest use nvcompositor plugin to composite the sources into video plane and then render out. So that you can use one nv3dsink.

[merwin]

We would need an extensive re-architecture of our software to be able to use the nvcompositor since each pipeline is completely separate even though they are in the same process.

Everything was working well in R32.5. It appears that R32.6.1 introduced this bug.

[DaneLLL]

Hi,
We see side effect that CPU usage is higher in certain cases on r32.5, and there is modification in later releases. If you prefer not to modify the application, may consider stay on r32.5

[merwin]

We are currently reverted back to r32.5 but now have other decoder issues that were fixed in r32.7.1 that we are trying to work around.