Subject: Mute vs. PAUSE in RTSP

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 23 Mar 1997 18:29:28 -0500

I think it might be useful to have a MUTE request that stops delivery of
a stream without interrupting the time progress. Currently, the
assumption is that

PAUSE /movie

stops time and delivery, while

PAUSE /movie/audio

just stops delivery of audio (mutes it), while the video track (and thus
time) keeps on playing. This does not seem clean, as it doesn't
correspond to typical word (and VCR button) usage.

An alternative would be a new method, MUTE, that continues time
progress, but interrupts delivery.

MUTE /movie

doesn't make a whole lot of sense (although it may in some circumstances
where, say, the server can't do absolute positioning and I just want to
wasting my pay-per-byte dollars on the next ten minutes of drivel).

MUTE /movie/audio

would simply shut off delivery of the audio stream, without affecting
progress on other streams. Presumably, we would need an UNMUTE as well.
(Thus, MUTE-UNMUTE are akin to PAUSE-PLAY.)

The disadvantage is that PAUSE then really only makes sense on the
top-level stream (/movie). We could define PAUSE to pause the whole show
even if issued for a stream (say, /movie/audio) or simply disallow it
for anything but the whole show.

I realize that MUTE has an audio-ring to it, so better terms are
solicited. STOP is bad.

Clearly, I can't mute a stream that I'm not playing, but that's not too
difficult to handle.

Comments?

Henning

---

From: Sampo Syreeni <[email-masked]>
Date: Tue, 25 Mar 1997 11:13:37 +0200 (EET)

>correspond to typical word (and VCR button) usage.

Hmm. Assuming the tracks come from different servers, what happens if you
separately kill each and every one of the separate parts of the
presentation? Does the time stop or not? If yes, then you're bound to have
some synchro problems, if not, you have your MUTE method right there.

>wasting my pay-per-byte dollars on the next ten minutes of drivel).

Hmm. It would seem to make a lot of sense if the presentation is
real-time. (Conference, was it?) In this case keeping the connections but
pausing delivery would be quite nice (For example, for the time to go to
the fridge in the middle of a conference... ;).

>for anything but the whole show.

Not very consistent usage, in my opinion.

>I realize that MUTE has an audio-ring to it, so better terms are

HOLD, for example.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Mar 1997 08:41:59 -0500

Muting for multicast should be done by dropping membership, so that the
network can be relieved of carrying data. Does not require RTSP help
(and RTSP wouldn't help here, anyway).

In discussions I've had since I wrote this note, I'm becoming more
convinced that a single RTSP session should really only control a single
media stream (which may consist of several substreams, as when you are
delivering a Quicktime/AVI/ASF movie) to avoid problems with
presentation authors piecing together unrelated media objects. Muting,
however, may still be useful in some circumstances, but its interaction
with PAUSE requires further thought. Probably a version-2 item.

---

From: Philipp Hoschka <[email-masked]>
Date: Tue, 25 Mar 1997 16:34:45 +0100

>delivering a Quicktime/AVI/ASF movie) 

But the substreams are stored in a single file, and stored on a single server ?
So, if you have an audio and a video, you either deliver them multiplexed
into a single stream, or keep two RTSP sessions for controling them ?

>to avoid problems with
>presentation authors piecing together unrelated media objects. 

Could you elaborate a bit on the problems ? Different time-bases etc. ?
I would guess that presentation authors know what they are doing/will be
able to test it out.
Or do you mean: seperate streams don't work, so it's not worth for
RTSP to support them ? If so, why don't they work ?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Mar 1997 11:09:11 -0500

> into a single stream, or keep two RTSP sessions for controling them ?

Yes, three choices: either a single RTP session (if RTP, using different
SSRCs and PTs - I'm not claiming this is a good idea), as an
AVI/Quicktime/ASF format encapsulated as RTP packets or as separate RTP
streams (separate ports, etc.), where the client has no clue that they
came from the same on-disk media file. Two separate RTSP sessions are
not that bad. All you need is

PLAY /movie/audio
Range: 17-

PLAY /movie/video
Range: 17-

in a single UDP packet or TCP stream.

> RTSP to support them ? If so, why don't they work ?

Separate streams work just fine from a synchronization (done at the
receiver anyway) and server standpoint, although playing together a
"synchronized" sound track of "Twisters" and the video of "Forrest Gump"
may have unintended comical effects. It's just that the server has to
know about the presentation description to recognize that
/movie/audio.en and /movie/video.loqual were tied together by the
description author as /movie/. This can be done (using the Session or
state maintenance mechanism in the draft) and should work, but is a
little more complicated. The sequence for "bundling" would be

SETUP /movie/audio.en RTSP/1.0
Transport: port=1234

server sends session info back:

RTSP/1.0 200 
Session: 17

SETUP /movie/video.en RTSP/1.0
Transport: port=1235
Session: 17

(server adds this to the list of streams for this session 17)

PLAY /movie RTSP/1.0
Session: 17

(server recognizes the session and, by looking at the URL, figures out
that this command applies to the whole presentation rather than a
stream).

---

From: Mark Handley <[email-masked]>
Date: Tue, 25 Mar 1997 12:10:43 -0500

>presentation authors piecing together unrelated media objects.

Given that the delay from a user pressing "go" to the server getting
the message is not predictable, how would you suggest synchronised
startup of playback of separate audio and video streams is performed
if you don't have a common RTSP session (and can therefore guarantee
atomicity)?  

You can buffer the first stream which arrives, but this does seem to
complicate the issue somewhat wrt the client knowing for certain that
the later stream is definitely going to start arriving eventually.

Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Mar 1997 13:31:06 -0500

> if you don't have a common RTSP session (and can therefore guarantee

You have to solve the same problem if two streams are on two different
servers (that's where the time= parameter kicks in to start them both at
the same wallclock time to minimize the effect of RTSP latency
differences). If the streams are on a single server, the two commands
should be in one UDP/TCP packet (easy, since RTSP "connections" are
divorced from TCP connections). Can't necessarily force this for TCP,
but for practical purposes, this will work. 

> the later stream is definitely going to start arriving eventually.

Indeed, but that's a problem you are going to have to solve if you allow
distributing streams across servers or from a single server across
different RSVP flows (possibly QOS-routed across different paths).

> Mark

Based on my example in the subsequent message, controlling groups of
streams may not be quite as hard if the server can know which URLs refer
to individual streams and which URL names the group. The directory
notation that I have used (/movie/ is the whole stream /movie/audio.en
is the substream) may be sufficient. Note that there's no reason this
can't be server-specific, as long as the writer of the presentation file
adheres to the convention. 

Henning

---

From: Philipp Hoschka <[email-masked]>
Date: Tue, 25 Mar 1997 19:40:15 +0100

>came from the same on-disk media file. 

Ok, this clears things up.

Note that in Quicktime, you don't necessarily have to have all your
data in a single file - you can include data "by reference" when it is
local, using MacOS filenames.
 
The extension to URLs is pretty straightforward, and has been done 
experimentally 
(see 
http://www.w3.org/pub/WWW/AudioVideo/9610_Workshop/paper20/paper20.txt)
This makes mapping onto seperate RTP streams even easier.

Today, however, you have to "flatten" the movie if you put QT stuff 
on the Internet, i.e. put all data into a single file.
But this is just one particular choice in the Quicktime architecture.

---

From: Sampo Syreeni <[email-masked]>
Date: Thu, 27 Mar 1997 14:36:00 +0200 (EET)

>the later stream is definitely going to start arriving eventually.

Added with transport throttleback this does the deed.