Don't throw away the first RTCP packet if it arrives before the first
RTP packet but remember and use it to signal sync once we get the
RTP packet.
See https://bugzilla.gnome.org/show_bug.cgi?id=691400
Also send stream-start and segment event on the RTCP pad.
We don't need to send anything on the sync_src pad because we
already forwarded all incomming events.
Otherwise we get a race where if the RTCP packet comes in first and while
it is added the pads, the segment event arrives on the RTP stream, the event
may be lost completely and never forwarded.
change_ssrc field of RTPSession should be set before calling
rtp_session_schedule_bye_locked () as this function will call reconsider function
that will wake up rtcp_thread which will call rtp_session_on_timeout () that will
check change_ssrc to change the ssrc.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=694184
Only delay the RTCP thread when we are a sender, which we can know because we
have a send_rtp_src pad. Otherwise we might delay the RTCP thread if we
are only a receiver and then there is no code path that wakes up the
RTCP thread and we end up without RTCP packets.
Delay sending the first RTCP packet until we have sent the first RTP packet.
Otherwise we will send out a Receiver Report instead of a sender report.
See https://bugzilla.gnome.org/show_bug.cgi?id=691400
Move the work of cleaning up the client streams in the free_stream
function. This allows us to properly clean up the client streams when we
remove an RTP stream as well.
Based on patch by Sujay <sdatar@cisco.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=660156
Only run the skew estimation code when we have a new RTP timestamp. If we have
the same RTP timestamp, we simply use the previous estimation. This works
because the new observation with the same RTP timestamp has to have a bigger
receiver time and is thus not going to influence the estimation except for
causing more jitter.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=640023
Move the code that combines the last SR packet and the current jitterbuffer sync
values into a sync structure, into its own function. We want to reuse this bit
later.
When we make a mapping between an RTP timestamp and an NTP timestamp, include
the downstream latency applied to the sinks. This makes it possible to have
both sinks run with different latencies and still have correct sync on the
client. It also is more correct because the RTP timestamp in the SR report will
actually correspond more closely to the NTP time it was sent on the server.
For pipelines with high latency on the sender side, this actually allows a
GStreamer receiver to perform synchronisation instead of dropping the RTCP
packets.
There is no need to cast the event functions and only causes problems later when
we change the signature later and things silently compiles wrong code.
