Sam Zhang's Blog

If you have read my previous blog here, you probably already know that in IIS Media Services 4.0 we’re exposing more detailed runtime status information about the live smooth streaming publishing points through RSCA APIs. The “Details” page of the publishing point UI retrieves information through the same APIs. As promised, here I’m publishing a sample Java script that we use internally to test those RSCA APIs. RSCA APIs were already used in IIS Media Services 3.0 to control the publishing point states (start/stop/shutdown). Ezequiel Jadib wrote a nice blog here showing how to use managed code to call RSCA APIs which you can reference if you want to port the sample script to managed code.

One frequently asked question especially from new users of IIS Live Smooth Streaming is that “why does the publishing point have to get stuck at “Stopped” state before it can be shut down?”. This can  be especially annoying if you want to control your publishing point from the encoder side: After you stopped the encoder, the publishing point goes to “Stopped” state. But if you try to restart the encoder right away, it will fail to connect until you shut down the publishing point.

In the new IIS Media Services 4.0 release, the most obvious change for Live Smooth Streaming is probably the new UI pages that show a lot more detailed information about the publishing points. Here let me walk through some interesting pieces of the new UI and show you some examples about how it could help you with server monitoring and troubleshooting.

This is probably a post that’s long due. IIS Media Services allows you to create and configure live publishing points from the UI but that’s not all that you can do with those publishing points. There are some “hidden” and “advanced” properties that you can set on the publishing point to achieve some interesting new behavior. A few new advanced properties were also added in the IIS Media Services 4.0 that was just released. Below is a table listing all the supported publishing point attributes in IIS Media Services 3.0 and 4.0:

It’s been a long time since I wrote my last blog. Now with the IIS Media Services 4.0 just released, I will finally have some time to write some blogs and talk about some interesting things in IIS smooth streaming and IIS Media Services. Hopefully you will find them useful. More coming up……

As you may know, IIS Media Services 3.0 includes the latest smooth streaming technology offering – Live Smooth Streaming with which you can do HD quality live streaming with smooth playback experience. Together with Smooth Streaming enabled Silverlight client (link), you also get advanced features like full live DVR, FF/RW, Slow Motion, live Ads insertion, etc. Live Smooth Streaming has been successfully deployed in many high profile online events including the most recent NBC Sunday Night Football. To enable Live Smooth Streaming for such big-scale online events, we not only need to build great streaming and playback features but also need to make sure scalable and robust server solutions can be built to handle the massive streaming load as well as any unexpected failures in the network. So in this blog, I will go through the related server features and discuss how such server solutions can be built by using those features.

Last week we released the first Beta of IIS Live Smooth Streaming. If you had a chance to watch Scott Guthrie’s demo in the MIX keynote, or our program manager John Bocharov’s MIX session, you have probably seen the slick player UI and gotten a feel for how the technology works in general. I hope you like the experience and the new functionalities. Today I’d like to dig a little bit deeper and talk about some interesting design thoughts we put in when developing this product.

So in part one, I talked about technically how streaming and content protection works and why they're independent and not tied to each other. Today, I'd like to share with you how I view the claims behind this notion and what they're really about. The claims I'm going to quote here are from a technical paper that was published by a company that advocates this concept. If you're familiar with media streaming, you should know which company I'm talking about. :) For the purpose of this blog, let me call it "the company". (Disclaimer: this is not the same "the company" that chases Michael Scofield and his brother in "Prison Break" :-) ).