Through applications such as Google’s Shaka Player or the DASH-IF JS player, MPEG-DASH allows a single video format to be displayed on any device. It provides support for devices from mobile phones to hybrid broadcast/broadband television (HbbTV). It is a native ABR scheme, ensuring that the best quality is always achieved for a given bandwidth. This article is a section of a detailed white paper on server-side ad insertion recently released by Elemental Technologies.

MPEG-DASH is codec-agnostic. Because HEVC is fully compatible with MPEG-DASH, high performance compression can be used to maximize quality, or can be used as a common platform to deliver 4K Ultra HD. In 2014, IBC honored the Vienna State Opera with a special award for its 4K UHD streaming using HEVC encoding and MPEG-DASH delivery.

MPEG-DASH also hosts common encryption (CENC), an emerging standard that uses the encrypted media extensions (EME) defined in HTML5 to provide the digital rights management (DRM) decryption in the player. This in turn allows a common encrypted file to be delivered by MPEG-DASH, whatever the DRM system used in the player.

Apple’s HLS

However, MPEG-DASH is not the only solution currently available. For Apple hardware and a number of other very popular devices, the rule is to use Apple HLS protocol for ABR streaming.

HLS is a very mature technology and is implemented in a wide range of manufacturers’ devices beyond Apple, even though that in and of itself is a major market. There are third-party players available, such as THEOplayer from OpenTelly or Flowplayer, which do not require any plug-in for HLS playback, making them widely applicable.

On the other hand, HLS is a proprietary technology, developed by Apple and other private companies. It has not changed much since its launch ten years ago and is very stable – or getting outdated, depending on your point of view. As a proprietary standard, it carries some risk of obsolescence.

Contrast that with MPEG-DASH, which is developed by the very long-standing and independent MPEG forum. The MPEG forum continues to develop the standard and will undoubtedly develop new MPEG formats in future. The ubiquity of MPEG formats will almost certainly see DASH support in all browsers, most mobile devices, set-top boxes and smart TVs.

MPEG-DASH can deliver substantially lower end-to-end latency compared to HLS. It also uses a templated manifest that can be cached at the edge, while an HLS manifest is updated routinely and needs to be propagated several times a minute.

More open

The one significant philosophical difference between the two is that MPEG-DASH is open to a range of encryption solutions, whereas HLS only supports its own DRM. To provide heavy duty content protection in HLS means wrapping the streams in another technology that can be interpreted by the receiving device. CENC common encryption technology is the usual solution to this issue.

HLS and MPEG-DASH share much in common, though, in the philosophy of how content is presented through manifests or playlists, and how video content is sliced into small chunks. The architecture and the underlying protocols are what allow server-side ad insertion without recourse to complex proprietary extensions. This therefore allow users to build open infrastructures while retaining the benefits of advanced capabilities.

Finally, to be fully exhaustive, there are other ABR protocols in the field, like Smooth Streaming from Microsoft and HTTP Dynamic Streaming (HDS) from Adobe. These two streaming formats have less flexibility in the way manifests are generated, and while they can also be used for server-side ad insertion with static ad replacement, it is much more complex to deal with personalized server-side ad insertion.

Client-side ad insertion

High-value streaming video content can attract large volumes of viewers, and responding effectively to peaks in demand is essential. It requires the ability to scale video delivery seamlessly while maintaining performance and the best quality of service.

Sporting events, for example, can create enormous demand. During the 2014 FIFA World Cup in Brazil, as many as three million consumers a day worldwide used online video services provided by the host broadcaster. Twenty-four million unique users watched tens of millions of hours of content online during the tournament. The peak streaming rate – during the Argentina v. Netherlands game – was 6.9 terabytes per second.

The advantage of client-side advertising is that program content can be encoded and packaged in all the different formats, in advance. When a request comes from a consumer, all that happens is that the appropriate file is played out from a server.

Server-side ad insertion

Server-side advertising depends fundamentally upon just-in-time packaging; the content is stored in some suitable high-quality delivery format and packaged for delivery at the time it is requested. This has other benefits for the operator, including reduction of storage and bandwidth costs by delivering content best suited to network conditions, and the target device, at the moment of delivery.

To cope with fluctuations in demand for just-in-time server-side ad insertion, a highly scalable architecture is required. Demand will inherently vary over time, but for broadcasters, there will inevitably be sharp peaks: a breaking news story, or the return of a highly popular television series.

The solution lies in encoding and packaging that can be virtualized for rapid deployment and hosted in a cloud infrastructure for immediate auto-scaling. Dedicated single path hardware encoders and packagers lack flexibility. The only practical solution is to spin up instances of software-based video processing as they are needed.

Further, for dynamic server-side advertising insertion, the best place to prepare the content stream is at the edge, as close as possible to the consumer. This implies a cloud service. In the 2014 World Cup example quoted above, the encoding and packaging used Elemental software hosted on Amazon Web Services. The cloud is required to create millions of individually tailored manifests of content and advertising, even for live streamed events.

That, in turn, demands a flexible architecture to manage requests and determine where best to create output streams. A manifest must be created and manipulated according to the rules and demands of the advertising management provider. Instructions must be delivered to just-in-time encoding and packaging software, wherever it is. Finally, a single contiguous stream is sent to the client.

Lionel Bringuier is Director, Product Management, Video Delivery Solutions for Elemental Technologies, an Amazon Web Services Company.