Deepstream 5.0, multi-stream processing got exited unexpectedly or stuck

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU) GPU
• DeepStream Version 5.0
• JetPack Version (valid for Jetson only)
• TensorRT Version
• NVIDIA GPU Driver Version (valid for GPU only) 440.64

Based on the sample deepstream_imagedata_multistream, I created an application to process multiple rtsp streams. I ran into some problems. I enabled GST_DEBUG=3 and collected logs as below. There were some warnings and errors, but I don’t know what is the root cause. Please be noted this is not always happening.

  1. The application got exited unexpectedly.
    m2f_5.log (61.0 KB)

  2. The application didn’t exit, yet seemed stuck somewhere, no more progressing.
    h2p_8.log (58.8 KB)

Can anybody please take a look and shed some light on the root cause?

deepstream app is only the client to receive the rtsp stream from server. It is of no use to only analysis deepstream log to find the rtsp connection or transmission problems. It may be caused by many reasons, rtsp server, udp connection, socket,…

The first log shows there is no udp package received for very long time. The second log has no useful information in it.

There may be more useful information in GStreamer community for how to debug GStreamer rtsp plugins.

Thanks @Fiona.Chen.

This turned out to be input source issue. I tested it with vlc, it took a few seconds or a few minutes to play the rtsp stream.

Yet there is still other problems.

For one particular rtsp stream, vlc can play it immediately, but my application could run into the following scenarios.

  1. It could not get the frame in the callback as time went on, so it could not process frames any more. Sometime it could come back after a few minutes, but most likely it couldn’t. The parameter batched-time-out is set to 40ms, FPS is 15.

  2. It could just exit the pipeline. In this case, below error message will be seen in the log after GST_DEBUG=3 is enabled.

0:19:08.405545331 ^[[336m18071^[[00m 0xf94b70 ^[[33;01mWARN ^[[00m ^[[00m rtspsrc gstrtspsrc.c:3155:on_timeout:^[[00m source 74c357f5, stream 74c357f5 in session 0 timed out

It seems deepstream were seeing something unusual and could not recover from that situation. Any idea what I can further check?

And by the way, it seems the rtsp in deepstream is using udp, where can I specify it to use tcp? I would like to have a try with tcp.

When using vlc to play some rtsp stream, I noticed the option “–rtsp-tcp” matters. W/ this option it could play properly while not w/o this option.

$ vlc –rtsp-tcp [rtsp url]

You can put the question about gstreamer rtspsrc with Gstreamer community.

GStreamer community has mail lists: https://gstreamer.freedesktop.org/lists/
And you can also file bug: https://gstreamer.freedesktop.org/documentation/contribute/index.html?gi-language=c

According to GStreamer community, the rtspsrc neogotiate between UDP/TCP automatically.
https://gstreamer.freedesktop.org/documentation/rtsp/rtspsrc.html?gi-language=c