RE: Format of RTSP URLs
Brad Hefta-Gaub <brad@prognet.com> Thu, 17 July 1997 09:26 UTC
Received: from cnri by ietf.org id aa02691; 17 Jul 97 5:26 EDT
Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid FAA10898; Thu, 17 Jul 1997 05:25:16 -0400 (EDT)
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id FAA20195 for uri-out; Thu, 17 Jul 1997 05:10:33 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id FAA20180 for <uri@services.bunyip.com>; Thu, 17 Jul 1997 05:10:30 -0400 (EDT)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id FAA04569 for uri@services; Thu, 17 Jul 1997 05:10:29 -0400 (EDT)
Received: from murrow.prognet.com (prognet.com [205.219.198.1]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id FAA04566 for <uri@bunyip.com>; Thu, 17 Jul 1997 05:10:27 -0400 (EDT)
Received: from zappo-home.prognet.com (correro-PPP2.prognet.com) by murrow.prognet.com with SMTP id AA00509 (5.67b/IDA-1.5 for <uri@bunyip.com>); Thu, 17 Jul 1997 02:15:16 -0700
Received: by zappo-home.prognet.com with Microsoft Mail id <01BC9256.063C7740@zappo-home.prognet.com>; Thu, 17 Jul 1997 02:06:22 -0700
Message-Id: <01BC9256.063C7740@zappo-home.prognet.com>
From: Brad Hefta-Gaub <brad@prognet.com>
To: "'bill@syd.dit.csiro.au'" <bill@syd.dit.csiro.au>, Rob Lanphier <robla@prognet.com>
Cc: "'brad@prognet.com'" <brad@prognet.com>, "confctrl@isi.edu" <confctrl@isi.edu>, "uri@bunyip.com" <uri@bunyip.com>, "www-talk@w3.org" <www-talk@w3.org>
Subject: RE: Format of RTSP URLs
Date: Thu, 17 Jul 1997 02:06:07 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-uri@bunyip.com
Precedence: bulk
Bill Simpson-Young wrote: >> 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... As we have already discussed on the confctrl list there are actually two very distinct uses for "description" formats like SDP in the process of playing back media streams. The first use is for accessing "media server indirection" information. This is clearly best handled by an HTTP server. It seems to me that you are referring to this type of use of SDP. However, there is another equally important use for "description formats" like SDP in the process of playing streaming media, specifically, "media initialization information". This is basically the information needed to initialize the "rendering" context of the media stream. This information is often not hand authored, because it may contain codec specific initialization goo, and as such should not be separated from the media file itself. Retrieval of this information is the purpose and intended use of the RTSP DESCRIBE verb. The RTSP authors chose not to use GET because this is explicitly not the same semantics of the HTTP GET. You don't get the resource, you get a description of the resource. For more information on this specific topic please see my post to the confctrl list dated Fri, 20 Jun 1997, at... http://www.mbone.com/lists/confctrl.1997/0339.html >> http://foo/db/moviebase/twister (for the bootstrapping info) >> rtsp://foo/db/moviebase/twister/video1 >> rtsp://foo/db/moviebase/twister/audio1 Let's for the moment ignore the issue of a file system add-on that you and Roy have dismissed as being handled by "redirection"... would your arguments be the same if the container media stream was being "generated" on the fly by a "cgi-bin" like add-on to the media server? Imagine a cgi-bin that produces a video container file with a stream of randomized fractal images which morph along the timeline of the presentation synchronized with a music audio stream. Imagine that such a cgi-bin actually produces a resource which is a real AVI file, such that if said cgi-bin was running on a web server today it would work exactly as one might expect. The url for such a resource might be... http://foo/cgi-bin/fractalavi.exe?c1=ff00ff&c2=444400&e=0.3 Now, are you suggesting that a media server which knows the AVI file format, and needs to demultiplex this AVI file and send each of its contained streams to different ports, should inform the client of the existence of these streams, and should be informed of the port selections by the client via the following urls? rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/audio rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/video Are these legal URLs? Maybe I've misunderstood the uri spec, but I would expect a standard uri parser to barf on these. Certainly, such a parser would have no clue that the "/audio" and "/video" portions of the url are not to be sent to the cgi-bin and in fact are to be used in the demuxing process by the server component. Remember that this is a cgi-bin that runs on a web server and therefor has no idea of how to demux AVI. The server (not the cgi-bin add-in) will do the demux and routing to the correct port. -Brad ----------------------------------------- Brad Hefta-Gaub Mad Scientist, Technical Lead - RealMedia Progressive Networks ----------------------------------------- phone: (206)674-2272 fax: (206)674-2699 email: brad@prognet.com web: http://www.real.com -----------------------------------------
- Format of RTSP URLs Rob Lanphier
- Re: Format of RTSP URLs Bill Simpson-Young
- Re: Format of RTSP URLs Rob Lanphier
- Re: Format of RTSP URLs Roy T. Fielding
- Re: Format of RTSP URLs Roy T. Fielding
- Re: Format of RTSP URLs Rob Lanphier
- Re: Format of RTSP URLs Roy T. Fielding
- Re: Format of RTSP URLs Bill Simpson-Young
- Re: Format of RTSP URLs Rob Lanphier
- RE: Format of RTSP URLs Brad Hefta-Gaub
- Re: Format of RTSP URLs Roy T. Fielding