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.