[gst-devel] RTP clocking issue

[Kai Vehmanen]

On Tue, 8 Nov 2005, Zeeshan Ali wrote:

> 2. Make the rtpbin/depayloader translates the timestamps on the
> packets according to the pipeline clock, *somehow* ? I dont know if
> that is possible or not and how. So please throw some light on this
> one.

So as the first step, how about adding code to gstbasertpdepayload.c
that checks if the pipeline and network have gone out of sync, and if yes,
resync by sending a gst_event_new_newsegment() downstream.

The out-of-sync scenario has happened if a) queue is continuosly empty in 
gst_base_rtp_depayload_queue_release(), or b) queue has reached maximum 
size, for example 2*target-delay, in gst_base_rtp_depayload_chain().

This would fix the current problem of RTP reception stalling if clocks 
drift out of sync for some reason (not just because of clock drift, but 
possible network trouble, bugs on the sender side code, etc, etc). Once 
someone implements a drift compensation algorithm, this fix won't be 
needed anymore (at least as often), but still serves as a backup to make 
sure reception won't stall.

Is this doable? I'm not that familiar with newsegment, but based on
reading of...
   - http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstEvent.html#gst-event-new-newsegment
...it could be used, not just for initializing, but also to reset the 
rtp-timestamp<->gst-timestamp mapping.

--
  under work: Sofia-SIP at http://sofia-sip.sf.net