Smooth Streaming – Silverlight’s Trojan Horse

Home/Articles/Smooth Streaming – Silverlight’s Trojan Horse
By | 2009-08-14T00:00:00+00:00 August 14th, 2009|Articles|Comments Off on Smooth Streaming – Silverlight’s Trojan Horse

I’ve written before that most consumers couldn’t care less if Microsoft pulled the plug on Silverlight, primarily because from their view — that of the user — it does little that Flash can’t do. I know, I know, there’s lot of fringe features Silverlight offers that Flash doesn’t, but the reverse is also true, and in terms of the core feature set – the features used by most web sites – and from the point of view of the user, the technologies are similar.

This doesn’t mean that Silverlight doesn’t offer multiple advantages over Flash from the developer’s perspective – it clearly does. Specifically, if you’ve got large libraries of legacy content encoded in Windows Media format, Silverlight can play it, while Flash can’t. If you’ve got lots of applications developed in .Net or C#, they’re easier to port to the web using Silverlight than with Flash. The developers who created these programs can also be immediately become productive with Silverlight, while they basically have to start from scratch to produce Flash programming.

So it’s relatively clear that there’s a lot of pent up demand for Silverlight from the web site producer’s standpoint. What’s holding them back from deploying Silverlight for general Internet application is the relatively low installed base of Silverlight players – still only around 33%, and those numbers are vague and un-audited.

At 33%, you can deploy Silverlight for internal or captive applications, where you control the viewers, or if your content is so compelling that you can assume that interested users will download the player to view your content. The Olympics, French Open and Wimbledon come to mind. Where it doesn’t make sense is in bread and butter general Internet applications, where viewers may not want to download a plug-in to view marketing or sales oriented content. So Microsoft faces the classic chicken and egg problem – web sites won’t use Silverlight until the installed base passes some unknown tipping point, but the installed base won’t grow until web sites start using Silverlight.

The feature that they’ve created to break through this logjam is Smooth Streaming, and it seems to be working. Smooth Streaming is an adaptive bitrate streaming technology that delivers a stream customized to the viewer’s connection bandwidth and adjusts that stream should conditions change. From one link, for example, the viewer on the high speed corporate LAN might get a 2 mbps stream, while the home user on a slow DSL connection might get a 500 kbps. If conditions change for either viewer – say the home user’s kids start watching YouTube videos – the video drops to a lower data rate automatically. Quality may degrade, but the stream continues, and when the kiddies go to bed, the quality will improve.

Of course, Adobe has the same feature with Dynamic Streaming. The biggest differences are that Smooth Streaming is more proven – especially the digital rights management component – and that Smooth Streaming uses the HTTP protocol rather than RTMP. Using RTMP has two consequences. First, it requires a Flash Media Server connection with each viewer, which means higher server-related costs.

Second is that HTTP data is more cache-friendly than RTMP, which should translate to fewer streams delivered to satisfy the same number of viewers and better quality of service. For example, viewer 1 on a corporate LAN or watching via an ISP would get the complete video, which would be stored on the corporation’s or ISP’s cache server. Subsequent requests for the same data would be satisfied from the cache, so the producer doesn’t have to pay the CDN to send the streams again. Since the data is served essentially locally, the subsequent viewers should also have a better viewing experience.

I’ve written about this before (see Streaming Gets Smarter: Evaluating the Adaptive Streaming Technologies, and have never been comfortable that the theoretical benefits of HTTP over RTMP actually translate to lower costs or higher quality of service. For example, I’ve asked Microsoft multiple times to supply a Smooth Streaming user that would state on the record that Smooth Streaming was more efficient from a delivery perspective, and haven’t heard back.

I’ve interviewed multiple CDNs and none have said that HTTP-based technologies allow their customers to deliver an event cheaper than RTMP. To a degree, perhaps that’s because virtually all of their clients have been asking to deliver streams to the ubiquitous Flash Player, and the alternatives – Silverlight – has the aforementioned penetration issues. No sense trying to sell someone beef when they’re asking for chicken. On the other hand, if HTTP based technologies were so much more efficient, you would expect pricing to follow, and then users to follow the pricing. To date, that really hasn’t happened.

Next: Smooth Streaming, Microsoft’s Trojan Horse


#1Jan PetzoldSaid this on 08/14/2009 At 03:11 pmHey Jan,

good article. Don't forget about the firewall issue, which is a major issue. RTMP or RTSP have to be tunneled via HTTP if you want to make sure that your content reaches the audience, which wastes bandwidth and increases buffering times. In my opinion, one of the main reasons why Youtube became so big - it just works, even in company's networks.

I'm surprised to read that CDN costs should be the same for HTTP and RTSP/RTMP traffic - tell me the provider charging the same price per GB for both delivery options, I'd be happy to hear ;-)

Lastly: If I can deliver web sites and audio/video content from the same server without fumbling around with the usual port 80 issue and two server software instances running in parallel - fine for me.#2KamelSaid this on 08/18/2009 At 12:38 pmHello Jan,

I want to comment that doing the dynamic streaming HTTP-based is only one part of the story. This fact alone can't be used by the CDN in order to use the HTTP cache infrastructure. The key point to make it cache friendly is the fragmentation of the entire stream. Instead of doing only one connection for transmitting a long stream, Smooth Streaming makes a hundred of very quick and efficient progressive downloads for each small video chunk. Also, if Adobe decides to implement a solution similar to Smooth Streaming, it will be a lot easier remove the Flash Media Server dependency.

I agree with you. For me it is not clear enough what is the direction of the big players during the next months.#3Philipp AngeleSaid this on 10/31/2011 At 04:29 am

Hey, allways nice to read your articles. Would be great if you could review your review now 2 years later :) what is your prognoses with html5 in the adaptive bitrate lottery :)

#4Jan OzerSaid this on 11/04/2011 At 12:13 pm

Hey Phillip:

Thanks for your note. I have to say, it looks like my prediction was correct, as Adobe announced HTTP based streaming (single and adaptive) in May 2010, 3 months before my deadline.

I'm pretty negative on HTML5 in general, but I'll be hearing about the DASH standard next week from some Microsofties, and if any technology can make adaptive streaming work under HTML5, that's probably it. I'll be writing up my impressions for, so look for something in the next couple of weeks.

Thanks for writing in.