Subject: [AVT] sender report rtp timestamp

From: "Matthew Heaney" <[email-masked]>
Date: Mon, 30 Dec 2002 14:58:57 -0500

Section 6.4.1 of the RFC describes the RTP timestamp of the RTCP sender report this way:

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.

Does anyone know how to calculate this?  I understand that an RTP timestamp has a start time (the initial value is random, and assigned at session-creation time), but how to you convert a NTP value to RTP timestamp format?

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

---

From: Stephen Casner <[email-masked]>
Date: Mon, 30 Dec 2002 12:42:04 -0800 (PST)

On Mon, 30 Dec 2002, Matthew Heaney wrote:

> 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.
>
> Does anyone know how to calculate this?  I understand that an RTP
> timestamp has a start time (the initial value is random, and
> assigned at session-creation time), but how to you convert a NTP
> value to RTP timestamp format?

I'm working on a note to describe how I think intra-media and
inter-media synchronization (e.g., audio/video lip sync) should be
implemented in RTP.  It is not complete, but below are the parts that
address the method for calculating the RTP timestamp corresponding to
the NTP timestamp in an RTCP SR packet.

An introduction to some of the notation (which is partially borrowed):

  First letter

    T = reference timestamp, often wall-clock (absolute) time, either
        in 64-bit fixed-point NTP format or in double-precision
	floating-point format

    M = media timestamp, i.e., the 32-bit RTP timestamp that ticks at
        the natural rate of the medium

    O = a media timestamp offset (difference between two timestamps)

    R = the clock rate for a media timestamp, in Hz

  Second or third letter

    l = local (that is L, not one)

    r = remote

    a = audio

    v = video

For example, Mla is the local audio clock, which represents both the
audio sample being captured at any instant and the sample being
rendered at the same instant, if the audio is full-duplex on the same
clock, or just the sample being rendered if the application is
receive-only.  Similarly, Mlv is the local video clock, but it may be
useful only for the capture side because the video capture and video
rendering may not be synchronous (even different frame rates).  This
is one reason why audio is more likely to be the master -- the audio
needs to be continuous, and video can be more flexible.  Per the RTP
spec, the Ml clocks are initialized with random values.

  - For each medium, maintain the relationship between local reference
    clock Tl (NTP timestamps) and local media clock Ml (RTP
    timestamps) for media clock rate R.  The result is an offset Ol,
    normally kept as a 32-bit integer:

	Ola = Mla - (Tl - Da) * Ra
	Olv = Mlv - (Tl - Dv) * Rv

    This is implemented by obtaining timestamp pairs Ml (the timestamp
    of the first sample in the block) and Tl (reference/system time)
    at each media input interrupt.  D is the (configured) estimate of
    the delay from capture of the first sample to the interrupt, in
    reference clock units (presumably a fraction of a second).  After
    multiplying by R, the whole part of the partial result is
    truncated to 32 bits (i.e., mod 2**32) to be subtracted from Ml.

    Since there is some interrupt jitter, we need to use a minimum
    filter to track the earliest interrupts, which all have delay
    values close to each other (that's D).  This minimum filter is
    relatively easy to implement because the time constant can be
    short, and it is robust because there are no shifts (assuming no
    overruns).  Ol changes (slowly) to track the skew between the
    local reference clock and media clock.

-   Since the local media clock is not directly readable, the offset
    Ol can be used to calculate the current value of the media clock
    at any time using the readable reference clock (usually the system
    clock):

	Mla = Tl * Ra + Ola
	Mlv = Tl * Rv + Olv

    Again here, the result of the multiplication is truncated to a
    32-bit integer (i.e., mod 2**32).  We don't have to worry about
    timestamp wraparound because this is all modulo arithmetic.

    This equation is used to calculate the RTP timestamps in RTCP
    Sender Report (SR) packets.  Whenever it is time to send an SR,
    the NTP timestamp for the SR is Tl and the RTP timestamp is Ml as
    calculated.  Note that Ml is generally NOT equal to the RTP
    timestamp in the last data packet transmitted since that timestamp
    would correspond to a reference timestamp at least D earlier (the
    capture delay).

To achieve sample-accurate synchronization, the reference time
corresponding to the media sample time must be obtained very
accurately.  In addition, the truncation of a fraction of a sample
time must be avoided in the calculations of Ol and Ml above.  It is
possible to keep Ol as a floating point number, but when calculating
the integer Ml is it necessary to fudge the value of Tl so that no
fraction is truncated.  This will affect the RTT calculation that can
be done with RTCP SR timestamps, but in most cases not significantly.
This level of accuracy is not necessary for typical audio/video
synchronization, but is necessary when synchronizing multiple channels
of audio sent in separate streams.

                                                        -- Steve