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

---

From: Rob Lanphier <[email-masked]>
Date: Mon, 14 Jul 1997 12:18:04 -0700

At 01:17 PM 7/11/97 -0700, Stephen Casner wrote:
>> How would a client tell a server to record several streams into a single
file?
>> 
>> SETUP movie?audio
>> SETUP movie?video
>> RECORD movie?audio
>> RECORD movie?video
>> [^^^ this is very difficult on the server]
...
>Who is in control of the file format during a record operation?  I
>would expect the presentation description to control the grouping and
>determine what kind of individual or collective files should be
>written.  Who sends the presenation description?  (From my reading of
>the protocol, presentation descriptions only go from the server to the
>client.)  If a client wants to record, perhaps the URI it needs to
>access the server would identify an "opportunity" to record, and that
>opportunity would imply a file structure.
>
>Being able to say
>
>SETUP movie
>Stream-id: aud
>SETUP movie
>Stream-id: vid
>RECORD movie
>Stream-id: aud,vid
>
>does not answer the question of what kind of container file movie is
>supposed to be.

This is a good point.  I would assume, since the client is controlling the
interaction, that the client would want to decide what file type it is.
However, the server is only going to have the capability to write a finite
set of files.  I suppose an optional field in the new ANNOUNCE method that
could provide a MIME type for the file, and the server response could
either be affirmative or provide an error which lists the available types.

>> Ok, but how would a client know whether to establish one session, and when
>> to establish n sessions, without doing some interpretation on the URL.
>
>The presentation description answers that question.  If there are
>multiple media URLs contained therein, the client must establish
>sessions for each of those that it wants.

That is 1-n-n (1 description, n-RTSP sessions, n-RTP Sessions).  How would
the client know when to do 1-1-n (1 description, 1-RTSP sessions, n-RTP
Sessions)?

>> If you are simultaneously trying to make the case against 1-1-n (and in
>> favor of 1-n-n), then I point you to the RECORD example above.
>
>I'm not against there being some means of collecting multiple RTSP
>streams into a presentation.  I just want the protocol to be the same
>independent of whether the data is kept in one file or several.  The
>client should have to know or care.

