FPS Drops to 0 every so often

Please provide complete information as applicable to your setup.

• Nvidia Jetson Xavier
• Deepstream 6.1.1
• Jetpack 5.0.2-b231
• TensorRT 8.4.1-1
• Issue Type-Bug/Question
**• I am facing a problem where every ~20 PERF calls the frame rate will drop to ~0, the video RTSP output will freeze for ~5 seconds and then normalize. I am also facing an issue where if the PTZ camera doesn’t move the image starts to become pixelated like so(this is supposed to be a 1920x1080 Color Stream but notice the gray looking color that happens and the weird yellow tint to the bottom left).:


**

This is something that’s not noticed when streaming in the image directly from the UDP source to VLC:

Here is my deepstream config file:
deepstream_app_config_speed.txt (3.6 KB)

I am running Object Detection on two sources coming from a PTZ Camera via UDP Unicast at 25FPS. I am achieving real-time as you can see in the PERF output below. However every ~20 PERF calls the video will freeze for ~5 seconds and then normalize again. I would imagine some sort of buffer is filling up and then having to be freed or something of that nature and its causing the deepstream app to block? Any ideas on what I can do to troubleshoot this issue?

**PERF: FPS 0 (Avg) FPS 1 (Avg)
**PERF: 25.08 (25.00) 24.91 (25.00)
**PERF: 25.00 (25.00) 25.00 (25.00)
**PERF: 25.01 (25.00) 25.00 (25.00)
**PERF: 24.99 (25.00) 24.99 (25.00)
**PERF: 25.01 (25.00) 25.01 (25.00)
**PERF: 25.03 (25.00) 25.02 (25.00)
**PERF: 24.98 (25.00) 24.98 (25.00)
**PERF: 24.99 (25.00) 24.98 (25.00)
**PERF: 25.06 (25.00) 25.03 (25.00)
**PERF: 25.01 (25.00) 25.01 (25.00)
**PERF: 24.91 (25.00) 24.95 (25.00)
**PERF: 24.96 (25.00) 24.94 (25.00)
**PERF: 25.10 (25.00) 25.05 (25.00)
**PERF: 24.97 (25.00) 25.03 (25.00)
**PERF: 24.97 (25.00) 24.97 (25.00)
**PERF: 25.05 (25.00) 25.01 (25.00)
**PERF: 25.02 (25.00) 25.00 (25.00)
**PERF: 25.00 (25.00) 25.01 (25.00)
**PERF: 24.99 (25.00) 25.01 (25.00)
**PERF: 24.99 (25.00) 24.99 (25.00)

**PERF: FPS 0 (Avg) FPS 1 (Avg)
**PERF: 25.02 (25.00) 25.00 (25.00)
**PERF: 24.98 (25.00) 25.02 (25.00)
**PERF: 25.04 (25.00) 24.99 (25.00)
**PERF: 24.96 (25.00) 24.99 (25.00)
**PERF: 25.01 (25.00) 24.98 (25.00)
**PERF: 24.99 (25.00) 25.04 (25.00)
**PERF: 24.99 (25.00) 24.99 (25.00)
**PERF: 24.89 (25.00) 25.06 (25.00)
**PERF: 25.12 (25.00) 24.91 (25.00)
**PERF: 24.99 (25.00) 25.08 (25.00)
**PERF: 24.97 (25.00) 24.93 (25.00)
**PERF: 25.00 (25.00) 25.00 (25.00)
**PERF: 25.07 (25.00) 25.01 (25.00)
**PERF: 24.95 (25.00) 25.02 (25.00)
**PERF: 25.01 (25.00) 24.99 (25.00)
**PERF: 24.99 (25.00) 24.99 (25.00)
**PERF: 25.02 (25.00) 24.98 (25.00)
**PERF: 25.01 (25.00) 25.08 (25.00)
**PERF: 24.98 (25.00) 24.94 (25.00)
**PERF: 24.98 (25.00) 24.98 (25.00)

What the FPS of the two PTZ Cameras? What are the PTA Cameras video properties such as format, colorspace, encoding type,…

Have you viewed the output videos directly with nveglglessink instead of output as RTSP streams?

Sorry for the delay,

Question 1 Answer: The two PTZ Camera feeds are outputting UDP Unicast at 25.0 FPS with YUV-4.2.2 colorspace, and H.264 encoding.

