From: Nicholas Hart <[EMAIL PROTECTED]>
Subject: Re: SureStream "benefits"

At 04:00 PM 8/17/99 -0700, you wrote:
 >From: Kevin Irelan <[EMAIL PROTECTED]>
 >Subject: Re: SureStream "benefits"
 >
 >Someone said:
 > >[With SureStream] the Player
 > >automatically switches between the streams (while playing) to give you the
 > >best stream that can be run your available bandwidth.  Helps a lot in
 > >preventing those damn "network congestion: rebuffering" error messages.
 >
 >         I've come to think that SureStream actually increases the
 >potential for
 >net congestion.  In my experience the switching between stream rates is
 >almost never smooth, necesitating rebuffering.  And, unless one has a
 >dedicated internet connection, the bandwidth settings in the player seem to
 >be set to an impractically high value when based on modem speed thus
 >causing the player to  switch upwards to stream rates that dial up
 >connections can't support.  Any comments?

The RealPlayer maintains a buffer of data for the presentation.  For
argument's sake let's say it is buffers 10 seconds of data.  As soon as
bandwidth drops and this buffer starts to run dry (because data is being
read from it faster than the player can stream it from the network) the
player switches to a lower bandwidth setting.  It does not wait until the
player completely runs out of data-- this would certainly force rebuffering.

If you are having rebuffering problems the likely causes are:
- you have multiple sources in your presentation (eg: SMIL) and a
non-surestream source requires rebuffering,
- or you are not using rtsp for your surestream sources,
- or your bandwidth completely cuts out,

However, SureStream never increases bandwidth requirements, unless it
detects more bandwidth is available, in which case it will select a higher
bandwidth stream and increase bandwidth usage.  The stream switching itself
does not use extra bandwidth.

Also, even if the upper range of your player's bandwidth is set to a T1 and
you are using a modem it will never upshift to a stream that your
connection doesn't have the bandwidth to support.  It only upshifts when it
detects that the packets are arriving fast enough that it will be able to
maintain that higher bandwidth setting.

 >         On this subject, is the "monitoring" of network conditions (upon
 >which a
 >player's surestream connection rates are established) simply a measurement
 >of the datarate being received by the player at any given time?  Or, is
 >this an IP networking process?

The player uses some sophisticated algorithms for determining bandwidth
usage.  It does not do anything like ping servers to figure out how good
the bandwidth is.

Reply via email to