Subject: Re: [AVT] Clock skew and RTP

From: "Dan Firac" <[email-masked]>
Date: Fri, 18 Oct 2002 13:30:01 +0200

Hi,

 Clock-skew can be compensated at receiver side using the information
contained in RTCP Source Reports. To be more specific:
- RTP Timestamp field, which is a measure of the producer clock
(units=samples)
- NTP time, which is a reference time (units=seconds or subdivisions).
A difference between two succesive Source Reports would mean:
- timestamp difference (ts_diff1)= how many samples where produced between
reports
- NTP time difference (ntp_diff)= real interval between reports.

 Assuming that source and receiver are NTP synchronized (they have the same
reference time),
and assuming that the receiver can measure its own consumer clock, then the
receiver can compute how sample can consume(ts_diff2) in an interval of
ntp_diff seconds.

So, the receiver has to insert a number of samples equal to
(ts_diff2-ts_diff1) in over an ntp_diff time interval in order to compensate
skew. If the number of samples to insert is <0, then, of course, the
receiver has to drop that number of samples.

And another thing: clock skew has a cumulative effect, so it is easier to
wait until the number of samples to compensate reach f.e. 30ms (240 samples)
and to drop/insert a 30ms packet.

Best regards,
Dan.

----- Original Message -----
From: "Dominique Fober" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 18, 2002 10:40 AM
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               <[email-masked]>
> ----------------------------------------------
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Mike Marchywka" <[email-masked]>
Date: Fri, 18 Oct 2002 07:09:45 -0400

> 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: Dan Firac [mailto:[email-masked]]
> Sent: Friday, October 18, 2002 7:30 AM
> To: [email-masked]
> Subject: Re: [AVT] Clock skew and RTP
> 
> 
>  Hi,
>

---

From: "Mike Marchywka" <[email-masked]>
Date: Fri, 18 Oct 2002 07:36:23 -0400

( re-post, earlier post apparently got lost ...) 

Mike Marchywka
Chief Scientist
EyeWonder Inc.
2859 Paces Ferry Rd
Suite 1200
Atlanta GA 30339
770-261-5084

> From: Alan Clark [mailto:[email-masked]]
> Sent: Friday, October 18, 2002 7:10 AM
> To: Dominique Fober; [email-masked]
> 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
> 
> 
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Dominique Fober
> Sent: Friday, October 18, 2002 4:40 AM
> To: [email-masked]

---

From: John Lazzaro <[email-masked]>
Date: Sun, 20 Oct 2002 17:50:09 -0700

> Dave Singer <[email-masked]> writes:
>
> Unless you are 
> lucky and there are frequent silence intervals (common in telephony 

MIDI applications are lucky too in this regard -- coding music as a
sequence of discrete gestures simplifies this particular issue (but
complicates many others!).

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Mike Marchywka" <[email-masked]>
Date: Mon, 21 Oct 2002 09:46:16 -0400

> 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.

> Sent: Monday, October 21, 2002 9:58 AM
> To: Mike Marchywka
> Cc: [email-masked]
> 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.
> 
> 
> From: "Mike Marchywka" <[email-masked]>
> To: "Dan Firac" <[email-masked]>; "Colin Perkins"
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, October 21, 2002 12:17 PM
> > I did find this on citeseer:
> >
> > http://citeseer.nj.nec.com/moon99estimation.html
> >
> >
> >
> > Sent: Monday, October 21, 2002 3:57 AM
> > To: Colin Perkins
> > Cc: [email-masked]
> > Hi Colin,
> > See comments below.
> > From: "Colin Perkins" <[email-masked]>
> > To: "Dominique Fober" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, October 18, 2002 6:15 PM
> > > --> 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