Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
I’ve been tracking Scalable Video Coding (SVC) for the last year or so and there’s been little tangible evidence of adoption. Recently Toronto-based Seawell Networks came out of stealth mode, but only barely, announcing that they are in the H.264 marketplace, but providing no product details.
I met company CEO Brian Collie at a trade show last November, but he couldn’t detail what Seawell was up to product wise, and still won’t. But he did agree to take a stab at detailing the state of the state of the SVC market, and predicting what 2010 would bring.
Let’s take a moment and set the stage. Briefly, Scalable Video Coding is an extension of the H.264 standard that enables streaming producers to distribute video at multiple bit rates and resolutions, so the cellular viewer gets one stream, and the broadband viewer quite another, both customized for connection speed, screen resolution and processor speed.
SVC’s unique advantage is that it can serve these multiple streams from a single encoded file, where technologies like Adobe’s Adaptive Streaming, and Microsoft’s Smooth Streaming need different streams for every supported configuration. For example, Major League Baseball streamed 11 configurations of H.264 video during last years’ playoffs, and had to create eleven unique streams. This required multiple racks of encoders, and obviously increased storage and bandwidth cost.
With SVC, only one stream would be required, and it’s only about 20% larger than the size of the largest stream served. In addition, that single stream can dynamically adjust output resolution, data rate and frame rate to provide a much greater range of output streams. Where Adaptive Streaming requires eleven source streams to serve eleven different video configurations, a single SVC stream can serve as many as 48 different configurations, perhaps more.
This makes SVC cheaper to encode, store and administrate, while providing a superior viewing experience to a broader range of viewers. In theory, anyway, because no one who can talk about it has ever seen it working.
So, back to Brian Collie. Brian first outlined that the SVC has three basic components; two mandatory, one optional. The two mandatory components are the encoder to create the stream, and the player to play it. In this schema, the intelligence lies in the player, which retrieves the most appropriate stream and then monitors playback, changing streams to adjust for changing conditions, which is how Adobe’s Dynamic Streaming and Microsoft’s Smooth Streaming operate.
The server is optional, and enables two things. First, broadcasters seeking to optimize service over a range of viewers can monitor and adjust the data rate distributed during high demand periods to better serve all viewers. Second, the server component could also enable the publisher to differentiate between its customers, providing multiple levels of service and a tiered service approach.
I asked Brian which of these components are available now, and he responded that all current producers were still in stealth mode. Then we picked up the crystal ball and started predicting.
I first asked “will we see commercially available SVC encoding tools shipping in 2010?” Brian responded “yes.”
I followed up with “Will we see SVC decoding in either the Flash or Silverlight players?” Brian hedged a bit and said “we see strong momentum in that direction,” then added “all the major ecosystem players, including content providers, content management systems, content delivery networks and players, are all actively working on SVC.”
My final question was “will we see any content providers distributing streams with SVC technology in 2010.” Collie’s response was short and unequivocal. “Definitely.”
There you have it.
