Re: [Ccrtp-devel] Finding out packet timestamps

[Federico Montesino Pouzols]

There is no such mechanism in ccRTP at this time. If the app asks for
a packet, it is provided without delay. The problem with disordered
packets is how much you want to wait for them to arrive before giving
up and using the first available packet regardless of order.

You can wait for disordered packets if for example you ask for a
packet (that should arrive at time t0) at time t0+t1. Usually, you
know the expected timestamp of the next (ordered) packet, so you can
compare with getFirstTimestamp() and decide whether to wait for some
time. A simple way to provide some time for reordering is adding an
artificial delay just after you get the first packet in a stream. Of
course, you do not have to care about RTP sequence numbers, these are
transparently handled by ccRTP.

In old versions of ccRTP there was a method for adding a delay, but it
was dropped. I think that if we come up with a clear, simple and
flexible interface, it could be added back again, probably with some
dynamic adaptation mechanism such as those based on jitter that you
mention.

On Tue, Mar 08, 2005 at 11:40:37PM +0100, Claude Brisson wrote:
> Does it mean that after evaluating the jitter for a given source, the
> stack will wait for a short while after it receives a packet, and before
> providing it to the app, to be sure it won't receive a newer packet ?
> 
> Otherwise I don't understand how the reordering can work. If packet 2
> arrives before packet 1 and if getData(getFirstTimestamp()) is called
> still before packet 1 is received, there won't be any reordering.
> 
> Can you give me some light ?
> 
> --
> Claude
> 
> On Mon, 2005-02-07 at 17:04 +0100, Federico Montesino Pouzols wrote:
> > Yes, getFirstTimestamp will always return the timestamp of the first
> > packet in the queue, and the queue is transparently ordered. That's
> > why you do not need direct access to the packet timestamp in the most
> > external interface. ccRTP handles reordering. 
> >