GNOME Bugzilla – Bug 729577
rtpsession: collisions detected
Last modified: 2014-05-15 22:34:48 UTC
With a recent gst-plugins-good build, I get the following warnings when playing back an RTSP stream with audio and video: rtpsession: Our packets are being looped back to us, dropping rtpsession: received RTCP packet rtpsession: ignoring packet because its collisioning So the audio stream will not play. Both audio and video streams have the same SSRC of 0, and the same UDP source address. The server does not implement SDES, which is not mandatory in RFC 3550. Only Sender Reports are sent. What's wrong with my setup ? Or is there a bug in rtpsession ? The stream was working fine in gstreamer 1.2
That does sound like a bug, was it broken after commit 2e54d38d, before that, local collision detection was completely broken/disabled in git master. "Our packets are being looped back to us, dropping" means that it receives a RTP or RTCP packets that we think comes from us. Can you attach a log with GST_DEBUG=*rtp*:9 and a matching tcpdump ?
Ok I'll do that. I'll also add that the stream plays fine if I comment the call to check_collision in rtpsession.
Created attachment 275899 [details] tcpdump capture of rtsp/rtp
Created attachment 275900 [details] *rtp*:9 log
It creates an internal source with SSRC 0, that's the problem. So it thinks the remote packets are from a collision. And it creates this internal source in the rtp timeout (because you're not sending RTP/RTCP at all). I'm not sure why suggested_ssrc is 0 at this point, that sounds wrong. I'm not sure how easy it is for you to debug this, but if you can break in rtp_session_init(), add a watch point on &sess->suggested_ssrc and figure out who sets it to 000000, that may lead us in the right direction. Incriminating evidence: 0:01:14.182943691 1718 0x9c7bd50 DEBUG rtpsession gst/rtpmanager/rtpsession.c:1538:obtain_internal_source: creating new internal source 00000000
As I said the server sets SSRC to 0 for both audio and video streams, it's hardcoded. We don't need a random value here in our simple case. Indeed there's no RTP/RTCP for audio at stream start, it comes a few seconds later. You should see it in the logs.
Both client and server have 0 as the SSRC? which ones do you set manually to 0? (both client and server?)
From what I understand (and from the tcpdump) the client never sends anything. But, for some reason, rtpsession thinks the SSRC of the internal RTPSource is 0. I think we should be able to reproduce with the pcap log and "filesrc ! pcapparse ! identity sync=1 ! rtpbin".
I've tried using the same setup, but using SSRC 0x1234 in the server instead of 0, and it works. I'm attaching the logs and pcap for this session.
Created attachment 276452 [details] *rtp*:9 log, server SSRC 0x1234
Created attachment 276453 [details] tcpdump capture of rtsp/rtp, SSRC 0x1234
The other bug has a patch, lets mark this one as duplicate. *** This bug has been marked as a duplicate of bug 730212 ***