|
From: | Frédérik Rouleau |
Subject: | Re: [Linphone-developers] Bug in adaptive jitter buffer |
Date: | Tue, 12 Nov 2013 18:18:58 +0100 |
Regards,On request, I can make a small sample code to demonstrate the problem.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.In my case, the problem occures frequently and the communication is very bad besides the low jitter of the received rtp flow.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 !The last line is the slide value of jitter struct of oRTP.The packet_ts line is the timestamp of the packet returned by oRTP (NULL if no packet).The 3rd line represent when the user is calling ortp_recvm_with_ts function, the 4th is the user_ts used as argument.The first line is the sender timestamp, the second line when the network stack is receiving the packet.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
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).
jitter.patch
Description: Binary data
[Prev in Thread] | Current Thread | [Next in Thread] |