VOD transcoding is getting a lot of attention these days. Not that it ever went out of style, but lately it’s become front and center again for many video service providers (VSPs). I am on several customer calls and meetings per week about the topic.

Why all the attention on VOD transcoding? Simple answer – adaptive bitrate (ABR) streaming. Tablets, phones, even set-top boxes are getting in the act. The new iPad “3” (even though Apple just calls it “the new iPad”) is taking ABR streaming capabilities to a new level. The new iPad’s 2048-by-1536 pixel resolution at 264 pixels per inch (ppi) is double the ppi density of the iPad 2. Analysts predict that Apple will sell a mind boggling 70 million of them this year.

And Apple isn’t the only game in town – the Samsung Galaxy tab and Amazon Kindle are two other hot devices that VSPs want to reach. Not to mention connected TVs and new adaptive streaming capable set-top boxes.

Providing VOD content to these devices is an entirely new revenue opportunity that has opened up to operators – and they want to capitalize on it.

Unfortunately however (there’s always a “but” isn’t there?) it’s not that simple. The traditional VOD transcoding that is done to deliver content to MPEG-2 and H.264 capable set-top boxes doesn’t work for newer over-the-top (OTT) devices. The content needs to be coded into several different profiles (bitrates and resolutions), segmented, packaged and encrypted. Plus, different packaging is required depending on whether you want to deliver content to HLS, SS, HDS or MPEG DASH clients.

That’s where file-to-file (F2F) ABR VOD transcoding comes in. With an ABR capable transcoder (like RGB’s Linux software-based TransAct Transcoder), you can transcode all of your VOD content into every bitrate, resolution and package type to reach any device. Plus, with built-in encryption capabilities that are integrated with leading DRM providers, our TransAct Transcoder allows operators to encrypt content and push to the CDN for distribution to end devices. In fact, we have several customers doing this today – packaging and encrypting latest release movies and making them available over a CDN.

A few key advantages that customers appreciate about our offline/VOD transcoding capabilities:

• Multiscreen VOD enablement
  • ABR VOD transcoding to all adaptive streaming formats
  • Manifest/index file creation
  • HLS and SS DRM encryption

• Plug-and-play into VOD ecosystem
  • Watch folders and drop folders on NFS, CIFS or WebDAV mounts
  • F2F XML-RPC API signaling with call back
• CableLabs-compliant output including interlaced output for MPEG-2 and H.264

Plus, one of the really cool things you can do with our VOD transcoder is create a set of mezzanine format TS files that can then be packaged later for delivery “just-in-time” to ABR devices (take a look here for more information on this application).

If you want to learn more about our VOD transcoding capabilities, visit our File-to-File Transcoding page where you can download a detailed solution overview.

It was bound to happen at some point. MPEG DASH (Dynamic Adaptive Streaming over HTTP) has been ratified and is on its way to becoming an industry-accepted standard. There will still be a few bumps along the way, but it seems that streaming industry vendor development is moving along well. Adobe and Microsoft are active participants in the DASH Promoters Group, along with Netflix, Akamai, Samsung and many others (including RGB Networks!), and in fact Microsoft chairs the group.

What is MPEG DASH?

MPEG DASH is the MPEG standardization of Dynamic Adaptive Streaming over HTTP. DASH is described by document ISO/IEC 23009-1. For those already familiar with the three prominent adaptive streaming protocols – Apple HLS, Microsoft Smooth Streaming, and Adobe HDS – DASH can be thought of as an amalgamation of the three (for a comparison of these protocols, download our white paper).

At a high level, DASH works nearly identically to the other adaptive streaming protocols. Available stream content is presented to the player in a manifest (index) file. In DASH, the manifest is called a Media Presentation Description (MPD) file, which is in XML format. The MPD is analogous to an HLS m3u8 file, a Smooth Streaming Manifest file or an HDS f4m file. After the MPD is delivered to the client, content – such as video, audio, subtitles or other data – is downloaded to clients over HTTP as a sequence of video files that is played back contiguously.

The MPD describes the content that is available, including URL addresses of stream chunks, byte-ranges, different bitrates, resolutions, and content encryption mechanisms. The task of choosing which adaptive stream bitrate and resolution to play, and changing to different bitrate streams according to network conditions, is done by the client (again, similar to other adaptive streaming protocols). In fact the MPEG DASH standard does not prescribe any client-specific playback functionality, rather it pertains to the formatting of the content and associated MPDs only.

