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.

With memories of a very successful Mobile World Congress still fresh in our minds, we wanted to share a video from the show of RGB's Andy Salo discussing the challenges of mobile video delivery.

One of they key points raised in the discussion is the fact that operators receive most of their content in a single format and must quickly convert it to dozens of new profiles, making rapid changes to codecs, resolution and bit rates, as well as packaging the content for different adaptive streaming protocols, such as Apple HLS, Microsoft Smooth Streaming and Adobe Zeri. As mobile video expands rapidly, operators are faced with a serious problem—how do they deploy a solution today that will scale easily and cost-effectively as demand grows and provide the reliability and quality required for a pay service? Take a look at the video to learn more.

A highlight of last week’s Mobile World Congress was the announcement of many new tablets and smartphones. With the proliferation of these high-res mobile devices, consumers expect to be able to stream a wide variety of high-quality video anywhere they go. With this demand for premium video from their subscribers, mobile carriers and other service providers face a number of technical challenges. RGB’s Ramin Farassat talked with Mobile Europe editor Keith Dyer about how operators can build and sustain a network that can efficiently and cost-effectively deliver high-quality video to any device without putting undue burden on their network.

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.

HTTP Live Streaming (HLS) allows you to stream live and on- demand video and audio to an iPhone, iPad, or iPod Touch. HLS is similar to Smooth Streaming in Microsoft’s Silverlight platform architecture, and can be thought of as a successor to both RTSP and HTTP Progressive Download (HTTP PD), although both of those video options serve a purpose and likely won’t be going away anytime soon.

HLS was originally unveiled by Apple with the introduction of the iPhone 3.0 in mid-2009. Prior to the iPhone 3, no streaming protocols were supported natively on the iPhone, leaving developers to wonder what Apple had in mind for native streaming support. In May of last year, Apple proposed HLS as a standard to the IETF, and the draft is now in its fourth iteration.

As an adaptive streaming protocol, HLS has several advantages that I’ve enumerated in a previous post. Those advantages include multiple bit rate encoding for different devices, HTTP delivery, and segmented stream chunks suitable for delivery of live streams over widely available HTTP CDN infrastructure.

How HLS works

HLS lets you send streaming video and audio to any supported Apple product, including Macs with a Safari browser. HLS works by segmenting video streams into 10-second chunks; the chunks are stored using a standard MPEG-2 transport stream file format. Optionally, chunks are created using several bit rates, allowing a client to dynamically switch between different bit rates depending on network conditions.

How does a stream get into HLS format? There are three main steps:

1. An input stream is encoded/transcoded. The input can be a satellite feed or any other typical input. The video and audio source is encoded (or transcoded) to an MPEG-2 transport stream container, with H.264 video and AAC audio, which are the codecs Apple devices currently support.




2. Output profiles are created. Typically a single input stream will be transcoded to several output resolutions/bit rates, depending on the types of client devices that the stream is destined for. For example, an input stream of H.264/AAC at 7 Mbps could be transcoded to four different profiles with bit rates of 1.5Mbps, 750K, 500K, and 200K. These would be suitable for devices and network conditions ranging from high-end to low-end, such as an iPad, iPhone 4, iPhone 3, and a low bit rate version for bad network conditions.




3. The streams are segmented. The streams contained within the profiles all need to be segmented and made available for delivery to an origin web server or directly to a client device over HTTP. The software or hardware device that does the segmenting (the segmenter) also creates an index file which is used to keep track of the individual video/audio segments.

Optionally, the segmenter might also encrypt the stream (each individual chunk) and create a key file.

What does the client do?
The client downloads the index file via a URL that identifies the stream. The index file tells the client where to get the stream chunks (each with its own URL). For a given stream, the client then fetches each stream chunk in order. Once the client has enough of the stream downloaded and buffered, it displays it to the user. If encryption is used, the URLs for the decryption keys are also given in the index file.

If multiple profiles (that is, bit rates and resolutions) are available, the index file is different in that it contains a specially tagged list of variant index files for the different stream profiles. In that case, the client downloads the primary index file first, and then downloads the index file for the bit rate it wants to play back. The bit rates and resolutions of the variant streams are specified in the main index file, but precise handling of the variants offered is left up to the client implementation.

Typical playback latency for HLS is around 30 seconds. This is caused by the size of the chunks (10 seconds) and the need for the client to buffer a number of chunks before it starts displaying the video.

An odd curiosity about HLS is that it doesn’t make use of Apple’s Quicktime MOV file format, which is the basis for the ISO MPEG file format. Apple thought that the TS format was more widely used and better understood by the broadcasters who would ultimately use HLS, and so they focused on the MPEG-2 TS format. Ironically, Microsoft’s Smooth Streaming protocol does make use of ISO MPEG files (MPEG-4 Part 12).

