[Top][All Lists]

[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: Fri, 15 Nov 2013 19:04:31 +0100

Hi Simon,

I have checked and your solution is also working but leads to make twice more call to the OS network stack for 20ms ptime.

Otherwise I thought about my patch and found a far more simplier implementation. You just have to use obj->prev_slide instead of obj->slide in jitter_control_get_compensated_timestamp().

This is less intrusive to the existing code. It may be better then to rename prev_slide in something like buffered_slide to make it more explicit.

Here is the new patch. As far as I tested it, it is working well but I might not have reproduced all the case you have encountered.


2013/11/15 Frédérik Rouleau <address@hidden>
Hi Simon,

In fact in is not - strictly speeking- a rounding problem. When you compute the jitter, as the packet is shift from a sampling period, you have diff increased by 160 samples (ptime).
So as slide formula is: slide = prev_slide*(1-JC_BETA)+diff*JC_BETA, the slide offset is always sampling_period*JC_BETA.
Perhaps when could adjust the JC_BETA coef to make this offset below 1 but it is dependant of the sampling period.

If I poll every ptime/2, yes I would probably have all the packets. I can check this. But this looks for me like a workarround.

In my opinion, adding an hysteresys on the slide applied on the timestamp is a good improvement. As it has been done for the corrective_slide. Digging further, my implementation has bugs (corrupting in some condition packet timestamp returned) and certainly need to be improved.


2013/11/15 Simon MORLAT <address@hidden>
Hi Frederik,

Thank you for taking the time to explain this complex problem.
It looks to be a rounding problem, that produces when you request a jitter buffer size which is the same as polling period (20 ms). Your patch can certainly work for this case, however I feel that it would be safer to call rtp_session_recvm_with_ts() every 10 ms with timestamp incrementing by 80.
If my computation are good, the 1320 timestamp would have been returned.
What do you think ?


2013/11/14 Frédérik Rouleau <address@hidden>
Hi Julien,

I did not change how slide and other parameters are computed, I have juste changed how the slide is applied to get sender_ts. I have merged in the corrective_slide the previous corrective_slide and the initial slide.
The the function jitter_control_get_compensated_timestamp is no more using slide but corrective_ts instead.

Then as you said, when we got a packet, we update the corrective_slide when the slide variration is above the corrective_step.
That way, we add an hysteresis in the slide and avoid packet lost by slide jittering.

I could have add another parameter like effective_slide, it would have been cleaner but I wanted to avoid increasing to much the jitter structure. I you want I can provide you a patch using that alternative if you think it is better.


2013/11/14 Julien Chavanton <address@hidden>
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
It is not used for slide, gap, jitter, jitter_comp estimation.

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

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
>> >
>> >
>> _______________________________________________
>> Linphone-developers mailing list
>> address@hidden
> _______________________________________________
> Linphone-developers mailing list
> address@hidden

Linphone-developers mailing list

Linphone-developers mailing list

Linphone-developers mailing list

Attachment: 0001-Add-jitter-slide-hysteresis.patch
Description: Binary data

reply via email to

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