April 6, 2016
By Jan Ozer Contributing Editor
Featured Articles

How to Encode and Deliver to Multiple ABR Formats

I recently hosted a poll on my Streaming Learning Center blog asking whether DASH or HLS was the best adaptive bitrate technology for deployment today. I added an option for comments, and I’m glad I did, because several were quite insightful, including one respondent who wrote: “It’s not a selection question, you need to use both for complete coverage.”

That’s not completely true, of course; many producers are using HLS, or DASH—either singly or in concert with other technologies—to deliver content to viewers on computers and mobile devices. But the key point is this: Most streaming producers must deploy multiple adaptive bitrate (ABR) formats to reach their target viewers, either now or in the near term. This puts a premium on producing multiple ABR packages as efficiently and economically as possible.

How to produce multiple ABR packages for live streaming is the subject of a different how-to article. Therefore, this article focuses primarily on video on demand (VOD); specifically, I’ll look at the most efficient way to encode and deliver multiple ABR formats to different target platforms.

Definitions

Like all things streaming, it helps to learn the lingo before diving into the technology behind it. Let’s explore this briefly using Figure 1, a diagram adapted from a Microsoft Azure technical note on Dynamic Packaging. We’re dealing with VOD content here, so the video starts life as a single mezzanine file, all the way on the left.

Traditional encoding, packaging, and delivery workflow

The traditional encoding, packaging, and delivery workflow

This mezzanine file is transcoded into multiple-bitrate MP4 streams that make up the adaptive group. These files are then packaged (or transmuxed) into the combination of chunked or segmented video files and accompanying metadata files required for all HTTP-based ABR formats. The ABR packages are sent to one or more origin servers, which distribute HLS (HTTP Live Streaming) assets to iOS and Android devices, and DASH (Dynamic Adaptive Streaming via HTTP) to Microsoft Edge, the Windows 10 browser, and Google Chrome.

Figure 1 also illustrates what’s often referred to as static delivery. That is, the ABR packages are created and stored at the origin server for distribution to the various viewers. In the context of distributing multiple ABR packages, this static schema has several disadvantages. First, when you decide to support an additional ABR format, you must create new packages for your entire library and upload them to your origin servers, which is time-consuming, potentially expensive, or both. For example, though packaging is a very lightweight step, most cloud encoding providers charge full price for the additional outputs, so you’ll pay full price for MP4 files, and then full price again for HLS and DASH output. Zencoder is an exception, charging only 25 percent the normal price for transcoding MP4 files to HLS output, a discount that it doesn’t extend to DASH.

Second, online storage costs will increase with each additional ABR format you support. Both disadvantages are resolved by a technique called dynamic packaging.

Dynamic Packaging

Dynamic packaging workflows begin the same way as static workflows, with the mezzanine file converted into multiple-bitrate MP4 assets. Those files are then uploaded to a streaming server where a separate program or process dynamically converts the MP4 files into the ABR formatting required by the requesting device. For an example, see Figure 2, which is adapted from an Azure technical note. If an iOS or Android device requests the video, HLS-packaged video will be sent. If a Microsoft Edge or Google Chrome client requests the video, DASH will be sent. Depending on the program driving the conversion, it might be able to produce other ABR packaging, such as the Smooth Streaming content sent to the Xbox. Not surprisingly, this is a feature that Azure supports.

Dynamic streaming sends MP4 files to origin server

Dynamic streaming sends the MP4 files to the origin server, where they are dynamically packaged for the requesting client.

For users supporting multiple ABR formats, the advantages are obvious. You can enable support for a new format by changing a few lines of code on the server or in the player, and doing so won’t increase your storage load and the associated costs. The obvious negatives are the cost of the software that performs the packaging (if any, since there are multiple open source options), and the CPU use necessary to perform the transcoding, though this may be lower than you think.

To explain, packaging is a very lightweight function on a CPU, since it doesn’t involve true transcoding. Rather, packaging merely converts the container format of the file and creates any necessary manifest files. In deployment examples on its website, Wowza claims that a single Amazon Cloud C3.8XLarge instance, which would rent for as little as $8,300 per year (for a 3-year commitment), combined with the Wowza Streaming Engine ($65 per month) could distribute video to up to 1,400 simultaneous viewers. While your mileage will certainly vary, these numbers are smaller than the cost of transcoding even a modest-sized content library into a new ABR format, without the storage and administrative costs associated with a static ABR group.

Beyond Wowza, there are multiple products or services that provide the same function. For example, Elemental Delta is a product that can be installed as an appliance, as a VM routine, or accessed via the Elemental Cloud, while the open source NGINX-based MP4 Repackager is available from Kaltura. Service providers who perform these functions include all the usual suspects: Akamai, Limelight, Microsoft Azure, and others.

How do you choose a provider? Assume that all will perform the basic packaging function well, though efficiency will vary by product and service provider. The major differentiation will come in the finer points—captioning, digital rights management (DRM), and advertising insertion—so check these aspects first. For example, while Kaltura might be ideal for many users, it doesn’t support DRM.

Format support is key, and DASH support isn’t yet universal among all streaming servers available on the cloud. Of course, pricing will also be key, and because of the disparate business models deployed by the product and service providers, it’s important to budget lots of spreadsheet time to compute apples-to-apples comparisons.

Live Cloud Transcoding

What about live transcoding and packaging? This is every video producer’s dream; you upload and store one high quality mezzanine file to the web, then transcode to the required stream and package as necessary for each viewer request. While multiple services tout this capability, it’s very CPU-intensive, so transcoding costs will certainly eat into any storage-related savings.

In addition, Akamai, one of the early advocates of this approach, has recently reversed course, finding that the latency involved, particularly in transcoding and packaging 4K files with DRM, captioning, and advertising insertion points, can be significant. While this is a trend worth watching, it may be 2–3 years out for widespread commercial usage.

Static Packaging

The opposite of dynamic packaging is static packaging, where you output the required ABR-packaged files and upload them to the origin server for distribution. If you’re only supporting HLS now, and not DASH, it’s key to recognize that you’ll be producing DASH output in the near term and to plan ahead so you can reduce that encoding expense.

Specifically, make sure that you’re not encoding to HLS in a single step; rather, make sure that your encoder is producing the MP4 files first, saving them, and then producing the HLS output as a separate step. That way, when it’s time to produce the DASH files, your encoding tool can work from the previously encoded MP4 files, and not start from scratch with the mezzanine files.