linphone-developers
[Top][All Lists]
Advanced

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

Re: [Linphone-developers] Bug in adaptive jitter buffer


From: Frédérik Rouleau
Subject: Re: [Linphone-developers] Bug in adaptive jitter buffer
Date: Wed, 13 Nov 2013 11:59:32 +0100

I forgot that info in my previous email. The initial jitter buffer size is 20ms => 160 samples. So oRTP is using the received packet to fill the buffer.
The sender ts is the timestamp of received packet (the one in the RTP packet). The user_ts is the user timestamp used when we call rtp_session_recvm_with_ts.

Regards



2013/11/13 Julien Chavanton <address@hidden>
Hi Frederik, we are also facing small problems and limitations in the
Jitter buffer implementation of Linphone. (I will take more time
elaborate more later in another post)

Something I do not understand in your explanation, why you have a NULL
timestamp at tick 160, since there was a packet received and the slide
as changed ?

What is the different between sender_ts and packet_ts ?



On Tue, Nov 12, 2013 at 5:50 PM, Frédérik Rouleau <address@hidden> wrote:
> 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,
>
>
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/linphone-developers
>

_______________________________________________
Linphone-developers mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/linphone-developers


reply via email to

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