[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ccrtp-devel] Finding out packet timestamps

From: Federico Montesino Pouzols
Subject: Re: [Ccrtp-devel] Finding out packet timestamps
Date: Wed, 9 Mar 2005 11:06:46 +0100
User-agent: Mutt/1.5.6+20040907i

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

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. 
> > 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]