Subject: Why Stream IDs in URLs are bad. (was: RTSP and SDP with container files)

From: Brad Hefta-Gaub <[email-masked]>
Date: Sat, 21 Jun 1997 00:36:06 -0700

As you all consider the current strawman on the table for dealing
with container files and the targeting of single streams from that
container to multiple ports, I think we should keep in mind the 
following issue related to placing stream IDs in URLs.

Rob Lanphier wrote:

>> *  Embedding the stream id in the URL
>> 
>>    The disadvantage this approach has is in a modular system where the
>>    URL is being processed by a file system module that knows nothing
>>    about the specific datatype.  One could envision an RTSP server as
>>    a database rather than a traditional file server, where the original
>>    describe URL is actually a query to the server.  Coming up with a way
>>    of unambiguously appending a stream ID to that query is a non-trivial 
>>    matter (where does the query end and the stream ID begin?)

Basically, the problem that Rob is describing is a very real problem
for a massively scaled media server serving massive amounts of static and
live content. In such a scenario, a very real likelihood is that the actual
content is being served from a database object store instead of a standard 
file system. As such the URL is probably an actual query into the database.

This massively scaled media server probably supports the mounting of an
object store (file system) of arbitrary design within the name space of 
the media server. The resource request would be handed off to this arbitrary 
object store for the actual location of the resource bits. Obviously, the 
object store code is not interpreting the actual bits of the "blob" 
associated with the resource and formatting them into an RTSP and RTP friendly 
stream, instead some file format interpretation code is handling this task. 
The task of separating the individual streams of the container blob and 
sending them to multiple ports lives even further away from the object store 
component that located the bits.

Overloading the URL's parameters to perform the stream selection requires a 
mixing of which components handle the interpretation of the different parts of 
the URL in a way that seriously impacts the ability to successfully implement 
such a massively scaled server.

This problem is clear if you consider the following URL for locating a 
container media file (let's say a music video) on one of these massively 
scaled media servers...

 rtsp://server/db/query?artist="Nirvana"&album="Nevermind"

Now let's consider using an URL parameter named "track" to target a
container stream to a particular port. Under such a spec the URL
used for targeting the audio track of this video would be as follows...

 rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="audio"

This would conflict with a very reasonable implementation of the above data 
base query where the actual song "track" is to be selected. For example, the 
following would be broken...

 rtsp://server/db/query?artist="Nirvana"&album="Nevermind"&track="Polly"

Since the implementation of the actual object store can be arbitrary, the
meaning of the URL parameters, and the actual parameter names should belong 
to this object store, not the protocol that ultimately serves the resource.

-Brad

-----------------------------------------
Brad Hefta-Gaub 
Mad Scientist, Technical Lead - RealMedia
Progressive Networks
-----------------------------------------
phone: (206)674-2272
fax:   (206)674-2699
email: [email-masked]
web:   http://www.real.com
-----------------------------------------