For those who have Apple TN2224 committed to memory, I’ll start by saying, “sorry”. It’s not that the Apple document isn’t useful for bitrate planning, but rather it’s just not that relevant today. Said another way, TN2224 is useful for those seeking best practices for HLS implementations – especially HLS implementations on Apple devices – but if you depend on TN2224 for your ABR bitrate recommendations solely, the state of the art for encoders has moved on, and you would do good to follow.
Apple issued TN2224 in 2010 to help video distributors understand HTTP Live Streaming to iPhones and iPads, but since then encoding advancements and methods of efficiently packing video quality into smaller files have improved by orders of magnitude. As a resource guide, this blog post will focus on new techniques for choosing optimum bit rates based on the need of the content and the target resolution, as opposed to the static recipes recommended by Apple.
Network bandwidth congestion is courtesy of streaming video over the Internet
If you have read this far, then you know the challenge video distributors face. Bandwidths are coming under ever increasing pressure as a result of the wholesale adoption of streaming video. T-Mobile in an effort to address this introduced the highly controversial yet successful program called Binge-On, even gaining the FCC’s blessing. For more details on Binge-On you may want to read the blog post we published on the subject here.
Whether consumers are replacing traditional pay TV services or other entertainment offerings with streaming video, or if they are just augmenting (expanding) their entertainment choices, it doesn’t matter. The fact is, consumers are streaming video everywhere, over WiFi, mobile, and fixed wireline networks. Which means video services must plan their bit rates even more carefully. With every modern smartphone and tablet supporting 1080p video playback, distributors of streaming content must consider not only the device capabilities, but also what bandwidth will that network be able to deliver.
Consider an iPad on a home WiFi connection, where the ISP is capable of maintaining a robust 50 Mbps; there should be little difficulty in playing back a high bitrate 6 Mbps 1080p profile. But once that iPad leaves the home, even though it may receive data over LTE, due to varying network and RF conditions, the same 6 Mbps that the mobile network is theoretically capable of delivering, could become highly variable leading to a poor user experience or compromised video quality.
How to select ABR profile variants
Let’s examine the process of choosing more efficient ABR file variants for the range of devices and networks that we must address. The first step to moving beyond fixed bit rate profiles is to select variations that are most appropriate for your application. This means you need to understand the devices that your customers will be viewing content on, including the network type and performance capabilities. For example, if you know most viewers are watching on mobile devices, with a 50/50 split of WiFi and radio connectivity. You know that the screen size will be limited, making more pixels less relevant since the viewing distance is beyond the range of human perception. Furthermore, you will find WiFi and cellular radio congestion can pose streaming data reliability issues, otherwise known as buffering.
When it comes to user engagement, UX and general satisfaction, many services fail in one of the following ways: poor video quality or poor streaming quality (generally buffering). The issue with poor video quality is triggered by overly aggressive encoding bitrates, where the tension between marketing, that feel they must offer 1080p, and the reality of data rates that do not support the needed stream size, is very real. Remember that the optics of viewing high-density screens such as retina displays, at higher resolutions such as 1080p, means much of the video encoded at these higher resolutions is beyond human vision. The trouble with low video quality is when a low target bit rate is chosen (based on cost or network limitations) for resolutions where much of the encoded pixels cannot be seen by the naked eye.
Tip #1: do not feel you must encode HD at 1080p
720p can yield lower bit rates with better quality on many mobile devices.
The root cause of poor streaming UX is easy to understand as it is simply a matter of encoding at bit rates that are too high for the network. The best example is right out of TN2224, where Apple recommends 1080p @ 8.5 Mbps. Though it is possible, on a rock solid LTE connection, to achieve sufficient throughput, the odds are pretty low of this happening in actual practice. Even on WiFi, where interference is highly variable, 8.5 Mbps can be problematic. Want proof? Consider that Netflix’s own ISP Speed Index shows that even on Verizon FiOS, the average bit rate they can deliver is just 3.79 Mbps.
Tip #2: the next frontier in encoding is content adaptive
Netflix made major news when last December they announced that they are re-encoding the entire library to gain a 20% reduction in bit rate. For more details on content adaptive optimization, check out our blog post on the subject.
Future posts will expand on this highly innovative approach and demonstrate why fixed recipes will soon be as antique as a 57 Chevy. Though a 57 Chevy is cool, I’m not so sure fixed recipes should carry the same level of nostalgia!
