Delivering Profitable Multi-screen: What You Need to Know About Manifest Manipulation

Wed, 08/13/2014 - 12:17am
Duncan Potter, product and regional marketing, Arris

How are service providers solving the challenge of making multiscreen profitable?

It is a big question, and for an increasing number of providers, the answer is manifest manipulation. This is a solution that enables them to better control, scale and monetize pay TV on multiple screens, particularly when it comes to targeted ad insertion and content substitution.

That said, manifest manipulation is not a silver bullet, and there are different approaches and deployment models available. In order to select the solution that is right for your organization, it is essential to first get all the facts about manifest manipulation so you can ask the right questions.

What are we talking about?

To meet the subscriber demand for multi-screen and deliver video to any device across any network, operators use adaptive bit rate (ABR) protocols in their multi-screen implementations, such as Apple HLS, Microsoft Smooth, Adobe HDS and mpegDASH. The different video formats deliver two main elements:

• Fragments: these are the actual “chunks” of video content.

• The manifest, sometimes referred to as “the playlist”— instructs the player to retrieve the next fragment by providing information about the next playable video fragments available and their location.

It is a text-based or XML file with specific variants depending on format.

Manifest manipulation is a simple concept.

By changing the “playlist,” one or multiple goals can be achieved, such as: • Inserting ads • Inserting alternate content for blackouts • Limiting or expanding the number of bit rates available • Setting initial bit rates • Specific authentication requirements As with most technology, it is never quite as simple as it appears. For a variety of reasons, most protocols do not take kindly to having the manifest rewritten.

This has left some service providers in a difficult spot as it means that experiments or trials with one protocol and one device type (typically Apple HLS with iPad as the device) may not cleanly extend to other HLS-supported devices, such as Android, or to other protocols, such as Microsoft Smooth or mpegDASH.

Therefore, it is extremely important that operators thinking of using this approach understand the implications of managing and “manipulating” the manifest, and deploy technology that has been proven to achieve that goal. The result of a wrong choice is often that the required process will just not work or the user experience will be completely unacceptable.

Different Approaches to Manifest Manipulation

While there are many different approaches to manifest manipulation, in general they can be divided into three primary types.

Manifest “Conditioning”

Taking place early in the video delivery workflow, and primarily done by the encoder, manifest conditioning means inserting the Event Signaling and Messaging (ESAM) or other markers in the manifest. The encoder works in conjunction with a Placement Opportunity Information Service (POIS) or blackout management system (typically using SCTE 35 standardization protocol) to determine when ad or blackout markers should be inserted into the stream.

Benefits: No additional software or hardware is required, as the encoder accomplishes the task.

Limitations: As manifest conditioning is normally done by the encoder, it is limited to those decisions that can only be made early on, such as zone-based ad delivery. It is highly limited in its flexibility and only works where defined zones have been pre-agreed upon.

Manifest Builder or “Playlist Re-writing”

Another approach is to create the required manifests upfront, post encoding, based on where, to whom and to what device they will be delivered. This process makes sense in environments where a smaller number of different manifests may be needed, such as where only a few ad zones are identified.

Benefits: As the parameters for re-writing are usually well-defined in advance, there is little room for error. In addition, testing can be done prior to a live delivery environment.

Limitations: This method is extremely limited in its flexibility, particularly where protocols such as Microsoft Smooth are required, because of the need to create the appropriate content along with the manifest. It is also limited by the inability to have a large number of variants (targeted ad insertion and/or blackout).

Dynamic Manifest Manipulation (DMM)

DMM is the process of creating custom manifests per content, device or session, in real-time, in response to a device request.

Compared to manifest conditioning or re-writing, DMM is done much later in the video delivery workflow.

Benefits: DMM enables highly scalable, targeted ad insertion or alternate content placement. Creating a virtual session with the end-user device, DMM also enables a long list of real-time control features.

DMM can customize generic manifests provided from the encoder/packager and retrieved from an origin based on a number of factors: user demographics, subscribed services, service tiers, access network, devices, etc. It can support both live and on-demand content. There are a number of other key benefits of creating the manifest in real-time such as:

• Request based ad insertion / blackouts

• Policy enforcement by user, service, network and device

• Network-based ad placement notification

• Ad/blackout DMA aggregation

• Support for absolute URLs

