rtpbin, jitterbuffer: ts-offset on RFC7273 synchronized streams

Submitted by Michael Tretter @m.tretter

Link to original bug (#793513)

Description

The rtpbin sets the ts-offset on rtpjitterbuffer to synchronize multiple SSRC for one CNAME based on the timestamps in the SR. The offset is added to the buffer pts after the pts has been calculated from the rtptime.

However, I use RFC7273 to already synchronize RTP streams between multiple clients and the rtpjitterbuffers already calculate a synchronized pts. The additional offset breaks the synchronization again. Therefore, I don't want the rtpbin to add a ts-offset to the streams if the pts is already in sync.

I added a check in the rtpbin, if rfc7273-sync is set and skip the synchronization in these cases and with this change, my streams are in sync. However this is not really a fix, because the rfc7273-sync can be also set if the SDP does not announce an RFC7273 clock. In this case, the rtpbin should synchronize the streams.

If there is only one SSRC, there not an issue, because then the rtpbin does not add the offset, but I want separate streams for audio and video to avoid the additional latency for muxing and demuxing.

Maybe we can add a property to the rtpjitterbuffer if the produced pts are already synchronous to a wall clock or if the rtpbin should take care of synchronization.

Any thoughts?