Search results matching tags 'Media' and 'Bit Rate Throttling'

IIS Media Services 3.0, including IIS Live Smooth Streaming, has been released

chriskno — Mon, 12 Oct 2009 21:31:00 GMT

What Just Happened?

We just released IIS Media Services 3.0, a set of extensions for Internet Information Services 7 (IIS) that provide an integrated HTTP-based media delivery platform. This includes the new IIS Live Smooth Streaming and the separate IIS Advanced Logging package.

In addition, we released the beta of the Smooth Streaming Player Development Kit, which allows developers to easily create Smooth Streaming experiences using Silverlight. Supported features include PlayReady, DVR controls, instant replay, slow motion, multiple camera angles, alternate audio tracks, content protection, ad integration, in-stream data feeds, and more.

Market Impact

Since April, 2009, key broadcasters around the world have used beta versions of IIS Media Services 3.0 to successfully broadcast some of the world's premier live events. These include the Tour de France and the Roland Garros 2009 International French Open Tennis Tournament on France Télévisions; the IAAF Athletics World Championships and FINA Swimming World Championships on both France Télévisions and RAI; the FIFA Confederations Cup South Africa 2009 on RAI; and Champions League Soccer on BSkyB; as well as events such as the Michael Jackson Memorial on Sympatico/MSN inMusic and SKY News. In a combined effort with Microsoft, NBC Sports and others, Wimbledon Live delivered more than 6,500 minutes of live and on-demand Smooth Streaming video via a high-definition (HD), interactive online video experience. Each Sunday this Fall, NBC and Microsoft are broadcasting Sunday Night Football on-line in HD, utilizing live DVR controls, multiple camera angles, slow motion, ad integration, analytics, and other cutting-edge features. 26 such trial deployments are currently highlighted on the Smooth Streaming Showcase.

Component Overview

With this release, the key elements of the IIS media server platform now include:

Smooth Streaming, adaptive streaming of media over HTTP
Live Smooth Streaming, for live adaptive streaming of broadcast events
Smooth Streaming Player Development Kit, for creating custom clients
Bit Rate Throttling, meters the speed that media is delivered to a player
Web Playlists, secure sequencing of media content
Advanced Logging, with real-time client- and server-side logging
Application Request Routing (ARR), providing HTTP proxying and caching

Download the latest IIS Media offerings

