For most people under the age of 30, sitting down and viewing linear television is something their parents did in ancient history. They certainly don’t watch TV that way. But now, even older demographic viewers are reacting negatively to the standard offering from pay-tv providers.

Research indicates that the high cost of cable and satellite packages (over 60 percent of subscribers pay more than $100 per month for their triple-play contract), together with the large amount of unwanted material that these packages include (the hundreds of channels that nobody watches) are pushing viewers to look for something they can tailor to their own requirements.

Around 20% of pay-tv subscribers in the US terminated their contracts in 2015, and with figures like that, it’s not surprising that streaming and OTT delivery is now centre stage in the planning of most media organisations. And this dramatic change in viewing preferences means that there’s much more demand for providers to deliver a service that matches the quality expectations people have for their mainstream entertainment. Once streaming services are the main item rather than an additional freebie, quality problems are no longer tolerated.

The challenge for OTT

Let’s look at some of the pitfalls to be avoided – some of the things that, if done without care and attention may create bottlenecks and inefficiencies that make it difficult to achieve the quality levels providers should be aiming for.

First, there’s the question of standards and how providers deal with multiple technologies used in the viewers’ devices . The different devices started to support the latest standards - like MPEG-DASH. Everything is evolving around DASH these days - it is the new standard that everybody wants to implement.

It covers everything - the providers can encode and serve one format for all devices.

Before, they had to create specific solutions for each device. For example, Smooth Streaming for Silverlight clients, Flash Streaming for Flash Clients. This required the creation of multiple formats in the back-end stage in order to support all these different devices - Flash Video and Smooth Streaming.

Today, they are using MPEG Dash. Other solutions include HLS (HTTP Live Streaming) and Flash Videos, all this makes for much more work.

With the era of proprietary technologies like Flash coming to an end, but no dominant standard yet established to replace them (perhaps it will be MPEG-DASH, but it’s too early to tell), the question of encoding is important. How can providers construct a workflow that gives maximum efficiency and the flexibility to serve customers on a variety of platforms? 

Choosing a codec

At the ingest stage, it makes sense to encode content into a non-proprietary open format such as MP4. With the files held in MP4 format, they can be reused without further processing for a wide variety of purposes.

The video component of MP4 is compressed in H264, and the audio in AAC. Both of these standards have been around for years and have matured in efficiency and quality. Megabyte per megabyte, file sizes now are around fifty percent smaller than they were five or ten years ago, and this has been achieved by improvements in the encoders, without compromising compatibility.

A provider’s choice of codec is usually based on a number of criteria, but one of the uppermost considerations is the decision between on-site infrastructure and a cloud-based service. The advantage of a cloud-based approach, Amazon Elastic for example, is that it can instantly scale up to cope with peaks of demand, without needing dedicated machines set up on site. 

This represents the process of different transcoder pipelines. Each transcoder pipeline has one input bucket, where video source files are placed, and one output bucket for transcoder output files. Each transcoding pipeline can queue several thousand transcoder jobs and process at least 20 transcoder jobs simultaneously.

This is an important advantage both for a new service, where up-front investment carries a risk, and for established services with rapidly growing subscriber base and content in high demand. However, there can be a trade off in features, and that’s why we support both Elastic and other codecs. The downside of the on-site approach is that it requires dedicated machines to do the transcoding and there is no automated scaling to meet fluctuations in demand.

Focus on workflow and DRM

The workflow should also be planned carefully not only for streaming, but for content download. In many parts of the world the internet connections are not good enough to watch streaming media so downloading content to watch later is an important alternative. For this, providers need to use encryption and licences that work for offline consumption, and here again there are choices to make.

An increasingly popular option is the MARLIN open source encryption system, which avoids the cost of proprietary systems like Playready and Wildvine. There’s no standardisation here, even within a standard format like MPEG-DASH. This means the choice of DRM is dictated by the player the content is viewed on. MPEG-DASH viewed in Internet Explorer has to have DRM with Playready; with Chrome it’s Wildvine, and with Firefox it’s Adobe Access…and so on. For this reason, the selected service platform provider needs to support all varieties of DRM.

MP4 files must also be encrypted and prepared specially for offline consumption. Versions of the files at different bitrates are necessary to cater for varying bandwidth, and the choice of version to download is usually made by the player but with some services such as Iflix, viewers can choose what quality they download. Unlike streaming media, the quality will not change dynamically during a download.

Avoiding server bottlenecks

A rapidly increasing subscriber base and peaks in demand for popular content can cause bottlenecks at the origin server. It is common practice to create the different output streams dynamically. Unfortunately this doesn’t scale well to cope with peak demand. That is why service providers use CDNs (Content Delivery Networks) to cache streams in front of subscribers (for example, Akamai), to be able to scale.

A better approach uses pre-fragmentation, where all the media fragments are harvested from the origin server and stored in the cloud. This avoids relying on the dynamic creation of files when content is demanded. Instead, all the files, in all the formats and bitrates required, are already prepared and ready to be consumed by the end user. The processing has already been done and the origin server doesn’t have to do any dynamic work in response to demand. The downside of this approach is that we have to produce all formats in all bitrates. This requires more disk space, which triggers higher costs. 

A good solution is to use the same technology to pre-warm CDNs with content ready-cached to meet peaks in demand when popular episodes are released. (Pre-warm means to fetch the content or draw the content into the CDN cache so that it is quickly available to the customer.)

This way, the CDN will not get burst traffic going back to the origin server. The needed content will have already been sent to the CDN cache. Without this step, the CDN would not be able to reliably serve customers, which could result in the viewer getting a lower quality stream or experiencing a lot of buffering.

These and other improvements to the way streaming and download traffic is handled help premium service providers like Netflix, Hulu Reuters TV, Comcast’s service and Asia’s iflix ensure that their OTT services meet the quality benchmark established by linear television.