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

[Frédérik Rouleau]

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.

Regards,

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.

Regards,

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 ?

Simon

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.

Regards,

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
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
>

_______________________________________________
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

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