The impact of Adaptive Bit Rate Streaming: A primer

This paper is part of a three-part series that looks at what adaptive bit rate streaming is and its potential as a disruptive technology Adaptive rate streaming is a breakthrough approach that enables a video’s bit-rate to adapt dynamically to resources available in the network and on playback devices. The goal of dynamic adaption is to provide a smooth presentation of media and a “TVlike” consumer friendly experience even when bandwidth availability is unmanaged.

Appearing commercially in 2007, this approach was first deployed on a mass scale during the 2008 Summer Olympics. Unlike previous unsuccessful attempts adapt a video stream’s bandwidth to available network conditions, it takes advantage of existing Internet infrastructure.

This is a key enabling technology for over-the-top (OTT) video, which will profoundly impact content distribution even in walled garden environments. With improved media  resentation comes greater consumer enthusiasm, and enhanced prospects for commercialisation. Monetised services can, therefore, be enabled for more devices, from high-end 3D TVs at home to mobile phones over varied network conditions. We will often use the term Apple has submitted for standardising adaptive rate streaming, an architecture known as HTTP Live Streaming (HLS).

We start with a description that is as non-technical as possible, covering the key stakeholders that include Apple, Microsoft and Adobe with a few deployment examples. We then dive  into the technology to explain what technical tradeoffs are required when deploying this technology today. The third main section covers gamechanging business issues from the perspective of different operators and vendors. Before wrapping up, we further explain what the main issues are and take a peek into the future of adaptive rate streaming technologies.

Adaptive Rate Streaming

So how does adaptive rate streaming work? Imagine a movie as a puzzle broken into 1,000 pieces. You’re at home and the puzzle is in the store. Each piece of the puzzle exists in a high-resolution version, but there are also smaller and simpler versions that have lower resolutions and are lighter and quicker to sort and move around. If you buy the puzzle online, each piece needs to get to your house for you to build the whole picture. If you go ahead and buy, you first get a plan (the playlist), then pieces themselves start arriving immediately for you to start assembling and having fun. Every piece can be downloaded at its own pace. So if you have a good connection, you can ask for, and get, bigger pieces arriving at the same rate you are putting the puzzle together. Those parts of the puzzle will be of dazzling quality.

If the Internet is not working well for part of the time, you will get lower resolution pieces during that period. But as long as the Internet connection is there at all, you won’t be stalled waiting for pieces to arrive, and all parts of the puzzle will still look fine even if some are a little less glossy and high-resolution than others. What is certain is that you’ll get your whole puzzle with no interruption to your enjoyment, on the TV, the tablet or the phone, complete in as good a quality as is possible. Before this technology was invented, you’d either had gaps in an otherwise uniform puzzle, or had to wait for the whole puzzle to be delivered before you started to play.

Adaptive rate streaming is a relatively new technology for delivering video to a variety of user devices. The video resolution varies depending on the resources available from the network and the device on which it is played back, but as long as there are at least minimal resources, the show will go on IPTV, which uses dedicated networks, this is often called Internet TV or Over-The-Top TV (OTT). Among its many advantages, adaptive rate streaming offers rapid channel changes and fast start-up, as a low bit-rate can often be used for the first video frames displayed. Once the video starts decoding, the device can move up to the highest supportable bit-rate and quickly improve the displayed resolution. Smoothly changing the resolution or compression rate of displayed video will typically go unnoticed by consumers, in contrast to obvious frustration with slow startup or stalled playback during re-buffering.

Streaming vs. Broadcast & Multicast vs. Unicast

Streaming occurs between a server and a client device both connected to the same network. At the end of the 1990s, it promised to make the Web a more interesting place where static pages were enhanced with sound and video. A few years ago, the processing power available in mobile devices was too low to support high resolution decoding and the management of multiple streams. In traditional streaming the server keeps track of what a client is doing; in HLS and other adaptive models the client manages the relationship. In any kind of streaming, there is a connection between the server and the device.

