Subject: RE: RTSP: relative time

From: Eric Fleischman <[email-masked]>
Date: Thu, 6 Mar 1997 09:46:50 -0800

The answer to your question is dependent upon your underlying model of 
streaming. Our product's model is entirely built upon the concept of a 
single "timeline". All media is orchestrated according to that timeline. 
This orchestration is manifested by the timestamps and (optional) 
interleaving strategies.

Thus, from our approach the answer would be "no": relative time is not 
desirable, all time references should be in terms of the underlying session 
timeline. I would also think that the specification of relative time would 
be tricky since what you are really wanting is an offset from a given 
event. Such an offset is most unambiguously expressed in terms of the 
timeline itself.

As I previously stated, we have deep problems with a timeline with a 
granularity as coarse as one second. While our 100ns timeline is probably 
overkill, the timeline really must be finer than human senses can discern 
if the multimedia events are to be orchestrated appropriately to achieve 
the desired effects. Thus, I would like to request that we please adopt a 
system with a microsecond or millisecond time granularity. From an 
engineering perspective, a too-granular timeline is not of great concern, 
an inadequately granular timeline is of tremendous concern. When in doubt, 
aim for a greater degree of granularity in the timeline definitions. This 
will permit systems lacking that granularity to "fudge" but will support 
the accuracy needed by systems requiring those granularities.

-----Original Message-----
From:	Henning Schulzrinne [SMTP:[email-masked]]
Sent:	Wednesday, March 05, 1997 4:33 PM
To:	[email-masked]
Subject:	RTSP: relative time

Is there a need for a relative timing measurement other than SMPTE? In
particular, is there a need for time expressed simply as some whole
number of seconds (doesn't really matter if hh:mm:ss or a second count)
and a fractional second of whatever precision?
--
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Mar 1997 15:42:48 -0500

> the accuracy needed by systems requiring those granularities.

Actually, the current SMPTE timestamp defined in RTSP has a resolution
of one frame. The problem, however, with SMPTE is that the notion of a
"frame" is not particularly well defined if you are not running NTSC or
PAL. Thus, my hunch would be to define a relative time according to
DSM-CC NPT, that is, with second and fractions or seconds and
microseconds (a la NPT). Something like

Range: npt=8383.1005
or
Range: npt=8383:995509

The clock time specification always had a resolution below a second.

Maintaining SMPTE as an option makes sense, IMO, since it corresponds
nicely with standard professional equipment and you don't have to worry
about the 29.97 Hz issue.
-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 212 939-7042
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Anup Rao <[email-masked]>
Date: Thu, 06 Mar 1997 13:37:55 -0800

> event. Such an offset is most unambiguously expressed in terms of the

Eric,

I believe Hennings question was really related to  the units and
precision of the time. RTSP too embodies the notion of single
timeline(see mail regarding seperate timelines a la DSM-CC). All times
are  relative to the "beginning" of this single timeline. At this point,
we express this time as SMPTE timestamps. As you have stated before and 
below, and as Henning proposed it seems *highly* desirable and necessary
to have this time expressed in seconds, either with floating point
precision or some other format.

Does "TimeOffset=seconds:microseconds" in the Range header seem
appropriate ? I think it is granular enough and (can't help thinking
this way :-) it maps easily to struct timeval.

An example would be:

PLAY foo/bar RTSP/1.0
Range: TimeOffset=3:3452-5:8765

> the accuracy needed by systems requiring those granularities.

Regards,
-- 
-----------------------------------------------------------------
  Anup Rao                                                      
  Netscape Communications Corp.                   
  email : [email-masked]         Phone : (415) 937 3129       
-----------------------------------------------------------------