Subject: RE: MUTE in RTSP

From: Eric Fleischman <[email-masked]>
Date: Mon, 21 Apr 1997 10:05:22 -0700

My concerns from the beginning have been about so-called "CD-ROM
content". Such multimedia streams are commonly already bundled as a
"unit". The significant majority of "on demand" multimedia streaming is
of that type of content.

I am surprised that you do not believe that it is more work for a server
to 
(A) split out already-integrated multimedia data into the separate
"media types" which make up the unit, associate a session for each of
those "media types", and send the data on its way, handling each media
types' timing dependencies and timeline than 
(B) to have that same server send that content "as a bundle" down to the
client at a rate determined by the "bundled" media timing dependencies. 
Even if we were only talking about 2 media types (instead of arbitrarily
large number of media types) it appears obvious (to my feeble mind, at
least) that A is significantly more work than B. 

Remember, RTSP is about multimedia *streaming*. This is a somewhat
different "ball game" than MBONE. Here "on demand" use is at least as
important as satisfying the needs of "live events".

> -----Original Message-----
> From:	Karl Auerbach [SMTP:[email-masked]]
> Sent:	Saturday, April 19, 1997 12:16 PM
> To:	[email-masked]
> Subject:	RE: MUTE in RTSP
> 
> 
> > Streaming a presentation (i.e., multiple multimedia streams treated
> as a
> > single entity) is the most efficient streaming approach possible for
> a
> > server. 
> 
> I do not believe that assertion.
> 
> In fact, when a composition of streams can be sent by distinct, but
> time
> synchronized computers (or processors) that bundling would tend to add
> artificial limitations.
> 
> As has been said many times on this list: Real implementations have
> demonstrated that the true burden of achieving synchronized rendering
> among multiple streams falls on the receiver.  Whether the streams are
> emitted in tight or loose synchrony at the source(s) is somewhat
> irrelevant. 
> 
> 		--karl--
> 
>

---

From: Karl Auerbach <[email-masked]>
Date: Mon, 21 Apr 1997 11:34:18 -0700 (PDT)

> types' timing dependencies and timeline than 

I am surprised that you have such a narrow focus.  I deal quite frequently
with media which is generated by two, three, or often many distinct,
synchronized but non-colocated, sources.  These are not bundled (and
indeed they are usually captured live from multiple sources) nor does the
data necessarily flow by the same pathways to the receivers. 

If you have adopted a media format which is hard to unbundle, you have my
sympathy.  But I do not see any reason to impose that design attribute
onto the network in perpituity as part of a protocol standard.

Whether the media streams arrive at the receiver unbundled or not, because
the time-to-render characteristics of each kind of rendering hardware
(audio/video/etc), the receiver must often unbundle them and do
considerable amounts of inter-stream time biasing in order to get get them
to be rendered at the same time.

In addition, by sending worthless data onto the network, the approach that
you are advocating may cause congestion and damage to the presentation
quality of entirely separate presentations.

> least) that A is significantly more work than B. 

From my experience building working sofware, I do not feel that the word
"significantly" is a correct assesment.

		--karl--

---

From: Sampo Syreeni <[email-masked]>
Date: Wed, 23 Apr 1997 16:34:42 +0300 (EET DST)

>onto the network in perpituity as part of a protocol standard.

I think the problem is in whether the unbundling can be done (at least
partially) off-line. If not, the costs can go up very rapidly. Of course,
with most formats, there is no problem in separating the feeds previously
to putting the data online.

But I agree. Interlaced formats should be possibly but by no means 
compulsory.

>to be rendered at the same time.

But such buffering is easier to do because you do not have to take into
account the delay jitter of the network, which is, with current, widely
deployed networking technologies, quite considerable. There are also bound
to be more synchronization problems over a heterogeneous cloud of routers
and networks when operating with segregated data streams than with
interlaced ones. Just one problem is the time it takes for a transport to
throttle back in the precense of heavy network load and very high
bandwidth data streams (say, HDTV quality audio+video).

>quality of entirely separate presentations.

But in the future networks, where resource reservation and QoSR abound,
and there will be a huge amount of bandwidth available (not endless, but
huge), that might not be such a problem that it is today.

>"significantly" is a correct assesment.

But it takes, nevertheless, more from the server side. Assume you have a
high quality, interlaced MM presentation to send. If you send it as-is,
practically no work is required in addition to retrieving it from the disk
and sending it (steady state transmission is assumed). If you have to
segregate it, however, you end up with more network layer state (many,
many more connections, possibly), separate buffers for all of the
interlaced streams, larger server side code (leading to cache coherency
problems), high latencies and, possibly, considerably more difficult
resource reservation procedures when QoSR is present; complex, mandatory
client-side buffering to rid the delay jitter, no real benefit for
multicasting situations etc. etc. This all assumes a single server, of
course. But if the presentation already exists in an interlaced format, it
may not be feasible to distribute it to many machines.

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