[Bug 691400] New: rtpbin rtpsession->RTCP thread is starting to early for ntp-sync

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=691400
  GStreamer | gst-plugins-good | unspecified

           Summary: rtpbin rtpsession->RTCP thread is starting to early
                    for ntp-sync
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: thomas at roosesweb.de
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=233057)
 View: https://bugzilla.gnome.org/attachment.cgi?id=233057
 Review: https://bugzilla.gnome.org/review?bug=691400&attachment=233057

RTCP startup delay patch

I want to use the ntp-sync property on the rtpbin element in order to get sync
audio playback on ntp synced devices.
I had a problem (see here:
http://lists.freedesktop.org/archives/gstreamer-devel/2012-December/038542.html
and
http://lists.freedesktop.org/archives/gstreamer-devel/2013-January/038673.html)
that the sending rtpbin is sending at first an RTCP SR or an RTCP RR randomly.
I looked into the code - the problem is that the RTCP and RTP thread are
starting in parallel. If the RTP thread has received RTP data from the RTP
payloader before RTCP thread is started it will send an SR. 
If the RTP thread has received no data from the RTP payloader it will send an
RR.
According to the rfc3550 this behavior is correct.
But if you want to use the ntp-sync mechanism on the receiver side it's
important that you have a SR with the RTP to NTP time correlation before you
start the playout - otherwise it will wait for the next RTCP packet (first
SR-report), which is sended with a min delay of 2s to get that correlation. And
if your playout has started already this time-jump will be audible...

I made a simple patch to delay the startup of the RTCP thread with a startup
delay timer (default 20ms) which will be stopped if either RTP data is ready to
send or received before the timer ends.

I would like to have at least some feedback on my ideas (am I right?) or have
some property to enable my patch in a future version of GStreamer.

cheers Thomas

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.