RE: [AVT] Clock skew and RTP

["Mike Marchywka" <mmarchywka@eyewonder.com>]

Multiple real-time clocks can be  annoying. There is always a cost benefit issue
to consider. Someone suggested dropping or adding silence data once
clock descrepancies are detected. This strikes me as kind of artifact-prone but
my solution ( using Fourier interpolation to change the sample rate after syncing
with a PLL )
would be much too expensive for a lot of applications. However, the more
general issue of time base synchronization can not always be resolved by
making steps in time ( adding or deleting a block of make-up time ).
Oddly enough, the opposite problem of undesired synchronization can show up
in some systems by mechanisms normally thought of
as too weak to matter ( this is kind of cool:  http://www.physics.gatech.edu/schatz/clocks.html  )


I'm still not sure about terminology here, however. I thought clock skew
was an instantanious difference between two media streams ( say audio and video)
that are sent at the same rate as opposed to the issue here of having two 
clocks with different scale factors  ( one is a little faster than the other).


-----Original Message-----
From: Chuck Harrison [mailto:cfharr@erols.com]
Sent: Friday, October 18, 2002 12:25 PM
To: Dominique Fober
Cc: avt@ietf.org
Subject: Re: [AVT] Clock skew and RTP


Dominique, all,

Dominique Fober wrote:
> 
> 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.
> In fact, I was not looking for a concrete solution but rather trying to clarify this point. An interesting thing in your feedback is also to get different points of view and practices concerning the problem (including contextual solutions). Additional feedback in this domain is welcome (if there is) and notably concerning video (may the problem be considered as equivalent in the audio and video domains).

I was looking at this a year or so ago and felt that it would be
useful to develop specific tools to control skew. I have attached
a draft I produced at the time, but it was a one-man project which
definitely would need more participation to go anywhere.

FWIW it seems that the current "professional quality" audio
systems like CobraNet and Gibson Magic operate at layer 2
Ethernet and stay away from IP entirely. However I saw a vendor
at IBC this year (Aaton, of Grenoble) offering sync-over-IP for
film-to-video transfers; no details.

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