There are two file segment types allowed in DASH – MPEG2 TS and ISO Base media file format (ISO BMFF). MPEG2 TS is what HLS currently uses, and ISO BMFF is what Smooth Streaming and HDS currently use. This allows for a relatively easy migration of existing adaptive streaming content to MPEG DASH, as the media segments can often stay the same, and only the index files need to be migrated to an MPD format.

MPEG DASH defines and allows for different profiles to be created. A profile is a set of restrictions of media formats, codecs, protection formats, bitrates, resolutions, or other aspects of the content. For example, the DASH spec defines a profile for ISOBMFF basic on-demand.

What capabilities will MPEG DASH offer for video service providers?

MPEG DASH offers a standards-based approach for enabling a host of services that operators have traditionally offered in IPTV and broadcast environments, and extends those capabilities to adaptive bitrate delivery, including:

• Live and on-demand content delivery
• Time-shift services (NDVR, Catch-up TV)
• Targeted ad insertion

MPEG DASH enables these features through a number of inherent capabilities, and importantly, flexibility of design and implementation:

• Multiple segment formats (ISO base media FF and MPEG-2 TS)
• Codec independency
• Trick mode functionality
• Profiles: restriction of DASH and system features (claim & permission)
• Content descriptors for protection, accessibility, content rating, and more
• Common encryption (defined by ISO/IEC 23001-7)
• Clock drift control for live content
• Metrics for reporting the client session experience

One of the most important features of DASH is its use of Common Encryption (a topic for another blog post), which standardizes a number of different, widely-used encryption methods. This allows content owners to distribute content, and allows service providers to have access to an interoperable ecosystem of vendors.

What aspects of DASH could hinder widespread adoption?

First, there are some unresolved intellectual property rights with DASH. Normally, IP introduced into MPEG standards is accepted only if the IP owner agrees to Reasonable and Non-Discriminatory (RAND) terms. In the case of DASH, it is not clear that all IPR in the standard is covered by RAND terms. Second, while DASH has one name, it is a collection of different, non-interoperable profiles. So DASH doesn’t solve the problem of different, non-interoperable implementations unless DASH clients support all profiles. And this is basically equivalent to having a client that supports HLS and HDS and Smooth Streaming (which incidentally would also address the interoperability problem).

Time will tell if MPEG DASH will coexist or supersede existing adaptive streaming formats. Certainly, DASH provides quite a flexible framework for delivering streaming media content. As usual, it will depend on what the major vendors do, and whether VSPs see the benefits of augmenting or changing trajectory of in-process deployments and content offerings.

I’ve written about how both Apple HTTP Live Streaming (HLS) and Microsoft Smooth Streaming work, and the main differences between each adaptive streaming delivery protocol. Today I will focus on the third of the market trilogy of adaptive streaming power houses, Adobe’s HTTP Dynamic Streaming (HDS).

HTTP Dynamic Streaming was announced by Adobe in late 2009 as “project Zeri” and was delivered in June 2010. HDS is typical of adaptive streaming – the video content is segmented into small chunks, it is delivered over HTTP, and 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.

HDS is more similar to Microsoft Smooth Streaming than it is to Apple HLS. Primarily this is because it uses a single aggregate file from which MPEG-file container fragments are extracted and delivered rather than HLS-like individual chunks, and consequently there are certain implications of that design, which will be discussed in detail.

Characteristics of Adobe HDS

HTTP Dynamic Streaming supports both live and on-demand content using a standard MP4 fragment format (F4F). Video/audio codec support includes VP6/MP3 and H.264/AAC, however as with HLS and SS, the predominant video/audio codecs are H.264/AAC.

Similar to other adaptive streaming protocols, at the start of the stream, the client or CDN/origin server downloads the manifest file (in this case F4M file) which provides all the information needed to play back the content, including fragment format, available bitrates, Flash Access license server location, and metadata information.

Files representing either live or VOD workflows are sent to an HTTP origin server. The origin server is responsible for receiving segment requests from the client over HTTP and returning the appropriate segment from the file. Standard origin servers like Apache can leverage Adobe’s Open Source Media Framework (OSMF) to serve the content.

Differences Between Adobe HDS and Apple HLS

There are several key differences between Adobe HDS and Apple HLS:

