After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748627 - rtspsrc: Don't send NACKs and early RTCP in non-feedback profiles
rtspsrc: Don't send NACKs and early RTCP in non-feedback profiles
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-04-29 11:13 UTC by Jesper Larsen
Modified: 2015-04-30 06:07 UTC
See Also:
GNOME target: ---
GNOME version: ---

Debug log (rtpsession:7,rtspsrc:7) (229.58 KB, text/x-log)
2015-04-29 11:14 UTC, Jesper Larsen
Wireshark dump (657.25 KB, application/x-pcapng)
2015-04-29 11:22 UTC, Jesper Larsen

Description Jesper Larsen 2015-04-29 11:13:00 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@ name=src ! rtph264depay ! decodebin ! autovideosink src. ! rtppcmudepay ! decodebin ! autoaudiosink

This commit seems to introduce a regression

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.
Comment 1 Jesper Larsen 2015-04-29 11:14:27 UTC
Created attachment 302553 [details]
Debug log (rtpsession:7,rtspsrc:7)
Comment 2 Jesper Larsen 2015-04-29 11:22:26 UTC
Created attachment 302555 [details]
Wireshark dump

pcap dump of the first and last network traffic
Comment 3 Sebastian Dröge (slomo) 2015-04-29 11:55:36 UTC
Can you provide a more complete network dump? We never sent a RTCP packet back to the server here.
Comment 4 Sebastian Dröge (slomo) 2015-04-29 11:58:01 UTC
Also can you provide logs with


That would also explain why we even try to send feedback messages here :)
Comment 5 Sebastian Dröge (slomo) 2015-04-29 12:05:34 UTC
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?
Comment 6 Sebastian Dröge (slomo) 2015-04-29 12:07:34 UTC
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.
Comment 7 Sebastian Dröge (slomo) 2015-04-29 12:14:26 UTC
And also add GST_CLOCK:7 to the debug log please :)

On what kind of system are you running this?
Comment 8 Jesper Larsen 2015-04-29 12:27:19 UTC
pcap dump with current master:

pcap dump with the commit reverted:

log with current master:

log with commit reverted:

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.
Comment 9 Jesper Larsen 2015-04-29 12:36:57 UTC
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.
Comment 10 Jesper Larsen 2015-04-29 12:41:28 UTC
Setting rtcp-min-interval in rtpsession to 1 second seems to workaround the issue.
Comment 11 Sebastian Dröge (slomo) 2015-04-29 12:42:47 UTC
Thanks, I'll let you know if I need to know more :)
Comment 12 Sebastian Dröge (slomo) 2015-04-29 12:49:04 UTC
Also the RTP streams by this camera are far from spec compliant, but that's not looking like the problem here.
Comment 13 Sebastian Dröge (slomo) 2015-04-29 13:44:08 UTC
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
Comment 14 Sebastian Dröge (slomo) 2015-04-29 13:53:56 UTC
This should fix the actual bug here:

commit 33693525b98ec4d7dae5e4d8ac922167ccb8b522
Author: Sebastian Dröge <>
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.

Please test if this helps for you. If it doesn't, we'll have to think of another solution.
Comment 15 Jesper Larsen 2015-04-30 06:07:19 UTC
I can confirm that the commit has fixed things for me. The server no longer closes the connection within the first minute. Thank you.