Limitations: To enjoy the full feature- set and benefits above, dynamic manifest manipulation has to be accomplished late in the delivery process, generally at the edge.

Manifest Manipulation Constraints

There are multiple challenges associated with using manifest manipulation alone to insert ads or provide alternate content (blackouts). The primary problem is one of discontinuity, i.e., the problem that occurs when audio and video fragments are different, for example due to the sampling rate. While some implementations of HLS can tolerate discontinuity, such as those on the iPad or iPhone, many others, such as those on current Android devices as well as ISOBMFF protocols such as Microsoft Smooth, are not able to handle this problem. As manifest manipulation alone does not touch the fragment size/ duration, it cannot correct this problem on the fly.

A second major issue is that certain clients, including specific Android implementations of HLS and most Smooth Streaming clients, only request the manifest once at the start of session to initialize the request template and get decoder initialization parameters for each bit rate.

This requires that ad content must be encoded the same as the asset (bit rate, resolution, etc.).

Similarly, the Smooth Streaming protocol creates another challenge by defining a template in the manifest on which all future requests are based. This prevents a client from requesting ad segments from a different source, requiring the provider to store all assets in the same location.

Overcoming the Limitations of Manifest Manipulation

Multiple approaches have been proposed to overcome these limitations. The first is to use manifest re-writing (see above) to “pre-create” the customized manifest and all associated content, or to use a “just in time” approach at the headend packager.

This approach works reasonably well for small numbers of profiles or zones.

However, it can dramatically increase both the amount of storage (at the origin and caches) and network load because it is effectively producing a customized stream for each profile or zone all the way from the head end.

The alternative approach is to distribute the DMM function to the edge of the network, typically co-resident with an edge cache. In this case, both the manifest and the fragment duration are manipulated dynamically, overcoming the challenge of discontinuity and ensuring playback on all devices.

The benefits of managing each session in real time are dramatic. For example, DRM and/or watermarking can be applied per stream. By providing a stream only when requested by the client, in some cases operators can achieve up to 60 percent savings in storage and network bandwidth.

Deployment Models

The manifest can be altered at any number of different stages in the video delivery workflow, making multiple deployment models possible. The optimal architecture depends on the goals of the service provider. For instance, if blackout areas and ad delivery zones are well defined, an encoder (inserting ad markers) placed in the network core should be able to satisfy these needs.

However, eventually the needs of most service providers will outgrow these requirements, and they will be looking to harness the potential revenue lift from real-time, targeted ad delivery. There are two primary models to handle these needs: on and off network.

On-network DMM deployments are designed to handle the discontinuity challenges detailed above, as they sit at the edge, working in conjunction with the cache and in line with fragment delivery.

In addition to manipulating the manifest dynamically, on-network DMM can also adjust fragment duration on the fly, which enables better synchronization between audio and video.

The key challenge here is to achieve scale. While a manifest re-writer scales well, it has none of the benefits of user- based targeting and personalization.

Scale is possible with dynamic manipulation through a combination of highly-efficient software that can handle thousands of simultaneous requests and intelligent cluster management. In fact, the cost reduction benefits gained from serving only those streams that are requested will typically far exceed the total cost of DMM implementation, while providing the revenue-enhancing benefits of targeted and personalized video delivery.

Off-network deployments that are not at the edge do not touch the data plane and can be situated in a number of places, including the operator’s network. This deployment model is suitable for service providers partnered with a commercial CDN.

While off-network deployments are able to affect the primary goal of real-time blackout and ad insertion on a per-device basis, they are limited to the type of devices they can support (e.g.

Apple IOS and selected Android-based players) because they cannot deal with discontinuity issues.

To achieve the essential benefits of multiscreen delivery, such as targeted ad insertion, per-session security and policy management, manifest manipulation has emerged as a cornerstone technology. However, while in theory the concept sounds simple, there are many pitfalls that service providers need to be aware of. In the absence of standard approaches in protocols that significantly increase the complexity of ABR delivery, edge-based dynamic manifest manipulation has emerged as the solution with the most promise for service providers. This is because of its unique ability to ensure consistent delivery to all clients, significantly reduce costs and achieve unprecedented levels of control. ■   


Share This Story

You may login with either your assigned username or your e-mail address.
The password field is case sensitive.