[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt



Stefan Döhla <stefan.doehla at iis.fraunhofer.de> writes:
>>> Then I think my assumption was correct, that you need to pre-filter the
>>> NTP timestamps so that they increase roughly linearly - but at least
>>> monotonically with each according RTP timestamp - otherwise it would be
>>> possible to align samples from several layers but it is no more
>>> guaranteed that they have the timestamps in correct order).
>>
>> I need an example to follow you here :-)
>
>The example would be related to the bad behaviour of some implementations
>that create quite rough RTCP SRs when it comes to timestamp creation. I
>think Asterisk was a good example of NTP timestamps that jump back and
>forth. If the same bad clock would be used to write the NTP timestamp for
>the HDR_EXT, then you would end up with subsequent packets where the RTP
>timestamp is e.g. monotonically increasing but the NTP timestamp is not
>because there's a high jitter added.

"jumping around" doesn't even come close to describing what Asterisk does
to RTCP timestamps.  "Virtually random" is closer, or "totally useless".

Sorry, sore point. 1/2 :-)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)