Web Playlist and Bit-rate Throttling - Working together

Hello, my name is Sam Zhang (or 章葛强 if you can read Chinese) and I'm a lead developer on IIS Media Pack team. I've always wanted to start my own blog to talk about IIS and media but couldn't do it until now. J IIS Media Pack team is a relatively new team with a vision to enable advanced media scenarios on IIS platform. This team has a group of bright and smart people who are really passionate about web media technologies. I hope you will find useful information in my blogs and at the same time provide us your valuable feedbacks.    

I think you've probably known or used the two Media Pack modules we've released so far: Bit-rate throttling 1.0 and Web Playlist CTP2. There have already been some great posts about the features and functionalities in these two products. So I won't go into those details again. Today I'd like to talk about how these two modules fit into IIS pipeline and how they work with each other.

First, let's talk about Web Playlist. If you have used Web Playlist, you probably know that Web Playlist by default handles requests with ".isx" extension. In Web Playlist, ".isx" is defined for "default playlist provider" and you can add your own playlist extension by adding a playlist provider. In IIS7 pipeline, the component that handles requests and produces responses for a particular extension is called "request handler". For example, ASP.net registers a request handler with ".aspx" extension. In IIS7, request handler only gets invoked if the request comes with the extension that it registered with. In our case, default web playlist handler is only called if the request has ".isx" extension.

For Bit-rate Throttling (BRT), the design approach is different. It's less about "what to return" but more about "how to return". In another word, BRT's job is to control how fast we can send the response rather than figuring out what response needs to be sent to the client. So with that, it was naturally implemented as an IIS7 module instead of a handler. In IIS7, a module listens to one or multiple event notifications which are fired for all the requests. BRT mainly listens to RQ_SEND_RESPONSE event which is fired right before the response is going to be sent. All the magic of doing bit-rate control happens at that point.

So, if you have both Web Playlist and BRT installed and enabled, they both exist in the request processing pipeline but get invoked at different stages. At the same time, they're totally independent with each other as well. For example, it's perfectly fine to just run Web Playlist without BRT if bandwidth consumption is not a concern. Because BRT is implemented as a module in IIS7 pipeline, it can handle all type of responses, static file or dynamic responses, as long as you have the right throttling rules defined.

So how exactly is BRT working with Web Playlist? If you have used Web Playlist, you probably know that the entry URLs embedded in the ASX response are obfuscated. There's no way to tell which content is going to be returned just by looking at the URL. Web Playlist keeps track of the user session state and communicate with playlist provider to find out the exact content at runtime. Can it still be properly throttled? The answer is yes, and you get the same behavior as if the client is requesting a static media file. BRT does not rely on the request URL to determine where to look at. Instead, it directly intercepts the response entity and find out what is actually being returned. If the response contains a file handle, it knows how to trace back to the original location of the file, get the file extension and apply the corresponding throttling rules. If it's a media file, it will follow the same logic of parsing the encoded bit-rate from that file and use the proper media throttling rules (e.g. 20s/100%). So all you need to do is to set the right throttling rules for the file type you want to return with Web Playlist, and everything else will happen automatically. It works not only with entries entered with relative URIs in playlist but also with entries located by physical path which does not need to be in the public URL namespace. One thing to note here is that BRT won't work with remote URLs you set in your playlist because the actual downloading is going to happen on the remote server (well, you could still install BRT on your remote server J).

As you can see, BRT can easily work with static files as well as dynamic responses. Web Playlist is just a good example here. You can write your own request handler to dynamically return media files or any type of responses and BRT will just work.

Want to give it a try? J