Subject: RE: Speed field in RTSP

From: Eric Fleischman <[email-masked]>
Date: Fri, 28 Mar 1997 14:00:25 -0800

Actually, my arguments are:
1.  Rewind (and backwards-play) should be handled by making the Scale
header (within the PLAY or RECORD methods) negative with the rate of
timeline advancement (whether positive or negative) determined by the
scale value (e.g. Scale:-2 means rewind at 2x speed).
2.  However, if both speed and scale headers are present and both are
negative then we have an indeterminate state. For this reason, speed
should never be permitted to become negative because a negative speed is
really a physical impossibility: the source never becomes the sink.
3.  In fact, the speed header should be eliminated altogether because it
is a dangerous, network unfriendly idea. Rather, if one wishes to
increase the consumed bandwidth for that session then that should rather
occur via mid-session negotiation between the client and the server via
the DESCRIBE method -- either that or else via standard RTP methods to
accomplish the same effect.

	-----Original Message-----
	From:	Larry Rowe [SMTP:[email-masked]]
	Sent:	Friday, March 28, 1997 11:21 AM
	To:	Sampo Syreeni
	Cc:	Eric Fleischman; [email-masked]'
	Subject:	Re: Speed field in RTSP 

	Hi -

	I have watched the discussion on the speed/rate issue for some
time.  We have 
	been developing and using a toolkit, the Berkeley Continuous
Media Toolkit, 
	for the past four years that has the speed attribute built-in to
the logical 
	time system and playback abstractions.  The CMT logical time
system (LTS) 
	abstraction has a speed property that can be positive or
negative. We find it 
	a very useful construct.  Obviously not all sources can support
backward play, 
	but who cares, the software just ignores that situation.  That
is, the LTS 
	runs backwards, but objects that don't have any actions to take
when that 
	happens just ignore it.  This is probably too detailed for this
discussion, 
	but I want to *strongly* support Eric's arguments for a speed
attribute that 
	can be positive and negative.

	I'll also weigh in on the bitrate issue.  Clearly, the standard
must support 
	the use of scalable codecs that might dynamically alter the
bitrate being sent 
	based on any number of characteristics (e.g., decoding speed of
the client, 
	channel capacity/jitter, server capacity, etc.).  In addition,
it must allow a 
	client to select a stream bitrate when it is established.  It
might make sense 
	to allow the client to request a change in the bitrate or the
format when the 
	stream is paused.  The issue from my perspective is that we will
have a 
	heterogeneous network for a long time to come and content
providers want to 
	produce products that can be played differently on different
networks. The 
	playback system must accomodate this feature.  I'm not sure it
needs to be 
	built into the server protocol, but it should be possible to
implement these 
	features.
		Larry  
	-- 
	Professor Lawrence A. Rowe               Internet:
[email-masked]
	Computer Science Division - EECS         Phone: 510-642-5117
	University of California, Berkeley       Fax: 510-642-5615
	Berkeley, CA 94720-1776
	URL: http://www.bmrc.berkeley.edu/~larry

---

From: Larry Rowe <[email-masked]>
Date: Fri, 28 Mar 1997 17:42:42 -0800

Excuse me, I meant to say "scale" not "speed."  Speed is the parameter name we 
use for the LTS abstraction in CMT.
	Larry

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 29 Mar 1997 11:50:17 -0500

"Scale" should be in the current I-D that was just announced. Since
nobody spoke up in favor of a negative Speed value, that is gone from
the next iteration.

The current spec contains the "bandwidth" header which would allow
specification of client bandwidth availability for scaling (although
this is probably more properly done by RTCP in many cases). Currently,
it is spec'ed only for SETUP, but I see no good reason why a client
could not indicate it in PLAY and RECORD, if it becomes aware of
changes. 

The bandwidth available to the client may change during 
an RTSP session, e.g., due to modem retraining.

After all, a server is free to ignore the advice (at its own and the 
peril, naturally).

Since Anup (if I remember correctly) has in the past argued for the
"Speed" functionality and he's currently out of email reach, I'd like to
give him a chance to respond with his thoughts on this issue.

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