• HLS makes use of a regularly updated “moving window” metadata index (manifest) file that tells the client which chunks are available for download. Adobe HDS uses sequence numbers in the chunk requests and thus the client doesn’t have to repeatedly download a manifest file.
• In addition to the manifest, there is a bootstrap file, which in the live case gives the updated sequence numbers and is equivalent to the repeatedly downloaded HLS playlist.
• Because HLS requires a download of a manifest file as often as every time a new chunk is available, it is desirable to run HLS with longer duration chunks, thus minimizing the number of manifest file downloads. More recent Apple client versions appear to now check how many segments are in the playlist and only re-fetch the manifest when the client runs out of segments. Nevertheless, the recommended chunk duration with HLS is 10 seconds, while with Adobe HDS it is usually 2-5 seconds.
• 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 Adobe HDS (and Microsoft SS) make use of “fragmented” ISO MPEG-4 files.

As with HLS, Adobe Flash clients first request a manifest 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:

• The client reads the manifest and can request chunks by a URL with a sequence number rather than a specific chunk name.
• The server must calculate 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 Adobe HDS works, a good resource is Adobe’s HTTP Dynamic Streaming technical whitepaper.

Interestingly, several changes are on the horizon though for Adobe’s adaptive streaming capabilities, so stay tuned to Adobe announcements for what is on the way.

You've heard the saying—"If you're not the lead dog, the view never changes." Here at RGB, we're very happy to have a great view of the rapidly evolving world of multi-screen video as we help lead the way into an exciting new "TV everywhere" era. Today we’re excited to be able to highlight a deployment that not only demonstrates the power of RGB’s transcoding solutions, but it also gives us the opportunity to take an interesting view into an extraordinary event pitting dog and human against the elements.

Called “the last great race on earth,” the Iditarod race kicks off this weekend, taking dedicated teams of dogs and their mushers over 1150 miles through the frigid Alaskan wilderness. Subscribers to GCI, the largest telecom and cable operator in the state, will not only be able to tune into the excitement of this event on their TVs, but on their PCs and laptops as well. GCI is utilizing RGB’s TransAct Transcoder to deliver high-quality video in real-time to this “second screen,” putting them well on their way to a full blown three screen service.

RGB’s transcoding products take on the burden of converting individual streams to the large number of resolutions and bit rates required by the wide variety of PCs and broadband speeds used by subscribers; and the scalability of RGB’s solution enables customers to start with small deployments and easily grow them as demand increases for more channels on more devices.

Every dog has his day and we hope that GCI’s subscribers enjoy watching the remarkable sled dogs of the Iditarod have theirs.

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.

We’re happy to report that our flagship three screens solution – the Video Multiprocessing Gateway (VMG) – received a stellar 4 Diamond Ranking in Broadband Gear Report’s annual Diamond Technology Reviews. We certainly weren’t surprised by the high score. The VMG has been getting rave reviews from operators around the world – big and small – who are taking advantage of the VMG’s outstanding transcoding performance and industry-leading stream processing capacity for trials of multi-screen services and deployments of other transcoding applications, such as MPEG-2 to H.264 for bandwidth savings and HD to SD downconverion, eliminating the need for costly SD simulcasting and duplicated ad insertion costs.

One recent video-to-the-PC trial in particular highlights the unique capabilities of the VMG. Since cable operators are the leading providers of broadband service here in the US, it’s natural for them to want to deliver service to the PC rather than surrender this potentially lucrative market to the over-the-top (OTT) players. While many OTT players claim that delivering TV to a PC is simple, it’s actually quite a challenge if the goal is to offer a service that’s “as good as TV” and free from choppy video, tinny audio, poor picture quality and annoying “waiting for download” messages.

The key to a quality viewing experience is being able to accommodate a wide array of connection speeds, screen resolutions, etc. The ideal approach is to create multiple different “profiles” of each video stream to meet a variety of user requirements. In this major trial the VMG created 14 separate streams for each incoming stream – in other words, it output 14 different versions of HBO, Showtime, ESPN and dozens of other channels. Multiply a 100+ channel line-up by 14 and you get a sense of the stream processing and transcoding horsepower required to deliver a complete channel line-up.

This is where the VMG really shines. Its ability to repurpose up to 144 HD input streams into over 400 output streams, all within a single chassis under a single management system, drives down the cost and complexity for operators to expand small scale trials with a handful of channels to a commercially available service that delivers a full line-up of hundreds of channels.

What’s more, this combination of unprecedented stream processing capacity and advanced transcoding abilities can make delivering live TV to mobile devices as equally widespread.

Come visit us at Cable-Tec Expo, booth #2025, to learn more about the full capabilities of the VMG. Click here for more information now and to download a free exhibit pass.
 

