Subject: Re: stream primitives

From: "Marc Eshel/Almaden/IBM" <[email-masked]>
Date: 7 Jan 97 13:35:33

Here is a note that I sent to 'rtsp-partners @ netscape.com' on Dec 17 .
  I guess the discussion moved to this location?

To:  rtsp-partners @ netscape.com @ gw
cc:  (bcc: Marc Eshel/Almaden/IBM)
Subject: stream primitives

Hi,
Here are some suggestion on how to improve the RTSP.
First I think that RTSP' should become prime draft on which we build
to get to the final standard. One thing that I noticed from attending
few IETF sessions last week is that there is a lot of reinventing. Using
HTTP as the starting point will probably cut few years from the
standardization process.

I also think the dsm-cc stream primitives are a good starting point
for the VCR like functions that should be supported. The dsm-cc as
a whole is too complicated but the set of stream primitives is small
and makes a lot of sense for multimedia control interface.
We can add or delete from the dsm-cc stream primitives but not
reinvent again an interface when we have something that evolved for few
years. dsm-cc is more popular in Japan and Europe and most video servers
there support this interface. I suspect that any serious video server
will have to support both dsm-cc and RTSP so lets make it easy to do.

Here are some things that we get from dsm-cc stream primitives. Some
of the items were already suggested by other people, but I want to
repeat them to both show support for the suggestion and show that
they exist in dsm-cc.
1. offset: 64 bit offset with 32 bit seconds and 32 bit microseconds.
2. scale (speed): a numerator/denominator indicates rate and direction.
   A negative numerator indicates reverse direction. 1/1 indicates
   normal play speed and 1/2 is half the normal play speed.
3. pause: first we should distinguish between pause and stop (dsm-cc
   close) because when we pause we don't want to free resources.
   We also need pause-at-offset which is important to keep to streams
   in sync. (like audio and video on 2 different servers).
   Another important reason for pause-at-offset is to let the server
   know where it will be expected to resume from, which is important
   for the server so it can prefetch the data and response faster to
   resume/play.
4. next: next is a primitive form of play list and we might even need
   play list but at the minimum we need next. Next is a way to queue
   a stream behind another stream for both smooth transition from
   one stream to another and also to make sure that you have resources
   for the next stream. If you stop one stream and start another
   the server might give up the resources used for the first stream
   and will not be to get resources for the second stream. next will
   guaranty that you have the resources and save some work on the server
   side too.

Another important improvement was made (that is not in dsm-cc) is to
have the options to specify offset in different units. The two mandatory
formats should be relative time-stamp and byte offset (64 bits).
Other units can be frame number, absolute time, etc.

Regards, Marc.