Re: [Linphone-developers] Re: Video freeze after ~30 min (reproducible) (CAUSE + WORKAROUND)

[Simon Morlat]

The reason for the RTP_TIMESTAMP_NEWER_THAN macro is that timestamps are 
circular. Using > won't work in all cases. Indeed 0 is newer than (2^31)+1.
It seems that the problem is that both timestamp don't grow identically.
Having a video timestamp growing by +10 is problematic. It would mean that 
video frames are separated by 10/90000=1.1111e-04 s, so a framerate of 9000 
frame per second. Are you inventing a new VVHD standart (Very Very High 
Definition) -:) ?

Simon


Le mardi 30 juin 2009 02:11:59, Vadim Lebedev a écrit :
> Simon,
>
> What di you think about it?
>
>
> Thanks
> Vadim
>
> Le 30 juin 09 à 00:31, Markus Hossner a écrit :
> > Hi,
> >
> > I found the cause for the ~30 min video picture freeze it lies in
> > rtp_getq_permissive (qutecom-2.2/wifo/ortp/src/rtpsession.c)
> >
> >
> > This function tests if the packet queue (video) is empty. If it is not
> > empty it checks if the first packet in the queue has a timestamp which
> > is newer than the timestamp that was hand over as parameter. In that
> > case the first packet in the queue is returned. If not no packet is
> > returned.
> >
> > This is what the function should do. The problem is that the parameter
> > timestamp (wanted) and the packet timestamp (seen) have no connection.
> > At least it seems to me that there is no connection:
> >
> > ...
> >
> > Timestamp 2305800000 wanted.
> > Seeing packet with ts=158855220
> >
> > Timestamp 2305890000 wanted.
> > Seeing packet with ts=158862330
> >
> > Timestamp 2305980000 wanted.
> > Seeing packet with ts=158869620
> >
> > Timestamp 2306070000 wanted.
> > Seeing packet with ts=158876730
> >
> > ...
> >
> > The two timestamps grow with different speed (t1: +90000, t2: +10).
> > The
> > wanted timestamp (t1) grows faster than the seen timestamp (t2). So
> > there should be no problem. t2 will always be newer than t1 (unless
> > there is a overflow). But the problem is how the test ist done. To do
> > this test the macro RTP_TIMESTAMP_IS_NEWER_THAN is used which uses the
> > following:
> >
> > t1 - t2 < 1<<31
> >
> >
> > I don't know why this test is done like this. But as t1 grows faster
> > than t2 after some time (~30 min) t1 - t2 >= 1 << 31. And therefore no
> > more packets are taken from the full queue.
> >
> >
> > A easy workaround should be to just skip the strange timestamp is
> > newer
> > test.
> >
> > Nicer would be if the function could be fixed to do a real check if
> > the
> > queue timestamp is newer or equal the wanted timestamp.
> >
> >
> > I hope this helps
> >
> > Markus
> > _______________________________________________
> > QuteCom-dev mailing list
> > address@hidden
> > http://lists.qutecom.org/mailman/listinfo/qutecom-dev
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers