Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
One of the more intriguing streaming-related numbers out there is the Netflix ISP Speed Index which topped out at a paltry 3.98 Mbps in the US during December 2017 (Figure 1). According to Netflix, “The Netflix ISP Speed Index lists the average prime-time bitrate for Netflix content streamed to Netflix members during a particular month. For ‘Prime Time’, we calculate the average bitrate of Netflix content in megabits per second (Mbps) streamed by Netflix members per ISP. We measure the speed via all available end-user devices.”
Figure 1. The Netflix ISP Speed Index, December 2017 showing about 4 Mbps top speed in the US.
What’s particularly interesting is how the Netflix number compares to the average US connection speed reported by Akamai, which was 18.7 Mbps for Q1 2017, the last reported period. How to square these numbers? It’s a critical question with far-ranging impact on how you should encode your files.
Contents
Speed Index Reflects True Retrieval Bandwidth
There are at least two possible explanations. The first is that effective throughput is limited to about 4 Mbps and that Akamai might be testing with shorter streams than those watched by the typical Netflix viewer. Assuming this is the case, the 4 Mbps limitation reflects true retrieval bandwidth, and you would expect most users to experience frequent stream shifting during video playback.
From an encoding perspective, you might:
- Create a comprehensive encoding ladder with high-quality files at all relevant data rates.
- Encode using 110% constrained VBR to minimize stream switching caused by peaks and valleys in the streams themselves.
- Caution that switching to VP9, HEVC, or AV1 will yield minimal bandwidth savings because whether it’s H.264 or HEVC, you’ll still be pushing an average of 4 Mbps. You’ll improve QoE but won’t save much on bandwidth costs.
Speed Index Reflects Mix of SD and HD Playback, All at Top Quality
The other explanation is that Akamai’s numbers are correct and that the Netflix ISP rating reflects a mix of SD and HD playback. That is, assume that Netflix distributes both SD and HD video footage (which it does), and that the bulk of the retrieved streams are either the top-quality SD stream (say 2 Mbps) and top-quality HD stream (say 6 Mbps) averaging out to 4 Mbps, with few other streams being retrieved and played.
In this case, you might:
- Have fewer rungs on the encoding ladder, and prioritize quality for the top rung, say using the Very Slow x264 preset for that rung, and Medium or Fast for the others.
- Deploy 200% constrained VBR rather than the more conservative 110% constrained VBR because you expect fewer stream switches.
- Expect switching to VP9, HEVC, or AV1 to deliver significant bandwidth savings because you’ll reduce the data rate of the highest quality stream by 35-50% and that’s the stream retrieved by the bulk of your customers. So, you’ll get bandwidth savings and higher QoE.
Pretty far reaching implications, eh? How can you tell which is correct? As the title suggests, check your dang log files.
Case in Point
Figure 2 are statistics for VOD streams deployed via HLS as supplied by a major Scandinavian broadcaster that I visited last November when I attended Streaming Tech Sweden. Here, the 8 Mbps file was the top quality 1080p stream, while the 2.5 Mbps file was the top quality SD stream. As you can see, slightly over 85.5% of the delivered streams was one of these two (and the average delivery bandwidth of the client was slightly above 4 Mbps). A full 93.82 percent of all traffic is from these two and the 1.8 Mbps stream.
Figure 2. Distributed streams from a large Scandinavian broadcaster.
What would you do based on this data? Certainly, there’s a strong incentive to add HEVC to the ladder, as that would reduce the top 1080p rate from 8,000 to 5,500 (or lower) with no loss in quality. While the savings from the top quality SD stream would be less, it might also be worth chasing.
If you were looking to shave encoding and storage costs, you could argue against continuing to produce the 464 or 264 kbps streams or could produce them using a faster preset. And I would recommend encoding the 1200 kbps streams and higher with 200% constrained VBR to maximize quality since there’s so little stream switching occurring.
The bottom line is that you shouldn’t take Netflix’s number as an indicator that your clients can only retrieve 4 Mbps or so. Instead, you should check your dang log files, particularly when attempting to assess the cost/benefit of deploying HEVC, VP9, or AV1.
