Nx decoder crash in some streams

[yc007ft]

Nx decoder crash when I connect IPC camera with DS5.0 sdk. I record this stream, This stream can play to 59s with ffmpeg, but only play to 54s with nx decoder. IPC stream can lost some streams when decoder slowly or net slowly usually, but decorder need process it instead of crash.
when play this video with DS, some wrong procduce:

hk_chn3_2s.h264 (14.6 MB)

GST_DEBUG=2 gst-launch-1.0 filesrc location=./hk_chn3_2s.h264 ! h264parse ! nvv4l2decoder ! queue ! nvegltransform ! nveglglessink

0:00:39.148637793 14866 0x55975310f0 WARN codecparsers_h264 gsth264parser.c:674:slice_parse_ref_pic_list_modification_1: error parsing “Reference picture list 0 modification”
0:00:39.149029607 14866 0x55975310f0 WARN codecparsers_h264 gsth264parser.c:2225:gst_h264_parser_parse_slice_hdr: error parsing “Slice header”
0:00:42.184163733 14866 0x55975310f0 WARN baseparse gstbaseparse.c:3611:gst_base_parse_loop: error: Internal data stream error.
0:00:42.184226454 14866 0x55975310f0 WARN baseparse gstbaseparse.c:3611:gst_base_parse_loop: error: streaming stopped, reason not-negotiated (-4)
ERROR: from element /GstPipeline:pipeline0/GstH264Parse:h264parse0: Internal data stream error.
Additional debug info:
gstbaseparse.c(3611): gst_base_parse_loop (): /GstPipeline:pipeline0/GstH264Parse:h264parse0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:41.654463335
Setting pipeline to PAUSED …
Setting pipeline to READY …
NVMEDIA: NVMEDIABufferProcessing: 1096: Consume the extra signalling for EOS
Setting pipeline to NULL …
Freeing pipeline …

[DaneLLL]

Hi,
The stream is invalid around end of the stream and decoding terminates. It exists gracefully and does not crash the application. We think the handling is fine. For minor error it should not exit. Once it hits bitstream error, it should exit gracefully and you can re-start the application.

[yc007ft]

@DaneLLL

gracefully

hi,
i don’t know when this occors, so the channel can’t restore. how can i restart application without affect other vdec channels and algorithm run.

[Honey_Patouceul]

Checked the file by downloading, and it seems it has some jumps as you can see with:

gst-launch-1.0 -v filesrc location=./hk_chn3_2s.h264 ! h264parse ! nvv4l2decoder enable-error-check=1 ! queue ! nvegltransform ! nveglglessink
...
ErrorType= 2  Decoded MBs= 524  Concealed MBs= 3076  FrameDecodeTime 3083

Using ffmpeg libraires just leads to a segfault with nveglglessink a few seconds before the end, you may try with:

gst-launch-1.0 -v filesrc location=./hk_chn3_2s.h264 ! h264parse ! avdec_h264 ! nvvidconv ! queue ! nvegltransform ! nveglglessink

I think you may investigate on source errors, but you may get further with another displaysink (there may be an ignored EOS):

gst-launch-1.0 -v filesrc location=./hk_chn3_2s.h264 ! h264parse ! nvv4l2decoder ! nvvidconv ! xvimagesink

# Or 
gst-launch-1.0 -v filesrc location=./hk_chn3_2s.h264 ! h264parse ! nvv4l2decoder ! nvoverlaysink

You may see at the end it changes format from:

video/x-h264, width=(int)1280, height=(int)720, framerate=(fraction)25/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)main, level=(string)3.1

to

video/x-h264, width=(int)112, height=(int)8, framerate=(fraction)0/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)au

[yc007ft]

thanks，
I use ffplay can play to 59s, but gstream only play to 54s, and can’t process this problem stream completely and break in middle. We use IPC cameras, frequently occur this, and break algorithm process.

[DaneLLL]

Hi,
We would suggest check why invalid stream is frequently triggered by the cameras. It looks to be an issue and may impact stability. For valid stream, hardware decoder should work as good as software decoder. But for invalid stream, certain corner cases may make hardware decoder hang. It is better to make sure the stream is good before sending to decoder.