Is adaptive bit rate the yellow brick road, or fool's gold for HD streaming?


By Pete Mastin

Pete MastinThe world seems to have gone nuts for adaptive bit rate (ABR)/HTTP streaming as the obvious solution for High Definition (HD) Internet streaming. However, if the goal is HD, then perhaps we need to consider whether there are other, perhaps better, approaches. At the very least, it makes sense at this point in time to ponder some of the drawbacks of the ABR/HTTP method for HD streaming.

But first a note on what is meant by HD streaming--since that definition seems to be so nebulous in the industry. Traditionally, HD is anything higher resolution than Standard Definition (SD), which is 480 lines. While there are set standards in TV broadcasting, Internet HD is defined more by marketing than by resolution. An argument could be made that SD on the Internet was 320X240, a very popular delivery resolution on the Internet for many years. In the most general terms, most folks would agree that HD on the Internet is a stream with a high-quality visual appearance, a 16X9 aspect ratio and a resolution of at least 852X480. A better standard to work from would be the lowest resolution of broadcast HD, 1280X720.

The problem that ABR/HTTP streaming set out to solve was to provide a good experience for both high-end and low-end Internet connections with little buffering and a fast "first frame" delivery. But, there are always many drivers behind technology selection in general, so it's probably helpful to point out the industry's motivations in adopting ABR. The ecosystem in question is made up of at least two main players: content delivery networks (CDNs) and encoder companies.

CDN companies prefer ABR/HTTP because it maximizes the use of HTTP networks so that the CDN does not incur more cost, as it does with other technologies, such as Adobe Flash or Microsoft Silverlight. HTTP delivery networks are typically the least expensive part of the CDN architecture. CDN players also have a vested interest in this delivery mechanism since it often uses their own customized reverse proxy servers and doesn't require them to buy additional equipment. To net it out, CDN companies don't have to pay for a software license or revenue share for bits streamed over HTTP as they would with other proprietary streaming technologies. Thus, they are happy with this direction.

The CDN industry also likes ABR because it creates more storage per asset. For example, if you have a long-form piece of content that you want to stream, ‘best practices' suggest that you parse it into as few as five files, and as many as nine files, for distribution. These files have to be stored, and this, of course, costs money.

ABR works by detecting a user's bandwidth and CPU capacity in real time and adjusting the quality of a video stream accordingly. Since ABR requires the use of encoders that separate the files into "chunks," it requires the encoder companies to provide new high-end encoders that can perform this function. So, the encoder companies that got to market first with this "chunking" technology are doing well (more power to them by the way--I AM a capitalist).

However, there is a major, looming issue bogging down live HD streaming as a whole: moving the feed. This includes feed to the Internet, worldwide distribution and ultimately through the "last mile" to the end user. Let's break down the live streaming scenario for a better understanding of what this issue looks like at each stage.

Signal Acquisition. For true HD, every step in the process has to be, well ... HD. In other words, the video camera, the connections and the encoder all have to support HD. If the quality drops anywhere along the chain, the overall value of the streaming HD asset is compromised. When a producer is streaming a live event, they have to make sure that the connection to the ingress (or gateway) points will support HD. But how can they do that? Practically speaking, the TCP Internet does provide that type of guaranteed delivery. In a perfect HD world, I just have to know that I have a connection. The software should take care of getting the stream out to the distribution channel.

Encoding. ABR/HTTP encoding is more complex than encoding a single bit rate. It requires that producers think through the number of streaming files that will be generated given the various other parameters (frame-rate, aspect ratio, etc). For a first-time or even a more experienced producer of a live event, this could be extremely overwhelming. In an ideal HD scenario, none of this would matter, and it would not be necessary to determine how many files to generate and what their bit rate needs to be.

Distribution. There are also many issues here. An organization may be streaming out a live HD event, but who's watching it? The breadth of Internet-connected devices is larger (and will remain larger) than even the largest CDN. It is unlikely that any CDN will ever have caching and streaming servers in the most remote places. Furthermore, my specific CDN account may not have been set up to align with the regions that my current viewers are in. So, even if the CDN has coverage in Venezuela, for example, my account may not have access to that region. From the perspective of the user, they won't want to--and ultimately probably won't--figure all of this out in advance. The ideal HD network would deliver HD bits to any region of the world, and it would use off-net delivery if it had to. It would overcome distribution shortcomings by being smarter than the Internet's TCP limitations.

The "Last Mile." This is an Internet cliché, and ABR exists because of it. It has been around as a problem since the inception of the Internet, but the attempt of CDNs to emulate broadcast networks over the Web has made it a star. A faultless HD solution would obviously need to overcome this. But there are better ways than ABR. ABR is a compromise.

So far, the question of whether ABR is the best way to deliver streaming HD hasn't been hotly debated, but it should be. Rather, the current question seems to be, "What is the best way to deliver the most bits to consumers while approximating HD?" Let's consider how one might design an HD CDN in an ideal situation:

  • Simple encoding and streaming from live venues of the HD stream. This would be a single HD stream and would have guaranteed flawless delivery to a primary and backup ingress point; 
  • Worldwide distribution of the HD stream. This distribution would not be limited to places the CDN has coverage in. Furthermore, it should work flawlessly within the enterprise as well as the broader Internet. This distribution would not confine itself to bit delivery from a CDN or paid network;
  • Technology that overcomes the "last mile" issue; and 
  • Cost effective.

Again, this is a "perfect world" scenario. We are certainly making strides and technology will continue to evolve. However, I am not quite convinced that we are building the right bridge for the answer to streaming HD with ABR. I think we can do better.

Pete Mastin is the senior director of CDN Engineering at Internap