Re: [AVT] Clock skew and RTP

["Dan Firac" <danutf@redlinecommunications.ro>]

 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