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 d