For broadcast, one typically refers to a transmitter rather than a server. There is not necessarily any kind of physical or logical connection between a transmitter and the receiving devices, so broadcasting a signal takes the same resources whether there is one person watching or several million. When sending a TV show in a stream to a single user, typically in an on-demand use case, the stream is called unicast. But when several viewers are watching the same stream at the same time, multicast streaming can be used to optimise network usage. Telcos think of this rather like broadcasting within their controlled network. If several ADSL users connected to the same telephone exchange are watching the same live broadcast, then that exchange only requests one stream from the headend server and copies it to each of the viewers.

Multicasting in today’s IPTV deployments is complex; it requires special infrastructure and bandwidth management in the network, which are not easy to duplicate in the multihop connections of the Internet.

The Move to HTTP Unleashed the Beast Early PC implementations of adaptive rate streaming were unsuccessful because they relied on specialised protocols, like Real-Time Streaming Protocol (RTSP). They could, therefore, not use equipment designed to optimise ordinary Web traffic that used the more standard HTTP protocol. As the H part of the acronym suggests, HLS uses the Internet’s basic HTTP protocol.

It seems counter-intuitive that a protocol dating from the very beginning of the Internet, originally designed to transport small text files, should end up being the enabling technology for mass deployment of video delivery. One key reason for this is that sophisticated CDNs from the likes of Akamai can be used without much adaptation at all. Even a cheap stand-alone HTTP web cache helps deliver HLS. Velocix supplies service providers with infrastructure to build their own CDN.

Paul Larbey, the company’s CEO, stated that HLS simplifies deployment and typically reduces cost by 30%. Velocix infrastructure is currently used by Verizon to deliver “HBO Go” and by Talk Talk to prepare or YouView delivery. Velocix further found that the nature of adaptive streaming makes CDNs even more appropriate for streaming to mobile device with a better quality of experience. By using the existing infrastructure, HLS creates a mechanism akin to a “multicast” architecture for very low cost. Video content divided into small files is cached at various points in the network and saved for a short time. Another viewer can request the same content directly from the cache if it’s still there. There’s no need to travel any further up the network to the headend. By avoiding a silo architecture, HTTP live streaming is also a good enabler of TV Everywhere.

The HTTP protocol is about moving files around, not streams. The technical description below explains how video streams are converted into “chunks” that are nothing other than files. A valuable benefit that comes with using the HTTP protocol is that it carries traffic seamlessly through all parts of the network, including the home and through firewalls and other security mechanisms. It uses the standard “port number” (80) of all ordinary web traffic, whereas other protocols use specific ports (554 or 7070 for TCP and 6790 and higher for UDP) that are often blocked.

A New Client Server Architecture, with an Active Client Broadcast existed long before streaming, so it was only natural for streaming video to mimic its predecessor. The server originally had more resources to control the streaming than the client. In IPTV, videoplaying software on thin client architectures typically joins or leaves an existing stream that runs at a fixed constant bit-rate. Until recently, streaming on the Internet has mainly used RTSP, which is a stateful protocol developed by Real Networks and Netscape in the 1990s. That means that the server keeps track of the client’s state at all times and tries to help optimize delivery and deal with errors in real-time.

HLS is a stateless protocol. This means the software running in the end device completely takes over the setting up and optimising of video, wholly from the point of view of optimizing the consumers’ experience, while the headend server is dedicated to creation and management of a  fixed range of chunked video sources. Encoding and preparing the video chunks takes place with no reference to the streams that are actually being consumed, so no client state is required or maintained. Like everything else at the video headend, the encoding process has to be set up for the type of service being offered. This includes appropriate mechanisms to encrypt copyrighted video and manage the delivery of keys to authenticated users.

Written by Benjamin Schwarz, Owner, CTO Innovation Consulting. Jointly produced by Harmonic Inc. and Verimatrix