Bit Rate Throttling and Smooth Streaming - Part 2

This is Part 2 of a post on IIS Bit Rate Throttling and IIS Smooth Streaming.  In Part 1, I provided a high-level overview of why Bit Rate Throttling and Smooth Streaming would never normally be applied to the same content, and then elaborated more on Bit Rate Throttling.  In this part, I'll focus more on Smooth Streaming, including the way it self-meters the amount of data delivered to clients.

As noted in Part 1, Bit Rate Throttling takes any existing file, whether video or otherwise, and automatically meters the delivery at the server.  On the other hand, Smooth Streaming defines a file format, encoding parameters, server functionality, delivery protocol, and client functionality and heuristics. 

Here's a typical basic workflow for on-demand Smooth Streaming:

1. Content is encoded in multiple GOP-aligned quality levels (bit rates, e.g., 300 kbps, 500 kbps, 750 kbps, 1.1Mbps, 1.5 Mbps, etc.) using either the VC-1/WMA or H.264/AAC codecs, either in multiple files (typically one bit rate per file) or a single file containing all quality levels.
2. Files are published to a Windows Server running as an IIS Web server, where the free IIS Media Services extensions have been installed and IIS Smooth Streaming has been enabled.
3. A Smooth Streaming client (perhaps created automatically during the encoding process on Expression Encoder, or using a downloaded template from the free Microsoft Media Platform Player Framework) is published to the IIS server.
4. An end user clicks on a URL to watch a video, which loads the Smooth-Streaming-capable player.
5. The player requests a manifest from the server that describes the content and quality levels available.
6. The server delivers the manifest.
7. The client requests requests the lowest-quality two-second fragment.
8. The server finds the requested bit rate video file and matching audio file, pulls out the appropriate two-second GOP from the file(s), wraps it up as a cacheable HTTP file, and sends it to the client.
9. The client measures the time it takes to download the two-second fragment and ensures that the content plays back without stuttering, determines whether it can download a higher quality level video fragment for the next two seconds, and then requests the next two-second fragment while the current video fragment is still playing.
10. Repeat steps 8 and 9 until the end of the video is reached.

For those of you who prefer visual learning, the simplified image below for earlier versions of our components (which are all now on version 4) might be useful.

Thus, the key to bandwidth metering in Smooth Streaming is that the client typically requests only one or two fragments (2-4 seconds) ahead of the currently playing video. In essence, it is "just-in-time" video delivery. Like Bit Rate Throttling, should an end user click the Stop button on their player, only a few seconds of video goes unwatched, unlike what happens with traditional fire-and-forget web server downloads.