[Top][All Lists]

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

Re: [Linphone-developers] ortp: jitter buffer timestamp correction probl

From: Petr Kuba
Subject: Re: [Linphone-developers] ortp: jitter buffer timestamp correction problem
Date: Mon, 15 Mar 2010 12:21:27 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv: Gecko/20100227 Thunderbird/3.0.3

Hi Simon,

Thanks for response.

Your explanation confirms my expectations. However, it doesn't seem to work in my case.

Am I correct that the "small adaptations" are made by modifications of timetamps in received packets? That's how I understand the source code.

I know that in my case the clockrate is not exactly 8000. That's why I need the adaptive jitter buffer. My problem is that even after the adaptations done by the jitter buffer the packet timestamps do not correspond to my local time which causes buffer overflow after some time. You can see this in the example in my previous email below.

Shouldn't the jitter buffer adapt the timestamps so that they correspond (more or less) to the local time (i.e. time of the receiving machine? Otherwise, how can I know when to play a packet or when to drop some?


On 15.3.2010 12:02, Simon Morlat wrote:

The purpose of the 'adaptive' jitter buffer is to take in account the
fact that different devices or machines are not synchronised. During a
long call there might be several milliseconds difference.
The receiver adapts to the clockrate of the sender using the adaptive
jitter buffer. The way it works is by computing a mean of the difference
between local timestamps and remote received timestamps. When this
difference tends to increase or decrease, small adaptations are made,
which results in discarding one or more packets, or skip one or more
packet (that will be delivered a bit later, thus corresponding to a
silence if the result is played to a soundcard).
The 324ms observation probably corresponds to something that really
happened on the audio streams. You can check the clockrate by doing
(last_ts - first_ts)/(last_packet_time-first_packet_time), using a
wireshark capture. In many cases you will see it is not exactly 8000,
while it was really 8000 at the sender side.

Hope this helps.


Le vendredi 05 mars 2010 à 17:04 +0100, Petr Kuba a écrit :
Hi all,

could someone (probably Simon?) explain me how the "corrective_slide"
and timestamp correction mechanism in ortp works?

My idea was that the goal of this mechanism is to make the incoming
stream timestamps correspond to the local time. Am I right?

However, I'm experiencing the following situation. I use ortp with
adaptive jitter buffer and then I compare two packets of the same
incoming stream (values provided by ortp):

1) ts=2529404960, seq=22032, ssrc=0xd1824425
received at time 54652488 ms

2) ts=2534100160, seq=51371, ssrc=0xd1824425
received at time 55239064 ms

I'm using ulaw audio format where packets has 160bytes, which means 20ms.

And now:
- the difference between the times these packets were received is 586576
ms. This corresponds to 29329 packets.

- we received 29339 packets (seq difference)

- the difference between the timestamps is 4695200. This corresponds to
586900 ms, i.e. 29345 packets. Note that the timestamp values are
modified by the ortp adaptive jitter buffer.

I would expect the timestamp difference to correspond to the delivery
time difference but it seems to represent 586900 - 586576 = 324ms more.
So it looks like after 586576 ms of audio we received 324ms more than we
should. This causes us serious problems in synchronization of streams.

Do I miss something or is there anything wrong?

Thanks for help,
Petr Kuba

Linphone-developers mailing list

reply via email to

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