Subject: Format of RTSP URLs

From: Stephen Casner <[email-masked]>
Date: Wed, 9 Jul 1997 19:46:04 -0700 ()

I believe there is too much emphasis here on container files.  Alagu's
proposal to identify the cases as muxed and non-muxed is a good
notion, though I think some of the details after that are not right.

One case is a pre-multiplexed container file, such as MPEG Systems
Streams format, which will be sent by the server as one multiplexed
data stream.  In this case, THERE IS NO CONTROL OF INDIVIDUAL MEDIA.
The raison d'etre for this case is that the server does not have time
to touch the bits, hence it does not have time to reformulate a new
multiplexed stream with one medium muted, for example.  In this case,
there is only one RTSP URL, one RTSP session, one transport session.

The other case is the non-multiplexed case, where a presentation
consists of multiple transport streams.  (Some transport streams may
contain more than one medium pre-multiplexed, but each transport
stream is the minimum unit of control.)  As Anup already pointed out
much earlier in this discussion, for the purposes of designing how a
presentation will be controlled and delivered by a single server, it
should not matter whether all the media come from one file or from
separate files.

If you accept that premise, then what we need is a way to specify
where the bits for each transport stream will come from.  It seems to
me that an RTSP URL for each stream is the right way to do it.  That
URL may take any of several forms depending upon whether the bits come
from one or more files or some magic database or from an analog input
device.  Brad expressed the following concern in response to Philipp's
message:

    >> rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"
    >>
    >> Now, my first question is: why is this a query ? Why do you need to use
    >> a questionmark ?

    My point is exactly that the RTSP spec should not answer these
    questions. Instead the RTSP spec should reference the standard
    URI spec, and should not place additional limitations on the
    semantics of sub-syntax of the URI.

    A solution that limits the name space of the URI seems especially
    wrong when we have a perfectly reasonable pathway in the 822 headers.

I agree wholeheartedly that the RTSP spec should not answer these
questions, but I draw the opposite conclusion.  Section 3.2 of the
RTSP spec says that "the path components of the RTSP URL are opaque to
the client and do not imply any particular file system structure for
the server".  The example

    rtsp://media.example.com:554/twister/audiotrack

is given, and similar examples for audio and video tracks are given in
section 14.1.  As in these examples, the RTSP URL should identify a
particular media stream to be transported.  The person who constructs
a presentation with multiple media streams will figure out what the
URLs need to be to specify whence those media streams come and will
also build a presentation description that includes those URLs.

SDP does not yet include a way to specify the source of a media
stream, e.g. using a URL, though Precept and others have made their
own extensions to SDP.  We need to specify how to include these URLs
in the SDP description, and that was my question to this list way back
at the beginning of this discussion.

I don't see this as limiting the name space of the URI; rather, we may
need to extend the name space of the URI if it is only sufficient for
referencing files and not parts of files.  The object identified by an
HTTP URI is generally a file (which might be a script to which
parameters are supplied), whereas the object identified by an RTSP URL
is a media stream.  If the storage mechanism is going to deliver
separate media streams, then the references to it have to be able to
identify separate media streams.  But the RTSP spec doesn't have to
say anything about whether you use '?' or any other character to get
there.  The server is the only entity that needs to be able to
interpret the URL to get the right bits.

It seems wrong to me that if the media are in separate files then you
just give the URLs, but if the media are in one containter file then
you need a URL plus a stream-id.  That is just augmenting the URL with
a separate line.
							-- Steve