GNOME Bugzilla – Bug 741864
RTCP is broken (regression)
Last modified: 2018-10-27 11:46:48 UTC
I've noticed that the RTCP packets in current git code are no longer being sent to a multicast address. This is, two of them are sent, then silence. The setup is that an RTP stream is sent to a MC address 239.1.2.3:1234 and the RTCP packets are sent to port+1 239.1.2.3:1235 When I started debugging, I noticed that rtpsession generates and sends 2 RTCP packets. It also receives the packets it sent to the multicast address. Since the packets sent and the packets received have the same SSRC, it marks them as a collision and sends an EOS on the RTCP pad. While the RTP session still generateds RTCP packets, the pad ignores and frees them because of the EOS. rtpmanager/rtpsession.c check_collision is too strict IMO (since it cannot figure out if it is sent to MC or not).
I disabled the collision detection on my end to restore RTCP.
Could you bisect which commit introduced this?
Created attachment 302653 [details] [review] disable collision
Also what I asked on IRC already :) There's supposed to be some loop detection in rtpsession, not sure why that fails here. Can you provide a testcase to reproduce it? :) and is this with gst-rtsp-server or some other server?
Does changing the "favor-new" property on rtpsession help ? The most recent change to that code is 2e54d38d from a year ago, but that was fixing something that had been changed shortly before.
Marc?
Marc, could you provide more info about the exact scenario? See questions above.
We are still using the patch as submitted, I will disable the patch again and see if we are still in the same situation as 3 years ago.
Tested with gst-launch-1.0 videotestsrc ! x264enc ! h264parse ! rtph264pay ! rtpsink uri=rtp://239.1.2.3:1234 sudo tcpdump -i wlp1s0 port 1235 RTCP packets are still flowing, I assume this one got squashed somewhere in the past 4 years.