Thread-safety of NVIDIA's hardware-accelerated GStreamer elements.

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

Given that NVIDIA’s hardware-accelerated GStreamer elements use NVMM, is it safe to interleave them with GStreamer queues (such that the elements run in separate threads)?

For instance, is this thread-safe?

gst-launch-1.0 filesrc location=some_mjpeg_video.mkv ! nvjpegdec ! 'video/x-raw(memory:NVMM), format=I420' ! queue ! nvvidconv ! 'video/x-raw, format=I420' ! videoconverter ! 'video/x-raw, format=RGBx' ! xvimagesink

My worry is what happens between nvjpegdec and nvvidconv. Since they are using NVMM, the actual image data decoded from nvjpegdec is not in the ordinary GstBuffer. Does nvjpegdec ensure to allocate new blocks using NVMM, which are released only after nvvidconv is done using them, so that I don’t risk getting torn frames because of multithreading between nvjpegdec and nvvidconv? I’m worried that nvjpegdec just keeps writing to the same blocks and nvvidconv could read torn frames because it’s running in a separate thread.

2

Hi,
If you observe the issue, please raise it up and share the pipeline. We develop NVIDIA plugins based on gstreamer frameworks and both keep moving forward to having new SW release. It is difficult to ensure absolutely bug-free. We don’t actively look into source code of gstreamer, but if you catch issues, please feel free to report it and let’s work out a solution. Thanks.