[UPDATE: This functionality has been removed, and this information is now out of date.]

Smooth Streaming is changing fast. The team at Microsoft has and continues to make improvements in Smooth Streaming technologies, one of which recently has been Live Smooth Streaming with Expression Encoder.

I’m happy to report that NimbusHD now supports Push Live Smooth Streaming, which has been the #1 request from most of our clients for some time now. This supports hardware encoders, however, I’m going to focus on how this is now possible with Expression Encoder 4 Pro. In this exercise, we’re going to accomplish the following workflow:

  1. Set up a Live Publishing Point for my event through the NimbusHD Admin Center.
  2. Stream the event from Expression Encoder 4 Pro, with client DVR support.
  3. Adjust our Content Distribution Networks on the fly.
  4. End the live stream, leave DVR active.
  5. Shut down the Publishing Point, and transfer our Live Event content to On-Demand Content.

If you don’t already have an account, go get a trial at www.nimbushd.com (free for 14 days).

Set Up The Publishing Point

For the first step, go to the Live tab of NimbusHD Admin, and click Create Publishing Point…


Title it, and set the Estimated Length (this isn’t something to stress over, it just helps set the correct DVR timeline).

Hit OK, and Nimbus will create and configure a Live Smooth Streaming publishing point for you, generate your push server address, and configure a set of client player parameters.


You’ll notice that the Status is Idle, Ready to Start and the default CDN is Akamai. Now, let’s start broadcasting something…

Stream The Event

Fire up Expression Encoder 4 Pro. (This is important – without the Pro version, Live IIS Smooth Streaming is limited.)

If you see the initial “Load a new project” wizard screen, click “Live Broadcasting Project”.


Set up your sources (outside the scope of this post), and we’ll tweak the settings for our live stream. To start, I’ll just select a preset of IIS Smooth Streaming, VC-1 codec @ 480p. There is no restriction on what bitrates, or how many bitrates you can push to Nimbus at any one time. However, pushing more than a couple bitrates (especially high-resolution ones) takes a pretty decent machine.


If you wish to adjust which bitrates you are encoding, you can do so under the Video section of the Encode tab.


Now, under the Output tab, check the Streaming box, and copy and paste the Encoder Stream URL provided by Nimbus.


Before Expression Encoder can connect to the Publishing Point, it must be started. Click Start Live Streaming in the NimbusHD Admin panel.


You’ll now notice that the status changes to Ready, waiting for encoder to connect…


So let’s connect – press Connect in Expression Encoder.


You’re now ready to roll… hit Start to begin streaming!


It’s worth noting a couple of things here that are happening in the background. NimbusHD is maintaining DVR support for your event, so your viewers can skip backward and surf through the previous event content (just like your cable/satellite DVR at home). Your event is also being recorded – we’ll get to this later.

Generate a player for Viewers

Your clients will need to be able to see this, so they’ll either need a link, or you can embed a player on your own site.


You can use the Player Quick URL if you want to use a simple NimbusHD player embedded on a blank page, or hit Generate Player / Embed HTML if you want to generate a player for your own site.


Adjust Content Distribution Networks on the fly

One of the major cool points of NimbusHD is the Content Delivery Network support, for scalability and optimal bandwidth/quality for your viewers. We support 3 out of the box (Akamai is the default) and your CDN of choice can be changed per-publishing point, and in real time for new viewers.

If you want to change from, say, Akamai to EdgeCast, hit the Change CDN… button.


… select your new CDN, and press OK…


That’s it… we’re done.

End Live Stream

You’ll notice that when you disconnect Expression Encoder, the Publishing Point changes status to Live Streaming Stopped, DVR Active.


DVR Active means that your viewers can still surf through the event in DVR mode, even though there is no new live content being delivered.

(One important note: If you experience a network interruption, you will need to shutdown and restart the Publishing Point. This is due in part to DVR functionality, as well as limitations of Encoder’s timecoding and IIS Smooth Streaming’s design. We’re working on making this better, but for the time being, it’s important to have a solid network connection.)

Transfer Live Event to On-Demand Content

The first thing that you’ll probably want to do after broadcasting your live event is to make it available to those who missed it. When your event is done, press Shutdown / End Event.

Your live event will automatically be transferred into a “Live Stream Archive” media bin. It’s instantly available for on-demand viewing!



At this point, it’s just like other on-demand media assets. You’ll probably want to trim it via the clip editor, and then make it available on your web site, or send a link out to those who missed the event.


The Live Smooth Streaming capabilities of NimbusHD are very powerful, even at this stage. There are a lot more exciting things to come (live viewer geolocation mapping has been suggested already), so stay tuned.


I received an interesting question from someone setting up their own Smooth Streaming infrastructure recently, and I couldn’t help but blog it.

When setting up an on-demand Smooth Streaming infrastructure for a corporate environment, is it better to invest in WAN optimization, or Content Distribution?

It’s a great question, but let’s take a quick time out to make sure we’re on the same page with these terms.