But wouldn't you agree that there are cases where the client *does* care?
(I'm assuming you meant to say "shouldn't" :) )  Recording is the best
example, but there are also cases where if the client is willing to be a
little accomodating, the server gets efficiency gains.

>In fact, the definition of "presentation" in the spec says that the
>presentation description is supposed to contain RTSP URIs that the
>define which streams can be controlled individually and an RTSP URI to
>control the whole presentation.  However, I'm not sure that remainder
>of the protocol specification says how that collective URI is supposed
>to be used or how the whole-presentation control is supposed to
>happen.
...
>Perhaps the whole-presentation URI does not allow the SETUP method but
>instead another method that binds a whole-presentation session-id with
>the individual session-ids for the individually controllable streams?

I think the point here, though, is that aggregate streams aren't supposed
to be individually controllable.  The key here is to have 1 NPT for all
streams.  PLAY and PAUSE apply to that NPT, not to the individual streams.

>If so, what if the presentation description identifies streams that
>will come from multiple servers: will the server identified by the
>collective URI be responsible for passing commands by some mechanism
>(perhaps outside of RTSP) to the individual stream servers?  This is
>clearly a hard problem, and one which I believe led to decisions to
>limit some of the functionality provided by RTSP v1.

Right, that is a hard problem.  However, streaming from a container file is
a much simpler problem, which there is already a substantial amount of
expertise at among the members of this group and in general.  I think we
are turning an easy problem into a hard problem by trying to come up with
this level of generality.

>> Even in playback, in the very common case where one has a neatly
>> pre-interleaved file, it makes it a lot easier for a server to just spit
>> out the packets in the order in which they are in the file, rather than
>> having to open n instances of the file, and then only stream 1/nth of the
>> file.
>
>I don't see any reason why the server should not be able to do that
>with URL's defining the streams instead of stream-ids.  Assuming that
>we're talking about multiple transport streams, then the server is
>going to have to look at each packet coming out of the file and
>determine on which stream to send it.  That's the difference between
>the multiplexed and non-multiplexed cases.

How does the client know that a set of streams with different URLs should
be bound together by a common NPT?  If they are all at the same URL but
only different stream ids, then this is simple (they are).  If they are
different URLs, and the mechanism by which stream ids are added and
extracted is *very* well defined, then I would concede that this is almost
as simple (depending on the parsing of the URL).  If there is only a fuzzy
definition of the stream id, then this is much more complex.

Rob
---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt

---

From: Rob Lanphier <[email-masked]>
Date: Wed, 16 Jul 1997 22:16:06 -0700

At 01:09 PM 7/17/97 +1000, Bill Simpson-Young wrote:
>robla wrote:
>> C->S  DESCRIBE rtsp://foo/db/moviebase?movie=twister RTSP/1.0 1
>> 
>> S->C  RTSP/1.0 200 1 OK
>>       Content-length: 178
>>       Content-type: application/sdp
>> 
>>       s= sample rtsp presentation
>>       r = rtsp://foo/db/moviebase?movie=twister   /* aggregate URL*/
>>       m= audio 0 RTP/AVP 0
>>       r = :track=audio1                           /* URL to control audio*/
>>       m=video 0 RTP?AVP 26
>>       r = :track=video1                           /* URL to control video*/
>
>I don't think this example would be a common one as surely, in practice, 
>HTTP will be used to retrieve the SDP info rather than RTSP.  

I very sincerely beg to differ.  In practice, there are a lot of datatypes
that need more initialization information than you would expect a content
author to get right in their hand-authored portion.  This is bound pretty
intricately to the media file itself, and therefore should be served by the
media server.  This is in fact how we are implementing this (and have
implemented it in our RealMedia developer betas).

This idea was brought up once before on confctrl, in a message from Brad
Hefta-Gaub, one of our RealMedia development leads:

http://www.mbone.com/lists/confctrl.1997/0339.html

>If I'm right, then this will have an impact on relative URLs specified in 
>SDP (or some XML version of it) as they would be HTTP URLs not RTSP ones 
>unless some form of base tag is used in the SDP data. Either way I agree 
>with Roy about the specification of tracks using the path itself (using 
>"/").  So, regardless of whether we're using container file formats or 
>separate tracks in separate files, the respective URLs could be:
>
>http://foo/db/moviebase/twister          (for the bootstrapping info)
>rtsp://foo/db/moviebase/twister/video1
>rtsp://foo/db/moviebase/twister/audio1
>
>and we could have the following (using an imaginary XML DTD for the 
>bootstrapping info):
>
>C->S  GET http://foo/db/moviebase/twister HTTP/1.1
>
>(if this was from a query you would have had a redirect stage before this 
>as suggested by Roy)
>
>S->C  HTTP/1.1 200 1 OK
>      Content-length: 178
>      Content-type: text/foo
>
>      <?XML version="1.0"?>
>      <!DOCTYPE foo SYSTEM "http://foo/foo.dtd">
>      <session base="rtsp://foo/db/moviebase/twister"/>
>      <summary>Sample RTSP Presentation</summary>
>      <media type="audio" location="audio1" ... />
>      <media type="video" location="video1" ... />
>      </session>

There is a lot of work going on in this area.  We have an SGML-based
metafile language that looks very similar to this actually called RTSL
which is included in the RealMedia SDK (see http://www.real.com/rma for
more details).  However, we don't require content authors to place all of
the media initialization information into their presentations, which leads
us to rely on DESCRIBE to get the bulk of the parameters.  We instead use
this metafile as a means of providing high-level sequencing, selection, and
synchronization, and for mapping stream components onto layout components.

Rob