Hardware Accelerated Encoding with Gstreamer in CPP Fails with Segmentation Fault

Autonomous Machines Jetson & Embedded Systems Jetson Nano
,
1

I’ve recently switched from a raspberry pi 4 to the Jetson Nano, so I made what modifications needed to migrate the code over, but the pipeline on the pi ran as good as it could on the pi. The problem is that I’m running into segmentation faults from nvv4l2h264enc when running the pipeline below in my cpp code.

"nvarguscamerasrc ! video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1 ! nvvidconv ! video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)I420, framerate=(fraction)30/1 ! nvv4l2h264enc bitrate=2000000 output-io-mode=0 ! video/x-h264 ! rtph264pay pt=123 mtu=1200 ! appsink name=appsink"

And here’s the last few lines of the gstreamer debug file:

0:00:02.165735929  9406   0x7f7c004b20 INFO               GST_EVENT gstevent.c:814:gst_event_new_caps: creating caps event application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, sprop-parameter-sets=(string)"Z0JAKJZUA8ARPyo\=\,aM48gA\=\=", payload=(int)123, seqnum-offset=(uint)7490, timestamp-offset=(uint)604783546, ssrc=(uint)3294057694, a-framerate=(string)30
0:00:02.165764262  9406   0x7f7c004b20 DEBUG              GST_EVENT gstevent.c:306:gst_event_new_custom: creating new event 0x7f5c005d00 caps 12814
0:00:02.165790564  9406   0x7f7c004b20 DEBUG               GST_PADS gstpad.c:5776:gst_pad_send_event_unchecked:<appsink:sink> sent event, ret ok
0:00:02.165814314  9406   0x7f7c004b20 DEBUG               GST_PADS gstpad.c:5225:store_sticky_event:<appsink:sink> notify caps
0:00:02.165845512  9406   0x7f7c004b20 DEBUG               GST_PADS gstpad.c:3932:push_sticky:<rtph264pay0:src> event caps marked received
0:00:02.165902179  9406   0x7f7c004b20 DEBUG             GST_MEMORY gstmemory.c:139:gst_memory_init: new memory 0x7f7c17a1d0, maxsize:3110407 offset:4 size:11
0:00:02.165929627  9406   0x7f7c004b20 DEBUG             rtph264pay gstrtph264pay.c:809:gst_rtp_h264_pay_payload_nal:<rtph264pay0> Processing Buffer with NAL TYPE=7
0:00:02.165968690  9406   0x7f7c004b20 DEBUG               GST_CAPS gstpad.c:2705:gst_pad_has_current_caps:<rtph264pay0:src> check current pad caps application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, packetization-mode=(string)1, sprop-parameter-sets=(string)"Z0JAKJZUA8ARPyo\=\,aM48gA\=\=", payload=(int)123, seqnum-offset=(uint)7490, timestamp-offset=(uint)604783546, ssrc=(uint)3294057694, a-framerate=(string)30
0:00:02.165994680  9406   0x7f7c004b20 DEBUG             rtph264pay gstrtph264pay.c:874:gst_rtp_h264_pay_payload_nal:<rtph264pay0> NAL Unit fit in one packet datasize=11 mtu=1200
0:00:02.166016555  9406   0x7f7c004b20 DEBUG             GST_BUFFER gstbuffer.c:1266:gst_buffer_remove_memory_range: idx 0, length -1
0:00:02.166041555  9406   0x7f7c004b20 DEBUG             GST_MEMORY gstmemory.c:139:gst_memory_init: new memory 0x7f8c2dd6f0, maxsize:19 offset:0 size:12
0:00:02.166085461  9406   0x7f7c004b20 DEBUG               GST_PADS gstpad.c:3980:check_sticky:<rtph264pay0:src> pushing all sticky events
0:00:02.166110357  9406   0x7f7c004b20 DEBUG               GST_PADS gstpad.c:3910:push_sticky:<rtph264pay0:src> event stream-start was already received
0:00:02.166134524  9406   0x7f7c004b20 DEBUG               GST_PADS gstpad.c:3910:push_sticky:<rtph264pay0:src> event caps was already received
0:00:02.166211868  9406   0x7f7c004b20 DEBUG              GST_EVENT gstpad.c:5693:gst_pad_send_event_unchecked:<appsink:sink> have event type segment event: 0x7f7c005ae0, time 99:99:99.999999999, seq-num 70, GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";
0:00:02.166285931  9406   0x7f7c004b20 DEBUG               basesink gstbasesink.c:3252:gst_base_sink_event:<appsink> received event 0x7f7c005ae0 segment event: 0x7f7c005ae0, time 99:99:99.999999999, seq-num 70, GstEventSegment, segment=(GstSegment)"GstSegment, flags=(GstSegmentFlags)GST_SEGMENT_FLAG_NONE, rate=(double)1, applied-rate=(double)1, format=(GstFormat)GST_FORMAT_TIME, base=(guint64)0, offset=(guint64)0, start=(guint64)0, stop=(guint64)18446744073709551615, time=(guint64)0, position=(guint64)0, duration=(guint64)18446744073709551615;";
0:00:02.166308275  9406   0x7f7c004b20 DEBUG                appsink gstappsink.c:701:gst_app_sink_event:<appsink> receiving SEGMENT
0:00:02.166347493  9406   0x7f7c004b20 DEBUG               basesink gstbasesink.c:3187:gst_base_sink_default_event:<appsink> configured segment time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1.000000, applied_rate=1.000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999
0:00:02.166371660  9406   0x7f7c004b20 DEBUG               GST_PADS gstpad.c:5776:gst_pad_send_event_unchecked:<appsink:sink> sent event, ret ok
0:00:02.166395462  9406   0x7f7c004b20 DEBUG               GST_PADS gstpad.c:3932:push_sticky:<rtph264pay0:src> event segment marked received
0:00:02.166430306  9406   0x7f7c004b20 DEBUG         GST_SCHEDULING gstpad.c:4320:gst_pad_chain_data_unchecked:<appsink:sink> calling chainfunction &gst_base_sink_chain with buffer buffer: 0x7f7c176880, pts 0:00:00.541957264, dts 0:00:00.541957264, dur 99:99:99.999999999, size 23, offset none, offset_end none, flags 0x4040
0:00:02.166463744  9406   0x7f7c004b20 DEBUG               basesink gstbasesink.c:3421:gst_base_sink_chain_unlocked:<appsink> got times start: 0:00:00.541957264, end: 99:99:99.999999999
0:00:02.166497390  9406   0x7f7c004b20 DEBUG               basesink gstbasesink.c:2006:gst_base_sink_get_sync_times:<appsink> got times start: 0:00:00.541957264, stop: 99:99:99.999999999, do_sync 1
0:00:02.166516244  9406   0x7f7c004b20 DEBUG                default gstsegment.c:737:gst_segment_to_running_time_full: invalid position (-1)
0:00:02.166541400  9406   0x7f7c004b20 DEBUG               basesink gstbasesink.c:2312:gst_base_sink_do_preroll:<appsink> prerolling object 0x7f7c176880
0:00:02.166558900  9406   0x7f7c004b20 DEBUG               basesink gstbasesink.c:994:gst_base_sink_set_last_buffer_unlocked:<appsink> setting last buffer to 0x7f7c176880
0:00:02.166583536  9406   0x7f7c004b20 DEBUG               basesink gstbasesink.c:2335:gst_base_sink_do_preroll:<appsink> preroll buffer 0:00:00.541957264
0:00:02.166603119  9406   0x7f7c004b20 DEBUG                appsink gstappsink.c:783:gst_app_sink_preroll:<appsink> setting preroll buffer 0x7f7c176880