You can download all of the IIS media server platform components using the Web Platform Installer button on the IIS Media page (http://www.iis.net/media).

Key new features:

See these blog posts to learn more about the key new features that are part of this release:

IIS Live Smooth Streaming: http://blogs.iis.net/jboch/archive/2009/10/09/rtw-of-live-smooth-streaming-is-now-live.aspx
IIS Advanced Logging: http://blogs.iis.net/vsood/archive/2009/10/12/iis-advanced-logging-1-0-released.aspx
IIS Smooth Streaming Player Development Kit – Beta 1: http://blogs.iis.net/vsood/archive/2009/10/09/iis-smooth-streaming-player-development-kit-1-0-beta-1-released.aspx

Give the IIS Media server platform a try, and let us know what you think on our Forum.

-Chris

IIS Media Pack 1.0 Released

chriskno — Sat, 08 Nov 2008 01:19:29 GMT

Following up on our Smooth Streaming announcement last week, today we released IIS Media Pack 1.0! This first release of the IIS Media Pack features two IIS 7.0 extensions that focus on the intelligent delivery of video and audio to end users: Bit Rate Throttling, and Web Playlists.

Bit Rate Throttling

Bit Rate Throttling gives Web server administrators the ability to automatically meter the delivery of 11 built-in media file types, including Windows Media Video (.wmv), Flash Video (.flv), and MPEG-4 (.mp4) files. Additional media formats can be added, as can any non-media file type. By controlling how fast or how much data is downloaded to the client, site operators can see significant bandwidth cost savings for rich media content that has a high drop-off rate, such as videos on popular social media sites. When bandwidth is a concern, reducing the amount of data being sent to end users can increase the number of concurrent users per server.

Another feature of Bit Rate Throttling is dynamic throttling. When enabled, IIS can dynamically split your total available bandwidth allocation across all concurrent users. If you are billed for network usage based on a peak usage billing model, rather than number of datas transferred, this equitably shares extra available bandwidth among all of your users. As new users start to consume the extra bandwidth, dynamic throttling reduces bandwidth to each user, but ensures that the allocated bandwidth for each user will not fall below the specified bit rate for the content being consumed.

Web Playlists

Web Playlists let you deliver server-controlled media playlists from your Web server infrastructure, rather than using a dedicated streaming server. They enable you to control whether clients can Seek or Skip for each media asset, which lends itself very well to monetizing your content with pre-roll and in-stream ads. Web Playlists also obfuscate the location of media assets from the end user, and prevent client-side caching of those assets.

Web Playlists are simple to create and deliver. They are based on a standard playlist format (SMIL), are transformable to other common playlist types, and can be used with many popular media players. If you have existing business applications written in ASP, PHP, etc. to personalize the end user experience, it can be used with Web Playlists on your IIS 7.0 server to provide custom media playlists.

Call to Action

Download and try out the new IIS Media Pack 1.0 release! Add your comments below, or join us in the IIS Media forum, to let us know how well IIS Media Pack 1.0 meets your needs, and how we can make it even better for the next release.

Resources

IIS Media overview

Bit Rate Throttling details

Web Playlists details

IIS Media Pack downloads: 32-bit; 64-bit

Media delivery options in the Web Platform Installer

chriskno — Fri, 17 Oct 2008 06:18:24 GMT

Yesterday, we released the new Microsoft Web Application Installer, or Web AI, at www.microsoft.com/web. This tool for IIS7 allows you to simply install and get running with some of the most popular PHP and ASP.NET open source and community applications.

In case you missed it, we also released another tool on www.microsoft.com/web a few weeks ago: the Web Platform Installer (Web PI). Think of this, as Bill Staples put it, as "a one stop shop for downloading and installing the Microsoft Web Stack including IIS, ASP.NET, SQL Server, Visual Web Developer, all of the current IIS Extensions and more!" The IIS Media Pack features are among the IIS Extensions available in Web PI. If you use this tool, you will always get the latest production-ready versions of the IIS media features.

Here's the quickest way to find and install the IIS media features, using Web PI in five steps:

Launch Web PI: http://go.microsoft.com/?linkid=9588072
Click on Run when prompted
After a moment, when the Web PI application appears, scroll down to the Media section
Check the features you want (see screenshot, below)
Click on Install and follow a few prompts

-Chris

Windows Media Server or Web Server?

dmnelson — Thu, 15 May 2008 20:57:00 GMT

As promised in Chris Knowlton's Blog, we have an updated document that compares digital media content delivery from Windows Media servers (running Windows Media Services 2008) and Web servers (running IIS 7.0). You can find it here.

Concepts of IIS Bit Rate Throttling – Part 2

jimin_gao — Fri, 02 May 2008 01:22:00 GMT

Managing Service Quality

There are many situations under which we would like to impose limits to file serving speed and the number of clients served. For example, a large rogue media file with a huge (faked) bit rate may induce unfair server bandwidth contention with legitimate media files of small bit rates and cause their serving quality to deteriorate; similarly serving too many requests simultaneously for certain popular media files can also cause server saturation that defeats the purpose of progressive download—nobody can have a smooth viewing experience. The Bit Rate Throttling settings maximum throttle rate and connection limit are designed for better management of such undesirable scenarios. In addition, a default throttle rate can be applied to all files at a certain location, being it a site, virtual directory, or physical folder, so that these files, which may be of too many different types to have a throttling setting for each, can all be served at a reduced constant speed when no explicit throttling settings apply.

Maximum Throttle Rate

The maximum throttle rate is the largest permitted speed to serve a throttled file. For example, if the maximum throttle rate is set to 500kbps the previous FLV file configured to be throttled at 363kbps would still be served at 363kbps, while with a maximum throttle rate of 300kpbs (smaller than the calculated throttle rate) the file will be served at 300kbps. The same logic also applies to data file throttling. Note however the maximum throttle rate only affects files to be throttled (by file-type throttle settings or default throttle rate settings) and those without applicable throttle settings will still be sent at full speed regardless.

The maximum throttle rate can be used by server administrator to impose restrictions on different sites to ensure fairness and serving quality when used in combination with connection limit. Typically it should be set and locked in applicationHost.config. The maximum throttle rate can be configured through Bit Rate Throttling GUI (in Advanced Settings dialogue), as demonstrated in this walkthrough, or by editing IIS configuration files.

Connection Limit

The maximum number of simultaneous HTTP connections, or the connection limit, can be set for a collection of file types in an IIS site using the Bit Rate Throttling Module. For example, in a site we may define all FLV, AVI, ASF, and WMV files as a connection limit group called Video, and MP3 and WMA files as another called Audio. For each defined connection limit group we can set a connection limit, for example, 100 for Video and 200 for Audio. Then the maximum number of simultaneous downloads for all files belonging to Video will be 100, and the 101th request will be rejected with HTTP status code 503 (Service Unavailable). Similarly the 201th request for Audio files will be rejected. Notably different from other Bit Rate Throttling configuration settings, the connection limit settings and restrictions are site based, and therefore

A file may belong to different connection limit groups for different sites.
Connection limits can be different for different sites.
Any of these settings at levels lower than site are ignored.
The current number of connections for a connection group is aggregated for each site and the connection limit restrictions are applied to each site independently.

Multiplying maximum throttle rate with the total connection limit of a site can give us the peak bandwidth usage for all the regulated files in this site. So used together these settings limit the bandwidth usage for different sites, especially of large media and data files to balance the service quality of different types of contents. For example, we may set the maximum throttle rate and connection limits for video files for every site, ensuring that their total peak usage will not exceed our server bandwidth so that every (served) user's experience can be guaranteed. We may also set these numbers to ensure the serving of HTML web pages is not disrupted by the bandwidth usage of media contents. The connection limit groups and connection limits can only be set by editing IIS configuration files and are not accessible for GUI. See Jack's blog for how this can be done. It is recommended they are configured and locked in applicationHost.config only.

(Note: there is an issue in the current release that connection limits are at times not correctly enforced. This is to be addressed by a forthcoming patch.)

Default Throttle Rate

The default throttle rate acts as the fallback throttle rate when no explicit throttle settings can be applied to calculate the throttle rate of a file. When set to 0, default throttle rate is disabled and files without applicable throttle settings will be sent at full speed at HTTP responses. The default throttle rate is a convenience feature to manage the send rate of all file types in a particular location, which may be a site, a virtual directory, or a physical folder (through web.config), so that we do not have to add a throttle settings for each type. By purposed arrangement of files into different locations, the default throttle rate to an extent can be used for managing total bandwidth usage and service quality as well.

Dynamic Throttling

The maximum throttle rate and connection limits are typically used for setting a bandwidth allowance for a site, but this peak estimate is rarely used in full; files usually are throttled at a rate much lower than the maximum throttle rate, and connection limits are not reached most of the time. Dynamic Throttling is a Bit Rate Throttling feature designed to make better usage of the reserved bandwidth for a site or connection limit group. The per-site setting target throughput rate explicitly states the total bandwidth allowance for regulated files in a site, and when under light load the Bit Rate Throttling Module will scale up the throttle rates to make maximal usage of this allowance. The throttle rates are adjusted up and down on-the-fly depending on the throttle rate presets and the number of connections for the files but never lower than the presets. For example, there is a file A with the throttle rate (calculated from configuration) of 400kbps and a file B with the throttle rate of 100kbps belonging to the same site with its target throughput rate set to 5000kbps. Their actual throttle rates will be scaled up to 4000kbps and 1000kbps so the total bandwidth is equal to the target throughput rate 5000kbps when A and B are simultaneously served. Now suppose another request for A comes in. Serving this additional request, the Bit Rate Throttling Module will adjust down the throttle rates proportionately. File A will then be sent at 500 * 5000 / (500 * 2 + 100) = 2273kbps and B at 100 * 5000 / (500 * 2 + 100) = 455kbps; the total bandwidth usage for all 3 connections is still 5000kbps. When one of the responses is finished, the rest will be again adjusted up. Note that the throttle rate will never be adjusted to lower than the configured rate, 500kbps for A and 100kbps for B in this case, even when the target throughput rate is exceeded due to a large number of connections. Un-throttled files will not be affected by dynamic throttling.

In addition to sites, the target throughput rate can be configured for connection limit groups as well with similar logic (note connection limit group itself is a site-level only setting). The configuration can be done from the GUI (sites only) or by editing IIS configuration files. See Vishal's blog for a more thorough description of this feature.

(To be continued …)

Concepts of IIS Bit Rate Throttling – Part 1

jimin_gao — Wed, 23 Apr 2008 06:29:00 GMT

Bit Rate Throttling is the first IIS extension module released in IIS Media Pack. It adds to IIS the capability of per-response bandwidth control for the delivery of media and data contents. The idea for this module initially grew out of the need to serve progressive media downloads while saving bandwidth costs. Its core functionality was to automatically detect the encoded bit-rate of files of a wide range of video and audio formats and serve the requests at a ratio to the encoded bit-rate as specified by the administrator. However, during its development we saw the needs of more general bandwidth control capabilities that can be logically combined with its media functionalities and over time Bit Rate Throttling Module has evolved into a full-rounded bandwidth control package for IIS.

There are several blog articles describing in detail aspects of Bit Rate Throttling. Here however I would like to give an overview of the capabilities of this module, not too drawn into the technical details but with enough information for a clear understanding of its capabilities so that users looking for solutions to their problems can make informed decisions. This article also tries to serve as the string for the beads and will provide links to previously available articles within this context, so that those interested in more hands-on details can easily locate the needed resources.

The basic promise of Bit Rate Throttling is the measured slowing down of sending out a HTTP response. The actual send speed can be controlled in various ways for various purposes and the most notable one is the automatic throttling of media files.

Intelligent Media File Throttling

Bit Rate Throttling for IIS can automatically detect the encoded bit rate of a media file and send the file at an administrator-configured speed ratio to this bit rate. For example, if an ASF video file has a video data rate of 300kbps (kilobits per second) and audio data rate of 30kbps, and ASF files are configure to be sent at the speed ratio (throttle rate percentage) of 110%, this file will be sent at the speed of (300kbps + 30kbps) * 110% = 363kbps. This speed is sufficient for uninterrupted viewing of the video on the client side assuming ample network bandwidth between the server and the client. However, to factor in possible network fluctuations most media players buffer some of the content before starting to play. Correspondingly Bit Rate Throttling has a configurable fast start time for each media type such that initial media content within this (play) time period will be sent without throttling so that the player buffer can be quickly filled before playing. For example, if ASF files are configured to have a fast start time of 10 seconds, then the initial (300kbps + 30kbps) * 10s = 3300kb of the file above will be sent at full speed and the rest will then be sent at 363kbps.

Supported Media Formats

The types of media files supported by Bit Rate Throttling upon installation includes ASF, WMV, WMA, FLV, MP3, MP4, M4V, MOV, AVI, RM, and RMVB. The throttle rate percentage and fast start time can be configured per file type through Bit Rate Throttling GUI or by editing IIS configuration files. See this walkthrough for how this can be done.

Extended Media Format Support

It is also possible for Bit Rate Throttling to support additional media formats, assuming the format specifications are known and have the following characteristics so that their encoded bit rates can be obtained using a simple search:

1. Bit rate information exists in the media file at a fixed offset from a certain keyword (search pattern), OR

2. Content duration information exists in the media file at a fixed offset from a certain keyword (search pattern).

Most known media file formats satisfy these properties and therefore can be supported by Bit Rate Throttling. In essence, the Bit Rate Throttling Module will first find the search pattern (keyword) in the file and then read the bit rate or duration information at the offset. The bit rate or duration information may be encoded in various formats, such as big or little-endian and float or integer. If there are multiple bit rates available, such as in the previous example where the ASF file has a video bit rate of 300kbps and an audio bit rate of 30kbps, they are added together to obtain the total bit rate 330kbps. If there is only duration information available, it is used to divide the file size to obtain the estimated bit rate.

The media format information can be added to by editing the IIS configuration file and this functionality is not accessible from GUI. See this walkthrough for how this can be done. It is worth noticing that most out-of-the-box media type supports are attained though the same mechanism except for MP3 and AVI files which have dedicated file parsers due to their complexity. Once a file type is added to media formats in IIS configuration files, the media format becomes known to Bit Rate Throttling and their throttle rate percentage and fast start time can be configured just like natively supported media files.

Data File Throttling

Files not treated (known to Bit Rate Throttling Module) as video/audio media can be sent at a fixed rate as HTTP responses using Bit Rate Throttling. They are called data files and similarly to media files their throttle rate can be configured per file type (extension). However the rate is not specified as a percentage ratio but absolute send speed in kbps. There is an also a configurable initial send size (in kilobytes) for each data file type corresponding to the fast start time of media files.

The throttle rate and initial send size for data files can be configured through Bit Rate Throttling GUI or by editing IIS configuration files. The configuration entries for media and data files are distinguished by their throttle types, which may be media or data. This explicit distinction is necessary because a media type known to Bit Rate Throttling can nonetheless be treated as either media or data files for throttling purpose. See this walkthrough for detailed steps to configure data file throttling.

The throttling of data files can be useful for the distribution of large documents such as PDF and PPT files which similarly to media files are inherently serial but do not have the notion of unit-time bit rates.

(Continue to Part 2)

Bit Rate Throttling is the pick of the week on Channel 9

vsood — Tue, 22 Apr 2008 20:30:00 GMT

Bit Rate Throttling was Brian's pick of the week on channel 9. We love you Brian :)

Here is the link to video and the post on the site - Click (To see the relevant section in the video seek to around 16:28 into the video.)

Here is the excerpt from the post:

This Week on Channel 9, Dan and Brian cover:

- Updates to Live Maps and Virtual Earth 3D - including export GPS, new traffic-based directions, importing of 3D models into VE 3D (add a massive 9-guy on campus), MapCruncher for overlays of user-generated information (stadium seats), and more (0 - 2:41)
- .NET 3.5 Training Kit - ASP.NET Dynamic Data, MVC, Silverlight, etc, via Greg Duncan (2:41 - 3:30)
- Follow up from last week: Firechild in the forums points to a .NET Rocks episode with Jon Goodyear on how to program SMS (3:30 - 5:26)
- Follow up story: Gizmodo has first video of a Surface at an AT&T store showing interactive AT&T coverage map, dynamic device colors, information and even phone comparison. (5:26 - 8:06)
- Symantec releases study showing Microsoft is #1 in fewest days in average response time for security vulnerabilities via Matt Hardman (8:06 - 9:51)
- Dan and Brian's reaction to the internal leaked Vista SP1 video and Microsoft's original response. (via DCMonkey in the forums). (9:51 - 12:28)
- The Channel 9 Dev team releases Developer Diary, a recurring weekly show on what features they're working on (12:28 - 13:18)
- The N+ Dev Team talks about how you build an Xbox Live Arcade game and how you program against lag (13:18 - 14:50)
- Dan's Pick of the Week: 15-year old Ashish Dergawan's Coding4Fun article on how to convert a laser pointer into a mouse by using a motion tracking web camera (14:50 - 16:30)
- Brian's Pick of the Week: IIS Pack for bit-rate throttling of Web Videos via Vishal Sood (16:30 - end)

Are you saving bandwidth yet?

Bit Rate Throttling is 1 week old - some interesting thoughts and applications

vsood — Fri, 21 Mar 2008 20:55:00 GMT

Last week, we announced the release of Bit Rate Throttling (BRT) module and there has been a lot of positive feedback already. I love the way the world of media latches on to new things so fast.

Scott Guthrie posted about the release in his blog here. Thank you Scott! I really like how he captures the importance of this module in the entire eco-system.

Is there something about BRT that all Scott's seem like it?

I say this because Scott Hansleman also posted about BRT. In his post he covers a great scenario from the podcasting world. He wants to save bandwidth if the customer watches the podcast online and not throttle while they try to download. Great example of how excellent customer experience and savings can go hand in hand.

Podcasting is very relevant application area for BRT since the bit rates are low there and almost always all files will get downloaded pretty fast. Here is Scott in his words:

That's the problem this module tries to solve. If you think it's not a problem, talk to me or Carl. It costs a metric buttload to pay for bandwidth of my podcast and it's a harder problem to solve than you think. (Yes, every show has bittorrent as an option, but few Feed Readers use it). A surprising number of folks visit the site and just click on a show and start listening in whatever Media Player they dig. If someone starts streaming the first 20 seconds of a 45 minute show, decides they don't like it and stops, we may have to pay for the whole 45 minutes as it might already have been downloaded! This is also good for screencasts.

Scott, in this blog implements a module on server-side to determine whether to throttle or not using URL distinctions. Read more about the scenario here. Also, since BRT is really format agnostic, it works really well for any media downloads.

To summarize, if you are Scott, you must try BRT. If you are not Scott, go beat the Scott's to it :)

In addition a very smart dev on our team Jack blogged about another great feature in BRT, connection limits. Here is an excerpt from Jack's blog:

The recent release of the Bit Rate Throttling Module for IIS provides some useful and compelling features for managing response rates for data and media files. One of the interesting features that is included is the notion of a connection limit group. While IIS (via HTTP.SYS) provides a mechanism for limiting the concurrent connections for an entire site (see Advanced Settings in the UI), our Bit Rate Throttling module goes a step further, allowing admins to define and configure their own connection limits, grouped according to file type (based on file extension) or mime-type (based on the content-type response header).

I blogged about Dynamic Throttling feature in BRT. Here is an excerpt from that post

In our earlier releases if we had Bit Rate Throttling enabled, we would just throttle the media/data file at the desired rate. This is very useful, however there are scenarios where you want to use throttling to plan bandwidth better, for example, you want to be able to support more simultaneous downloads. In these scenarios there might be conditions where the load on the server is less

Do you have any interesting ideas on how you used BRT? I am sure I am missing many more thoughts out there.

Dynamic Throttling with Bit Rate Throttling

vsood — Mon, 17 Mar 2008 20:56:00 GMT

In the latest RTW release of Bit Rate Throttling, we have an amazing feature - dynamic throttling. It can also be looked at as bandwidth splitting. The primary intentions of this post is to serve as an introduction to this feature.

In our earlier releases if we had Bit Rate Throttling enabled, we would just throttle the media/data file at the desired rate. This is very useful, however there are scenarios where you want to use throttling to plan bandwidth better, for example, you want to be able to support more simultaneous downloads. In these scenarios there might be conditions where the load on the server is less. In this situation you may not want to throttle the response or you may want to split the available bandwidth among all active connections at any given point. Dynamic throttling allows you to do this. This feature lets you use all of the availble bandwidth and split is among all active connections. The availble bandwidth needs to be configured in IIS by setting the "Site target throughput rate" setting in Advanced Settings in the UI. As the name suggested this setting is availble at site level or below only.

This can also be set in the config directly (not advised though). Here is an example web.config

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <media>
            <bitrateThrottling targetThroughputRateKbps="1000000" />
        </media>
    </system.webServer>
</configuration>

Dynamic Throttling in simple scenarios

Using Dynamic Throttling with media/data rules

Consider the scenario below:

All files being served are .wmv
Each file is encoded at 400 Kbps
The throttle rate for each wmv is 100% (i.e., 100% of 400 Kbps = 400 Kbps)
The site target throughput rate is configured at 1 Gbps

In this case the media throttle rate acts as a minimum required. The availble bandwidth (1 Gbps) will now be distributed evenly among all active connections from a server perspective. For example, if there are 1000 concurrent connections, each will be throttled at 1 Mbps. This will go on till a maximum of 1 Gbps / 400 Kbps = 2500 concurrent connections. Although, here we take an example for media rule, the same is valid for data rule too.

Using Dynamic Throttling with default Throttle rate

The scenario is as under:

There are NO media / data rules configured
The default throttle rate is configured at 200 Kbps
The site target throughput rate is configured at 1 Gbps

In this case the default throttle rate acts as a minimum required. The availble bandwidth (1 Gbps) will now be distributed evenly among all active connections from a server perspective. For example, if there are 1000 concurrent connections, each will get 1 Mbps. This will go on till a maximum of 1 Gbps / 200 Kbps = 5000 concurrent connections.

Dynamic Throttling in advanced scenarios

In the advanced scenario you could have:

Two rules - Let us assume media rule for .wmv and data rule for .msi
Each rule could have a different throttle rate (e.g., .wmv - 100% (400 Kbps), .msi - 100 Kbps and so on)

In this case, the BRT will compute the throttle rate for each request by splitting the available bandwidth in the ratio of thier configured throttle rates. In the above case, for example the availble bandwidth will be split in the ratio of 4:1 for .wmv:.msi. So in case there are 500 .wmv connections and 500 .msi connections, the .wmv connections wil get 800 Mpbs (1.6 Mbps per connection) and .msi connections will get 200 Mbps (400 Kbps per connection). In this example we took only two possible rules but this logic would apply to any number of rules too.

Bit Rate Throttling is now released

vsood — Sat, 15 Mar 2008 00:27:00 GMT

Bit Rate Throttling is now out of Beta. We are really pleased to announced the release of IIS Media Pack Bit Rate Throttling

Download Links

The key features that constitute V 1.0 of Bit Rate Throttling are:

Automatically reads the encoded bit rate information from each defined media file type
Per-response bandwidth limiting on progressive downloads for every connection
Throttling rules are configurable at the server, site, virtual directory, and file levels
Fast Start experience for end users
Extensible to add support for other media and file formats
Fully integrated into the IIS7 administration and configuration models
Set default and maximum throttling rates, and concurrent connection limits
NEW - Dynamically adjust throttling to account for any available bandwidth as per a configured value (watch out for another post on this shortly)

For more information, see the Bit Rate Throttling walkthroughs:

Bit Rate Throttling Setup Walkthrough. Describes how to download and install the Bit Rate Throttling module.
Bit Rate Throttling Configuration Walkthrough. Describes how to configure the Bit Rate Throttling module at the server, site, virtual directory, and file levels, including new Site-level limits.
Bit Rate Throttling Extensibility Walkthrough. Describes how to use the extensibility interface provided by the Rate Throttling module to add support for additional media file types.

I cannot end this post without thanking the team for tremendous hard work. Thank you all!

Andrew, Sam, Jack and Brian for coding it
Jimin and Dave Cox for testing it
David Nelson for all the help content that ships with this release
And of course, I was the PM ;) (It's my post so I get to thank myself)
Chris (PM), for helping out with all earlier releases. We would not have got so far without that.
Mike, for envisioning this idea and doing early prototypes. We would not have this feature without him :)

Bit Rate Throttling is a great value add to the progressive download scenarios. Don't believe me, try it out to believe for yourself. We had fun making it hope you enjoy using the same.