Created attachment 320021 [details] [review]
rtpjitterbuffer: Don't touch base_time when pipelines are synchronized

I have a rtpbin sender and receiver whose pipelines are synchronized with each other (the server exposes its pipeline's clock with a network clock provider and the client syncs its pipeline to this clock). rtpbin's ntp-sync property is set to TRUE and the buffer-mode property is set to clock-time on both.  Both also use the avpf rtp-profile.  I am using rtprtxsend and rtprtxreceive auxiliary elements to enable retransmits.

What I notice is that sometimes a receiver is not synchronized at all, or gets completely out of sync on some re-syncs.  Most of the time it's not audible, but in maybe 1% they get way out of sync, sometimes more than 1 or 2 seconds.  And once they are out of sync, they no longer get back into sync.  I observed that when this happens, the rtpjitterbuffer's ts-offset is set to that value.  I traced it back and from what I understand when this happens, the jitterbuffer's base_time gets set to this value.  But because both pipelines are synchronized, I don't think this should happen and base_time should always remain at -1.  This patch seems to fix this condition for me.  In fact, this value is set to something all the time, it's just usually small enough (e.g. 30ms or less) so you don't notice it.

The one thing I am not sure about is whether my setup is causing this or whether this is indeed a deficiency.  Here's the part that I am not sure about:  The sender rtpbin has one RTP session and broadcasts the data to multiple receivers using a multiudpsink.  I am not sure if the sender rtpbin session is able to distinguish who is sending it rtcp packets, and I wonder if the fact that I am broadcasting with multiudpsinks somehow causes either the sender rtpbin, receiver rtpbin, or both to misinterpret rtcp packets not meant for them, triggering this condition.