Gstreamer prerecording pipeline locks up CPU

Autonomous Machines Jetson & Embedded Systems Jetson Nano
1

For a prerecording* pipeline I’m using gst-python with the following setup (input is 1080i@30):

v4l2src device=/dev/video0 ! identity drop-allocation=true ! queue leaky=2 max-size-buffers=150 max-size-bytes=0 max-size-time=0 ! nvvidconv ! nvv4l2h264enc ! h264parse ! qtmux ! filesink=output.mp4

I then put a blocking probe on the queue’s src pad, to be removed when a file should be written.

This type of pipeline works fine on my main machine (using a different encoder etc. of course). Unfortunately however, this setup completely locks up one of the CPU cores of the Jetson Nano, resulting in different kinds of warnings (‘hardlock detected’ etc.). When I remove the blocking probe, all is fine though. What is causing this? I would think the queue can operate quite efficiently.

Thanks!

  • With prerecording I mean having a buffer of last ‘x’ seconds of video and write it to file on demand.

EDIT: The v4l2src is an Elgato Cam Link 4K
EDIT2: I should add that the CPU locks up before the queue blocking probe is removed.

2

Hi,
nvvidconv and nvv4l2h264enc plugins do not support interlace inputs. Can you try to run the source in progressive mode?

3

I’ve tried, but it doesn’t seem to make a difference. I should add that the CPU locks up before I even remove the probe, so no buffers have been sent to the converter or encoder yet.

4

Hi,
We don’t observe any issue in running

$ gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=150 ! video/x-raw,format=UYVY,width=3840,height=2160,framerate=15/1 ! nvvidconv ! 'video/x-raw(memory:NVMM),format=NV12' ! nvv4l2h264enc ! h264parse ! qtmux ! filesink location=a.mp4

The USB camera is e-con See3CAM CU135. Can you try other USB cameras?