GNOME Bugzilla – Bug 748627
rtspsrc: Don't send NACKs and early RTCP in non-feedback profiles
Last modified: 2015-04-30 06:07:19 UTC
I'm testing a LILIN LD2222 IP camera, and I have come upon a regression. The camera serves a stream with two payloads, h264 video and µlaw audio. I test the stream using the following pipeline gst-launch-1.0 rtspsrc location=rtsp://admin:pass@192.168.1.109:554/rtsph2641080p name=src ! rtph264depay ! decodebin ! autovideosink src. ! rtppcmudepay ! decodebin ! autoaudiosink This commit seems to introduce a regression http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit?id=b07b7736b37757e3e271eda27aacb4b0669826fa After that commit the stream will stop within a minute, with a warning from rtspsrc: 34119 0:00:32.411405224 32265 0x264b280 WARN rtspsrc gstrtspsrc.c:4897:gst_rtspsrc_loop_udp:<src> warning: The server closed the connection. I found the commit by doing a git bisect. If I use current master and revert the commit, the issue disappears. Forcing the protocol to TCP makes the issue disappear. Using gst-rtsp-server as a source does not exhibit the same behaviour.
Created attachment 302553 [details] Debug log (rtpsession:7,rtspsrc:7)
Created attachment 302555 [details] Wireshark dump pcap dump of the first and last network traffic
Can you provide a more complete network dump? We never sent a RTCP packet back to the server here.
Also can you provide logs with rtpsession:7,rtpbin:7,rtspsrc:7,rtpsource:7,rtpjitterbuffer:7 That would also explain why we even try to send feedback messages here :)
For whatever reason we send the first RTCP packet only after 10 seconds, while it should be after 5 seconds. Can you also provide a log with that commit reverted?
Also does it work better if you reduce the rtp-min-interval in rtpbin (just change the default value in the code) from 5 seconds to 1 second? I assume the problem here is that the server just kicks us out if we don't send RTCP often enough.
And also add GST_CLOCK:7 to the debug log please :) On what kind of system are you running this?
pcap dump with current master: https://drive.google.com/file/d/0Bxsg_7vygeX2dDZ6MXh6WGY3UzA/view?usp=sharing pcap dump with the commit reverted: https://drive.google.com/file/d/0Bxsg_7vygeX2bjNXUGR6NV80MUE/view?usp=sharing log with current master: https://drive.google.com/file/d/0Bxsg_7vygeX2dllzRmdjWEZva1U/view?usp=sharing log with commit reverted: https://drive.google.com/file/d/0Bxsg_7vygeX2QXlla3FlTm1rSG8/view?usp=sharing I can not find any "rtp-min-interval" in the rtpbin? I'm running the client on a Ubuntu 14.04 64bit using glib 2.44.0, and fairly recent masters for all gstreamer repos. Let me know if you need anything else.
If I in an otherwise working condition add do-rtcp=false to the rtspsrc, the connection is also closed. So it does seem to be related to RTCP timing.
Setting rtcp-min-interval in rtpsession to 1 second seems to workaround the issue.
Thanks, I'll let you know if I need to know more :)
Also the RTP streams by this camera are far from spec compliant, but that's not looking like the problem here.
I think it all does the right thing actually. Whenever we send early feedback, the next regular RTCP packet is delayed accordingly so that we still on average send one RTCP packet every ~5 seconds (rtcp-min-interval + jitter). So for session 0 we send a packet at 1s, 3s (early), 13s. Similar for session 1. The keepalive via RTCP by this server is not defined by the spec, and it also does not tell us in the SDP or anywhere how often we should send RTCP. So what we're doing here is completely valid, and before the commit it was actually wrong (we sent too much RTCP according to our settings). But sending early RTCP here, and NACKs, is also wrong. We shouldn't do that in non-feedback profiles. That way we would keep the gaps between RTCP packets a bit more regular
This should fix the actual bug here: commit 33693525b98ec4d7dae5e4d8ac922167ccb8b522 Author: Sebastian Dröge <sebastian@centricular.com> Date: Wed Apr 29 15:52:27 2015 +0200 rtspsrc: Only enable retransmissions if there is retransmission info in the SDP Otherwise we're going to send early RTCP and NACKs in non-feedback sessions too, which will confuse servers. https://bugzilla.gnome.org/show_bug.cgi?id=748627 Please test if this helps for you. If it doesn't, we'll have to think of another solution.
I can confirm that the commit has fixed things for me. The server no longer closes the connection within the first minute. Thank you.