[gst-devel] RTP depacketizer timestamps
Kai Vehmanen
kvehmanen at eca.cx
Tue Nov 8 14:15:15 CET 2005
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
More information about the gstreamer-devel
mailing list