Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
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
