Please provide complete information as applicable to your setup.
• Hardware Platform Jetson
• DeepStream Version 5.0.1
• JetPack Version 4.5
• TensorRT Version 7.1.3
• Issue Type bugs
After upgrading my jetson AGX we noticed degredation in the quality of the rtsp stream from GstRstspServer. Below are some debug messages whilst trying to play the stream from a pc on the network with ffmpeg
[h264 @ 000002357cb8f540] negative number of zero coeffs at 43 52/302
[h264 @ 000002357cb8f540] error while decoding MB 43 52
[h264 @ 000002357cb8f540] concealing 1926 DC, 1926 AC, 1926 MV errors in I frame
[rtsp @ 0000023574ede640] max delay reached. need to consume packet11
[rtsp @ 0000023574ede640] RTP: missed 2 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 8 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 6 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 6 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 6 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 6 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 2 packets
[h264 @ 000002357bde0580] negative number of zero coeffs at 87 55/314
[h264 @ 000002357bde0580] error while decoding MB 87 55
[h264 @ 000002357bde0580] concealing 1522 DC, 1522 AC, 1522 MV errors in I frame
[rtsp @ 0000023574ede640] max delay reached. need to consume packet23
[rtsp @ 0000023574ede640] RTP: missed 69 packets
[h264 @ 000002357bc3b3c0] corrupted macroblock 81 48 (total_coeff=-1)
[h264 @ 000002357bc3b3c0] error while decoding MB 81 48
[h264 @ 000002357bc3b3c0] concealing 2368 DC, 2368 AC, 2368 MV errors in I frame
[rtsp @ 0000023574ede640] max delay reached. need to consume packet36
[rtsp @ 0000023574ede640] RTP: missed 3 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 5 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 6 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 1 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 6 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 2 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 6 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 5 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 3 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 4 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 3 packets
[h264 @ 0000023574f7f8c0] corrupted macroblock 14 52 (total_coeff=16)
[h264 @ 0000023574f7f8c0] error while decoding MB 14 52
[h264 @ 0000023574f7f8c0] concealing 1955 DC, 1955 AC, 1955 MV errors in I frame
[rtsp @ 0000023574ede640] max delay reached. need to consume packet49
[rtsp @ 0000023574ede640] RTP: missed 2 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 10 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 10 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 11 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 11 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 12 packets
[rtsp @ 0000023574ede640] max delay reached. need to consume packet
[rtsp @ 0000023574ede640] RTP: missed 1 packets
[h264 @ 000002357c7b3700] out of range intra chroma pred mode=352/352
[h264 @ 000002357c7b3700] error while decoding MB 111 49
[h264 @ 000002357c7b3700] concealing 2218 DC, 2218 AC, 2218 MV errors in I frame
[rtsp @ 0000023574ede640] max delay reached. need to consume packet63
The tearing is pretty permanent and can extend to well over half the screen.
The network is gigabit and the rtsp client is a beefy laptop with 5m max of lan cable
I can also confirm that a jetson running jetpack 4.4 with the identical deepstream program had minimal if any “tearing” or artefacts
and updating the jetson to 4.5.1 makes no difference to the rtsp output
And since down grading jetpack isnt an easy solution im hoping there is an easier fix
regards Andrew
Will the “tearing” be observed by the simple gstreamer rtsp pipeline?
gst-launch-1.0 uridecodebin uri=rtsp://xxxxx ! nvvideoconvert ! nvegltransform ! nveglglessink
From the picture you posted, the package lost happens with ffmpeg rtsp client, have you measured the network package lost rate? It can not be caused by deepstream or rtspserver which are just application level SDKs.
Im trying to workout why this is happening.
I have 2 agxs running an identical version of our deepstream application.
1 agx is jetpack 4.4
the other is 4.5
we have 2 laptops and each is connected to a different jetson with the same ffmpeg play commands.
1 laptop has terrible tearing (jp 4.5) and the other is great (jp 4.4)
I’m obviously investigating what is causing this but I just wanted to see if maybe Nvidia would have any insight
like maybe the missing “bufapi-version” property for nvv4l2decoder or something else that may have changed
Regards Andrew
The decoder can not work if the property is wrong, your application will fail. It has nothing to do with the package lost you met.
when using
gst-launch-1.0 uridecodebin uri=rtsp://xxxxx ! nvvideoconvert ! nvegltransform ! nveglglessink
it doesnt have the same artifacts, however the stream degrades over time as seen below
this was on localhost
So it is not caused by deepstream part.
okay so what could be the cause?
I don’t know. Have you measured the package lost rate for UDP and TCP?
It is suspected to be network issue.
I have not yet measured the network TCP and UDP packetloss, do you have a prescribed method and tool?
Also the gstreamer capture was performed on jetson so localhost ?
The above pipeline works well, so there is no network issue with localhost. You need to test the network between Jetson and your pc which run ffmpeg to display.
There are lot of network test tools with linux platform. You can google for it. E.G. iperf
Thanks I just came across I perf.
The snapshot above using gstreamer is by no means perfect, it has plenty of arifacts and decode errors?
It may be caused by low encoding bitrate, you can try a large bitrate. It is absolutely different to what you see with ffmpeg. ffmpeg result shows obvious package loss.
UDP
Accepted connection from 192.168.0.121, port 48244
[ 5] local 192.168.0.108 port 5201 connected to 192.168.0.121 port 53718
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 89.3 MBytes 749 Mbits/sec 0.007 ms 9/11441 (0.079%)
[ 5] 1.00-2.00 sec 110 MBytes 920 Mbits/sec 0.048 ms 61/14096 (0.43%)
[ 5] 2.00-3.00 sec 111 MBytes 932 Mbits/sec 0.043 ms 10/14231 (0.07%)
[ 5] 3.00-4.00 sec 110 MBytes 926 Mbits/sec 0.046 ms 26/14151 (0.18%)
[ 5] 4.00-5.00 sec 110 MBytes 923 Mbits/sec 0.051 ms 33/14112 (0.23%)
[ 5] 5.00-6.00 sec 110 MBytes 926 Mbits/sec 0.050 ms 12/14140 (0.085%)
TCP
Accepted connection from 192.168.0.121, port 48256
[ 5] local 192.168.0.108 port 5201 connected to 192.168.0.121 port 48258
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 112 MBytes 939 Mbits/sec
[ 5] 1.00-2.00 sec 88.1 MBytes 739 Mbits/sec
[ 5] 2.00-3.00 sec 64.9 MBytes 544 Mbits/sec
[ 5] 3.00-4.00 sec 64.6 MBytes 542 Mbits/sec
[ 5] 4.00-5.00 sec 84.9 MBytes 711 Mbits/sec
[ 5] 5.00-6.00 sec 67.8 MBytes 570 Mbits/sec
[ 5] 6.00-7.00 sec 112 MBytes 937 Mbits/sec
[ 5] 7.00-8.00 sec 111 MBytes 932 Mbits/sec
[ 5] 8.00-9.00 sec 112 MBytes 937 Mbits/sec
[ 5] 9.00-10.00 sec 112 MBytes 936 Mbits/sec
[ 5] 10.00-10.00 sec 150 KBytes 799 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.00 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-10.00 sec 929 MBytes 779 Mbits/sec receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
The video I posted earlier is what confuses me… same network, same laptop the only difference is the jetpack version
0.43% is very high lost rate. JetPack4.5 has been tested with all platforms before releasing, and the localhost seems fine with the gst-launch test. You may need to check your network environment.
I’m still struggling to fix my issue.
when i try the test1_rtsp_out i dont have any tearing or artifacts (jetpack 4.5)
So i guess we can rule out the 4.4 vs 4.5 bug as you stated
so now I am just trying to get the same results…
In my pipeline I use a drop-frame interval of 2 on each camera stream so usually my pipeline has an fps of 12, could this be causing issues with decoding on the client side? do I need to add something to the caps?
regards Andrew
Do you mean the “interval” parameter of nvinfer plugin configuration? If so, this parameter never impacts the video quality, it only impacts inference result.
on the on the decode_bin_child_added :
def decodebin_child_added(self, child_proxy, Object, name, user_data):
if (name.find("decodebin") != -1):
Object.connect("child-added", self.decodebin_child_added, user_data)
if (is_aarch64() and name.find("nvv4l2decoder") != -1):
# Object.set_property("bufapi-version", True)
Object.set_property("drop-frame-interval", 2)
it effects the whole pipeline fps, so the rtsp stream is 12fps from a 25fps camera.
drop-frame-interval of nvv4l2decoder only impact the pipeline FPS, it will not impact network package lost.
1 Like
I have managed to find my issues.
I had some different properties on the stream_sink element (udpsink)
I didnt realize the importance of “sync” = 1and async = False…
After setting these I had perfect rtspstreaming again.
