[gst-devel] RTP depacketizer timestamps

[Kai Vehmanen]

Hi,

On Fri, 4 Nov 2005, Sebastien Cote wrote:

> I think there's a bug in the way the base RTP
> depacketizer class sets the timestamp on the new
> segment event when the queue is in use.
[...]
> I think the queue length should also be added on the
> new segment's timestamp. Then, the new segment and the
> first buffer will have the same timestamp.

comments anyone?

Should we in fact add any delay to the newsegment 'start_time'? We already 
delay packets by 'queue_delay' msec in 
gst_base_rtp_depayload_queue_release(). Then when we push the first packet 
out and call gst_base_rtp_depayload_push(), we send out a newsegment event 
with a 'start_time' of the buffer's timestamp, but immediately after, we 
increase the packet's timestamp again by '(filter->queue_delay * 
GST_MSECOND)', and then push the buffer forward.

If I've understood right, gstbasesink.c will wait for queue_delay msecs 
before starting to play the first buffer. Aren't we adding the delay twice 
here?

> I attached a patch that fixes this. What do you guys
> think?

If the above is right, this patch should work better, as the newsegment 
start_time and the first packet pushed forward have same timestamp. But I 
guess we could also drop the queue_delay offset from newsegment as 
well...?

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