[Bug 691400] 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

--- Comment #8 from Wim Taymans <wim.taymans at gmail.com> 2013-02-20 20:16:26 UTC ---
(In reply to comment #6)
> >It sounds like you want to quickly synchronize streams. You can't do this
> >reliably with RTCP, you need RFC 6051.
> yes, I want to quickly synchronize streams. Audio recorded from A-Device
> synchronized played out with low latency on B-Device and C-Device (inter device
> sync). A,B,C-Device are ntp synced. 
> How long will it take till RFC 6051 is available in gstreamer? (acc. to
> http://gstreamer.freedesktop.org/wiki/ReleasePlanning/RoadMap it's this
> month?;)

There is no schedule for this, it will happen when it happens.

> Despite it's not reliable - might a short term solution is that the receiver
> bin is kinda buffering rtcp a SR when there's already a rtp package received
> and has not already completely processed the rtp package to setup the
> rtpsession!? And might this feature is only enabled if the ntp-sync property is
> set.

I don't quite understand what you propose but I think you propose to queue rtp
packets until you get an RTCP packet, then output the queued rtp packets with
proper timestamps as calculated from RTCP. I think this option is not so
interesting because there might be a lot of time between receiving RTP and the
RTCP packet, you would likely exceed the latency configured in the pipeline.

What sounds like a better idea is to simply drop RTP packets until you get an
RTCP packet. That doesn't sound like something complicated to implement and
would accomplish basically the same thing (you might loose a couple of packets
before the RTCP that you could have played maybe)

-- 
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.