Subject: RE: [AVT] RTCP timestamp units

From: "Allison, Art" <[email-masked]>
Date: Wed, 20 Aug 2003 13:37:16 -0400

Colin
By saying (no guarantee of ... resolution) it seems you are saying that the
RFC does not actually require all 32 bits to be incremented. If so one can
chose how many bits to send with real values, and zero fill the rest.
 Is that correct?
I would think that the resolution would be the precision of the number, and
the value of the lsb would establish absolutely the resolution (but it may
be offset by an unknown amount from real time which offset could vary - i.e.
no accuracy).

Art
::{)
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Wednesday, August 20, 2003 12:11 PM
To: Avinash Bhatia
Cc: [email-masked]; Vivek Mudgil
Subject: Re: [AVT] RTCP timestamp units

On Thursday, Aug 21, 2003, at 02:42 Europe/London, Avinash Bhatia wrote:
>    I am facing an issue in inter-stream (audio-video) synchronization 
> between two RTP streams. The NTP-RTP timestamp correlation comes in 
> the RTCP packets, but the RFC does not specify the units in which the 
> NTP is to be specified. This causes a problem in calculating the 
> audio-video synchronization.
>    As far as I understand, the Synchronization is not possible unless 
> the unit of the NTP is known exactly, which can only be known after 
> the second RTCP packet arrives (from which you can indirectly judje 
> the NTP granularity and hence it's unit). Are there any known 
> solutions to this problem ?

RTP makes no guarantee of the accuracy or resolution of the clock the 
sender is using to generate the timestamp. However, the format of the 
timestamp is precisely specified in Section 4 of RFC 3550 (the upper 32 
bits are seconds, the lower 32 bits fractions of a second, since 1 
January 1900).

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
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: Colin Perkins <[email-masked]>
Date: Wed, 20 Aug 2003 19:17:21 +0100

Art,

> chose how many bits to send with real values, and zero fill the rest.

That's one possible implementation choice for generating the NTP-format 
timestamp in RTCP SR packets, yes. However, all 32 bits of the RTP 
timestamp MUST be incremented.

> be offset by an unknown amount from real time which offset could vary 

The sender may not know the resolution of its clock, and hence the LSBs 
of the NTP format timestamp may be garbage. I expect this will make it 
difficult to infer the characteristics of the clock from the timestamp 
values.

Of course, if RTP is used in a controlled environment, it may be 
possible to mandate that senders use a clock with tightly-specified 
characteristics in that environment.

-- 
Colin Perkins
http://csperkins.org/

---

From: Vivek Mudgil <[email-masked]>
Date: Thu, 21 Aug 2003 10:24:44 +0530

Section 4 of RFC 3550 clearly specifies that for RTP purposes, only 
differences between pairs of NTP timestamps are used. This implies that
for inter-media synchronisation, the receiver should have received at
least 2 RTCP SR reports. Which in turn imply that inter-media 
synchronisation in playback is only possible after a minimum of 5 sec 
(min RTCP Interval). Is this implication right or am I missing something?

Even if first NTP timestamp is used for synchronisation,, assuming that
the NTP time stamp is provided as specified in Section 4, how will a
receiver synchronise the two media till the first SR report is received?

---

From: Avinash Bhatia <[email-masked]>
Date: Thu, 21 Aug 2003 10:29:18 -0700

The first query is valid in context of Section 6.3.1 of RFC 1889, but 
does not hold any more (i.e., since 3550), since the line "It is 
permissible to use the sampling clock to estimate elapsed wallclock 
time." has been removed.
However, it still says that "A sender that has no notion of wallclock or 
elapsed time may set the NTP timestamp to zero.". In such a case, how is 
the reciever of multiple streams expected to do inter-stream 
synchronization ?

Vivek Mudgil wrote:

>> That's one possible implementation choice for generating the 
>> NTP-format timestamp in RTCP SR packets, yes. However, all 32 bits of 
>> the RTP timestamp MUST be incremented.
>>
>> The sender may not know the resolution of its clock, and hence the 
>> LSBs of the NTP format timestamp may be garbage. I expect this will 
>> make it difficult to infer the characteristics of the clock from the 
>> timestamp values.
>>

---

From: Colin Perkins <[email-masked]>
Date: Thu, 21 Aug 2003 11:33:36 +0100

On Thursday, Aug 21, 2003, at 05:54 Europe/London, Vivek Mudgil wrote:
> differences between pairs of NTP timestamps are used. This implies > that

In order to perform lip-sync you need to receive one RTCP SR packet 
relating to the audio stream, and one RTCP SR packet relating to the 
video stream. This pair of NTP-format timestamps, and their 
corresponding RTP timestamps, is used to align the media.
This means there is an initial delay - on average 2.5 seconds duration 
if you use the default RTCP timing rules - when the receiver does not 
have the necessary information to perform lip-sync.

> receiver synchronise the two media till the first SR report is 

The receiver cannot synchronise media streams until an RTCP SR packet 
has been received from each stream.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 21 Aug 2003 11:37:50 +0100

On Thursday, Aug 21, 2003, at 18:29 Europe/London, Avinash Bhatia wrote:
> However, it still says that "A sender that has no notion of wallclock 
> or elapsed time may set the NTP timestamp to zero.". In such a case, 
> how is the reciever of multiple streams expected to do inter-stream 
> synchronization ?

If the sender sets the NTP timestamp to zero, it is not possible for a 
receiver to do inter-stream synchronisation.

-- 
Colin Perkins
http://csperkins.org/