Subject: Re: Pause, Fast-Forward, Fast-rewind in RTSP

From: Rob Lanphier <[email-masked]>
Date: Fri, 07 Mar 1997 09:21:33 -0800

At 05:51 PM 3/5/97 -0800, you wrote:
>[speaking of implementing "pause" by treating it like a stop/close]
>This is all very clean and has permitted our streaming servers to scale to 
>a thousand (or more) simultaneous sessions. This would not have been 
>possible had we been using the algorithm this discussion seems to be 
>assuming.

We've also been able to implement servers that scale to a thousand (or
more) simultaneous sessions, and we've actually maintained PAUSE as a
state.  The reason is very straightforward why this works:  when someone
hits "pause", they often do want to do a small, momentary pause.  In our
current implementation, there is a timeout when the pause is very long (I
can't remember the number, but this is easily verified using our client).

Momentary pausing is more scalable than stopping, since only allowing stop
would actually result in having to go through a potentially expensive setup
when playback resumes.

>Related user controls which seems to have been overlooked by the RTSP draft 
>are "fast forward" and "fast rewind". These are very important controls 
>which are quite popular with users. Unfortunately, they are only possible 
>for certain media types such as video. The way these commands work is very 
>similar to the "pause", so I mention it here for completeness' sake.
>
[explanation of "rate" as a parameter for the PLAY method]

I agree that we need these.  However, in early discussion we compromised
with the notion these are media-specific methods, since they don't
necessarily apply to all streams, as noted.  I think we can come up with a
core RTSP document without this method.  At that point, it would be simple
enough to standardize these as parameters in SET_PARAM and GET_PARAM, or as
an extension field to PLAY, as you described.

As long as we can stipulate that these belong as optional extensions rather
than core requirements, I'm sure there will be no problem placing these in
an appropriate document (which is probably the core document, though I'd
want to make sure we don't lose focus on the core framework before adding
this extra feature).

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio       Web: http://www.realaudio.com

---

From: "Henning Schulzrinne (BL)" <[email-masked]>
Date: Fri, 07 Mar 1997 15:44:23 -0500

I would still suggest a dual rate specification, data and NPT-rate. Both
can be defined in a media-independent way. In most cases, the client
doesn't care how it is done. In some cases, it won't be able to this at
all, but this is always a problem, as requesting a data or NPT-rate of
1000 is not likely to be successful, as would be speeding up a live
session. Thus:

Scale: 10/1 -> send data with ten times the NPT-rate, but the same
original data rate (how to do this is up to the server)

Scale: 10/10 -> send at ten times the normal data rate and NPT-rate

Scale: 1/10 -> doesn't make sense

Henning