[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Clock skew and RTP
( re-post, earlier post apparently got lost ...)
> What's the common way to solve this problem (if there is one) ?
> are there any mecanism and/or payload defined in RTP ?
Other than telling the recipient where to look for a (common) timebase, I don't
know how you could handle this with a RTP mechanism. If you insist on
independent timebases at source and receiver or the receiver can't
"look" at it's NIST WWV receiver ( this is a US standard time station http://www.boulder.nist.gov/timefreq/ )
then one option is to lock
the receiver timebase to the source timebase using a phase locked loop. In principle,
you could record the arrival time of each packet and derive the
average "real"-time clock rate that the sender is using relative to
your "real"-time clock rate ( receiver uses virtual_time = alpha*local_real_time
where alpha is derived from reception rate and should be near unity[ or else
you have really big problems :) ] ). The trick, of course, is like with any other
pll or fll design, to estimate alpha in an acceptable way.
This is similar to your suggestion but allows a little more control-
alpha will probably differ from unity by an amount much less than the arrival
time fluctuations ( clocks are better than the internet :) ).
This is the first thing that came up on Google for those
of you unfamiliar with plls : http://www.circuitsage.com/pll.html
this links to http://www.cmitech.co.kr/system/pdf/Pll.pdf which may be more relevant
(I haven't actually read these myself... ).
I've used something like this
with an audio player whose nominal sample rate didn't seem to be synced to the
operating system's "real"-time clock. It addresses a common problem of having to
sync different time bases when you only have a few time points for comparison and
some jitter in the master timebase.
Mike Marchywka
Chief Scientist
EyeWonder Inc.
2859 Paces Ferry Rd
Suite 1200
Atlanta GA 30339
770-261-5084
> -----Original Message-----
> From: Alan Clark [mailto:alan@telchemy.com]
> Sent: Friday, October 18, 2002 7:10 AM
> To: Dominique Fober; avt@ietf.org
> Subject: RE: [AVT] Clock skew and RTP
>
>
>
> This is a problem that dates back many years and applies
> equally to circuit
> switched networks (i.e. timing slip).
>
> For bidirectional streams the classic solution is to lock one
> clock to the
> other - typically using one as the timing source and running
> the other in
> loop back mode.
>
> For audio applications, where you may be dependant on
> non-adjustable sample
> rates for playout, the solution may be to measure the rate of
> clock drift
> and then either
>
> (a)inject interpolated samples or
> (b)delete a sample then smooth
> - in order to maintain a constant mean playout buffer level.
> (c)use a large buffer
>
> Regards
>
> Alan Clark
> Telchemy
>
>
> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of
> Dominique Fober
> Sent: Friday, October 18, 2002 4:40 AM
> To: avt@ietf.org
> Subject: [AVT] Clock skew and RTP
>
>
> I would like to know if there is any mecanism and/or payload defined
> to take account of the clock skew problem. To be more
> explicit, here is
> a brief description of what I mean by 'clock skew problem':
>
> Clocks on different stations are not running at the same frequency
> (we have commonly measured clock deviations up to 1 per 10000 ms).
> For real-time transmissions, it results in a problem similar to a
> consumer / producer problem.
> Let's take an example with a sender host A (the producer) and
> a receiver
> host B (the consumer):
> if the consumer consumes the events faster than produced (the
> B clock is
> running faster than the A clock), it will unavoidably lack data in a
> given delay,
> if the consumer consumes the events slower than produced,
> (the B clock is
> running slower than the A clock) it will unavoidably
> accummulate more and
> more data, resulting sooner or later in storage capacity problems.
>
> Real-time streaming multimedia applications are generally buffering
> up to several seconds of data in order to make up for the transport
> latency variations. Therefore side effects of the clock skew aren't
> noticeable unless the transmission lasts several hours.
>
> What's the common way to solve this problem (if there is one) ?
> are there any mecanism and/or payload defined in RTP ?
>
> ----------------------------------------------
> Dominique Fober <fober@grame.fr>
> ----------------------------------------------
> GRAME - Centre National de Creation Musicale -
> 9 rue du Garet 69001 Lyon France
> tel:+33 (0)4 720 737 06 fax:+33 (0)4 720 737 01
> http://www.grame.fr
>
>
> _______________________________________________
> 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