WAN Optimization, in this case, is a device that functions as a web proxy at the front end of a network. It downloads data and caches it for the next person to conserve internet bandwidth. Simply put, if Bob and John are on a network using WAN Optimization, and Bob visited Google.com, the WAN optimizer would cache the Google logo image. When John visits Google.com a few minutes later, the WAN optimizer serves up the Google logo image from its cache, instead of requesting it again from Google’s servers. There are a few products that do this from a variety of manufacturers (for example, ISA Server from Microsoft).

On the other hand, a Content Distribution Network is a network of servers throughout the world on a really fast backbone with synchronized caching. End-users are routed to the closest/fastest content distribution server near them, and content is delivered at really zippy speeds.

So now that we have that down, the question becomes: Is speed (CDN) or caching (WAN Optimization) the better strategy for On-Demand Smooth Streaming?

The answer, of course, is: It depends.

Exploring Caching (WAN Optimization)

The reason Smooth Streaming works so well is illustrated in this graphic:

Traditional Streaming Quality Compromise

While traditional streaming is easy to work with (and easy to cache), there’s a quality tradeoff. Smooth Streaming works differently, in that the client player can dynamically adjust to network conditions, and constantly switch up the bitrate all willy-nilly. Typically, Smooth Streaming “chunks” are requested in 2 second intervals. This generates 8 possible URLs for every 2 seconds of video, plus another 1 URL for every 2 seconds of audio. Compared to a traditional progressive-download stream of a single-bitrate file, this can get interesting quickly:

Number of URLs possibly used to play a video

Video Length Traditional 1-bitrate Streaming URL Count 8-bitrate Smooth Streaming URL Count
2 seconds 1 9
60 seconds 1 270
120 seconds 1 540
300 seconds (5 min) 1 1,350

If this doesn’t make sense, take a moment to read Demystifying IIS Smooth Streaming / Live Smooth Streaming.

You might be thinking this is game over for WAN Optimization already, because there’s no way that caching could be effective when a client will only use 11% of the possible URLs available. That’s true, but it doesn’t take into account what actually, or I should say typically, happens.


This is a curve of typical usage we see. Silverlight clients for users on decent home or corporate connections will usually hit their stable bandwidth within 10 seconds, and won’t deviate a whole lot. This brings a lot more predictability into Smooth Streaming – the “in between” bitrates aren’t used much, and the more stable your network, the less jumping around you’ll see. In other words, WAN Optimizer is back in the game. In fact, we tested a small number of videos with just a few users watching over a couple days (using the IIS7 Application Request Routing module with caching), and achieved an over 70% cache rate.

Exploring Content Distribution Networks

The most well-known CDN in the world is currently Akamai. They operate a CDN made up of over 61,000 servers. There are also other popular ones (for example, we use both Akamai and EdgeCast for my company’s Smooth Streaming platform). They are typically deployed in one of two ways; either you provide the origin (content servers) and the CDN retrieves content from you dynamically as users request it, or you place the content directly on the CDN network.

The idea is that you can deliver high-speed content anywhere in the world over a CDN, by basically placing your content geographically “next door” to your viewers. A CDN could very well mitigate the need for WAN optimization, especially if your viewers are scattered in multiple locations.

Make a Decision Already

So, what’s most effective? It depends on the number of videos vs. the number of users on the same network. I summarize my cumulative experience and testing in the following decision grid:


If you have a low number of videos and a high number of users, WAN Optimization will provide Smooth Streaming infrastructure savings.

On the other hand, if you have a high number of videos and a lower number of users, your WAN caching device is a waste of money, and you may as well go with a CDN.

If you have lots of videos and lots of users, then a hybrid strategy is most likely to be effective.

Shameless Plug

This is one of the many problems I’ve had to address with Smooth Streaming technology. Like most technologies, it has an occasional tradeoff in exchange for some great benefits, and this is one of them.

One of my primary efforts over the last few months has been heavy design and development on a cloud-based Smooth Streaming platform that solves problems like this one. You may notice that some of the graphics in this post came from Nimbus (www.nimbushd.com). I figure it may be helpful to shed some light on how the design for Nimbus solves this issue, even if it’s considered a shameless plug. 😉

Nimbus is designed to fit in to all 4 spots on the decision grid above, with multiple CDN provider integration. Media assets in Nimbus are divided up into groups (called Media Bins), and by default, the bins are configured for distribution through Akamai. The idea is to provide the highest quality distribution to a virtually unlimited number of users. However, CDN distribution costs money, and for larger corporations, costs add up. For a corporation providing training or news videos to a large number of internal users, it doesn’t make sense to use a CDN to stream the same content over and over again to the same corporate network, so Nimbus supports the hybrid CDN+WAN model, allowing Media Bins to be changed on the fly between CDNs and on-site WAN caching configurations for the best possible cost savings and caching efficiency.

Hopefully between the theoretical discussion points and the actual Nimbus design, this sheds some light on how to make the WAN Optimization vs. CDN decision. Happy Streaming!


Lately I’ve been trying to solve a few specific problems with Smooth Streaming, and I noticed as I go through forums, blogs, and Microsoft web sites, the only thing clear is that this topic is vague, and there are lots of unanswered questions out there. In addition, the way Microsoft uses the term “Live Smooth Streaming”, it almost seems intentionally misleading. So, with that in mind, I’d like to clear up a few things.

