If you have been working with video over IP for a while, you probably are aware of at least two approaches for streaming content over IP networks. The first involves moving professional video from the venue back to the television network facility, and the other is best-effort streaming over the Internet.
The first provides highly reliable transmission over highly managed networks, probably based on the SMPTE 2022 family of standards. The second involves using video servers to stream content on the Web to end-user computers, with less than reliable results. Video freezes, audio dropouts and total loss of the feed are commonplace.
Professional transmission of video over IP is reliable, but it is relatively expensive, it requires the grooming of networks to ensure available bandwidth, and the technology is not deployed in desktop computers and smart phones. The second provides less than perfect results for people who are trying to consume broadcast content on something other than a television set. Broadcasters and media companies needed a different alternative.
ABR concept
The solution comes in the form of adaptive bit rate streaming (ABR). ABR is a technique that is used in several products, from Apple, Microsoft and others. While the specifics of the technology vary, the concept is the same. ABR technology allows the streaming of video and audio over the generic Internet without the aforementioned problems by varying the bit rate of the content being sent to the consuming device, depending upon the status of the link between sender and receiver near the time the content is to be consumed. Basically, the server sends high bit-rate content when a high bit-rate connection is available to the consumer, and it switches to lower bit-rate content when the speed of the connection is reduced.
There is a key concept behind ABR, which allows everything to fall in to place. Question: If you are receiving a stream from a server, and you initially have a great connection, but you move to a location with a poor connection, how does the server know to switch you from a higher bit-rate feed to a lower bit-rate feed? The answer is that it doesn’t! It is the receiver that requests the change.
This is a key concept in ABR. ABR differs significantly from the video over IP streaming that came before it. ABR is a content pull technology, meaning that it is the receiver that requests the content, rather than the server that is pushing content to the receiver.
In a system where the receiver pulls content, the receiver knows whether it has a high bit-rate connection to the server or not. How does it know? There are several ways for the receiver to determine this. One technique is to monitor video buffer levels in the receiver. If the amount of video in the buffer is decreasing, then the bandwidth of the content is greater than the available connection. Basically, you are taking video out of the buffer and feeding it to the display faster than it is arriving at the input of the receiver. If the amount of video in the buffer is increasing, then the bandwidth of the content is lower than the available connection; the opposite condition is true. You are taking video out of the buffer and feeding it to the display slower than it is arriving at the input of the receiver.
In older IP streaming systems, if the buffer in the receiver is being depleted, at some point the buffer empties and the video freezes (a buffer underflow). There is nothing the receiver can do about it.
But what if the receiver can talk with the server? What if the receiver is able to choose between several “channels,” all of which contain identical content, but compressed at a different bit rate? And what if the receiver is able to ask the sender to change the “channel” being sent to it dynamically? The receiver could monitor its buffer condition. If the buffer was becoming depleted, the receiver could ask the server to send a lower bit-rate version of the same feed. If the bit rate of the content is low enough, it will arrive much more quickly than the previously streamed high bit-rate content, allowing the buffer to fill to a safe level. This approach solves the freezing problem caused by buffer underflows.
But what about moving from a low bit-rate connection to a higher one? The receiver continuously monitors the available bandwidth. Exactly how it does this varies from implementation to implementation, but in one case, the receiver probes the network by trying to download a file that is essentially bandwidth unlimited. It notes the link speed, waits for some period and then tries the download again. If the receiver notices that more bandwidth is available over a period of time, it requests a higher bit-rate “channel” from the server.
In many cases, users viewing an ABR feed are unaware that “channel” switches are being made in the background. In well-engineered ABR systems, the steps between ABR “channels” are chosen to reduce drastic changes in quality as the receiver moves from one “channel” to another. Of course, if the user is watching a feature movie on a high-quality display and the feed degrades quickly from high bandwidth to low bandwidth, then he or she is likely to see a difference. However, if the change takes place over the course of a few minutes, most users will not see the difference. In any case, a gradual loss of quality is much less noticeable to end viewers compared to a video freeze.
How exactly does this mechanism work? How are the different “channels” created? When a piece of content, a feature-length movie, for example, is ingested into an ABR system, it is typically encoded at several different bit rates. The exact bit rates depend upon the implementation, but, for our example, let’s say we code at 1.8Mb/s, 800Kb/s and 264Kb/s. When the movie is ingested, three separate renditions of the movie exist on the server — one for each bit rate. This may seem like a waste of space, but it means that at any time, when the receiver requests a different bit rate, that coding rate already exists.
Chunking content
Here is another key concept of ABR systems: Content is “chunked” into many small files. A system may chop up the recorded content into three-second segments. So when the whole ingest process is finished, a single movie has been ingested and converted into a number of three-second chunks or files coded at 1.8Mb/s, the same movie has been chunked into three-second files at 800Kb/s, and again, the same movie has been chunked into three-second files at 264Kb/s.
When a receiver sees that its buffer is draining faster than it is being refilled, the receiver sends a request for the next chunk at a lower bit rate. Assuming the same network conditions, the lower bit-rate chunk can be delivered more quickly, so the receiver buffer fills more rapidly. If this lower bit-rate content can be delivered quickly enough, then the receiver continues to request three-second chunks from this lower bit-rate version until network congestion improves.
Figure 1. As available link bandwidth changes, the receiver requests content encoded at lower or higher bit rates.
Importantly, the chunking on each file takes place at exactly the same time so that the switch between the end of one chunk of higher bit-rate content and a lower bit-rate chunk is not disruptive to the viewer. Put another way, the chunks are time-aligned across different bit-rate renditions of the movie. Chunk 1235 of the 1.8Mb/s version is exactly the same content as chunk 1235 of the 264Kb/s version.
Figure 1 ties all of these concepts together. In the top portion, you can see that the available bandwidth between the server and the receiver changes over time. In the lower portion of the figure, you can see that the receiver requests higher or lower encoded bit-rate chunks depending upon available link bandwidth. This is the essence of ABR.
More to learn
There is a lot to learn about ABR technology. I hope that this introductory article whets your appetite and that you will read more about this innovative way to deliver content over IP links that vary in quality over time.
—Brad Gilmer is executive director of the Video Services Forum, executive director of the Advanced Media Workflow Association and president of Gilmer & Associates.
