Using IIS Media Services Web Playlists with JW Player
Archived note. Originally published 3 August 2010 on iishacks.com. It describes IIS Media Services Web Playlists and a Silverlight-based player as they worked at that time and is preserved here as a record. Silverlight has been discontinued, and IIS Media Services is no longer how video is delivered from a Windows web server. Verify against current vendor documentation before applying any of it to a live system.
The recovered note
One reason to use Web Playlists is to hide the true path of a video. That makes it difficult for visitors to download a full copy of the file, which suited streaming of copyrighted or pay-per-view material. Screen-capture software could still record playback, but the process is more involved and correspondingly less likely.
The Flash build of JW Player, like most players of the period, required the media file — .mpeg, .mp4 and so on — to sit in a folder below the site root where a visitor could reach it. Web Playlists for IIS allowed videos to be added from any folder on the server and did not hand out the file directly when playback was requested; it used a one-time security token to obfuscate the path instead.
Step 1 — add a new playlist in IIS
Open IIS Manager, select the website and double-click Web Playlists. On the right-hand side, click Add Playlist. Naming the playlist generates a URL, and that URL is what the web-based player is pointed at.
Add the video itself under Media entries with Add. Three source types were available:
- A physical path, which made it possible to serve a file stored above the site root.
- A relative URI, for a file already in or below the root folder.
- A remote URL, for a file on another server or another domain.
The same dialog carried options to disable skip-back, skip-forward and seek. Where several videos were joined together, or advertisements were required before, between or after the content, those options were the reason to use a playlist at all.
Step 2 — point the player at the playlist
With the media entries added, the playlist is attached to a web-based player. At the time, the Silverlight build of JW Player was the only free player supporting the .isx playlist format without requiring ASP. IIS Web Playlists supported .asf, .avi, .flv, .m4v, .mov, .mp3, .mp4, .rm, .rmvb, .wma and .wmv.
The configuration is described here rather than reproduced, because the original embed carried a specific hostname of the period. The player is instantiated in JavaScript exactly as it would be for a single video, except that the file parameter is given the .isx playlist URL from Step 1 instead of the path to a media file. Sizing, controls and autostart are configured as normal.
Opening the .isx URL directly leads to a broken link or a text file rather than a video, and the playlist carries a tokenised session identifier appended to the URL. Following it by hand is a dead end.
What a server-side playlist bought you in 2010
The problem being solved is easy to forget now. In 2010 the normal way to publish video from IIS was to drop an .mp4 or .flv file into a folder under the site root and let the web server hand it out as a static file. That works, and it also means the file's URL is the file: anyone who could read the page source could paste the path into a browser and receive the complete video at full speed.
Two things changed with a server-side playlist. First, the media stopped needing to live in the published tree: a physical path let the file sit where the web server would never serve it directly, removing the risk of a stray directory listing or a misconfigured handler exposing it. Second, the address the browser used was no longer the address of the file — the player asked for a playlist, and the token it was issued was what the session played from.
A secondary benefit mattered commercially at the time: because playback was mediated, the playlist could stitch several assets together and enforce their order, which is how pre-roll and mid-roll advertising was inserted without touching the media files. Seek and skip were withheld for the same reason.
Obfuscation is not access control
This is the part to be clear about, and the original note was halfway to saying it when it observed that screen capture still worked.
Nothing in the arrangement authenticates anybody. It raises the effort required to obtain a copy — the path is not visible, the playlist URL is not the media, the token expires — and effort deters casual copying. It is not a barrier against anyone who wants the file. The bytes still have to reach the player to be played, so they can be captured in transit or at the point of decode, and a token issued to anyone who loads the page is available to anyone who loads the page.
The distinction matters because of what gets built on a misunderstanding of it. Where content genuinely must not reach unauthorised users, the control has to be an authorisation check tied to an identity and enforced on every request, not at the point a link is generated. Where the requirement is only to make casual downloading inconvenient, path obfuscation is a cheap and reasonable answer — and should be described as exactly that.
Reading it today
None of this is how the job is done now. Silverlight has been discontinued, Flash with it, and what replaced both is segmented adaptive streaming over ordinary HTTP, where the player fetches a manifest and then a series of short media segments. The path-hiding property survives there almost by accident — the manifest is not the media — while access control is answered separately by signed URLs, token-authenticated delivery or DRM, which is the honest place for it.
Current documentation for the web server is the IIS documentation home, and the Microsoft product lifecycle documentation covers the support status of the components named above.
Other notes on this server are filed under Internet Information Server. The note on installing PHP 5.3 FastCGI on Windows 2008 and IIS 7 covers another handler-level change to the same web server, high average disk queue length and finding the cause matters to anyone serving large media from spinning disks, and every recovered post is indexed at post archives.