Thread 30 "nvv4l2h264enc0:" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f724fca50 (LWP 9505)]
0x0000007fb701e178 in gst_base_sink_do_preroll () from /usr/lib/aarch64-linux-gnu/libgstbase-1.0.so.0
(gdb) bt
#0  0x0000007fb701e178 in gst_base_sink_do_preroll () at /usr/lib/aarch64-linux-gnu/libgstbase-1.0.so.0
#1  0x0000007fb701e3f0 in  () at /usr/lib/aarch64-linux-gnu/libgstbase-1.0.so.0
#2  0x0000007f8c2af9c0 in  ()
(gdb)

Now if I run the same pipeline in bash it appears to work just fine.

jetson@jetson02:~$ gst-launch-1.0 -e nvarguscamerasrc ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1' ! nvvidconv ! 'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)I420, framerate=(fraction)30/1' ! nvv4l2h264enc bitrate=2000000 output-io-mode=0 ! 'video/x-h264' ! rtph264pay pt=123 mtu=1200 ! fakesink
Setting pipeline to PAUSED ...
Opening in BLOCKING MODE
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Redistribute latency...
NvMMLiteOpen : Block : BlockType = 4
===== NVMEDIA: NVENC =====
NvMMLiteBlockCreate : Block : BlockType = 4
GST_ARGUS: Creating output stream
CONSUMER: Waiting until producer is connected...
GST_ARGUS: Available Sensor modes :
GST_ARGUS: 3264 x 2464 FR = 21.000000 fps Duration = 47619048 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 3264 x 1848 FR = 28.000001 fps Duration = 35714284 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1920 x 1080 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1640 x 1232 FR = 29.999999 fps Duration = 33333334 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1280 x 720 FR = 59.999999 fps Duration = 16666667 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: 1280 x 720 FR = 120.000005 fps Duration = 8333333 ; Analog Gain range min 1.000000, max 10.625000; Exposure Range min 13000, max 683709000;

GST_ARGUS: Running with following settings:
   Camera index = 0
   Camera mode  = 2
   Output Stream W = 1920 H = 1080
   seconds to Run    = 0
   Frame Rate = 29.999999
GST_ARGUS: Setup Complete, Starting captures for 0 seconds
GST_ARGUS: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
H264: Profile = 66, Level = 0
NVMEDIA_ENC: bBlitMode is set to TRUE

My goal in the end is to hardware encode vp8, but I received this same error using nvv4l2vp8enc. I’ve opted to try to get h264 working since more people are familiar with it, and that’s what my project encoded when it ran on the pi 4.

2

Forgot to mention that I’m using the Jetson Nano 4gb dev kit, and on Jetpack 4.6.4

4

Hi,
Please try the samples and see if you can run them successfully:
GStreamer freeze when using qtmux and NVIDIA-accelerated h264/h265 encoding - #7 by DaneLLL
Latency issue: nvv4l2h265enc accumulates four images before releasing the first - #3 by DaneLLL

And then you can implement your use-case by referring to the samples.

5

They both ran just fine! I modified my code to fit how the appsink was used in the second example and mine ran with no issue. I swapped out h264 for vp8 and it also ran with no issue which is what I needed in the end!

I am confused how the fact that referencing gst/app/gstappsink.h and using GstAppSink* instead of a generic GstElement* for the appsink element was seemingly the only difference. This pipeline ran with no errors on the pi, so its just weird how this was the fix. Then again, code rarely ports from system to system without any quirks.

Anyway, thanks @DaneLLL!