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.