deepstream-app crashes after a little while with rtsp sources - Could not multiplex stream - buffer ...

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

I’m testing the deepstream-app reference app and find that it crashes after a while. Here is the console output (below).

ps. I have 4 x rtsp camera sources set to 10fps.

Could not multiplex stream - buffer has no PTS ??

…
KLT Tracker Init
KLT Tracker Init
KLT Tracker Init
KLT Tracker Init
H264: Profile = 66, Level = 0
H264: Profile = 66, Level = 0
H264: Profile = 66, Level = 0
H264: Profile = 66, Level = 0
**PERF: 11.37 (11.37) 11.50 (11.50) 11.48 (11.48) 11.24 (11.24)
**PERF: 10.01 (10.62) 9.98 (10.66) 10.01 (10.67) 10.01 (10.56)
**PERF: 9.96 (10.38) 10.07 (10.45) 9.96 (10.42) 10.08 (10.39)
**PERF: 9.97 (10.28) 9.95 (10.32) 9.97 (10.30) 9.86 (10.25)
**PERF: 10.06 (10.23) 9.99 (10.25) 10.06 (10.25) 10.06 (10.21)
**PERF: 10.01 (10.19) 10.06 (10.22) 9.97 (10.20) 9.93 (10.16)
**PERF: 9.97 (10.16) 10.00 (10.19) 10.00 (10.17) 10.08 (10.15)
**PERF: 10.04 (10.14) 9.93 (10.15) 10.04 (10.16) 10.01 (10.13)
**PERF: 10.02 (10.13) 9.99 (10.14) 10.02 (10.14) 10.02 (10.12)
**PERF: 9.89 (10.11) 10.02 (10.12) 9.89 (10.12) 9.89 (10.10)
**PERF: 10.07 (10.10) 9.79 (10.09) 10.07 (10.11) 10.00 (10.09)
**PERF: 10.02 (10.09) 10.19 (10.10) 10.02 (10.10) 10.08 (10.09)
**PERF: 10.00 (10.09) 10.02 (10.10) 10.00 (10.10) 10.00 (10.08)
**PERF: 9.91 (10.07) 9.98 (10.09) 9.91 (10.08) 9.91 (10.07)
**PERF: 10.06 (10.07) 9.96 (10.08) 10.06 (10.08) 10.06 (10.07)
**PERF: 10.02 (10.07) 10.05 (10.08) 10.02 (10.08) 9.82 (10.05)
**PERF: 9.99 (10.07) 9.99 (10.07) 9.99 (10.07) 10.19 (10.06)
**PERF: 10.02 (10.06) 9.80 (10.06) 10.02 (10.07) 10.02 (10.06)
**PERF: 10.01 (10.06) 10.19 (10.06) 9.92 (10.06) 10.01 (10.05)

**PERF: FPS 0 (Avg) FPS 1 (Avg) FPS 2 (Avg) FPS 3 (Avg)
**PERF: 10.00 (10.06) 10.02 (10.06) 10.08 (10.06) 10.00 (10.05)
**PERF: 10.00 (10.05) 9.96 (10.06) 10.00 (10.06) 10.00 (10.05)
**PERF: 10.00 (10.05) 10.02 (10.06) 10.00 (10.06) 10.00 (10.05)
**PERF: 10.00 (10.05) 10.01 (10.05) 10.00 (10.05) 10.00 (10.04)
ERROR from sink_sub_bin_mux1: Could not multiplex stream.
Debug info: gstqtmux.c(4561): gst_qt_mux_add_buffer (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstQTMux:sink_sub_bin_mux1:
Buffer has no PTS.
Quitting
ERROR from sink_sub_bin_queue1: Internal data stream error.
Debug info: gstqueue.c(988): gst_queue_handle_sink_event (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstQueue:sink_sub_bin_queue1:
streaming stopped, reason error (-5)
App run failed

I there was a glitch in one of the camera rtsp streams you would expect things to carry on running and not crash the whole app?

2

Hi,
It looks like somehow the source(either one) does not give correct timestamps and triggers the issue. Do you run sink in ‘sync=1’ or ‘sync=0’? If you run in ‘sync=1’, you may try ‘sink=0’.

3

I use live-source = TRUE on the muxer and sync=0 all sinks.

4

Either way it should not segfault on a stream timing issue. It should handle it gracefully at least being the reference app for deepstream, otherwise we cannot trust it for continual use in IoT type situations.

I’m also building a custom app based on deepstream-test3 and it never seems to get these rtsp source issue so I think its an issue with deepstream-app.
Both use a decodebin but when I output the pipeline graph I see the deepstream-app version has extra queue’s created inside the decodebin and I have no idea why…

5

Hi,
We have verified with Sony and HikVision cameras and not hit the issue, hence there may be lack of handling of this error case. For information, please share your brand and model ID of IP cameras.

Please check if you configure live-source and batched-push-timeout accordingly:

[streammux]
...
##Boolean property to inform muxer that sources are live
live-source=0
...
##time out in usec, to wait after the first buffer is available
##to push the batch even if the complete batch is not formed
batched-push-timeout=40000
...

For RTSP sources, live-sourceshould be 1.
For 10fps, batched-push-timeout should be ~120000(usec).

6

The camera make is Hikvision. I’ll have to get back to you later on the actual model number as I’m not near them right now.

I already have live-source set to 1. I also note that deepstream-test3 does not fail with this issue even though it uses a decodebin to handle the rtsp cameras just the same was that deepstream-app does.

Something interesting that you mentioned is about

batch-push-timeout

. What rule are you using to calculate that it should be set to “~120000(usec)” for 10 fps ? The deepstram documentation does not seem to mention a rule or guideline on this.

7

Hi,
We have the property listed in
https://docs.nvidia.com/metropolis/deepstream/dev-guide/index.html#page/DeepStream%2520Development%2520Guide%2Fdeepstream_app_config.3.2.html%23wwpID0E0DB0HA
https://docs.nvidia.com/metropolis/deepstream/plugin-manual/index.html#page/DeepStream_Plugin_Manual%2Fdeepstream_plugin_details.02.03.html

The default value is for 30fps. For 30fps, frames are in 33ms interval and set the timeout value a bit higher to be 40ms. For 10fps, you may try 120ms or 110ms.

1 Like
8

Thanks @DaneLLL will try increasing that parameter tonight and test…

9

@DaneLLL - shouldn’t the deepstram-app source (and all the test apps) be updated to handle these issues without quitting.

If one source is having troubles and the other 7 sources (for example) are okay it should carry on with those 7.

10

Whats wrong with setting batch-push-timeout batch-push-timeout to a very high value like 5 seconds or 0 for forever? That would cater for any intermittent rtsp stream issue? Does this create a performance penalty maybe?

11

Hi,
0 is not recommended since nvstreammux may not collect frames and malfunction. Large value like 5 seconds is also not suggested. Better to be a value matching framerate.