Subject: Re: Format of RTSP URLs

From: Rob Lanphier <[email-masked]>
Date: Thu, 10 Jul 1997 16:20:36 -0700

At 07:46 PM 7/9/97 -0700, Stephen Casner wrote:
>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.
>
....
>The other case [for control of container files] 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.

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

??????
That would be *very* difficult to implement.  As far as the server is
concerned, the audio and video would be separate sessions, and it would
have to have some pretty sophisticated code to reliably merge the two
sessions into one.  This also implies that the client is going to have to
have some mechanical way of distinguishing between a file object on the
server and a stream object.

>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.

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.

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.

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 hope I'm not putting words in your mouth.  Are you proposing that 1-1-n
is not worthwhile?

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: Stephen Casner <[email-masked]>
Date: Fri, 11 Jul 1997 13:17:31 -0700 ()

Rob,

> server and a stream object.

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.

> 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.

> 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.

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?

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.

I would think the protocol should allow that, but that people who
create presentation descriptions can only spread the streams across
multiple servers if the collection of servers implements some
mechanism for collective control.  If a presentation is mistakenly
created across multiple servers when collective control is not
possible, then an error would be returned.

> having to open n instances of the file, and then only stream 1/nth of the

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.
							-- Steve