|Subject:||Re: [Linphone-developers] Bug in adaptive jitter buffer|
|Date:||Fri, 15 Nov 2013 09:16:17 +0100|
That way, we add an hysteresis in the slide and avoid packet lost by slide jittering.Then as you said, when we got a packet, we update the corrective_slide when the slide variration is above the corrective_step.Hi Julien,The the function jitter_control_get_compensated_timestamp is no more using slide but corrective_ts instead.
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.
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>
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
> 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
> 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>
>> > 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
> Linphone-developers mailing list
Linphone-developers mailing list
Linphone-developers mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|