Netflix: we’re very happy with Silverlight

One year ago, Netflix began looking at Silverlight primarily as a way to get media streamed to Macintosh computers. When we dug in further, we also wanted to broaden support for Firefox. Then we discovered we could produce a better solution for all platforms by eradicating platform-specific code, enabling us as a business to concentrate on producing the best possible experience for all of our customers.

Installers are evil! roughly 20% of our customers who had the appropriate system requirements wouldn’t make it through the process. A lot of the complexity came from the content protection issues. Now Netflix is out of the installer business – there’s just a one-time install that is supported by Microsoft that includes content protection and all the other media elements we need, allowing us to focus on our core business of helping our customers find and watch great movies.

Why is Silverlight uniquely suited for delivering these kinds of experiences? We’ve found that Silverlight is a great platform for developing video players. We want our customers to be able to start watching the video fast and then step up to a higher bit rate as soon as possible, all using a generic HTTP-serving infrastructure. But if we step up the bit rate too quickly, we get stuck in a rebuffering experience.

We’re learning by doing and enhancing our player on a regular basis. We’re using Silverlight to deliver better players transparently to our customers every two weeks without having to take them through a new install. Since we launched our player last November, we’ve halved the rebuffer rate. With our old video player, we were afraid to touch it because we knew it would be a painful experience to our customers – we’d therefore only update it every year. With Silverlight, we’re constantly enhancing!

The media stream source API gives us access at the right point in the pipeline to be able to really push the player. After we’ve done the innovation on Silverlight, we’re also able to take these same experiences and drive them into device-based players like Xbox and Roku.

In Silverlight 3, we’re looking forward to taking advantage of some new features from Microsoft, in particular GPU support for scaling and stretching video, expanding the range of processors and price points for running video playback, as well as taking advantage of all the other innovations and features that Microsoft have added over the last twelve months. We’re very happy with Silverlight.

SL3: Adobe AIR is dead!

“Out-of-browser Experiences have now come to Silverlight.  This is a highly requested feature and is enabled with no additional download/plugin.  Each and every Silverlight 3 application can be enabled to run as a desktop application (yes, cross-platform with Windows/Mac) by subscribing to a series of APIs and defining the application in the manifest. “

Silverlight 3 spoilers

 
Cool, in SL3, we’ll have the concept of screens and deeplinks out-of-the-box. Too bad we have implemented it @Axinom several times already (in different teams).
 
They’ve also added a mightly overview/detail controls – can it be interesting for AxCMS user interface?

Progressive download CPU consumption

As progressive download consumes more CPU than streaming, I’ve decided to research this issue further.
 
I’ve implemented a possibility to throttle the bandwidth used for the progressive download. The throttling happens on the client side, by inserting some Thread.Sleeps in the loop where the downstream is being repeatedly read in a memory buffer.
 
And I could measure the following CPU loads:
Progressive download
(unconstrained)
40%
Throttled to 6mbit/s
28%
Throttled to 2mbit/s
23%
Throttled to 1mbit/s
18%
Adaptive Streaming
10%
 
In the adaptive streaming case, I believe, it is not only their more optimized download loop implementation, but also the fact that they use MP4 container format instead of ASF can play a role. Alex Zambelli describes Smooth Streaming Architecture in his blog (Smooth Streaming is an alias of adaptive streaming).
 
I will also test CPU consumption for the same movie when it is being streamed via Windows Media Services, when I obtain a new test server.

Working off requirements

People are different. I have to think about this axiom every time I see a statement I can’t apply for myself.
 
One of such statements is a wish to get ideal software requirements and to work them off, preferrably left alone.
 
Every time I’ve tried this approach, a produced a dead-born something, that has corresponded pretty much to the requirements, but nobody wanted to use it.
 
I’m confident, it is not a coincidence. 
 
As a product owner, you know what a successful application must look like. You can communicate these requirements explicitely and verbally, or implicitely and non-verbally.
 
In the latter case, you have to make the developers to share your vision. When you succeed, they will evolve (even better and more complete) requirements on their own. In the former case, the communication channel is rather limited and too one-way-ish.
 
Without perfect knowledge, what exactly will make the app to success, developers will create just some set of bytes, albeit perfect in its internal architecture, but otherwise useless.
 
Making successful apps is more important to me than making apps with clear architecture.