Markus Hossner wrote:
Am 30.06.2009 12:40 Uhr, schrieb Simon Morlat:The reason for the RTP_TIMESTAMP_NEWER_THAN macro is that timestamps arecircular. 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 9000frame 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.
video timestamps in RTP always (typically?) grow by 90000 for each packet. if you change that, you'll break interoperability (actually, the rate was specified in the SDP part of the call setup). take a look at a SIP packet trace and you'll see the advertised rates.
I'd guess you're comparing the audio timestamp with the video timestamp - the two are *not* synchronized because the data rate is encoded in the timestamp (or at least, you need to divide by 90000 to get them in sync).
this code is attempting to keep the video in sync with the audio (and failing badly..). fixing this should help lip-sync issues too.
also worth noting that different audio codecs will have different timestamp intervals (G.722 is worth mentioning, because it pretends to be a narrowband codec as far as the audio timestamps, but is actually a wideband codec - leading to every implementer having to hard code around it...). for this code to work correctly the two rates (audio and video) need to be fished out of the SDP and the necessary divisions made...
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ QuteCom-dev mailing list QuteCom-dev@lists.qutecom.org http://lists.qutecom.org/mailman/listinfo/qutecom-dev
