Re: [AVT] RTP/RTCP Timestamp and transmission time
Colin Perkins <csp@csperkins.org> Thu, 18 September 2003 11:58 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08292 for <avt-archive@odin.ietf.org>; Thu, 18 Sep 2003 07:58:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zxQD-0001ks-I9 for avt-archive@odin.ietf.org; Thu, 18 Sep 2003 07:58:05 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IBw5G1006746 for avt-archive@odin.ietf.org; Thu, 18 Sep 2003 07:58:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zxQ9-0001kA-GJ; Thu, 18 Sep 2003 07:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zxPX-0001js-Jv for avt@optimus.ietf.org; Thu, 18 Sep 2003 07:57:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08263 for <avt@ietf.org>; Thu, 18 Sep 2003 07:57:16 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zxPW-0004ro-00 for avt@ietf.org; Thu, 18 Sep 2003 07:57:22 -0400
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19zxPW-0004rT-00 for avt@ietf.org; Thu, 18 Sep 2003 07:57:22 -0400
Received: from bisa ([130.209.247.104]:49480 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19zxP1-0001X5-00; Thu, 18 Sep 2003 12:56:51 +0100
Date: Thu, 18 Sep 2003 12:56:47 +0100
Subject: Re: [AVT] RTP/RTCP Timestamp and transmission time
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v552)
Cc: avt@ietf.org
To: Lorenzo Polidori <lorenzo@blt.it>
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <3F4F1DDF0072671F@vsmtp3.tin.it> (added by postmaster@virgilio.it)
Message-Id: <2E96E40D-E9CF-11D7-A337-000A957FC5F2@csperkins.org>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.552)
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
On Thursday, Sep 18, 2003, at 11:31 Europe/London, Lorenzo Polidori wrote: > Colin Perkins wrote: > >> The RTP timestamp is NOT calculated from the NTP timestamp, but >> represents a sampling of the media clock. > > Ok, thank you. But can you explain the exact meaning of the following > fragment of RFC 3550, section 6.4.1: > "Note that in most cases this timestamp [RTP timestamp of an SR-RTCP > packet] > 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". This is for the particular case of estimating the RTP timestamp value to include in an RTCP SR packet, if it is not possible to sample the RTP clock at arbitrary instants. A system that cannot sample the RTP clock at arbitrary times, and which has no NTP-format clock, will have to set the RTP timestamp in an RTCP SR to zero. Systems that have no local clock are very rare though, so this should almost never be a concern. > Now, I have an MPEG2 Elementary Stream (ES), stored on disk, to be > transmitted over RTP. From Elementary Stream I can get and convert > MPEG time > code & temporal reference to a 90 kHz RTP timestamp, as in RFC 2250. > So, I > put this RTP timestamp in RTP data packet header: this timestamp is > computed > from the MPEG2 time code stored on disk, so it isn't correlated to the > system wallclock current time. You need to schedule the transmission time of the RTP packets according to their RTP timestamp. Since the packets are timed, there is a correlation with the wall-clock. > If I get RTP timestamp of SR-RTCP packet > sampling the wallclock current time, what's the correlation between RTP > timestamp on RTP data packet and RTP timestamp on RTCP packet? The RTP timestamps in data packets and in RTCP SR packets are samples of the same conceptual clock, at the instant that packet is generated. The wall-clock time is always correlated with the RTP timestamp, although it is a separate clock (since the RTP timestamps are derived from the media timing). -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- Re: [AVT] RTP/RTCP Timestamp and transmission time Colin Perkins
- Re: [AVT] RTP/RTCP Timestamp and transmission time Magnus Westerlund
- Re: [AVT] RTP/RTCP Timestamp and transmission time Colin Perkins
- RE: [AVT] RTP/RTCP Timestamp and transmission time Allison, Art
- Re: [AVT] RTP/RTCP Timestamp and transmission time Colin Perkins
- RE: [AVT] RTP/RTCP Timestamp and transmission time Alan Clark
- Re: [AVT] RTP/RTCP Timestamp and transmission time Colin Perkins