Subject: Interleaved Data Formats in RTSP

From: Eric Fleischman <[email-masked]>
Date: Thu, 6 Mar 1997 07:53:27 -0800

My purpose in re-opening this discussion stems from two motives:
*	While there are indeed many similarities between the
conferencing applications this community has historically advanced and
streaming multimedia, there are also many differences as well. Many of
these differences are seen by the factors which have made interleaved
data become a preferential alternative for many streaming applications.
Therefore, it is difficult to conceive of satisfactorily addressing the
streaming milieu without including interleaved data as a significant
possibility within the domain's solution set.
*	My reading of the most recent RTSP spec has left me doubtful as
to whether the spec will permit the traditional and dominant approach to
streaming media (interleaved data) to continue to be used. I would like
to dedicate the remainder of this message to explaining my concern.

A previous message from Intel pointed out some of the confusing use of
terms to reference certain multimedia networking issues. I certainly
share his confusion and somehow have failed to notice what the solution
to his query turned out to be. 

Anyway, I fear that my reading of the RTSP spec is tainted by such a
confusion in my own mind. For example, the definition of "(media)
stream" in section 1.3 seems to be stating that a media stream is a
single segregated media type.  Then in Section 1.6 the text states "each
media stream is identified by an RTSP URL" and then goes on to give an
example where a session consists of several media streams each coming
from a different server. I have no qualms about this possibility. 

What does bother me is that 
(1) if segregated streams all come from the same server then it is
desirable that the segregated streams be able to be referenced as a unit
by a single RTSP URL; and
(2) in the interleaved data situation the interleaved data itself should
be referenced by a single RTSP URL since it is a "unit" just like a
segregated media stream could also be a "unit" of reference. No such
provision exists for this in the text. Thus, according to this usage,
the term "(media) stream" should also be able to refer to the entire
interleaved data stream as opposed to the individual media elements
within that stream. In such usage, the fact that the stream is made up
of multiple media is "opaque" - the stream functions as a unit and
should be treated as such by RTSP. 

Similarly, while it is possible to join together media streams of
segregated media data into a "session" (or whatever it is we decided to
call such a grouping), so I would imagine that it is theoretically
possible to join together an interleaved media stream with another media
stream to form a combined grouping. Thus, in my mind at least, an
interleaved media stream could theoretically function exactly like a
segregated media stream for the purposes of this spec - though in
practice I am only aware of interleaved media streams incorporating
other media types within themselves (e.g., including an MPEG interleaved
data stream within a larger interleaved stream containing other media
types such as streaming text and URL flipping) as opposed to having them
be "joined" at the recipient.

Other possible definitions could, of course, be made. My concern here
isn't to suggest the actual terminology but rather to urge that the RTSP
spec be amended to include the possibility of interleaved data. Since
interleaved data is the dominant approach for streaming data today, it
would be very desirable to not exclude this possibility from the RTSP
spec.

	-----Original Message-----
	From:	Henning Schulzrinne [SMTP:[email-masked]]
	Sent:	Thursday, March 06, 1997 5:05 AM
	To:	[email-masked]
	Cc:	[email-masked]
	Subject:	Re: In Defense of Interleaved Data Formats

	It should be pointed out that we had this same discussion many
moons
	ago, on the rem-conf list, at least once. Note that there is one
	interleaved MPEG format (Civanlar) already.
	-- 
	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: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Mar 1997 11:00:41 -0500

Don't ascribe to technical deficiencies what can easily be explained by
lack of clarity in documentation :-). Having a single rtsp:// URL for
the whole presentation (all streams, however interleaved or not) is
provided for in RTSP. Yes, we need to get the terminology straight, but
I'm waiting for input on that from the group (see my previous mails).
Note that the mapping of content to rtsp URLs is completely under the
control of the session description. The session description can
determine that tracks are not separately controllable, for example,
regardless of whether they are delivered from a single server, to a
single UDP port and as a single RTP PT or not.