Since we announced Smooth Streaming in October, the team has been hard at work preparing the feature for broad public release (the answer to the obvious question of “When?” is “Very soon!”... please stay tuned for details) and addressing feedback from customers in the early adoption program. But, of course, the Web (and especially the blogosphere) never stands still:
- RunAs Radio produced a podcast focused on Smooth Streaming and, more generally, streaming media (thanks to Richard and Greg for kindly inviting me to be on their show)
- Chris Knowlton highlights Smooth Streaming customer questions and the answers provided by Ben Waggoner and Alex Zambelli in a downright encyclopedic set of blog posts
- Updates to SmoothHD.com site that should reduce bandwidth utilized when the window is too small to see a higher quality picture from a higher bit rate
- Some interesting questions on my initial post, addressed below…
And although this last topic is not about Smooth Streaming as such, it highlighted one of the needs the technology fulfills. Coverage of the U.S. Presidential Inauguration drove traffic records across the Web and set a new bar for customer expectations. However, the day also caused frustration and demonstrated the challenges of scaling to the size of the audience, as captured in The Day Live Web Video Streaming Failed Us. When we demo Smooth Streaming, the end-user experience is the first thing people notice, but scale is where the technology truly gets its opportunity to shine. It never ceases to amaze me how massive (and massively distributed) the Web’s HTTP delivery infrastructures really are. With Smooth Streaming, we are betting that the way to reach the growing audience is to integrate video delivery into these infrastructures, rather than trying to scale out the comparatively far smaller parallel networks for streaming.
My last post sparked a couple of interesting questions that merit some clarification:
- How does Smooth Streaming relate to what Move Networks is doing? From my perspective, what we offer with Smooth Streaming is a platform technology while Move Networks is a one-stop-shop service solution provider that innovates on the Silverlight platform. So I would not view this as a competing offering – the intent is to create a vibrant ecosystem of great services for streaming media to Silverlight, in which Move Networks continues and will continue to be a strong and well-respected player.
- How does Smooth Streaming relate to Windows Media multiple bit rate (WM-MBR) technology? WM-MBR focused on the challenge of simplifying delivery to client that may have differing “last-mile” connection speeds, and provided a format that allowed all the bitrates to reside in a single file, along with a client and server that negotiate the delivery bit rate. Smooth Streaming addresses a similar challenge and several others:
- The Last Mile: Smooth Streaming takes the bit rate switching concept a step further by making the switches seamless, and adjusting the bit rate every few seconds as needed to ensure the optimal experience.
- Scaling Out for Global Delivery: Smooth Streaming addresses this by making the media communication HTTP-cacheable, accomplished by fragmenting the media into independently decodable units for transport. We chose a format that enables the server to fragment the media in an efficient and scalable fashion, but unfortunately fragmentation that is not a scenario WM-MBR was designed for.
- Future-Proofing the Algorithms: By leveraging managing code in Silverlight to host the bit rate decision algorithms, Smooth Streaming makes it easy to evolve these algorithms over time, customize them for a content library, and optimize them for a specific delivery network, all without changes to the client runtime.
Windows Media Services will continue to offer first-class support for WM-MBR streaming to Windows Media Player, and we’ll look to provide migration tools from existing formats in response to customer demand.
Hope this helps, and of course I’m looking forward to getting more great questions when the bits are public.