How does Smooth Streaming work? (the quick and straightforward version)
Smooth Streaming (or, as I will call it, On-Demand Smooth Streaming) relies on having the same stream encoded at varying bitrates, with one complete streaming file per bitrate. So you will typically have individual files that look like this in a web server directory:

  • MyStream_230.ismv
  • MyStream_305.ismv
  • MyStream_403.ismv
  • MyStream_534.ismv
  • MyStream_708.ismv
  • MyStream_937.ismv
  • MyStream_1241.ismv
  • MyStream_1644.ismv

These files all contain special timecode marks in them, and are all tied together by two “manifest” files, for example:

  • MyStream.ism
  • MyStream.ismc

These files simply contain a mapping of which bitrates correspond with each stream (for example, the 230k stream = MyStream_230.ismv, 708k stream = MyStream_708.ismv).

The Smooth Streaming player makes tiny HTTP requests requesting a second or two of video at a certain bitrate. For example, “give me 230k @ 00:01:06, give me 708k @ 00:01:08”, etc. These requests are no different than how your browser downloads images on a web page. The “smooth” part comes in because with this architecture, it’s extremely easy for your computer to switch bitrates and adjust to your network connection.

IIS Media Services
An IIS7 feature called IIS Media Services is what makes it possible for the server to understand these player requests, timecode, and a few special URL constructs.

An example of this is the Manifest request; if you had a smooth stream (with MyStream.ism) in the root folder of your IIS web server, you can open up your browser and go to:


IIS Media Services will generate the XML manifest file that the player would consume, and you can view it in your browser.

What is “Live Smooth Streaming”?
Live Smooth Streaming uses the same technique of on-demand Smooth Streaming, except encoded in real-time for live events by hardware encoders. Although it is similar in player concept, it is quite different in implementation.

IIS Features: Smooth Streaming Presentations vs. Live Smooth Streaming Publishing Points
Once you install IIS Media Services, and navigate to a folder under an IIS web site, you will see these options:


  • Live Smooth Streaming Publishing Points – Similar to Windows Media Services, you can create publishing points that live hardware encoders can use.
  • Smooth Streaming Presentations – This is the feature that detects ISM and ISMC files (smooth streaming manifests) within a web site directory and interprets them as Smooth Streams.

How can you encode content for On-Demand Smooth Streaming?
Expression Encoder, with the IIS Live Smooth Streaming option.

Clarification Point: Expression Encoder is offered in 2 versions, a free version without the ability to do this, and a paid version with IIS Smooth Streaming encoding capabilities.

The IIS Smooth Streaming version will:

  • Encode your content into separate bitrate files, and….
  • Create the manifest files (.ISM, .ISMC) automatically

How can you encode content for Live Smooth Streaming?
Let me be clear, since this is the most confusing and vague part of Smooth Streaming to date: As of this writing, there is no software encoder that can do Live Smooth Streaming. You will have to be prepared to drop anywhere between $5,000 to $20,000 on a hardware IP video encoder (or a series of hardware encoders). For example, the Inlet Spinnaker Encoder.

The reason for this is the amount of sheer processing power that it requires to encode a smooth stream – it’s fairly intensive for a regular computer to encode one stream in realtime of acceptable quality; for a normal smooth streaming event, it’s eight realtime streams, ranging from low-quality to extremely high quality.

Again, Expression Encoder does NOT do Live Smooth Streaming. Expression Encoder only prepares content for On-Demand Smooth Streaming.

How do you play a Smooth Stream with Silverlight?
Just as you would play another media file in a Silverlight media player, but with a twist or two.

  • Set the MediaSource property of your playlist item to the HTTP path of your .ISM file, appended with /Manifest - for example:


  • Make sure to also set the playlist item property IsAdaptiveStreaming to true. Without this, Silverlight won’t understand that it’s a smooth streaming source, and will be confused.
  • If your Silverlight player is not located on the same host / relative path of your Smooth Stream, make sure that the root directory of your IIS site has a CrossDomain.xml file present, with contents that look like this:

    <?xml version="1.0"?>
    <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
      <allow-http-request-headers-from domain="*" headers="*"/>

    This simply tells Silverlight that it’s okay to contact this domain for content.

  • If you’re making your own Silverlight application with a player, Silverlight somehow needs to reference the AdaptiveStreaming.dll assembly. The easiest way to do this is to take the stock boilerplate player that Expression Encoder creates for you, and look for the SmoothStreaming.xap file in your output directory. Rename it to SmoothStreaming.zip (XAP files are really Zip files), and extract it. Inside are the assemblies you need to reference in your custom player (including AdaptiveStreaming.dll).


Hopefully this will clear up some understanding when working with Smooth Streaming, or at least making the total picture a little easier. Good luck!

Oh, and by the way – if you don’t want to deal with any of this junk, try NimbusHD – it’s Smooth Streaming as an affordable cloud service with a lot more features.