[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

Wim Taymans <wim.taymans> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEEDINFO

--- Comment #10 from Wim Taymans <wim.taymans at gmail.com> 2013-06-26 14:23:12 UTC ---
(In reply to comment #9)
> No, I propose it the other way round. 
> I like to kinda buffering (not drop) rtCp packets on the receiver side if
> there's already a RTP packet received, but the rtpbin has not yet a session
> opened for it.

what do you mean with 'session open for it'?

> 
> At the moment (with the patch) the receiver rtpbin is dropping RTCP packets if
> they receive shortly after the first RTP packets (up to 4 RTP packets) -

no RTCP is ever dropped AFAIK, where do you see this being dropped?

> depending on the debug level. So either speed up the rtp-session setup or queue
> RTCP packets while processing RTP (setup the rtpsession).

I don't understand what you mean..

> 
> The rtp packets are buffered in the jitterbuffer, so while they are in the
> jitterbuffer their timestamps can be adjusted with the RTCP timestamp!?

Yes, it can be done and that's what happens.

I don't undestand what this is about

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