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 > > QuteCom-dev@lists.qutecom.org > > http://lists.qutecom.org/mailman/listinfo/qutecom-dev > > _______________________________________________ > Linphone-developers mailing list > linphone-develop...@nongnu.org > http://lists.nongnu.org/mailman/listinfo/linphone-developers _______________________________________________ QuteCom-dev mailing list QuteCom-dev@lists.qutecom.org http://lists.qutecom.org/mailman/listinfo/qutecom-dev
