Markus, I'd suggest that you examine the timestamps in the RTP streams using wireshark, and tell us if you see somthing funny there.
Thanks Vadim Markus Hossner wrote: > Vadim, > > I've got no contact using QuteCom. I've tested it with the "Make test > call". I don't know if this is more QuteCom <=> QuteCom. > > The result: > > Timestamp 110160000 wanted. > Seeing packet with ts=10983330 > t1 - t2 < 1<<31 : 99176670 < 2147483648 > > Timestamp 110250000 wanted. > Seeing packet with ts=10990800 > t1 - t2 < 1<<31 : 99259200 < 2147483648 > > Timestamp 110340000 wanted. > Seeing packet with ts=11001060 > t1 - t2 < 1<<31 : 99338940 < 2147483648 > > Timestamp 110430000 wanted. > Seeing packet with ts=11009430 > t1 - t2 < 1<<31 : 99420570 < 2147483648 > > Timestamp 110520000 wanted. > Seeing packet with ts=11019330 > t1 - t2 < 1<<31 : 99500670 < 2147483648 > > > Wanted timestamp grows with +90000 > Seen timestamp grows with about +7500 > > > It's better than +10 to +90000, therefore t1 - t2 is growing less > rapidly which means you can talk more than 30 min. About 32 min I guess. > > Markus > > > Am 01.07.2009 17:44 Uhr, schrieb Vadim Lebedev: >> Markus >> >> I undestand is that your setup is Wengophone<=> QuteCom.... >> Can you test please QuteCom<=> QuteCom >> >> Thanks >> Vadim >> Markus Hossner wrote: >>> Hi >>> >>> >>> Am 30.06.2009 12:40 Uhr, schrieb 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) -:) ? >>>> >>> >>> So the problem lies in the packet timestamp. It should grow like the >>> wanted timestamp to prevent a difference greater than 1<< 31. >>> >>> >>> Markus >>> _______________________________________________ >>> QuteCom-dev mailing list >>> [email protected] >>> http://lists.qutecom.org/mailman/listinfo/qutecom-dev >>> >>> >>> >> >> > > _______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
