Adaptive Bit Rate streaming (ABR) was invented to enable content providers to provide video streaming services in an environment in which bandwidth would fluctuate. The benefit is clear; as a connection capacity changes over time, the video carried over that connection can vary its bit rate and therefore its size to adapt to the network conditions. The player or client and the server exchange discrete information on the control plane throughout the transmission whereby the server exposes the available bit rates for the video being streamed and the client selects the appropriate version based on its reading of the current connection condition.
The technology is fundamental to helping accommodate the growth of online video delivery over unmanaged (OTT) and wireless networks.
Unfortunately, the main content delivery technology vendors started to diverge from the standard implementation to differentiate and control the user experience and the content provider community better. Below are the main implementations:
- Apple HTTP Adaptive (Live) streaming (HLS) for iPhone (News - Alert) and iPad: This version is implemented over HTTP and MPEG2 TS. It uses a proprietary manifest called m3u8. Apple creates different versions of the same streams (two to six, usually) and breaks down the stream into little “chunks” to facilitate the client jumping from one stream to the other. This results in thousands of chunks for each stream, identified through time code. Unfortunately, the content provider has to deal with the pain of managing thousands of fragments for each video stream. A costly implementation.
- Microsoft (News - Alert) IIS Smooth Streaming (Silverlight Windows phone 7): Microsoft has implemented fragmented MP4 (fMP4) to enable a stream to be separated in discrete fragments, again to allow the player to jump from one fragment to the other as conditions change. Microsoft uses AAC for audio and AVC/H264 for video compression. The implementation allows for the grouping of each video and audio stream with all its fragments in a single file, providing a more cost effective solution than Apple's (News - Alert).
- Adobe HTTP Dynamic Streaming (HDS) for Flash: Adobe uses a proprietary format called F4F to allow delivery of Flash videos over RTMP and HTTP. The Flash Media Server creates multiple streams at different bit rates but also different quality levels. Streams are full lengths (the duration of the video).
ABR presents some significant improvements on the way video can be delivered in certain network conditions.
If we take the fragmented MP4 implementation, we can see that the benefits to network and content providers are significant. The manifest, transmitted at the establishment of the connection between the player and the server, describes the video file, its audio counterpart, its encoding and the different streams and bit rates available.
Since the player has access to all this at the establishment of the connection, it has all the data necessary for an informed decision on the best bit rate to select for the delivery of the video. This is important because ABR is the only technology today that gives the device control over the selection of the version (and therefore quality and cost) of the video to be delivered.This is crucial since there is at present no efficient means to convey congestion notification from the Radio Access Network through the Core and Backhaul to the content provider.
Video optimization technology is situated in the Core Network and relies on its reading of the state of the TCP connection (percent packet loss, jitter, delay...) to deduce the health of the connection and the cell congestion. The problem is that a degradation of the TCP connection can have many causes beyond payload congestion. The video optimization server can end up taking decisions to degrade or increase video quality based on insufficient observations or assumptions that might end up contributing to congestion rather than assuage it.
ABR, by providing the device with the capability to decide on the bit rate to be delivered, relies on the device's reading of the connection state, rather than an appliance in the core network. Since the video will be played on the device, this is the place where the measurement of the connection state is most accurate.
As illustrated below, as network conditions fluctuate throughout a connection, the device selects the bit rate that is the most appropriate for the stream-- jumping between 300, 500 and 700kbps in this example -- to follow network conditions.
This provides an efficient means to provide the user with optimal quality as network conditions fluctuate, while reducing pressure on congested cells when the connection degrades.
So why isn't ABR more successful?Let’s review the problems experienced by ABR that hinder its penetration in the market.
Having three giants such as Apple, Adobe (News - Alert) and Microsoft each pushing their version of the implementation leads to obvious issues. First, the implementations by the three vendors are not interoperable. That's one of the reasons why your iPad won’t play Flash videos. Not only is the encoding of the file different (fMP4 vs. multiplexed), but the protocol (MPEG2TS vs. HTTP progressive download) and even the manifest are proprietary. This leads to a market fragmentation that forces content providers to choose their camp or implement all technologies, which drives up the cost of maintenance and operation proportionally which means that a content provider with a single 1080p HD video could see himself creating one version for each player, multiplied by the number of streams to accommodate the bandwidth variation, multiplied by the number of segments, chunks or file for each version... As illustrated above, a simple video can result in 18 versions and thousand of fragments to manage. MPEG DASH, a new initiative aimed at rationalizing ABR use across different platforms, was just approved last month. The idea is that all HTTP based ABR technologies will converge towards a single format, protocol and manifest.
Apple, Adobe and Microsoft seek to control the content owner and production by enforcing their own formats and encoding. I don't see them converging for the sake of cooperation in the short term. A good example is Google's foray into WebM and its ambitions for YouTube.
3. Content owners' knowledge of mobile networks
Adaptive bit rate puts the onus on content owners to decide which flavor of the technology they want to implement, together with the range of quality they want to enable. Obviously, not every content provider is going to go the costly route of transcoding and managing 18 versions of the same content, particularly if this content is user-generated or free to air. This leaves the content provider with the difficulty of selecting how many versions of the content and how many quality levels to support.
As we have seen over the last year, the market changes at a very rapid pace in terms of which vendors are dominant in smartphones and tablets. It is a headache for a content provider to foresee which devices will access their content. This is compounded by the fact that most content providers have no idea of what the effective delivery bit rates can be for EDGE, UMTS, HSPA, HSPA + or LTE (News - Alert). In this situation, the available encoding rate can be inappropriate for the delivery capacity.
In the example above, although the content is delivered through ABR, the content playback will be impacted as the delivery bit rate crosses the threshold of the lowest available encoding bit rate. This results in a bad user experience, ranging from buffering to interruption of the video playback.
4. Tablet and smartphone manufacturers’ knowledge of mobile networks
Obviously, delegating the selection of the quality of the content to the device is a smart move. Since the content is played on the device, this is where there is the clearest understanding of instantaneous network capacity or congestion. Unfortunately, certain handset vendors, particularly those coming from the consumer electronics world, do not have enough experience in wireless IP for efficient video delivery. Some devices, for instance, will go and grab the highest capacity available on the network, irrespective of the encoding of the video requested. So for instance, if the capacity at connection is 1Mbps and the video is encoded at 500kbps, it will be downloaded at twice its rate. That is not a problem when the network is available, but as congestion creeps in, this behavior snowballs and compounds congestion in embattled networks.
As we can see, there are still many obstacles to overcome for ABR to become a successful mass market implementation. There are technologies out there that are being developed to alleviate these issues. We will look at them in my next column.
Want to learn more about the latest in communications and technology? Then be sure to attend ITEXPO East 2012, taking place Jan. 31-Feb. 3 2012, in Miami, FL. ITEXPO offers an educational program to help corporate decision makers select the right IP-based voice, video, fax and unified communications solutions to improve their operations. It's also where service providers learn how to profitably roll out the services their subscribers are clamoring for – and where resellers can learn about new growth opportunities. For more information on registering for ITEXPO registration click here.
Stay in touch with everything happening at ITEXPO. Follow us on Twitter.