Subject: Re: [MMUSIC] RTSP: Speed and Scale overview text

From: Magnus Westerlund <[email-masked]>
Date: Fri, 06 Mar 2009 14:31:06 +0100

Hi,

I have received some input and have made an attempt for specification
text that covers several of the use cases. Here is the text that
currently is proposed:

Excerpt from Section 2.4.1:

   Speed affects how much of the playback timeline that is delivered in
   a given wall clock period.  The default is Speed = 1 which is to
   deliver at the same rate the media is consumed.  Speed > 1 means that
   the receiver will get content faster than it regularly would consume
   it.  Speed < 1 means that delivery is slower than the regular media
   rate.  Speed values of 0 or lower has no meaning and are not allowed.
   This mechanism enables two general functionalities.  Client side
   scale operations, i.e. the client receives all the frames and makes
   the adjustment to the playback locally.  The second usage is to
   control delivery for buffering of media.  By specifying a speed over
   1.0 the client can build up the amount of playback time it has
   present in its buffers to a level that is sufficient for its needs.

   A naive implementation of Speed would only affect the transmission
   schedule of the media and has a clear impact on the needed bandwidth.
   This would result in the data rate being proportional to the speed
   factor.  Speed = 1.5, i.e. 50% faster than normal delivery, will then
   result in a 50% increase in the data transport rate.  If that can be
   supported or not depends soley on the underlaying network path.
   Scale may also have some impact on the required bandwidth due to the
   manipulation of the content in the new playback schedule.  An example
   is fast forward where only the independently decodable intra frames
   are included in the media stream.  This usage of only intra frames
   increase the data rate significantly compared to a normal sequence
   with the same number of frames where most frames will be encoded
   using prediction.

   This potential increase of the data rate needs to be handled by the
   media sender.  The client has requested that the media is delivered
   in a specific way, which should be honored.  However, the media
   sender can not ignore if the network path between the sender and the
   receiver can't handle the resulting media stream.  In that case the
   media stream needs to be adapted to fit the available resources of
   the path.  This can result in that media quality has be reduced due
   to the delivery modifications that the client has requested.

   The need for bitrate adaptation becomes especially problematic in
   regards to Speed.  If the is target is to fill up the buffer then the
   client may not want to do that at the cost of reduced quality.  If
   you like to do local playout changes then you may actually require
   that the requested speed is honored.  To resolve this issue the usage
   of speed specifies a range so that both usages can be supported.  The
   server is request to use as high as possible speed value within the
   range if the bandwidth is insufficient for the upper bound.  As long
   as the server can maintain a speed value within the range it shall
   not change the media quality, instead modify the speed value in
   response to available bandwidth.  Only if the server becomes unable
   to maintain the lower bound speed value does it need to modify the
   media quality to maintain the lower bound speed value.

   This functionality enables the local scaling implementation to use a
   tight or even a range where lower bound equals upper bound to
   identify that it requries the server to deliver the requested amount
   of media time per delivery time independent of how much it needs to
   adapt the media quality to fit within the available path bandwidth.
   For buffer refilling it is suitable to use a range with a reasonable
   span and with a lower bound at the nominal media rate like 1.0 - 2.5.
   If one likes to reduce the buffer one specifies an upperbound that is
   below 1.0 to force the server to deliver slower than nominal media
   rate.

16.47.  Speed

   The Speed request-header field requests the server to deliver
   specific amounts of nominal media time per unit of delivery time,
   contingent on the server's ability and desire to serve the media
   stream at the given speed.  The client requests the delivery speed to
   be within a given range with an upper and lower bound.  The server
   SHALL delivery at the highest possible speed within the range, but
   not faster than the upper-bound, for which the underlying network
   path can support the resulting transport data rates.  As long as any
   speed value within the given range can be provided the server SHALL
   NOT modify the media quality.  Only if the server is unable to
   delivery media at the speed value provided by the lower bound shall
   it reduce the media quality.

   Implementation of the Speed functionality by the server is OPTIONAL.
   The server can indicate its support through a feature-tag,
   play.scale.  The lack of a Speed header in the response is an
   indication of lack of support of this functionality.

   The speed parameter values are expressed as a positive decimal value,
   e.g., a value of 2.0 indicates that data is to be delivered twice as
   fast as normal.  A speed value of zero is invalid.  The range is
   specified in the form "lower bound - upper bound".  The lower bound
   value may be smaller or equal to the upper bound.  All speeds may not
   be possible to support.  Therefore the server MAY modify the
   requested values to the closest supported.  The actual supported
   speed MUST be included in the response.  Note however that the use
   cases may vary and that Speed value ranges such as 0.7 - 0.8,
   0.3-2.0, 1.0-2.5, 2.5-2.5 all has their usage.

   Example:
     Speed: 1.0 - 2.5

   Use of this header changes the bandwidth used for data delivery.  It
   is meant for use in specific circumstances where delivery of the
   presentation at a higher or lower rate is desired.  The main use
   cases are buffer operations or local scale operations.  Implementors
   should keep in mind that bandwidth for the session may be negotiated
   beforehand (by means other than RTSP), and therefore re-negotiation
   may be necessary.  To perform Speed operations the server needs to
   ensure that the network path can support the resulting bit-rate.
   Thus the media transport needs to support feedback so that the server
   can react and adapt to the available bitrate.

>From 20.2.3: Header syntax:

   Speed            =  "Speed" HCOLON POS-FLOAT MINUS POS-FLOAT

   MINUS    =  SWS "-" SWS ; minus/dash

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------