“…an IIS 7.0 extension that meters the download speeds of media file types and data between a server and a client computer. The encoded bit rates of media file types such as Windows Media Video (WMV), MPEG-4 (MP4), and Adobe Flash Video, are automatically detected, and the rate at which those files are delivered to the client over HTTP are controlled according to the Bit Rate Throttling configuration.”

It basically saves you bandwidth by only transferring what you’ve watched plus a small, configurable buffer. Think about each user that starts watching a ten minute video but only watches one minute. In that time, they may have downloaded five minutes of content – quadrupling the bandwidth consumption unnecessarily. Bit Rate Throttling shares some user experience characteristics with Streaming Media, but it works on a normal web server over HTTP. It’s really quite a simple tool and I won’t devote space here to explaining it when the IIS.NET site already has some great content, including a brief introductory video. Definitely check it out.

So why am I writing about it?

• It’s cool! We wanted to turn it on to better manage bandwidth while delivering video with SharePoint 2010′s Silverlight Media Web Part.
• Unfortunately it didn’t work when we turned it on. In fact, it crashed our w3wp.exe for the web application where it was enabled.

At the time, I reported the issue on the SharePoint 2010 TechNet forums and IIS.NET, but didn’t get very far. We eventually decided to live with it, leaving BLOB Caching on, even if the bandwidth was left unoptimised.  To summarise the fault, when Bit Rate Throttling was enabled, my web application would load a page or two, then that application’s w3wp.exe would (apparently) leak memory until it crashed. Repeat. The issue and my troubleshooting is explained in more detail on those two threads. These are the key error messages:

Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bd0eb
Faulting module name: bitratemodule.dll, version: 7.1.625.10, time stamp: 0x4aca8535
Exception code: 0xc0000005
Fault offset: 0×0000000000007669
Faulting process id: 0×2140
Faulting application start time: 0x01cb2cd16410dafa
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Program Files\IIS\Media\bitratemodule.dll
Report Id: e3004397-98c4-11df-91ae-00155d06ab22

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: w3wp.exe
P2: 7.5.7600.16385
P3: 4a5bd0eb
P4: bitratemodule.dll
P5: 7.1.625.10
P6: 4aca8535
P7: c0000005
P8: 0000000000007669
P9:
P10:

Attached files:

These files may be available here:

Analysis symbol:
Rechecking for solution: 0
Report Id: e3004397-98c4-11df-91ae-00155d06ab22
Report Status: 0

Luckily, I noticed that Jack over at IIS.NET recently posted:

I believe we have identified the problem and have a fix for the issue.  The fix will be available as part of IIS Media Services 4.0 which will be released in the very near future.

Good news! I see that a release is now available for IIS Media Services 4.0 Beta (second down in the right-hand column on the Bit Rate Throttling site). Unfortunately I haven’t had a chance to test this yet and I’m not sure when I’ll get the time. For now, I’m posting this incomplete, as it would be great if many people tested this and the IIS team got as much feedback on this technology as possible while it’s in a Beta release. Obviously, I’d caution against installing either version in production for now. 3.0 doesn’t work and 4.0 is very new.

A few related notes:

• BLOB Caching is not a requirement for Bit Rate Throttling in general, but it is a requirement for Bit Rate Throttling SharePoint 2010 web applications. The Plan for caching and performance document notes, “Bit rate throttling will not work correctly if you do not first enable the BLOB cache and configure it to cache the files types that you want to throttle.”
• We didn’t look at Smooth Streaming for very long, because the Silverlight Media Web Part hasn’t been built to adapt content in that manner.

Last week we built a Windows Server 2008 R2 Hyper-V host that we used for our SharePoint 2010 launch event at Microsoft London. We were practicing the demonstration from connected Windows 7 laptops but we also wanted to understand the limitations of presenting from the host itself, should something go wrong with the networking. For the most part this worked fine, but we ran in to problems when we tried to run the media web part. The dialogue box would pop up as normal, but there was no option to Play. If I clicked View I would be prompted to download the .WMV file. At this point I realised that this hardened server did not have the Desktop Experience enabled, so it didn’t have a default media player.

After installing the Desktop Experience and rebooting (note: this does a few reboots), the pop-up looked the same; the Play button was still missing. Now if I clicked View it would launch in Windows Media Player.

Eventually it occurred to me that the server might be missing Silverlight. We install it by default, so it took some time for me to catch on. I checked the installed updates and sure enough, it was missing. When I tried to run Windows Update it revealed that Silverlight was the only availably update. I tried to install it and I quickly got error 80244019. Searching for a solution suggested a few possible answers – mostly network/DNS-related. To expedite things I visited the Silverlight site and installed it manually. I believe the problem may have been DNS or proxy-related but since all other Windows updates installed fine it’s a bit of a mystery.

Installing Silverlight manually did the trick. The Play option returned in the pop-up and video played normally. Out of curiosity I removed the Desktop Experience and tested again. Everything continued to work normally. All of this is totally clear in retrospect, but with the new technology cocktail that is SharePoint 2010, Silverlight 3, IE8 and Windows Server 2008 R2, it’s easy enough to loose sight of the obvious.