As I promised in my previous post, RGB is taking a strong stance towards a proactive integration of our platforms with partner devices, with the initial goal of easing the headaches of deployment for all involved and the eventual goal of providing “the whole is greater than the sum of the parts” equation for our customers. Evidence of this activity can be seen in a recent solution brief jointly authored with SeaChange which you can obtain from your sales representative for each company (or contact us). This brief, entitled “Managing Bandwidth and Video Quality Issues While Transitioning to an On-Demand Architecture” focuses on trends in the video distribution marketplace which impact service providers. It goes on to detail some of the ways which we’re working on integrating our solutions to provide the best solutions for those providers. The delivery of on-demand services is one area in which we see a tremendous growth curve over the coming years. The type of proactive integration undertaken by RGB and SeaChange is something we expect to be doing much more of as we progress down the path towards a ‘stream-per-set’ video delivery architecture. Further evidence of RGB’s partnership with SeaChange will be seen in an upcoming CED webinar – Time Shifting: Optimizing Bandwidth for New On-Demand TV Applications. Register for the March 12 event (or view it on-demand after the fact) and learn much more about this topic. In addition to narrowcast service delivery, RGB sees increasing needs for partnerships in areas such as targeted advertising. As you may have seen in blogs from my fellow RGB’ers, this is an area of intense interest to the industry as service providers battle the Web for advertising eyeballs. More to come on that topic in future posts.

As RGB prepares for next month’s IPTV World Forum in London, we’re very excited to announce that our Broadcast Network Processor (BNP) has been shortlisted for one of their prestigious IPTV World Series awards in the category of Best Cable IPTV Technology. Make sure to stop by stand #40 and see what all the fuss is about.

Politics isn’t the only thing changing on this historic day. Video is undergoing a major change as well. Congress now has its own YouTube channel. So if you want to know what your representatives are up to, check out the video channels for the House and Senate. And our new president is already using the video sharing website to make weekly addresses to the nation. It’s about time we got an upgrade from those outdated radio addresses. And if you’re working today at the time of the big inauguration, all the major news outlets (including ESPN) are providing multi-platform programming—set your TiVo to record the television broadcast, but you can watch online, on your mobile phone or even via video-on-demand after it’s all over. We’ve definitely entered a new video era—it’s everywhere—in politics and in the rest of our daily lives.

Most online video today is pretty grainy—there’s a lot of room for technology improvements—but video is certainly transforming from an entertainment medium delivered to your television to a whole new information delivery tool. It has become more than just a sit-on-the-couch, lean-back experience (although I don’t plan to give up my couch potato ways any time soon!).

Are you taking part in the video revolution?

In my previous blog post I wrote about the decline of ad dollars going to newspapers, radio, and broadcast TV that started in 2001 and the double digit growth in internet advertising spending that started at about that same time.  Advertising Age posted an article, “Marketers to Up Spending in Cable, Online, Mobile in Next 6 Months,” that describes this continuing trend for 2009 and the growing pessimism surrounding these traditional media. Interestingly enough the article paints a brighter picture for cable TV.

One reason for this better picture for cable is that the audience share for cable programming continues to increase versus broadcast TV.  Another and maybe more important reason is that the cable industry is taking steps to make advertising on its platform more targetable, interactive, and measureable – attributes that have attracted advertisers to the internet – with Canoe Ventures leading the way for the industry.

As the article mentions, they are “seeing less slowing in media that is more accountable and targetable,” and that the results (and measurement of those results) of ad campaigns are very important to marketers, maybe even more so than price.

Because of the connectivity that cable has to the home, cable is a great platform to enable advertising that is targetable, interactive, and measureable.  Cable systems are already divided into geographic territories through their headend, hub, and node structure.  VOD, for example, is divided into service groups made up of a few nodes where a separate QAM channel feeds only those homes in the node.  Using this structure, the cable industry already sends different ads to or tags the same ad with different content for different geographic areas.  With VOD, switched digital video (SDV), or applications in the set top box, cable can extend this targeting to the subscriber level.

In addition, the ability to overlay graphics on top of a video program coupled with mechanisms such as EBIF to encapsulate and transmit the content of these graphics is a great way to enable interactivity on the television screen.   Cable systems can also gather measurement information such as viewing data from set tops, knowing if and when an ad was inserted in the network or set top, click through data, and time spent on interactivity – all of which are very important to advertisers.

All of these capabilities allow the cable industry to create a new ad platform with the highly desirable attributes of targeting, interactivity, and measurability that are causing such upheavals in the advertising industry guaranteeing a bright future for cable television advertising.