[Top][All Lists]

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

[Linphone-developers] ortp: jitter buffer timestamp correction problem

From: Petr Kuba
Subject: [Linphone-developers] ortp: jitter buffer timestamp correction problem
Date: Fri, 05 Mar 2010 17:04:19 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv: Gecko/20100216 Thunderbird/3.0.2

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

reply via email to

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