GStreamer lockup with H.264 encoder from nvarguscamerasrc

Wow! That GStreamer pipeline is amazing. It launched 163 threads to do that pipeline on my system. However, I’m guessing there is only a single copy of the nvarguscamerasrc data to each of those tees that does the encode. So while this generates a lot of system activity, it may not be generating the right type of activity to cause the lockup. I will give this giant GStreamer pipeline a test also, but I would expect it could take 10+ hours to lockup just like my single instance testing.

Unfortunately, I don’t think a test on the old R28.2 release for only one hour with a single camera tells much. With a single camera you would need to run at least 48 hours to know if you have a race condition that results in a lockup. If you have more nvarguscamerasrc cameras that can be run simultaneously, you can shorten that time a bit.

Yes, I added sync=false when I did the localhost test as such:
gst-launch-1.0 -e nvarguscamerasrc sensor-id=$camera sensor-mode=0 ! 'video/x-raw(memory:NVMM),width=1920,height=1080,framerate=30/1' ! nvv4l2h264enc maxperf-enable=1 bitrate=4000000 insert-sps-pps=true ! rtph264pay mtu=1400 ! udpsink host=localhost port=$port sync=false async=false
This still had all six of the GStreamer instances lockup.

Yes, I think that with a single camera being replicated by SW I was unable to reproduce it, so probably this is related to something else. @DaneLLL told this was reproduced on NVIDIA side, so this is your main hope now.
For clarity, I haven’t tried with my old TX2, only with a Xavier NX.

I know this is a tough problem and takes a bit of time to reproduce and test changes, but I’m wondering if you have any update on the progress or estimated time for a solution?

Is there any additional information you need about my test setup or hardware?

Are there any experiments that you need me to run to collect more data or try to narrow down the problem?

We are still checking it. Will update once there is further progress. Thanks.

We should have it fixed in r32.5. Please give it a try.

Can you tell me the Bug Id/Issue # so I can review the source change and see the commit?

It is 200661319 listed in Release Notes.

Additional note: When using nv4l2h264enc, it may set profile and level as NULL. My guess is that some metadata holds the information. So if using nvarguscamerasrc, better H264 encode with: insert-vui=1.