SIGSEGV when running streaming via RTMP to Youtube

[Fredde]

Running test on streaming camera stream via RTMP to Youtube. Randomly it stops with SIGSEGV.

CONTROL_RATE=0
BITRATE_MIN=20000000
BITRATE_MAX=40000000

gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=4 tnr-mode=1 tnr-strength=1 aeantibanding=2 wbmode=3 ! ‘video/x-raw(memory:NVMM), width=3856, height=1608, framerate=60/1, format=NV12’ ! nvv4l2h264enc iframeinterval=60 control-rate=$CONTROL_RATE MeasureEncoderLatency=true profile=4 preset-level=2 maxperf-enable=true bitrate=$BITRATE_MIN peak-bitrate=$BITRATE_MAX idrinterval=60 insert-sps-pps=1 ! h264parse config-interval=1 ! flvmux name=mux streamable=true ! rtmpsink location=“rtmp://a.rtmp.youtube.com/live2/my-secret-key” audiotestsrc ! mux.

Error message

Caught SIGSEGV
#0 0x0000007f968bae28 in __GI___poll (fds=0x55af08a470, nfds=547987685944, timeout=) at …/sysdeps/unix/sysv/linux/poll.c:41
#1 0x0000007f969c7e08 in () at /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#2 0x00000055aefd5b30 in ()
Spinning. Please run ‘gdb gst-launch-1.0 15951’ to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.

nvargus-daemon have to be restared to get it going again

[DaneLLL]

Hi,
Please breakdown the pipeline to get more information:

gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=4 tnr-mode=1 tnr-strength=1 aeantibanding=2 wbmode=3 ! ‘video/x-raw(memory:NVMM), width=3856, height=1608, framerate=60/1, format=NV12’ ! fakesink

gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 sensor-mode=4 tnr-mode=1 tnr-strength=1 aeantibanding=2 wbmode=3 ! ‘video/x-raw(memory:NVMM), width=3856, height=1608, framerate=60/1, format=NV12’ ! nvv4l2h264enc iframeinterval=60 control-rate=$CONTROL_RATE MeasureEncoderLatency=true profile=4 preset-level=2 maxperf-enable=true bitrate=$BITRATE_MIN peak-bitrate=$BITRATE_MAX idrinterval=60 insert-sps-pps=1 ! h264parse config-interval=1 ! flvmux name=mux streamable=true ! fakesink

Check if we can catch which plugin triggers the segment fault.

[Fredde]

The second pipeline is the one triggering the segment fault

[Fredde]

I have set the VIC performance to “full throttle”

Nvvideoconvert issue, nvvideoconvert in DS4 is better than Ds5?

|•|Hardware Platform Jetson AGX Xavier| |•|DeepStream Version 4.0 And 5.0| |•|JetPack Version 4.2 and 4.4 DP| |•|TensorRT Version 5.0 and 7.1| Hello guys, during my tests I noticed that: executing the following pipeline I get different results using DS4 or DS5 Pipeline: DS5 gst-launch-1.0 filesrc location = /opt/nvidia/deepstream/deepstream-5.0/samples/streams/sample_1080p_h264.mp4 ! qtdemux ! h264parse ! nvv4l2decoder ! nvvideoconvert ! video/x-raw,format=RGBA ! fakesink DS4 gst-launc…

[DaneLLL]

Hi,
We try to run the command with Rasp Pi camera v2 and don’t hit segment fault:

$ gst-launch-1.0 -v nvarguscamerasrc sensor-id=0 tnr-mode=1 tnr-strength=1 aeantibanding=2 wbmode=3 num-buffers=300 ! 'video/x-raw(memory:NVMM), width=3264, height=2464, framerate=21/1, format=NV12' ! nvv4l2h264enc iframeinterval=60 control-rate=0 MeasureEncoderLatency=true profile=4 preset-level=2 maxperf-enable=true bitrate=20000000 peak-bitrate=40000000 idrinterval=60 insert-sps-pps=1 ! h264parse config-interval=1 ! flvmux name=mux streamable=true ! fakesink

The maximum resolution of the sensor is 3264x2464p21. Does your sensor support other modes? If yes, please try other sensor modes. See if it is specific to 3856x1608p60.

[Fredde]

I’m using the Raspberry PI HQ Camera with custom mode. Will try to reproduce with other/standard modes

[Fredde]

I have reproduced the error with standard modes,2 cameras with 1920x1080@60fps, Raspberry PI HQ Cameras

##!/bin/sh

NVARGUS_PARAM='tnr-mode=1 tnr-strength=0.2 aeantibanding=2 wbmode=3 ’

Youtube key for fixed streaming

KEY_FIXED=my-youtube-key

bitrate for transmission bits/s, CONTROL_RATE, 1 = constant rate, 0x = variable rate

CONTROL_RATE=0
BITRATE_MIN=40000000
BITRATE_MAX=60000000

