GNOME Bugzilla – Bug 764447
RTPSession sent RTCP before RTP traffic
Last modified: 2016-04-01 09:53:15 UTC
When dealing with a client that uses live555 for example, an RTCP SR+SDES is only sent after the receiver sends its RTCP packet. This causes an RTCP sync and as a consequence the clients buffer is dropped and there is video corruption. It is quite easy to reproduce, just pick a gst-rtsp-server example and connect to it with vlc. Tested on 1.6.3 and 1.8. I created a ticket on VLC and they helpfully responded here https://trac.videolan.org/vlc/ticket/16774 citing that the recommended behaviour is sending RTCP info before starting RTP traffic. I have been looking at the rtp sources and haven't found out how exactly to implement this. At the moment I am disabling RTCP by setting the allowed bandwidth to 0 as a workaround to avoid video corruption on the client side.
You can't (always) send RTCP before RTP (only in RTP/AVPF profile if there is only one sender and receiver) without going against the RTP RFCs, and even if you do you can't guarantee that it actually arrives before the first RTP packet.
What about sending it as soon as possible, there should be a time window while the client is buffering (if it does). Otherwise should we leave things as is?
It's already sending as soon as possible :) With RTP/AVPF that would be immediately if only one sender/receiver, otherwise at some random time around 2.5s after the sending started as defined by the RFC.
Thank you for your help. So I guess it is up to the received to decide if it should wait for the RTCP SR until it starts playback. When I use gstreamer as a client the behaviour is different, it shows the first frame then seems to pause until the RTCP packet is received. After that playback continues without any discontinuity.
The receiving side also can't assume that there will be RTCP. It should work without and if there is RTCP at some point make use of it. GStreamer is not waiting for RTCP, the stopping you see there might just be the buffering that happens for non-live streams or the latency handling. Let's close this then for now. Feel free to reopen if there's something new :)