Subject: timstamps in rtp and rtcp?

From: "T.V.Rami Reddy" <[email-masked]>
Date: Wed, 02 Feb 2000 15:48:15 +0530

hi,
can anyone give the detailed difference between the rtp timestamp in the
rtp packet and timestamp in the rtcp SR packet.
suppose if an rtcp SR packet is send
rtcpSR------------ntp timestamp 2nd feb 2000  10:00:05   time stamp
1174(some value)
then let 4 rtp packets be send in the interval before an another rtcp SR
packet is send
rtp                1234
rtp                1394 (234+160 say)
rtp                1454 (1394+160 )
rtp                1514  (1454+160 )
rtcp SR   ------------ntp timestamp 2nd feb 2000 10:00:10   timestamp
will be  1234 or 1514 or ?

thanks,

---

From: Colin Perkins <[email-masked]>
Date: Wed, 02 Feb 2000 13:23:12 +0000

>will be  1234 or 1514 or ?

The RTP timestamp in an SR packet represents the time at which that SR
packet is generated (section 6.4.1 of draft-ietf-avt-rtp-new-05.txt).
Both NTP and RTP clocks are free-running, and are sampled at the instant
the packet is generated.

For example:

	NTP time		RTP time	
2 Feb 2000 13:15:00.000		1000		RTP
2 Feb 2000 13:15:00.020		1160		RTP
2 Feb 2000 13:15:00.030		1240		RTCP SR
2 Feb 2000 13:15:00.040		1320		RTP
2 Feb 2000 13:15:00.060		1480		RTP
2 Feb 2000 13:15:00.080		1640		RTP
2 Feb 2000 13:15:00.100		1800		RTP
2 Feb 2000 13:15:00.120		1960		RTP
2 Feb 2000 13:15:00.140		2120		RTP
...				...		...

The SR packets provide a mapping between the RTP clock and the NTP clock,
so that RTP data packets don't need to include the NTP timestamp.

Colin

---

From: Stephen Casner <[email-masked]>
Date: Wed, 2 Feb 2000 11:04:16 -0800 (Pacific Standard Time)

> will be  1234 or 1514 or ?

Essentially the same question was asked on this list two weeks ago.
The RTP spec says:

        NTP timestamp: 64 bits
             Indicates the wallclock time (see Section 4) when this
             report was sent ...

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

Please let me know whether the text above is unclear or hard to find
in the document so we can improve it for the next revision.

The method I recommend to calculate the RTP timestamp for the RTCP SR
packet is as follows.  Periodically, at the time a sample buffer
completes, establish a correspondence between the RTP timestamp that
will correspond to the first sample in that buffer and the time that
sample was taken according to the clock used for the NTP timestamps.
That time is usually the current time minus the duration of the buffer
and some allowance for interrupt or operating system latency.

The correspondence is an offset in RTP timestamp units:

  offset = (int32)(current_NTP_time * RTP_timestamp_clock_rate) - RTP_timestamp

where current_NTP_time is in seconds and fraction.  The calculation
can be done in floating point (double precision) or with
multiple-precision integer arithmetic.  In both cases, there will be a
truncation to get the 32-bit integer offset and RTP timestamp.

You don't need to do this calculation on every sample buffer, just
often enough to accommodate the drift between the sampling clock and
the clock used for the NTP timestamps if these come from different
oscillators (for example, a crystal on the audio board and a crystal
on the motherboard from which the operating system clock is derived).
If both clocks are derived from the same oscillator, you only need to
establish the correspondence once because there will be no drift, but
then the NTP times are probably not synchronized with Network Time
Protocol to absolute time.  Ideally, the capture interrupt routine
would return a timestamp for the capture time from which you could
form the NTP timestamp.

After you have calculated the offset, then when it is time to send an
RTCP SR packet, you get the current NTP time and calculate the RTP
timestamp for the SR packet as:

  RTP_timestamp = (int32)(current_NTP_time * RTP_timestamp_clock_rate) - offset

I think this is pretty easy.

Generating these timestamps accurately is critical for the receivers
to be able to use them for inter-media synchronization.
Unfortunately, if the server does a bad job of it, then it is the
receiver that looks bad because the presentation is out of sync.
(Of course, the receiver can also mess up the synchronization even
when it is given good timestamps.)
							-- Steve