GStreamer MPEG decoder segmentation fault with fractional framerate

I’m using the patched gst-jpeg from nvjpegdec slower then jpegdec in gstreamer with nvjpegdec. However, setting framerate to 400000/1997 fails with a segfault. Using a more typical framerate like 200/1 or 30/1 works fine. Note that 400000/1997 (or just over 200fps) is the actual framerate of the camera that generated my source file.

Using fakesink instead of the decoder works fine. Omitting (memory:NVMM) has no effect, i.e. also segfaults.

Can anyone help?

$ gst-launch-1.0 filesrc location=src.mjpeg ! image/jpeg,framerate=400000/1997,width=192,height=192 ! nvjpegdec ! 'video/x-raw(memory:NVMM),format=I420' ! fakesink -ve
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
/GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = image/jpeg, width=(int)192, height=(int)192, framerate=(fraction)400000/1997
/GstPipeline:pipeline0/GstNvJpegDec:nvjpegdec0.GstPad:sink: caps = image/jpeg, width=(int)192, height=(int)192, framerate=(fraction)400000/1997
#0  0x0000007f8f9ff048 in __GI___poll (fds=0x556b5cd3e0, nfds=547871572536, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:41
#1  0x0000007f8fb0be08 in  () at /usr/lib/aarch64-linux-gnu/
#2  0x000000556b3f42f0 in  ()
Spinning.  Please run 'gdb gst-launch-1.0 32383' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

You may revert the patch and check if the issue is present. Since get-jpeg is open source, you should be able to debug further via gdb
Other users may also share experience.

@DaneLLL The issue is still present with nvjpegdec after reverting everything. There is no issue with jpegdec.

Can you help? Happy to send you my source file in case you can’t produce.

I’m not syncing the pipeline, so the frame rate is just a number. Thus, I’m guessing this could be a trivial bug in gst-nvjpeg.

Please try nvv4l2decoder mjpeg=1. For mjpeg file source, we would suggest use this element. JPEGs compressed from I420 are supported in nvv4l2decoder.

Most USB cameras output JPEGs compressed from YUV422(UYVY, YUYV, …). In this case we would suggest use nvjpegdec.

Or please add jpegparse and try again.

$ gst-launch-1.0 filesrc location= sample_720p.mjpeg ! image/jpeg,framerate=30000/1001 ! jpegparse ! nvjpegdec ! video/x-raw ! fakesink

Thank you for your suggestions, @DaneLLL. They both work.

However, they raise some more questions. Perhaps I should explain what I’m trying to achieve.

The above 200fps MJPEG stream is from an IR camera. I’m ultimately testing whether the Nano will be able to transcode two such streams from the left and right cameras. These are greyscale, so YUV order and chroma subsampling probably don’t matter.

I understand my current options are:

  1. jpegparse ! nvjpegdec ! 'video/x-raw': Performance is pretty good (~2400fps). However, it drops significantly (to ~950fps) on adding nvv4l2h264enc, presumably due to the raw frames being copied in and out of NVMM.
  2. nvv4l2decoder mjpeg=1 ! 'video/x-raw(memory:NVMM)': Performance is OK (~1800fps) but drops to an unacceptable 120fps on adding H.264 as follows: nvv4l2decoder mjpeg=1 ! 'video/x-raw(memory:NVMM)' ! nvvidconv ! nvv4l2h264enc bitrate=200000.
  3. Patched nvjpegdec to NVMM with jpegparse. Not tested yet.

With the revised focus on greyscale JPEG, what would you advise? While option #1 sounds best I’m still a little worried about the unnecessary copying as the Nano will have other things to do, so I want to maximise DMA use. Option #2 is way too slow, not sure why. Option #3 will probably perform best but I’m concerned about maintainability as in its current form it re-links libraries from several apt packages.

Finally, can you assure me you’re treating the SIGSEGV as a bug? I’d hate to have segmentation faults in production due to something as banal as a frame rate setting.

The hardware JPEG decoder does not support GREY. Please refer to

Be default, dynamic frequency scaling is enabled in nvv4l2h264enc for better power number. Please enable maxperf-enable and try.

  maxperf-enable      : Enable or Disable Max Performance mode
                        flags: readable, writable, changeable only in NULL or READY state
                        Boolean. Default: false

The segment fault looks minor. We think it is reasonable to have jpegparse in the pipeline. Probably certain issue in gst-jpeg code, not in low level code doing JPEG decoding. You may check the source code and investigate further, the solution of linking jpegparse looks fine though.