Advanced Fast Start

Updated: October 4, 2007

Applies To: Windows Server 2008, Windows Server 2008 R2

Advanced Fast Start is designed to minimize startup latency in Windows Media Player 10 or later. Startup latency is the period of time starting when a viewer requests a stream by using the Player and ending when the content begins playing. A number of factors can introduce latency such as the speed of the client computer, the state of the network, the available bandwidth, and the Windows Media server configuration. However, the primary reason for startup latency is the delay caused by buffering on the client.

An adequate buffer size is essential for providing a good user experience. The client buffer stores streaming media data in memory so that the Player can maintain smooth playback of a stream. With inadequate buffer size, presentation playback can be uneven. The buffer is also used by codecs that decode a stream. When more buffer memory is available to codecs, the audio and video quality is improved.

The buffer size affects the amount of startup latency because a client cannot begin playing a stream until the buffer is full. The Fast Start feature in Windows Media Services reduces latency significantly by streaming the data at an accelerated rate until the buffer is full. However, the stream still cannot be played until that point.

Advanced Fast Start enables the Player to begin playing a stream before its buffer is full. When the Player receives a minimum amount of data, it can begin playing a stream while its buffer continues to fill at an accelerated rate—a rate that is faster than the encoded bit rate of the content. When the buffer is full, acceleration stops and the Player begins receiving data at the encoded bit rate.

For Advanced Fast Start to work effectively, adequate bandwidth must be available above the encoded bit rate of a stream. For example, if 1,200 kilobits per second (Kbps) of bandwidth is available for an 800 Kbps stream, the Player can use an acceleration rate of 1.5 times the encoded bit rate. On the other hand, if no additional bandwidth is available, the Player must fill its buffer before it begins playing a stream and no benefit can be gained from either Advanced Fast Start or Fast Start.

To use Advanced Fast Start, it must be enabled on both the Player and Windows Media Services because it depends on communication between the two components when the Player initially requests a stream. On the client side, Advanced Fast Start is supported by Windows Media Player 10 or later or by Windows CE 5.0 or later (using the HTTP protocol).

Advanced Fast Start requires that the Windows Media server send an accelerated bit rate stream. Therefore, this feature is only available for unicast streaming.

The following process describes how Advanced Fast Start works after the Player sends a request and the server has successfully located the requested content and authorized the Player to receive it:

  1. The server analyzes the content, and calculates the following data for a number of acceleration rates:

    • Largest underflow amount. Underflow occurs when the Player renders the data faster than it is being received. When underflow occurs, the Player must stop and buffer more data. Therefore, underflow must be avoided to maintain a quality user experience. The largest underflow amount is the largest amount of extra data that the client will require during a given acceleration period to avoid underflow. The higher the acceleration rate and longer the acceleration period, the less likely it is that underflow will occur. The server initially determines a fixed acceleration period.

    • Time of underflow. The time that the largest underflow amount occurs.

    The server typically sends the client data at the following acceleration rates: 1.0, 1.2, 1.5, 2.0, and 3.0. For example, the data might show that with an acceleration rate of 1.2, the client will need 150 KB of additional data in its buffer after five seconds to avoid underflow.

  2. The Player calculates the current bandwidth between the client and server, and then requests the most appropriate acceleration rate from the server.

  3. The server streams the content at the requested acceleration rate.

  4. The Player buffers the minimum amount of data, checks to make sure that adequate data has been received, and then begins playing the content. Meanwhile, its buffer continues to fill at the requested acceleration rate.

  5. When its buffer is full, the Player sends a message to the server to end acceleration, and begins streaming at the encoded bit rate.

See Also

Community Additions