Web playlists - A brief introduction

Today we released the first Customer Technology Preview of the web playlist module for IIS 7.0.  This addition to our media initiatives for IIS, along with the earlier released bit-rate throttling module, provide administrators with a powerful way of delivering rich media to the end users.  It also enables them to monetize the same (e.g., by  inserting ads that are guaranteed to be played ).

What is a Playlist?

A playlist is a sequence of media elements (audio/video/pictures), created either statically or dynamically.  Typically administrators like to to control the sequence of media viewed by users. Administrators might also want to enforce further restrictions on the individual entries in the playlist.  For example, administrators might want  an advertisement to be viewed completely without the user being able to seek or skip through it.  Playlists usually come in two flavors:

• Client side playlists.
• Server side playlists

Client side playlists

In the client side playlist scenario the server sends down the playlist to the client. This is typically a plain text or an XML file.  The client parses the file, reads the entries in the file and then requests the entries in the order they are present in the file.  A properly written client would respect the order of entries and any other restrictions placed in the playlist like, "no skip" , "no seek", and so on.  A rogue client, however, could just ignore such restrictions and give users full control. The server has least control on what the client does.  Client side playlists are simple to implement and administer, and can be very easily generated using dynamic web pages.  No special server support is required.  In addition, a wide range of clients and formats can be supported easily. Most commonly used client side playlist formats are the m3u for mp3 playlists, and the ASX format for the windows media.  Synchronized Multimedia Integration Language, SMIL, is the W3C recommended playlist format, but not all clients support it.  Another disadvantage of client side playlists is that they expose the entries completely to the end user. It also means that the individual entries in the playlist need to the accessible in your URL namespace.

Server side playlists

Server side playlists try to overcome the limitations of client side playlists by implementing the playlist functionality entirely on the server side.  The clients do not even know how many entries are present in the playlist and what they are. The server can strictly enforce any restrictions it wants on the entries.  However this needs a special understanding between the clients and the server (usually at the protocol level).  This usually means server side playlist implementations are restricted to specific client implementations and/or media formats.  For example the server side playlist implementation in the windows media services supports only Windows Media format and only supports Windows Media clients. With server side playlist the media location is hidden from the clients and there is no way clients could directly request the media to overcome the playlist restrictions.

Where does web playlist fit in?

Web playlist feature in the IIS tries to bring the best of both worlds together by using a hybrid approach.  It presents a client side playlist to the clients but the playlist is enforced and validated on the server side as well. Thus administrators are not limited to the kind of media formats or clients they can use to deploy in their applications and at the same time they can be sure that any restrictions they want to place in the playlist are enforced and is not at the mercy of the client implementation. At the same time web playlists make sure that the individual media entries are not exposed to the end users and they need not be accessible in the URL namespace. 

How does web playlist work?

So how does the web playlist feature in IIS work? The functionality is implemented via a special request handler in the IIS pipeline.  The administrators create playlists on the server side using IIS Admin interface.  The playlist request handler is registered to serve these special files.  On the first request the handler reads the server side playlist and creates an equivalent client side playlist and sends to the client.  However the created client side playlist does not expose the individual media elements in the playlist. The playlist consists of special encoded URLs that only the playlist handler can understand and serve.  Further the playlist handler maintains the restrictions placed on the entries in its session state and enforces them on the server side.  So a rogue client could send a seek request on an entry it is not supposed to seek, but the server will validate and fail such requests.

What is the extensibility story?

While this looks interesting having simple static playlists with fixed entries on the server is very restrictive and lot of maintenance overhead for the administrators.  The web playlist has a solution for this too. The playlist module has an extensible provider framework.  So you could write code (either native or managed) that could generate the playlists dynamically. In fact the playlist need not be a physical file on the disk but could be queried from an external source (like a database) if one wishes to.  In the next release we will be publishing the APIs on how customers could write their custom playlist providers that could serve a rich set of content in a wide variety of formats to a wide spectrum of clients.  So do keep looking for further updates on this module :-).

The playlist feature can be configured to use the ASP.NET session state management. This way the playlist state can be maintained and restored irrespective of server failures.  The playlist module works very well together with the already released bit-rate throttling module. Combined together they could turn your web server in to a powerful platform for delivering media content in a way that is powerful, scalable, extensible and yet very cost effective.