Question 2 Answer: I have not video the UDP Unicast streams directly with nveglglessink has the Jetson Xavier has it’s display disabled. I can only access the Jetson Xavier via ssh. However, I have viewed the UDP unicast stream with VLC and I do not notice the video freeze.

Any ideas?

Can you change the output configuration to fakesink to check the PERF?

Yeah, so I switched to using a Fake Sink and everything appears to be working fine but then I start getting this warning continuously:

**PERF:  52.44 (52.04)
**PERF:  40.00 (45.37)
**PERF:  40.00 (43.36)
**PERF:  40.00 (42.52)
**PERF:  40.00 (41.95)
**PERF:  39.90 (41.61)
**PERF:  43.20 (41.85)
**PERF:  54.62 (43.49)
**PERF:  54.39 (44.73)
**PERF:  54.69 (45.74)
**PERF:  54.37 (46.54)
WARNING from sink_sub_bin_sink1: A lot of buffers are being dropped.
Debug info: gstbasesink.c(3003): gst_base_sink_is_too_late (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstFakeSink:sink_sub_bin_sink1:
There may be a timestamping problem, or this computer is too slow.
WARNING from sink_sub_bin_sink1: A lot of buffers are being dropped.
Debug info: gstbasesink.c(3003): gst_base_sink_is_too_late (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstFakeSink:sink_sub_bin_sink1:
There may be a timestamping problem, or this computer is too slow.
**PERF:  60.61 (47.73)
WARNING from sink_sub_bin_sink1: A lot of buffers are being dropped.
Debug info: gstbasesink.c(3003): gst_base_sink_is_too_late (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstFakeSink:sink_sub_bin_sink1:
There may be a timestamping problem, or this computer is too slow.
WARNING from sink_sub_bin_sink1: A lot of buffers are being dropped.
Debug info: gstbasesink.c(3003): gst_base_sink_is_too_late (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstFakeSink:sink_sub_bin_sink1:
There may be a timestamping problem, or this computer is too slow.
WARNING from sink_sub_bin_sink1: A lot of buffers are being dropped.
Debug info: gstbasesink.c(3003): gst_base_sink_is_too_late (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstFakeSink:sink_sub_bin_sink1:
There may be a timestamping problem, or this computer is too slow.
WARNING from sink_sub_bin_sink1: A lot of buffers are being dropped.
Debug info: gstbasesink.c(3003): gst_base_sink_is_too_late (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstFakeSink:sink_sub_bin_sink1:
There may be a timestamping problem, or this computer is too slow.
WARNING from sink_sub_bin_sink1: A lot of buffers are being dropped.
Debug info: gstbasesink.c(3003): gst_base_sink_is_too_late (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstFakeSink:sink_sub_bin_sink1:
There may be a timestamping problem, or this computer is too slow.
WARNING from sink_sub_bin_sink1: A lot of buffers are being dropped.
Debug info: gstbasesink.c(3003): gst_base_sink_is_too_late (): /GstPipeline:pipeline/GstBin:processing_bin_0/GstBin:sink_bin/GstBin:sink_sub_bin1/GstFakeSink:sink_sub_bin_sink1:

If I switch [sink0] back to type=4(RTSPStreaming) I don’t get this error. However, when viewing the RTSP stream via VLC I am noticing blurred pixels like so:

Here is the blurred pixels vs the Non-blurred:
Blur


The red bounding box starts to “leak”/“smoke” across the screen from time to time.

Non-Blur

Any ideas?

This is caused by packet lost during rtsp transferring on the network.

Very interesting, thanks for the cause!

Any ideas on how I can solve the lost packets problem?

It is a network issue or the issue with your ethernet card. It has nothing to do with DeepStream. High rate of packet loss and latency in a UDP multicast scenario · Issue #3601 · weaveworks/weave (github.com)

@Fiona.Chen I don’t think this is a correct statement. RTSP uses TCP, how can it be a UDP multicast problem?

I have the new Jetson Orin and I am getting the same exact issue with it’s RTSP Sink. We are seeing “leaky” pixels scroll across the screen and it’s only coming from the Jetson’s RTSP stream with the bounding box:

The stream on the left is from the Jetson RTSP Stream and the one on the right is from the Camera’s RTSP Stream. Any ideas on how to fix this?

Thanks

There is no update from you for a period, assuming this is not an issue anymore. Hence we are closing this topic. If need further support, please open a new one. Thanks

The payload can be transferred with UDP or TCP. Please refer to RTSP, RTP, RTCP protocols for the details.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.