gst-launch-1.0 -ev nvarguscamerasrc sensor-id=0 $NVARGUS_PARAM ! ‘video/x-raw(memory:NVMM), format=NV12, width=1920, height=1080, framerate=60/1’ ! nvvidconv ! comp1.sink_0 nvarguscamerasrc sensor-id=1 $NVARGUS_PARAM ! ‘video/x-raw(memory:NVMM), format=NV12, width=1920, height=1080, framerate=60/1’ ! nvvidconv ! comp1.sink_1 nvcompositor name=comp1 sink_0::xpos=0 sink_0::ypos=0 sink_1::xpos=1920 sink_1::ypos=0 sink_0::width=1920 sink_0::height=1080 sink_1::width=1920 sink_1::height=1080 ! ‘video/x-raw(memory:NVMM), width=3840, height=1080’ ! nvvidconv ! nvv4l2h264enc iframeinterval=60 control-rate=$CONTROL_RATE profile=4 preset-level=2 MeasureEncoderLatency=true maxperf-enable=true bitrate=$BITRATE_MIN peak-bitrate=$BITRATE_MAX ! h264parse ! flvmux name=mux1 ! rtmpsink location=“rtmp://a.rtmp.youtube.com/live2/$KEY_FIXED” audiotestsrc ! mux1.

[Fredde]

Same error with a fakesink

##!/bin/sh

NVARGUS_PARAM='tnr-mode=1 tnr-strength=0.2 aeantibanding=2 wbmode=3 ’

Youtube key for fixed streaming

KEY_FIXED=

bitrate for transmission bits/s, CONTROL_RATE, 1 = constant rate, 0x = variable rate

CONTROL_RATE=0
BITRATE_MIN=40000000
BITRATE_MAX=60000000

gst-launch-1.0 -ev nvarguscamerasrc sensor-id=0 $NVARGUS_PARAM ! 'video/x-raw(memory:NVMM), format=NV12, width=1920, height=1080, framerate=60/1' ! nvvidconv ! comp1.sink_0 nvarguscamerasrc sensor-id=1 $NVARGUS_PARAM ! 'video/x-raw(memory:NVMM), format=NV12, width=1920, height=1080, framerate=60/1' ! nvvidconv ! comp1.sink_1  nvcompositor name=comp1 sink_0::xpos=0 sink_0::ypos=0 sink_1::xpos=1920 sink_1::ypos=0  sink_0::width=1920 sink_0::height=1080 sink_1::width=1920 sink_1::height=1080 ! 'video/x-raw(memory:NVMM), width=3840, height=1080' ! nvvidconv ! nvv4l2h264enc iframeinterval=60 control-rate=$CONTROL_RATE profile=4 preset-level=2 MeasureEncoderLatency=true maxperf-enable=true bitrate=$BITRATE_MIN peak-bitrate=$BITRATE_MAX ! h264parse ! flvmux name=mux1 ! fakesink

[DaneLLL]

Hi,
We don’t have the setting of two imx477s on Xavier NX, so we try two imx219s(Rasp Pi camera v2) and don’t hit segment fault. We tested the two pipelines:
[1080p30]

gst-launch-1.0 -ev nvarguscamerasrc sensor-id=0 $NVARGUS_PARAM ! 'video/x-raw(memory:NVMM), format=NV12, width=1920, height=1080, framerate=30/1' ! nvvidconv ! comp1.sink_0 nvarguscamerasrc sensor-id=1 $NVARGUS_PARAM ! 'video/x-raw(memory:NVMM), format=NV12, width=1920, height=1080, framerate=30/1' ! nvvidconv ! comp1.sink_1  nvcompositor name=comp1 sink_0::xpos=0 sink_0::ypos=0 sink_1::xpos=1920 sink_1::ypos=0  sink_0::width=1920 sink_0::height=1080 sink_1::width=1920 sink_1::height=1080 ! 'video/x-raw(memory:NVMM), width=3840, height=1080' ! nvvidconv ! nvv4l2h264enc iframeinterval=60 control-rate=$CONTROL_RATE profile=4 preset-level=2 MeasureEncoderLatency=true maxperf-enable=true bitrate=$BITRATE_MIN peak-bitrate=$BITRATE_MAX ! h264parse ! flvmux name=mux1 ! fakesink

[720p60]

gst-launch-1.0 -ev nvarguscamerasrc sensor-id=0 $NVARGUS_PARAM ! 'video/x-raw(memory:NVMM), format=NV12, width=1280, height=720, framerate=60/1' ! nvvidconv ! comp1.sink_0 nvarguscamerasrc sensor-id=1 $NVARGUS_PARAM ! 'video/x-raw(memory:NVMM), format=NV12, width=1280, height=720, framerate=60/1' ! nvvidconv ! comp1.sink_1  nvcompositor name=comp1 sink_0::xpos=0 sink_0::ypos=0 sink_1::xpos=1280 sink_1::ypos=0  sink_0::width=1280 sink_0::height=720 sink_1::width=1280 sink_1::height=720 ! 'video/x-raw(memory:NVMM), width=2560, height=720' ! nvvidconv ! nvv4l2h264enc iframeinterval=60 control-rate=$CONTROL_RATE profile=4 preset-level=2 MeasureEncoderLatency=true maxperf-enable=true bitrate=$BITRATE_MIN peak-bitrate=$BITRATE_MAX ! h264parse ! flvmux name=mux1 ! fakesink

imx219 does not support 1080p60, so we are not able to try the case. Seems like it might be specific to using imx477. Do you run this setting?
Raspberry Pi HQ camera IMX477 Driver | Linux driver for Jetson | RidgeRun

The default HQ camera module does not work on Xavier NX/Nano 4GB, so you should have the hardware modification and use the driver.

[Fredde]

Yes, I’m using the RidgeRun IMX477 driver/setup

If i run the argus_camera application with the same driver modes and side by side viewing. MultiSession. I never get any segmentation fault. Nor do I get any fault in your first break-down proposal.

So in my mind the problem seems to be ralated to the h264 encoding part, or performance/timing