Subject: RE: RTSP, FastFoward and FastReverse

From: "Steven Levi (CSD)" <[email-masked]>
Date: Fri, 18 Oct 1996 13:04:05 -0700

Rao, thaks for your resonse.

Using Get/Set param to negotiate the definition of the rate field in the
is a good idea.  I still think it  makes sense though for the play
message 
to contain this information.  Any given  server can: 

1) ignore it 
2) use a default definition (if we can agree on one)
3) use Get/Set PARAMs  to alter its meaning. 

If I want to play at rate 4 and then play at rate 5 I should not 
have to send  setparam(), play(), setparam(), play(). I would rather: 

     setparam  (rate definition)  
     ...
     play(range1, 4) 
     play(range2,5)

And minimize control communications. The fact that the interface 
contains a field not supported in all cases should really be a problem. 

Steven Levi
Microsoft  - NetShow

>----------
>From: 	Anup Rao[SMTP:[email-masked]]
>Sent: 	Friday, October 18, 1996 12:36 PM
>To: 	Steven Levi (CSD)
>Cc: 	[email-masked]
>Subject: 	Re: RTSP, FastFoward and FastReverse
>
>Steven Levi (CSD) wrote:
>>
>> Currently,  there is no way to do Fast Forward (FF) or Fast
>> Reverse (FR) in RTSP. One simple way to do this would be to
>> add a signed 32-bit "rate" field to the play range message.
>>
>> This feature would be very useful for video playback.
>>
>
>Absolutely. However, (as you have also pointed out below), we believe
>this is a media specific property i.e the media itself may or may not be
>conducive to allow this (type of) subsampling or upsampling. Further,
>the server may or may not be up to performing this operation at a given
>time. We see this being accomplished via the SetParam mechanism, and we
>avoided defining this for RTSP-audio since it does not have any meaning
>meaning. Also, it is a good idea that the transmitted data rate not
>change at all for this operation.
>
>Our attempt has been to put all the core properties of the realtime
>stream in the control, and anything that does not apply to *all* media
>streams in the family specific parameters/properties. An example of how
>we see this being done is :
>
>Family RTSP-video = 2.
>Parameter = 1 : Format descriptor
>Parameter = 2 : Video annotations
>Parameter = 3 : SetSampleRate(n) for  up, SetSampleRate(1/n) for
>slowdown.(Fractional rates also to be considered)
>
>Client                         Server
>fetch    --->
>         <---               stream header
>
>SetParam(SetSampleRate(5)) -->
>
>         <-----             Reply or Refuse
>
>PlayRange() ---->
>           <-----            Data
>
>        If the transmitted bandwidth changes even slightly,(for eg by
>transmitting I frames only), the client should be informed of it in the
>Reply. (Would strongly recommend that this possible change of rate
>should be avoided by regulation at the server end)
>
>        One might argue that this should belong in a message such as
>play_range, as you have proposed. The downside of this is for some media
>this has no meaning. Also, it would be a good idea to be able to query
>the possibility(again via GetParam). We believe this mechanism is
>inherently
>more extensible, yet satisfies the requirements.
>
>> A positive rate implies  forward:  From -> To
>> A negative rate implies  reverse:  To -> From
>>
>        This should work fine.
>
>Thank you very much for the input. We should probably  explain
>some of this in the draft.
>
>-- 
>-----------------------------------------------------------------
>  Anup Rao                                                      
>  Netscape Communications Corp.  -  LiveMedia                   
>  email : [email-masked]         Phone : (415) 937 3129       
>-----------------------------------------------------------------
>