[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Clock skew and RTP
> Did you tried those algorithms ???
I didn't actually read this article, I thought it or references
may be useful to someone. So, I don't know if I've tried them or
not :). Its not exactly a comprehensive literature search
but it may be a good starting point for someone- I'm just
trusting that peer review makes citeseer results worth posting
( I don't think all citations are peer reviewed but many of them are).
The problem I actually worked on was slightly different- it involved
two ( or three, depending on how you count ) similar time bases
and a need to lock one( or two) to the other. There
was no network involvement ( at least not in this part of the problem).
If I look into this, I'll let you know.
Thanks.
> -----Original Message-----
> From: Dan Firac [mailto:danutf@redlinecommunications.ro]
> Sent: Monday, October 21, 2002 9:58 AM
> To: Mike Marchywka
> Cc: avt@ietf.org
> Subject: Re: [AVT] Clock skew and RTP
>
>
> 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