Subject: Re: MUTE in RTSP

From: Gray Cope <[email-masked]>
Date: Fri, 18 Apr 1997 23:06:15 -0700

Eric,

I think I understand your concern regarding some content creators
not wanting their "multimedia bundle" altered by muting individual
streams within their presentation.

So if the RTSP specification did not _require_ the MUTE request to be
implemented would that address your concerns?

Ultimately the content creator or distributor can exercise control
over how their presentation is delivered.  That is they can specify
that their content not be delivered by a service that implements
the MUTE request.

Gray

At 09:41 AM 4/18/97 -0700, you wrote:
>The Sept 26th version of the RTSP spec introduced the much-needed
>concept of "presentation" which was defined (see section 1.3) as "a set
>of one or more streams which the server allows the client to manipulate
>together." These streams are treated as a "unit", a "multimedia bundle"
>so-to-speak.
>
>The spec also preserves the concept of permitting separate media streams
>(which have not been defined into a presentation) to be controlled from
>the same source. That is, a set of multimedia streams may be formed into
>a logical session via registration/announcement facilities. The user is
>freely able to address and modify each of these streams within the
>constraints supported by RTSP.
>
>I believe that these two different control mechanisms provide us with
>the necessary insight to agree to what MUTE should mean in RTSP.
>
>In the first instance, all media streams are treated as a unit and are
>transparently manipulated together. In most/many cases, "presentations"
>will be the product of content creators who have designed these streams
>"off line" to function as that unit to create the intended multimedia
>experience. A MUTE, in this context, would introduce an orthogonal
>concept of providing independent control for one of those streams in the
>"multimedia bundle". This is hostile to the basic underlying philosophy
>of what a "presentation" actually is. MUTE is totally inappropriate
>within a "presentation" since it wars with the "core underlying
>philosophy" of what a "presentation" actually is.
>
>In the second instance, RTSP provides for the independent control of
>multiple media streams which the user (via the intermediate
>registration/announcement facilities) has orchestrated into a single
>logical session. RTSP has already provided the user with the ability to
>do a MUTE within this context by permitting him/her to PAUSE the audio
>stream and at a subsequent time to PLAY with Offset that same stream. A
>Mute in this instance, therefore, is merely a "simplification" to the
>PAUSE...PLAY with Offset sequence. I have no objection to a MUTE if it
>is solely targeted to this (non-presentation) environment since it
>automates what the "Offset" should be in the "Play with Offset" part of
>the sequence. More importantly, a MUTE in this context is fully
>consistent with the "underlying philosophies" of such logical sessions. 
>
>
>

---

From: Karl Auerbach <[email-masked]>
Date: Sat, 19 Apr 1997 12:23:46 -0700 (PDT)

> implemented would that address your concerns?

Making parts of a specification optional tends to cause interoperability
problems (and user unhappiness).

> that their content not be delivered by a service that implements

Since the user controls whether the audio is even plugged into speakers or
whether the screen is turned on, what you suggest would ultimately be
futile.

Which is better for the network?  To carry packets to the receiver just to
have them rendered into a device disabled by the user?  Or is it better
just to supress the useless data at the source and not pay the carrying
cost?

Somehow this whole thread of "author's rights" strikes me in about the
same was as did the old Outer Limits TV show -- They said that they
controlled the horizontal and that they controlled the vertical.  But I
controlled the power switch.  I think that in this case the user holds the
trump card over any "author's intention". 

		--karl--

---

From: Sampo Syreeni <[email-masked]>
Date: Wed, 23 Apr 1997 15:57:33 +0300 (EET DST)

>problems (and user unhappiness).

True. And it also makes the life harder for application writers that have
to cope with a heterogeneous server environment.

>whether the screen is turned on, what you suggest would ultimately be

So what MUTE is, it's basically just an optimization. Is it worth it?

>just to supress the useless data at the source and not pay the carrying

How does MUTE interoperate with multicast data streams? It would seem to
necessitate some layer violation in the architecture since the server
side would have to know whether an address is uni or multicast.

>trump card over any "author's intention". 

Indeed. No such limitations can reasonably be imposed upon the user. It
would be the same as forbidding one's going to a museum if one doesn't
agree to see /all/ the paintings.

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