Bit Rate Throttling and Smooth Streaming - Part 1

As more and more people evaluate the features in IIS Media Services, I occasionally get questions about how to use IIS Bit Rate Throttling with IIS Smooth Streaming.  In reality, these features work on separate types of content.  While they can run at the same time on a server, you would never typically use them on the same files.  Both features achieve a metered flow of content, but one regulates the flow using delivery logic on the server, while the other regulates the flow using request logic on the client.

In general, Bit Rate Throttling controls the server download speed of a large file, whether a video, a database, or some other content type.  Smooth Streaming, on the other hand, starts with a large video file formatted for Smooth Streaming delivery (e.g., MyVideo.ismv) encoded at several bit rates or quality levels, and typically splits the video into 2-second-long cacheable HTTP files as it is being delivered.  In effect, Smooth Streaming does not need Bit Rate Throttling, as the flow of 2-second-long HTTP video fragments is controlled by the just-in-time rate of requests coming from the Smooth Streaming client.

In this post, I'll talk more about Bit Rate Throttling.  In a subsequent post, I'll explain Smooth Streaming in a bit more detail.

Bit Rate Throttling takes an existing (typically large) file and reduces the speed at which that file is delivered.  While Bit Rate Throttling can be applied to specified file or MIME types of any kind, it was primarily designed to deliver video files, such as myVideo.flv or someVideo.wmv, using progressive download.  Progressive download describes the capability of a media player to start playing back a file being delivered from a standard Web server or network share before the whole file is downloaded.  

Using the default settings, Bit Rate Throttling does a few things during HTTP delivery of a video file:

1. Checks the file for information about the encoded buffer size, which is often 3-8 seconds - this is usually the minimum amount of video that has to be downloaded to a player to fill the video buffer and allow the video to start playing back even as downloading the file continues progressively in the background.
2. Checks the file for the encoded bit rate (e.g., 500 kbps).
3. Blasts down several seconds of data at full speed, to fill the video buffer and allow a user to start seeing video playback immediately.
4. Reduces the delivery rate to the encoded bit rate (e.g., 500 kbps) for the rest of the video until either:  a) the video finishes downloading, or b) the user performs a seek to another location in the video, which restarts the process at step 3.

The end result is that during progressive download, users only receive a few more seconds of data than they need to view the video, rather than downloading the whole file to them immediately. Especially on social media sites, users often stop playback of videos after watching only the first 10-20%; by using Bit Rate Throttling, you potentially save lots of bandwidth costs by not downloading the other 80-90% of the video that doesn't get watched.  As an added benefit, Bit Rate Throttling also keeps the egress path of your server free of fire-and-forget fast-as-possible downloads that could potentially congest the network connection and block other users from getting to your content. 

Bit Rate Throttling has some other really useful capabilities, such as:

• Dynamic Throttling, which shares bandwidth equally among users accessing a server; and
• Programmatic throttling, which allows you to turn Bit Rate Throttling on or off based on criteria you set - for instance, if you run a file download service, perhaps your non-paying users get slower file downloads than your paid subscribers.

Read more about Bit Rate Throttling at http://www.iis.net/BitRateThrottling, and look for Part 2 of this post.

Edit - Part 2 of this post is now available. (8/12/2010)