Vadmin, analysing a "test call" with wireshark. H.263 packets:
Incoming: TIME: Info 252.453727 ... Seq=48517, Time=73170 252.533420 ... Seq=48518, Time=83880 252.653552 ... Seq=48519, Time=91080 +0.0998 +8955 Outgoing: TIME: Info 252.290001 ... Seq=78, Time=175410 252.409980 ... Seq=79, Time=182610 252.490346 ... Seq=80, Time=193320 +0.1001 +8955 The packet timestamp grows with 8955 not with 90000. I guess TIME is in seconds so every 0.1 secs a new packet arrives. Markus Am 01.07.2009 18:48 Uhr, schrieb Vadim Lebedev: > 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
