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: Julien Chavanton
Subject: Re: [Linphone-developers] Bug in adaptive jitter buffer
Date: Thu, 14 Nov 2013 10:24:13 +0100

Hi Frederik,

I looked at you patch, as far as can see in the source code,

The ctl->corrective_slide is used to correct time stamp  after the
packet is removed from the queue before queuing it for the decoder
filter.
It is not used for slide, gap, jitter, jitter_comp estimation.

How is this helping when getting the target ts returned by ?
jitter_control_get_compensated_timestamp

On Wed, Nov 13, 2013 at 11:59 AM, Frédérik Rouleau <address@hidden> wrote:
> 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
>
>
>
> _______________________________________________
> 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]