In case you haven't already heard, 2010 was a spectacular year for RGB. While many companies struggled, we thrived, working around the clock to keep up with the demand for our solutions from cable operators, telecom carriers and other video service providers around the world.

One of the keys to our success in 2010 was the seriousness with which service providers began trials of three screen services in a rush to deliver TV Everywhere.

Our Video Multiprocessing Gateway (VMG) couldn’t have been better timed. As service providers worldwide initiated their three screen trials they quickly realized that capacity and scalability are key and that the modular VMG stood alone with its ability to process over 400 streams simultaneously. While transcoding a single stream is easily accomplished with low capacity solutions, the requirement for multi-screen video delivery is not to merely transcode an MPEG-2 program into a single MPEG-4/H.264 program. For PCs and mobile devices, you have to create a dozen or more streams or ‘profiles’ to ensure a high-quality experience for every viewer, regardless of screen resolution or format.

And here’s the kicker, if you’re even thinking of delivering live programming to small screen devices, you’ll need to perform all of this in real time!

It didn’t take service providers long to recognize that they needed a lot of transcoding capacity for their three screen TV Everywhere services … and it took them even less time to realize that using low capacity ‘pizza box’ transcoders was not only far too costly, but the management headaches and lack of scalability made the idea a non-starter for anything beyond small trials.

If the news coming out of last week’s CES is any indicator, the number of mobile devices available for video viewing is going to increase substantially this year, along with the demand for on-the-go video services.

Fortunately for service providers, the VMG offers unrivaled transcoding capacity in a carrier-class chassis with a comprehensive management system, making it simply the ideal solution for delivering a high-quality TV Everywhere service that can be enjoyed on any video-enabled device.

So as successful as 2010 was for RGB, our 2011 future is so bright we’re pulling out our shades!

Recently I wrote about how Apple HTTP Live Streaming (HLS) works. In this post I want to talk about Microsoft Smooth Streaming, and the key differences between Smooth Streaming and HLS.

Smooth Streaming was announced by Microsoft in October 2008 as part of the Silverlight architecture. That year they demonstrated a prototype version of Smooth Streaming by delivering live and on-demand streaming content such as the Beijing Olympics and Democratic National Convention.

Smooth Streaming has all of the typical characteristics of adaptive streaming. The video content is segmented into small chunks, it is delivered over HTTP, and usually multiple bit rates are encoded so that the client can choose the best video bit rate to deliver an optimal viewing experience based on network conditions.

Adaptive streaming is valuable for many reasons including low web-based infrastructure costs, firewall compatibility and bit rate switching. Microsoft is definitely a believer in those benefits as it is making a strong push to adaptive streaming technology with Microsoft Silverlight, Smooth Streaming and Mediaroom.

Smooth Streaming vs. Apple HLS

Microsoft has chosen to implement adaptive streaming in unique ways, however. There are several key differences between Silverlight Smooth Streaming and HLS:

1. HLS makes use of a regularly updated “moving window” metadata index file that tells the client which chunks are available for download. Smooth Streaming uses time codes in the chunk requests and thus the client doesn’t have to repeatedly download an index file. This leads to a second difference:
2. Because HLS requires a download of an index file every time a new chunk is available, it is desirable to run HLS with longer duration chunks, thus minimizing the number of index file downloads. Thus, the recommended chunk duration with HLS is 10 seconds, while with Smooth Streaming it is 2 seconds.
3. The “wire format” of the chunks is different. Both formats use H.264 video encoding and AAC audio encoding, but HLS makes use of MPEG-2 Transport Stream files, while Smooth Streaming makes use of “fragmented” ISO MPEG-4 files. The “fragmented” MP4 file is a variant in which not all the data in a regular MP4 file is included in the file. Each of these formats has some advantages and disadvantages. MPEG-2 TS files have a large installed analysis toolset and have pre-defined signaling mechanisms for things like data signals (e.g. specification of ad insertion points). Fragmented MP4 files are very flexible and can easily accommodate all kinds of data, for example decryption information, that MPEG-2 TS files don’t have defined slots to carry.

There is also a difference in the type of infrastructure support for these two formats. While there are clients for both HLS and Smooth Streaming, Microsoft has included Smooth Streaming server support in their IIS server. This server stores the Smooth Streaming file in an aggregate format, meaning a small number of files that collect all the chunks together. HLS can also support an aggregate format, but Apple does not support this functionality directly. Microsoft positions their aggregate format as a strength of Smooth Streaming over HLS, since one contiguous file can arguably allow files to be managed more effectively than thousands of individual chunks for a given video. While this is true on the content server side, this is not necessarily the case on the receiving web server or CDN side, since each segmented chunk is requested and delivered individually.

Conversely, the downside to having one large contiguous file is that it requires more work for the server when clients request a stream. As with HLS, clients first request a manifest file, in this case called a .ismc file. The manifest contains information about what streams are available, bit rates, codecs, etc. and the streams are represented by a URL. Using a contiguous file creates two significant changes in the client/server architecture:

1. The client reads the manifest and can request chunks by a URL with a time code rather than a specific chunk name.
2. The server calculates exact byte range offsets within the aggregate file by translating URL requests and delivers the appropriate chunk.

For a more in-depth overview of how Microsoft Smooth Streaming works, a good resource is Microsoft’s Smooth Streaming Technical Overview whitepaper.

Additionally, for a slightly biased but still accurate representation of some of the key differences between Smooth Streaming, HLS, and Adobe Zeri (HTTP Dynamic Streaming), check out this adaptive streaming comparison matrix.

I’d be happy to speak with you further about this topic. Please feel free to comment or ask questions.

You’ve heard of Hulu, right? Who hasn’t—through their video streaming website, the company has helped to change the way people watch video content. So we were excited to have the founding CTO of Hulu, Eric Feng, visit us and give us his thoughts on what we’re doing in the video space here at RGB. Take a look at what he had to say. As video viewing habits rapidly shift beyond the TV, RGB is excited to play a critical role in this process.