[Bug 761297] New: jitterbuffer: Do not mess with the base time in sync mode

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=761297

            Bug ID: 761297
           Summary: jitterbuffer: Do not mess with the base time in sync
                    mode
    Classification: Platform
           Product: GStreamer
           Version: 1.6.3
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: gstblub at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 320021
  --> https://bugzilla.gnome.org/attachment.cgi?id=320021&action=edit
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.