linphone-developers
[Top][All Lists]
Advanced

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

[Linphone-developers] Bug in adaptive jitter buffer


From: Frédérik Rouleau
Subject: [Linphone-developers] Bug in adaptive jitter buffer
Date: Tue, 12 Nov 2013 17:50:23 +0100

I recently had to investigate bad quality communication and then found a problem in the adaptive jitter buffer. I succeeded in reproducing it.
Let's see the following case:

sender ts       1000    1160  1320      1480    1640    1800
network       ---|-------|-----|---------|-------|-------|--
recv          --|-------|-------|-------|-------|-------|---
user ts         0      160     320     480     640     800
packet ts      NULL    NULL    1000    1160    NULL    1480
slide           0      840     840     840     839     840


The first line is the sender timestamp, the second line when the network stack is receiving the packet.
We can see that as the receiving time is very close to the sampling time, the 3rd packet is received before the 3rd sampling. In fact the real jitter is very low (below 1ms).
The 3rd line represent when the user is calling ortp_recvm_with_ts function, the 4th is the user_ts used as argument.
The packet_ts line is the timestamp of the packet returned by oRTP (NULL if no packet).
The last line is the slide value of jitter struct of oRTP.

As we can see, the 5th call of oRTP is returning no packet and dropping a packet it should have returned. This is because of the slide computation. The remote ts is computed by adding from user_ts the slide and removing  the adaptiv_jitter_compensation (function jitter_control_get_compensated_timestamp). As the slide has been decreased by one, the jitter computed is to low and no matching packet is found in the packet's queue (packet already returned). The next run, the packet is dropped !

In my case, the problem occures frequently and the communication is very bad besides the low jitter of the received rtp flow.

The proposed patch is to include the slide in the corrective_slide value which evolves only by steps. This might not be the best way to solve this issue but I have nothing better right now ! We might also change the JC_BETA coef used to compute slide, but I thought it might have side effects.

On request, I can make a small sample code to demonstrate the problem.

Regards,


Attachment: jitter.patch
Description: Binary data


reply via email to

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