Rob Fullerton has been with CBC/Radio-Canada for ten years within the online/digital group. His roles have included Database Administrator, System Administrator, Development Team Lead, Syndication Manager, Project Manager, and his current role of Platform Product Manager. His team manages the platform of tools used to publish and distribute content to the audience via CBC.ca.
Currently, it is widely known and documented that the public is consuming online video content through an increasingly complex ecosystem of interfaces. These range from the more traditional Web browser interface of a personal computer, to tablets, mobile phones, gaming consoles, and Internet-connected televisions. Each of these interfaces has different capabilities in terms of rendering and displaying video content, and each one can operate under a variety of network conditions. Adaptive Bitrate (ABR) video streaming is a strategy used to maximise the audiences’ experience regardless of the device they have selected to consume content.
What Is ABR?
What Does Bitrate Mean?
As mentioned above, the quality of video one is able to consume is based on several factors:
- The computing power of the device displaying the video,
- The screen resolution of that device, and
- The speed of connection to the Internet.
All of the factors above can vary from one consumer device to another. Beyond that, what is even more difficult to manage is the fact that computing speed and Internet connection speed may vary from one second to another, not to mention that devices manage many applications simultaneously, and use of the Internet generally rises and falls accordingly.
Given a sufficient quality of interface, how good a digital viewing experience can be is generally defined by the audio and video resolution, as well as the audio and video quality. When dealing with video, resolution is the number of pixels described in the signal and, in the case of audio, it is the sample rate and number of channels (mono, stereo, 5:1, etc.). Given a specific format (codec) of video content, the more data that can be delivered over a specific time period, the higher the resolution and quality that can be described in a signal. This is true in traditional broadcasting, and this truth still applies in the case of digital delivery. The digital terminology for data is bits, and the amount of data that can be delivered in a set period of time is the bitrate.
ABR vs. MBR
In order to deal with the multitude of consumption conditions described above, content producers have developed the strategy of offering many bitrates to their audience. This strategy, known as Multi-Bitrate (MBR) allows each audience member to receive video at an appropriate bitrate, given the consumption conditions noted above. Anyone familiar with YouTube (in other words, everyone) will likely have seen the option that their standard player offers to allow users to select a bitrate on almost all videos.
Figure 1 – YouTube bitrate selector
For a working example, try this link.
Adaptive Bitrate (ABR) means more than just a producer offering multiple bitrates of video to their audience, but also the functionality to constantly and automatically adapt the bitrate depending on the circumstances. This is what YouTube’s recently added Auto setting (as seen in figure 1) enables. It is offered by many content producers and aggregators, including CBC/Radio-Canada. The following sections describe how this technology works and the interfaces that support it.
How Does ABR Work?
This is where things take a turn towards the technical. As described above, MBR is a pre-requisite for ABR. As such, the first requirement is for several video files (or several live video streams) to be available at different bitrates. The first key to the success of MBR/ABR video is the selection of appropriate bitrate versions (renditions) of a piece of video for a producer’s audience. This is best done based on research into the consumption conditions (network connection, computing power, display resolution) of the audience. For example, if delivery takes place through a private Intranet with lots of available bandwidth, making only high-bitrate options available may be sensible. On the other hand, if the video is being delivered to rural regions or to a mobile audience who will retrieve the video signal through an inconsistent cellular connection and view it on smaller screens, more low-bitrate options will lead to a better viewing experience. There is no specific science to this – it is the usual cycle of market research, which can be broken down into three steps:
- Educated Guess,
- Implementation, and
- Measurement of consumption and audience feedback.
There are numerous other technical details (such as key frame synchronisation) beyond the scope of this article that a producer must consider in order to deliver the best audience experience. See the Further Reading section for links to this information.
Another pre-requisite for ABR is a manifest file, which is a text file that contains at least a listing of all the bitrates available for a given piece of content and a description of each including its bitrate, rendition file locations, and the like. When an audience member loads a video, this file is loaded first by the media player, so that it can understand what its options are.
If the first key to the success of ABR is the selection of renditions at the right bitrates, the other is a media player that makes smart decisions about what bitrate is appropriate and is able to adapt constantly to changes. The ideal experience is one where the video playback is smooth and makes full use of available bandwidth, computing resources, and display resolution. If the player is not smart, it will either switch to too low a bitrate, in which case the video will be smooth but resources will not be used optimally; or it will switch to too high a bitrate, which results in rendering problems like buffering and pixilation.
There are various ways in which media players make decisions about the most appropriate rendition at any given moment. Some simply look at the length of time it takes to download bits of the video; this only takes connection speed into account, without computing resources or screen resolution. Others periodically try higher bitrate renditions and prepare to react quickly to playback issues (buffering, pixilation, etc.) of any kind by switching to lower bitrates. This takes all resources into account, but necessarily leads to some issues as the player tests the waters, so to speak, using higher-bitrate renditions. Finally, more sophisticated media player systems perform complex functions, such as server-based network monitoring and trend analysis based on an audience member’s geographic location and Internet Service Provider, rendition pre-fetching, switching between physical sources for renditions, etc. In any case, the ability of the media player to appropriately select renditions to display is critical to a good audience experience.
Types of ABR
There are four main implementations of ABR[i]:
- Adobe Dynamic Streaming (Flash),
- Apple HTTP Adaptive Streaming (also known as HTTP Live Streaming or HLS),
- Microsoft Smooth Streaming, and
- Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH).
Susbtantially, the differences between these implementations are the technology required to create (encode) them, the playback interfaces that support them, and the other functionalities that they facilitate, such as security and rights management, embedded closed captions, and the like.
Producing and delivering ABR video properly is a tricky business; this section describes some of the complexities involved and how to deal with them.
Creating ABR Content
Creating single-bitrate content is a relatively straightforward process. Either a broadcast video signal or a high-resolution file is used as source material, fed into an encoder (or transcoder), and a file (or stream) is produced. Creating multiple renditions of a video is an order of magnitude more complicated. This is partly due to the amount of content being created (usually three to ten files, instead of one), but also because the renditions must be well synchronised with each other; otherwise, switching between them will not work well. For this reason, all the renditions must be created simultaneously and, if there are any issues with any of them (e.g., a file is corrupted for some reason), they must all be recreated. This generally means enterprise-class encoding software/hardware is required, and it also means that the process takes longer and/or is much more expensive than the single-bitrate variety. Ensuring quality of ABR content is also more difficult, as three to ten files or streams (plus the manifest file) must be checked prior to final publishing, as opposed to just one.
Another major consideration that content producers need to contend with when considering moving to ABR is what to do with the existing library of single-bitrate content. Going back in time to re-source and re-publish old content as ABR can be complex and costly for the reasons cited above. Not going back and doing so means audiences may get a mixed experience of single-bitrate and ABR, depending on the age of the content they are consuming. This is less of an issue for producers who only keep content available to their audience for a short period of time.
Content Management Implications
When supporting on-demand ABR content models in particular, a publisher must consider how the various renditions of video content (and associated metadata) will be stored. This has implications in terms of storage infrastructure and the general complexity of the system. Compared to a single-bitrate scenario, the storage requirements for ABR may be anywhere from three to fifteen times as large or even more. Volume discounts notwithstanding, storage usually scales with cost linearly, so this is a significant consideration. A mature Content Management System (CMS), capable of treating video content as objects with numerous renditions and metadata, should also be considered a prerequisite to enterprise-wise implementation of ABR. Manually keeping track of this content would likely be error-prone and extremely time consuming.
As described above, a smart player is required in order for ABR to work. Support for this functionality on mobile and TV-based technologies (game consoles, set-top boxes, connected TVs) is common, though it is also common that these same technologies only accommodate one of the types of ABR listed above (Flash, HLS, Smooth Streaming, DASH, etc.). This means that, to reach audiences across many playback interfaces, content must be prepared in these multiple formats. Desktop browser-based media players tend to offer more configuration options, but that does not necessarily mean that getting the right configuration for a particular audience is easy. In fact, more options can sometimes allow a publisher to stray further from the most ideal configurations.
Tracking usage of ABR is also significantly more difficult. In many contexts, audience metrics have typically been tracked based on how many files are viewed. In the ABR paradigm, a single piece of video content is represented by several renditions, each of which has at least one file. In addition, renditions may be created as different types of ABR to satisfy all platforms. Correlating the usage of all these files can be quite difficult, and may require significant reconfiguration of metrics systems and workflows.
The Business Case for ABR
Storage costs three to fifteen times greater than single-bitrate were mentioned above. In addition, unlike conventional broadcasting, the cost of delivering content to digital audiences scales linearly with consumption. A content producer literally pays for each bit of data delivered to their audience. Typically, ABR audiences consume bitrates two or three times higher than producers make available for single-bitrate consumption. This means that, when dealing with consumption of the same content, ABR delivery costs can be two or three times higher. Considering streaming video delivery is one of the largest vendor expenses for CBC/Radio-Canada Digital Operations, this is a major issue.
Compounding this issue is the fact that the audience experience of ABR is usually dramatically better than single-bitrate, for the reasons cited in the sections above. This means that consumption of content also generally increases over the same offering at single-bitrate. As such, a producer can expect the delivery costs to be closer to four or five times greater than single-bitrate.
Granted, costs can be mitigated by only offering the renditions a producer can afford to deliver, regardless of the maximum bitrate the audience can reliably consume.
The revenue model for ABR streaming is similar to that of single-bitrate streaming. Typically, this consists of pre- and mid-roll advertising as associated display ads, subscriptions, pay-per-view, or a combination of these. The difference between ABR and single-bitrate streaming in terms of revenue potential is that ABR audiences tend to be more engaged and, thus, advertising, subscriptions, and pay-per-view rates can be higher. As for the actual net profit potential of ABR, this must be calculated on a case-by-case basis. Providing a producer has a significant profit margin or (ideally) a revenue model that scales with consumption, it can be profitable.
CBC/Radio-Canada & the Future of ABR
Divergence within the complex ecosystem of consumption interfaces described at the beginning of this article is showing no signs of slowing. ABR video delivery is increasingly a good strategy for dealing with this complexity, as it offers the best possible audience experience given any consumption conditions.
CBC/Radio-Canada has been using ABR to present various types of video for over three years now. It started with iOS streaming of NHL playoff games (a paid service) in spring of 2010. The next major achievement was the 2010 FIFA World Cup, streamed using ABR to Web browsers. This hugely successful event proved the case for CBC/Radio-Canada’s ABR delivery of premium content. Starting in late 2011, various live events, including NHL games, have been presented as ABR on CBC/Radio-Canada’s website. In addition, select scripted TV shows have been available in ABR since then. As of this fall (October 2012), CBC/Radio-Canada intends to have all full-episode scripted and unscripted shows available in ABR, as well as all live streamed events on all platforms.
For more information about Adaptive Bitrate Streaming, feel free to visit the following websites:
- http://en.wikipedia.org/wiki/Adaptive_bitrate_streaming (general information)
- http://mashable.com/2011/01/25/adaptive-bit-rate-video-streaming/ (general information)
- http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Adaptive-Streaming-in-the-Field-73017.aspx (general information)
- http://streaminglearningcenter.com/articles/encoding-for-adaptive-streaming-3.html (configuration considerations)
- http://www.adobe.com/ca/products/hds-dynamic-streaming.html (Adobe Dynamic Streaming)
- http://en.wikipedia.org/wiki/HTTP_Live_Streaming (Apple HLS)
- http://www.microsoft.com/silverlight/smoothstreaming/ (Microsoft Smooth Streaming)
- http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP (MPEG DASH)