Re: [AVT] Clock skew and RTP

["Dan Firac" <danutf@redlinecommunications.ro>]

It's an interesting article. I've read it some time ago.
The question was not about if there are some clock skew estimation
algorithms,
and was a rather rethorical one about their computational cost and
performance.
So, let me put it another way:
Do you think it's worth implementing these algorithms on a DSP and run them
real-time ?
I think not.

The authors seemed to have run the algorithms AFTER collecting all the data,
and their results did not convice me.

Did you tried those algorithms ???

regards,
Dan.


----- Original Message -----
From: "Mike Marchywka" <mmarchywka@eyewonder.com>
To: "Dan Firac" <danutf@redlinecommunications.ro>; "Colin Perkins"
<csp@isi.edu>
Cc: <avt@ietf.org>
Sent: Monday, October 21, 2002 12:17 PM
Subject: RE: [AVT] Clock skew and RTP


> I did find this on citeseer:
>
> http://citeseer.nj.nec.com/moon99estimation.html
>
>
>
> -----Original Message-----
> From: Dan Firac [mailto:danutf@redlinecommunications.ro]
> Sent: Monday, October 21, 2002 3:57 AM
> To: Colin Perkins
> Cc: avt@ietf.org
> Subject: Re: [AVT] Clock skew and RTP
>
>
> Hi Colin,
>
> See comments below.
>
> ----- Original Message -----
> From: "Colin Perkins" <csp@isi.edu>
> To: "Dominique Fober" <fober@grame.fr>
> Cc: <avt@ietf.org>
> Sent: Friday, October 18, 2002 6:15 PM
> Subject: Re: [AVT] Clock skew and RTP
>
>
> > --> Dominique Fober writes:
> > >Thanks a lot for your replies. It answers my question: resuming the
> > >thread, it appears that RTP provides a mean to detect the clock skew to
> > >NTP synchronized hosts via the SR RTCP packets, but don't include
(itself
> > >or using a dedicated payload) an explicit solution.
> >
> > The mapping in RTCP SR packets is used for lip-synchronization, but is
not
> > needed to estimate clock skew between sender and receiver. The receiver
> can
> > estimate skew by looking at the relative offset between the RTP
timestamps
> > in packets it receives, and its local media clock.
> The problem with your solution is that the receiver measurements (your so
> called 'relative offset') contains the network jitter which can disturb
any
> skew estimation algorithm.
> There is some work about skew estimation algorithms, but what is their
> performance? and most of all, what is the cost?
> I've studied this problem a lot and I found that the most accurate measure
> (without network jitter) can be done only by the source which fills the SR
> RTCP packet with the two informations(local media clock + local system
> clock). In practice, the NTP skew is much less than the media skew, and
that
> makes this solution more simpler and more accurate than one with skew
> estimation.
> Anyway, the RTP rfc doesn't say that RTCP SR to be used ONLY for
> lip -synchronization (inter-media sinchronization).
> This is the RTP timestamp definition:
>
>     RTP timestamp: 32 bits
>              Corresponds to the same time as the NTP timestamp (above),
>              but in the same units and with the same random offset as
>              the RTP timestamps in data packets. This correspondence may
>              be used for intra- and inter-media synchronization for
>              sources whose NTP timestamps are synchronized, and may be
>              used by media-independent receivers to estimate the nominal
>              RTP clock frequency. Note that in most cases this timestamp
>              will not be equal to the RTP timestamp in any adjacent data
>              packet. Rather, it MUST be calculated from the
>              corresponding NTP timestamp using the relationship between
>              the RTP timestamp counter and real time as maintained by
>              periodically checking the wallclock time at a sampling
>              instant.
>
> >
> > Colin
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
>
> Best regards,
> Dan.
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt