[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] Clock skew and RTP
> 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: Dan Firac [mailto:danutf@redlinecommunications.ro]
> Sent: Friday, October 18, 2002 7:30 AM
> To: avt@ietf.org
> Subject: Re: [AVT] Clock skew and RTP
>
>
> 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" <fober@grame.fr>
> To: <avt@ietf.org>
> 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 <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