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

From: Eric Fleischman <[email-masked]>
Date: Wed, 5 Mar 1997 17:51:42 -0800

I'm sorry, guys, but I can't grok this conversation you are having about 
"Pause". My trouble isn't that you have been unclear in your arguments but 
rather that we seem to have fundamentally different presuppositions as to 
how things will work "under the covers". I therefore would be honored if 
you would try to see things from my point-of-view in the hopes that perhaps 
you would then be able to "span the gap" between us.

Firstly, maintaining "Pause state" in the server is not a scalable 
solution. What we rather have done in our streaming media products is to 
treat "pause" as follows:
7	The user thinks (s)he is pausing, but what (s)he really is doing is a 
"stop".
7	The client remembers the point at which the "stop" took place -- this 
state is solely kept in the client.
7	When the user hits play (start), the user thinks that (s)he is resuming, 
but what (s)he is really doing is starting with an offset set to where the 
client had previously stopped. Therefore, the server starts playing from 
that offset.

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.

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.

The "play" (or start) command actually has two parameters. It has the 
offset previously mentioned in regards to "pause" above and it also 
contains a "rate" parameter. This rate parameter does *not* refer to the 
data rate - the data rate is fixed for that session. Rather, "rate" refers 
to the timeline upon which the streaming "media experience" is built. The 
timeline rate may be arbitrarily sped up (I believe that our product 
currently supports up to a 10x speed-up, though there is no technical 
reason why it couldn't be slower or faster). For fast-forward and 
fast-rewind, the server therefore has to compute at what offset to "skip 
to" to match that accelerated timeline. It is aided in this task by the 
indexing present in certain media types - no indexing, then no fast-forward 
or fast-rewind capability. What this generally means is that only the 
key-frames are sent during fast-forward and fast-reverse. And not every 
key-frame will necessarily be set depending on the timeline acceleration 
speed selected for the timeline advancement.

-----Original Message-----
From:	Sampo Syreeni [SMTP:[email-masked]]
Sent:	Wednesday, March 05, 1997 7:26 AM
To:	Jeff Smith
Cc:	Henning Schulzrinne; [email-masked]
Subject:	Re: New version of RTSP draft

On Wed, 5 Mar 1997, Jeff Smith wrote:

> |> > Along the same lines:
> |> > - a PLAY range will result in which? the server going to PAUSE at 
end
> |> > of range or CLOSE at the end of range?
> |>
> |> PAUSE would seem to make more sense.
> |
> |Another meta-level question from me: How about having the server 
remember
> |ranges and start the next if one exists?
>
> I'm not sure what you mean here... cue up a list of ranges that you
> would like to play and have the server stream them in succession?

Indeed. But so that even though playback may be in progress, doing a PLAY
with a certain play range would just add to the cue list.

This is again about the network latencies. If the client wants to move to
a new point in a representation, loop a particular spot or whatever, then
just telling the server what to do would cause the network latencies to
mess up the coherence of the incoming data stream. The server wouldn't
necessarily seem to react to the requests fast enough. But if the client
knows in advance what to show, a dynamic cue can be constructed. In this
case the server instantaneously knows where to continue when a particular
PLAY range ends. If one is willing to give up the 'server liveliness'
test, then a PLAY without a range could be used to advance the cue list.
All this would fit in the protocol fairly nicely as the protocol already
has some server state.

But remember, this is truly a meta-level question. The idea may not be
coherent enough to warrant addition to the protocol.

Sampo Syreeni (Decoy/dAWN), student, <[email-masked]>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 05 Mar 1997 21:39:40 -0500

Quick note before I head home: 

The speed header does support the FF/Rewind functionality you desire.

PAUSE: Glad to find a fellow stateless (or maybe less-state) soul :-) If
we require the client to always specify the starting point with a PLAY,
this would seem to allow the server to do exactly what you describe
(which is, I think a good idea). If a state-challenged server gets a
PAUSE, it just drops the resources and doesn't have to worry about
holding resources.

