GStreamer MJPEG to H.264 (memory:NVMM) segmentation fault

I’ve successfully followed the steps at nvjpegdec slower then jpegdec in gstreamer to add DMA support to JPEG decoding. gst-inspect-1.0 nvjpegdec shows NVMM support as expected. However, I’ve encountered two issues:

  1. I get a segmentation when trying to pair up nvjpegdec and omxh264enc:
$ gst-launch-1.0 filesrc location=src.mjpeg ! 'image/jpeg,framerate=200/1,width=192,height=192' ! nvjpegdec ! 'video/x-raw(memory:NVMM),format=I420' ! omxh264enc ! 'video/x-h264' ! 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)200/1
/GstPipeline:pipeline0/GstNvJpegDec:nvjpegdec0.GstPad:sink: caps = image/jpeg, width=(int)192, height=(int)192, framerate=(fraction)200/1
/GstPipeline:pipeline0/GstNvJpegDec:nvjpegdec0.GstPad:src: caps = video/x-raw(memory:NVMM), format=(string)I420, width=(int)192, height=(int)192, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)1:4:0:0, framerate=(fraction)200/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:src: caps = video/x-raw(memory:NVMM), format=(string)I420, width=(int)192, height=(int)192, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)1:4:0:0, framerate=(fraction)200/1
Framerate set to : 200 at NvxVideoEncoderSetParameterNvMMLiteOpen : Block : BlockType = 4
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
H264: Profile = 66, Level = 40
/GstPipeline:pipeline0/GstOMXH264Enc-omxh264enc:omxh264enc-omxh264enc0.GstPad:sink: caps = video/x-raw(memory:NVMM), format=(string)I420, width=(int)192, height=(int)192, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)1:4:0:0, framerate=(fraction)200/1
/GstPipeline:pipeline0/GstCapsFilter:capsfilter1.GstPad:sink: caps = video/x-raw(memory:NVMM), format=(string)I420, width=(int)192, height=(int)192, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)1:4:0:0, framerate=(fraction)200/1
NvMMLiteVideoEncDoWork: Surface resolution (0 x 0) smaller than encode resolution (192 x 192)
VENC: NvMMLiteVideoEncDoWork: 4231: BlockSide error 0x4
Event_BlockError from 0BlockAvcEnc : Error code - 4
Sending error event from 0BlockAvcEncERROR: from element /GstPipeline:pipeline0/GstOMXH264Enc-omxh264enc:omxh264enc-omxh264enc0: GStreamer encountered a general supporting library error.
Additional debug info:
/dvs/git/dirty/git-master_linux/3rdparty/gst/gst-omx/omx/gstomxvideoenc.c(1331): gst_omx_video_enc_loop (): /GstPipeline:pipeline0/GstOMXH264Enc-omxh264enc:omxh264enc-omxh264enc0:
OpenMAX component in error state Bad parameter (0x80001005)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Caught SIGSEGV
#0  0x0000007f9bd85ce4 in __waitpid (pid=<optimized out>, stat_loc=0x7ff220de54, options=<optimized out>) at ../sysdeps/unix/sysv/linux/waitpid.c:30
#1  0x0000007f9bdc12a0 in g_on_error_stack_trace ()
#2  0x0000005560735c3c in  ()
#3  0x00000055764ab0d0 in  ()
Spinning.  Please run 'gdb gst-launch-1.0 19936' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
  1. jpegdec has stopped working after patching, gst-inspect-1.0 jpegdec gives me Bus error (core dumped), same when I try to use it.

Sending to nvoverlaysink after decoding to NVMM works fine.

I’m on 32.3.1, Nano dev kit.

Dose this work (either adjust resolution/fps or try another mjpg file) ?

gst-launch-1.0 filesrc location=test.mjpg ! image/jpeg, width=1920, height=1080, framerate=30/1, format=MJPG ! nvjpegdec ! 'video/x-raw(memory:NVMM),format=I420,width=1920,height=1080,framerate=30/1' ! nvoverlaysink

Works for me without any patch on Xavier with R32.3.1.

Checked further and seen same fault with omxh264enc after nvjpegdec, but using nvv4l2h264enc works better:

gst-launch-1.0 -ev filesrc location=test.mjpg ! image/jpeg, width=1920, height=1080, framerate=30/1, format=MJPG ! nvjpegdec ! 'video/x-raw(memory:NVMM),format=I420,width=1920,height=1080,framerate=30/1' ! nvvidconv ! nvv4l2h264enc ! h264parse ! nvv4l2decoder ! nvvidconv ! xvimagesink
1 Like

Hi,
Please use nvv4l2h264enc as Honey Patouceul suggests.

Thanks, the V4L2-based plugin works.

I’m using the patched gst-jpeg as @DaneLLL recently suggested to me in Max fps MJPEG to H.264/5 transcoding. Should I not be doing that?

In general, how do I know when to use OMX/V4L2? The GStreamer guide gives no indication about this issue, both OMX and V4L2 plugins seem to be fully supported. Is there any way I can help fix the SIGSEGV as well as the issue with jpegdec not working? In particular, can you point me to the bug tracker?

Hi,
We are deprecating omx plugins. Please ue v4l2 plugins.

After applying the patch, I don’t observe segment fault in executing gst-inspect-1.0 jpegdec

Resolution 192x192 is small and not standard resolution like 640x480, 1920x1080. If you use 192x192 in the final usecase, you probably don’t need the patch since the memcpy of copying NVMM buffer to CPU buffer should be fast and can be ignored.

Thanks, I’ll use nvv4l2 plugins then.

192x192 @ 200fps is actually comparable to 640x480 at a normal frame rate, and I have two such streams, so I still care about DMA. I’m also still encountering the segmentation fault.

I’ve re-raised both issues with more context in separate topics: