This post is about end-to-end scenario for digital media experience using Silverlight (SL) as UX front-end, Expression (Blend and Encoder) as tools and Windows Media Services (WMS) as back-end streaming engine. WMS is a platform for streaming audio and video contents to clients over the Internet or an intranet. Clients of WMS may be a player, such as Windows Media Player, or they may be other servers running WMS for proxy, cache, or content redistribution. In our case clients are custom Silverlight applications. Contents that WMS streams to clients can be either a live stream or a prerecorded digital media file. Interesting to try the live streaming, but we need encoding software to do that, such as Windows Media Encoder. In this post, I will focus on prerecorded digital media files.
Basically we can deliver digital media files to clients over a network by using one of two methods: Web Server Downloading and Streaming Media. The first method usually uses a Web server to deliver the audio and video data to a media player. The second method uses a separate streaming media server (like WMS) specialized to the audio/video streaming task. Let see how they are different.
Web Server Download Model
Web server approach is actually close to download-and-play model. Uncompressed audio and video is first compressed into a single "media file" for delivery over a specific network bandwidth such as a 28.8 kilobits per second (Kbps) modem. This media file is then placed on a standard Web server. Next, a Web page containing the media file's URL is created and placed on the same Web server. This Web page, when activated, launches the client-side player and downloads the media file. Downloading requires that users copy entire files to their computers before they can play the content, which consumes both time and disk space. Downloading does not make efficient use of available bandwidth when we have many concurrent users because web server is designed to deliver content as fast as possible. When a client begins to download, all available network bandwidth is used to transfer the data quickly. As a result, other network functions may slow down or be disrupted. Why?
Because web server streaming uses the HTTP for communication between the server and the client. HTTP operates on top of the Transmission Control Protocol (TCP), which handles all the data transfers. Optimized for non-real-time applications such as file transfer and remote log-in, TCP's goal is to maximize the data transfer rate while ensuring overall stability and high throughput of the entire network. To achieve this, using an algorithm called slow start, TCP first sends data at a low data rate, and then gradually increases the rate until the destination reports packet loss. TCP then assumes it has hit the bandwidth limit or network congestion, and returns to sending data at a low data rate, then gradually increases, repeating the process. TCP achieves reliable data transfer by re-transmitting lost packets. However, it cannot ensure that all resent packets will arrive at the client in time to be played in the media stream.
In case you still want to use download method, IIS 7.0 Media Pack Bit Rate Throttling module provides helpful features to reduce bandwidth costs while increasing per-server capacity for concurrent download connections. For media files, Bit Rate Throttling implements a dynamic per-file throttling capability to provide intelligent progressive downloading. It automatically detects the encoded bit rate of each file, sending the first few seconds at the highest data rate possible, and then throttling the rest of the file download based on the encoded bit rate. This saves network bandwidth while preserving the fast start-up experience for the end user. In addition, the Bit Rate Throttling module provides control over download rates for any file type, not just media files. While eleven media formats are pre-defined in the module, the module is fully extensible. This allows a developer to add support for any media file type, and allows an administrator to easily add support for any data file type.
Streaming Model
In this approach, the initial steps are similar to the Web server approach, except that the compressed media file is produced and copied to a specialized streaming media server (WMS in this case). Then a Web page with a reference to the media file is placed on a Web server. In contrast to Web server downloading, the data is actively and intelligently sent to the client, meaning that it delivers the content at the exact data rate associated with the compressed audio and video streams. The server and the client stay in close touch during the delivery process, and the streaming media server can respond to any feedback from the client. While streaming media servers can use the HTTP/TCP protocols used by Web servers, they can also use specialized protocols such as the UDP to greatly improve the streaming experience. Unlike TCP, UDP is a fast, lightweight protocol without any re-transmission or data-rate management functionality. This makes UDP an ideal protocol for transmitting real-time audio and video data, which can tolerate some lost packets. As a bonus, because of the back-off policies implicit in the TCP protocol, UDP traffic gets higher priority than the TCP traffic on the Internet. And instead of the blind retransmission scheme employed by TCP, streaming media servers such as WMS use an intelligent retransmission scheme on top of UDP. Windows Media Services' UDP Resend feature ensures that the server only retransmits lost packets that can be sent to the client in time to get played.
Streaming method saves the content to a Windows Media server, and then assign the content to a publishing point. We can then provide users with access to the content by either creating an announcement file or by supplying users with the URL of the publishing point. To stream content smoothly, the bit rate of the content must be lower than the bandwidth of the network. If the bit rate is higher than the available bandwidth, the player will attempt to thin the stream so it can render the stream properly by using a process called stream thinning. Because of this, the player may render only key frames of the video stream with audio so that the video is not in motion, just like a slide show. If the bit rate requirements greatly exceed the available bandwidth, video playback may stop altogether and only the audio portion will be played. We can minimize impact of inadequate available client bandwidth using multiple-bit-rate (MBR) content. MBR content enables the player to request a lower bit rate stream from the server.
Fast Streaming provides several features that combine the advantages of streaming and downloading. The server can use the Fast Start and Advanced Fast Start features to ensure that the client can begin playing the content as quickly as possible after the stream begins. The Fast Start feature enables the player to download and buffer a small portion of the content from the server as fast as the network will permit before the content begins to play. After the buffer has been filled on the player, the server slows down the stream until it matches the rendering speed of the player.
For more information about Windows Media Streaming, I would like to recommend you this article, Getting Started with Windows Media Services 9 Series.
More on Windows Media Services
With a WMS, the media may be streamed with the optimal UDP protocol when possible, and streamed with the TCP protocol when necessary. WMS also supports Multicast which allows a single media stream to be played simultaneously by multiple clients, drastically reducing bandwidth use (need Multicast-enabled routers). For corporate clients, WMS can deal with firewall security and ensures that all users on all networks can access all streaming media content. WMS implements its own version of the HTTP protocol to enable streaming through a firewall or proxy server while still retaining most of the advantages a WMS.
So before we go to the "how to" topics, I would like to summarize that WMS supports four different protocol configurations, each offering specific benefits, UDP, TCP, HTTP+TCP and Multicast. The WMS will automatically switch to the appropriate protocol so no client-side configuration is necessary. The server will initially attempt to transmit files using the optimal UDP or Multicast protocols. If unable, the server will then attempt to send first via the raw TCP protocol, then via TCP with HTTP-based control.
Installing WMS on Windows Server 2008
I am using Windows Server 2008 and followed this guideline. Everything went well. To obtain the new features that are available in WMS for Windows Server 2008, first, we must get and then run the Microsoft Update Standalone Package (MSU) file for the appropriate Streaming Media Services role. These new features include the built-in Cache/Proxy plug-in. WMS can be installed in Full and Server Core version of Windows 2008. After installed the MSU, just add Streaming Media Services role in your Server.
I have installed WMS in my new 64bit laptop (4GB RAM, Dual Core) and it runs well so far. A WMS Server instance has many properties that can be configured easily using the a very intuitive MMC, such as Authorization, Logging, Event Notification, Authentication, Cache/Proxy, Protocols and Limits.
Once you got familiar with the WMS MMC (dont forget to read WMS help file), you can start to create publishing point. WMS uses publishing point to translate client requests for content into physical path on the server hosting the content. After a client successfully connects to a publishing point, WMS manages the connection and stream the content. WMS includes two types of publishing points : On-Demand and Broadcast. Both types can be configured to deliver a stream from one of several types of sources, such as a file, a playlist, or a live stream from an encoder. One WMS instance can be configured to run multiple publishing points, hosting a combination of on-demand and broadcast contents.
On-Demand publishing point is best suited for scenarios in which you want users to be able to control playback of the content that is being streamed. This type of publishing point is most often used to host content sourced from files, playlists, or directories. When a client connects to the publishing point, the content starts at the beginning and the end-user can use the playback controls on a player to pause, fast-forward, rewind, skip between items in a playlist, or stop. An on-demand publishing point streams content only when a client is connected to receive the stream. Content streamed from an on-demand publishing point is always delivered as a unicast stream, which means that the server maintains a separate connection with each client.
Broadcast publishing point is best suited for scenarios in which you want to create an experience similar to viewing a television program—the content is controlled and streamed at the point of origin or the server. This type of publishing point is most often used to deliver live streams from encoders, remote servers, or other broadcast publishing points. When a client connects to a broadcast publishing point, the client is joining a broadcast that is already underway. For example, if a company-wide meeting is broadcast at 10:00 A.M., clients connecting at 10:18 A.M. have missed the first 18 minutes of the meeting. A client can start and stop the stream, but cannot pause, fast-forward, rewind, or skip.
Typically, a broadcast publishing point begins streaming when it is started and then continues until it is stopped or the content finishes. However, you can configure a broadcast publishing point to start and run automatically only if one or more clients are connected. By doing so, network and server resources are saved when no clients are connected. You can also configure a broadcast publishing point to start automatically when a WMS is started. You can deliver content from a broadcast publishing point as either a unicast or multicast stream.
To create a publishing point, just follow the wizard provided by WMS MMC. It is very easy to do and WMS also provides web based management for publishing point provisioning.
New Business - Hosting WMS
I hope if some folks from web hosters can read this post and think about new business for streaming media hosting using Microsoft SPLA (Service Provider License Agreement). In typical scenario, WMS can be separated from Web Servers and the web hoster can offer to customers streaming facilities of uploaded contents. Or in other scenario, web hosters can also provide File Server and live Encoder for live streaming or broadcasting like the last Olympic.
I will ask my partner-in-crime Mr. Kunto Baiquni to test it in hosting environment. In part 2 of this post, I will explain how you can manipulate media files using Expression Encoder and consume the WMS published content from Silverlight application. Just stay tuned!.
Hope this helps.
Ciao - RAM