For more information on how HLS works, good resources include Apple’s Live Streaming overview documentation and the IETF standard draft itself.

For a decade, streaming live video to a mobile device was hard to do. Bandwidth issues, firewalls and network infrastructure support all created problems. Streaming protocols weren’t firewall friendly. HTTP progressive download was invented partially to get past firewalls but didn’t offer true streaming capabilities. Now, the advent of adaptive streaming over HTTP has changed everything and is reshaping video delivery to mobile devices as well as devices such as IP set-top boxes (STBs).

There is a battle taking place over the adaptive streaming technology to reach those mobile devices. The three main adaptive streaming contenders are all industry heavyweights: Apple, Microsoft and Adobe. Last year Microsoft released its version of adaptive streaming called Smooth Streaming, part of its Silverlight web application framework. Shortly thereafter Apple introduced HTTP Live Streaming (HLS) as a proposed IETF standard and the draft is now on its fourth iteration. Not to be outdone, in late 2009 Adobe announced it too would play in the adaptive HTTP streaming space, with project Zeri. Aside from these three main contenders, 3GPP is standardizing its own version of HTTP streaming, and MPEG is also entering the fray.

What is the big deal with adaptive streaming?

Adaptive streaming does two main things for video that make it such a good choice for mobile delivery.

1. Adaptive streaming segments video into small chunks. For example HLS usually uses 10 second chunks.
2. The video is encoded at multiple bitrates and resolutions creating chunks of different sizes. This is the ‘adaptive’ part of adaptive streaming, as the mobile client can choose between different bitrates/resolutions and adapt to larger or smaller chunks automatically as network conditions change.

These two key features of adaptive streaming provide several benefits:

1. Video chunks can be cached by proxies and easily distributed to CDNs or HTTP servers, which are simpler and cheaper than the special streaming servers required for ‘older’ video streaming technologies.
2. Bitrate switching allows clients to dynamically adapt to network conditions.
3. Eliminates the guesswork for content providers on what bitrates to encode for end devices.
4. Works great with firewalls since the stream is sent over HTTP.
5. Live and VoD workflows are almost identical. When a provider creates a live stream, the chunks can be kept for later VoD delivery.

Who will win the adaptive streaming battle? I’m looking for the person that can answer that for me. Leave a comment on this post with a compelling argument of who you think that will be and I’ll send you a free RGB Networks shirt.

I’ll be covering each specific adaptive streaming protocol in more detail in a later post. Stay tuned.

ABI Research released their latest report on mobile TV, forecasting accelerated worldwide adoption in 2012 and predicting up to $20 billion in revenues by 2015.

Many believe the last hurdle for cable operators and other service providers to provide live TV on mobile devices is the real-time transcoding of programming from the bandwidth-hefty MPEG-2 into the bandwidth-thrifty MPEG-4/ H.264, but this isn’t entirely the case.

Service providers are quickly learning that transcoding isn’t the hardest part of mobile video—it’s the integration and management of all the equipment to perform the variety of necessary video processing functions. While it’s certainly possible to cobble together transcoders, ad splicers, etc. into a viable solution, the cost and complexity of managing these devices is a tremendous headache, and reliability becomes a significant factor.

To address this obstacle, RGB has developed the Video Multiprocessing Gateway (VMG) as an “all in one” solution multi-screen video using a single management system. Rather than assemble multiple independent “pizza box” transcoders, ad inserters, etc., service providers can take advantage of the chassis-based VMG and its family of flexible modules, each devoted to a specific application, such as transcoding. Service providers can populate a multi-function VMG with any mix of modules for transcoding, ad insertion, etc. they require and easily manage everything with a single user interface. This modular system also allows for easy, license-based upgrades, while the carrier-class platform ensures superior reliability. The VMG is currently involved in several multi-screen video trials and the feedback is both positive and helpful in further refining the VMG to make it the ideal solution for mobile TV.

As we approach accelerated adoption in 2012, be sure not to count out 2011. Subscribers’ appetite for mobile video may likely accelerate faster as the popularity of mobile devices, such as the iPad and iPhone, continue to proliferate. The key to ensuring that service providers can scale their limited trials into a ubiquitous service are innovative new products like the VMG that take video processing to a new level.

RGB Networks has made an exciting move today, acquiring RipCode, Inc., a provider of solutions for mobile IP video. With the addition of RipCode’s mobile delivery capabilities to RGB’s carrier-class Video Multiprocessing Gateway (VMG), RGB can now offer a very unique solution to all operators migrating to a three screen video environment.

As service providers navigate the complexities of delivering video to TVs, PCs and mobile devices over a single, converged network, we believe the unmatched simplicity, reliability and scalability offered by RGB’s integrated chassis solution will quickly set a new standard for multi-screen delivery.

We invite you to visit our website for more details on the acquisition and our new three screen offering.