The only problem (and this goes back to discussions that Rob, Anup and I
have had) is the ability to set the transport parameters like the
destination port. Currently, the server has to remember that information
from the SETUP. I had argued that putting this into the PLAY method
would allow, but not require, less-state servers, at the slight cost of
checking for changes.

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

---

From: Anup Rao <[email-masked]>
Date: Thu, 06 Mar 1997 10:04:24 -0800

> you would then be able to "span the gap" between us.

No problem. Thanks for initiating this great discussion.

> possible had we been using the algorithm this discussion seems to be

I do not understand how the PAUSE message has an effect on scalability.
Indeed, it is not necessary from a user point-of-view. There seem to be
two issues here:-
a) maintenance of current position at the server
b) maintenance of "SETUP" information ie. transport ports etc.
Note that we do not have the notion of "STOP", rather a "CLOSE" which
results in release of resources.
Are you arguing against a) or b) or both ?  I consider a) a matter of
convenience but not of critical importance. Also, as you have pointed
out, this can be maintained at the client. But b) is important to avoid
periodic setup and tear down of ports both for endpoints and
intermediaries(such as firewalls).

> speed selected for the timeline advancement.

There are two ways that the concepts of FF and FRewind may be thought of
: 

a) Simply deliver the data as-is, but faster than its natural  rate
based on the speed parameter. As Henning mentioned, this is specified.
Admittedly, this is useful only if bandwidth permits and should be used
with care, but it should not be entirely ruled out.

b) A media specific way. As you pointed out, these operations make sense
and may have different significance based on the media itself. This may
be achieved by using a SET_PARAMETER specific to the media type. For
example, the "fast forward" achieved by sending only key-frames is
really a subsampling of the sent data in the time domain, and not a
change in the sending rate or the natural data rate of the data. Also,
note that state is not affected.

Regards,

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

---

From: Sampo Syreeni <[email-masked]>
Date: Fri, 7 Mar 1997 22:33:27 +0200 (EET)

On Wed, 5 Mar 1997, Eric Fleischman wrote:

> solution.

How's that? The server has some state already as it's delivering the
stream at some specific point. The same state can be used for a simple
pause. And how many streams do you assume a single server to be able to
support anyway? Do such minute memory savings have any impact on such a
server?

> What we rather have done in our streaming media products is to 
>	-The user thinks (s)he is pausing, but what (s)he really is doing
>	 is a "stop".
>	-The client remembers the point at which the "stop" took place --
>	 this state is solely kept in the client.
>	-When the user hits play (start), the user thinks that (s)he is
>	 resuming, but what (s)he is really doing is starting with an offset set to where the 
> 	 client had previously stopped. Therefore, the server starts
>	 playing from that offset.
> 

Hmm. I'll have to admit that cue-lists do not scale very well. But a
single pause state doesn't harm the server performance appreciably. Also,
what is the scope of your servers? Are they're a LAN based technology. In
that case the arguments about network latencies do not apply. But in a WAN
they do deserve attention.

Furthermore, restarting a fully stopped stream always requires some setup
and that adds to the latency. With explicit pause state that time is
saved. And as said, the server already has state. The protocol IS session
based.

> which are quite popular with users.

How do you implement such functions neatly when the RTSP is carried over a
best-effort service accross such appreciable distances that the net
allows? In this case some very serious synchronization issues arise.

> timeline rate may be arbitrarily sped up

But this requires some implicit support for some kind of resampling of the
stream. Either just skipping frames true antialiased resampling. Neither
of these is a viable requirement for the minimal server the protocol must
support. And again, synchro? It's much too easy to mess with the sped up
data stream and frustrate the user.

> For fast-forward and 
> or fast-rewind capability.

I don't think this is in the same conservative line of thought that
your earlier comments about the explicit pause state are. This is a
heavy-weight, specialized solution designed only to aid in implementing a
certain familiar user interface paradigm. I do not think this is something
to be expected of a generic protocol such as RTSP.