Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
As you may have seen, I’ve been spending a lot of time analyzing multiview solutions and studying the technical alternatives, client-side vs. server-side (see here for an extensive analysis of the two). Briefly, client-side multiview uses existing encoded streams assembled into the multiview by the client, while server-side essentially creates a new multiview channel on the server, necessitating a new encode.
So, from a pure transcoding perspective, server-side costs more. But in the article, I claimed that client-side uses more bandwidth, which, assuming that sufficient viewers watched the stream, could more than offset the encoding cost differential. In a response to this article, one colleague commented.
The bandwidth argument in Jan’s article doesn’t fly when the individual streams are retrieved at the resolution they are displayed, as they will in a proper client-side multiview system like F1 uses. Basically, the bandwidth will be proportional to the number of pixels, regardless of whether the composite is client-side or server-side (emphasis supplied).
This comment triggered this post.
Before going any further, I should note that this transcoding/bandwidth economic comparison overlooks the server-side’s most significant advantage: near-universal compatibility. In comparison, client-side is limited to more powerful platforms, like Apple TV, that can retrieve and display multiple streams. As a result, client-side simply doesn’t work on the vast majority of Smart TVs.
But just because an argument isn’t the primary decision factor doesn’t mean it’s not worth chasing down. From a purely economic perspective, my colleague’s comments overlook one key reality about most codecs, including HEVC: that they operate more efficiently at higher resolutions.
The essential comparison is this. For a 4K 2×2 multiview, client-side multiview sends four 1080p streams, while the server-side sends a newly encoded 4K stream. If codecs do work more efficiently at higher resolutions, the server-side 4K stream should save bandwidth over the four 1080p streams while delivering the same quality. At a sufficient viewer count, if you consider both encoding and bandwidth costs, the server-side approach should actually become cheaper.
The first question is how much more efficient 4K encodes are than separate four 1080p encodes. Let’s examine several sources. Then we’ll tackle the breakeven analysis.
Contents
The Power of the .75 Rule
The Power of .75 Rule is a shorthand way to capture the idea that codecs become more efficient at higher resolutions. It posits that if you double the pixel count, you don’t need double the bitrate to keep quality constant. Instead, the bitrate only needs to rise by the resolution ratio raised to the power of 0.75. The rule dates back to the WMV and VP6 era, and I learned of it from Ben Waggoner when he was at Microsoft (he’s now at Amazon).
Here’s the formula.
If we take the ratio of 4K pixels to 1080p pixels (8,294,400 ÷ 2,073,600 = 4), the rule says that the bitrate only needs to increase by the pixel ratio of four raised to the power of 0.75, which translates to about 2.83 times.
How does that work in our case? Suppose each 1080p stream requires 5 Mbps, totalling 20 Mbps for the four. If we multiply the 5 Mbps by 2.83, an equivalent-quality 4K encode should be around 14.15 Mbps. That’s a theoretical 29% savings for the 4K server-side composite compared to the client-side 4×1080p.
Apple’s Recommendations
The next checkpoint was Apple’s HLS authoring specifications, which are generally too rich for my blood but still a useful benchmark. For 1080p30, Apple recommends between 4500 and 5800 Kbps. For 4K30, the recommended range is 11,600 to 16,800 Kbps.
Run the math, and the picture is clear. Four 1080p streams at the midpoint (about 5150 Kbps each) total just over 20.6 Mbps. A single 4K stream at the midpoint (around 14,200 Kbps) is about 31% lower.
Even if you compare the high ends, four 5800 Kbps streams = 23.2 Mbps, while the top-end 4K ladder at 16,800 Kbps is still 28% lower. On the low end, four 4500 Kbps streams = 18 Mbps, compared to Apple’s low 4K figure of 11,600 Kbps, a savings of about 36%.
So across the board, Apple’s own recommended bitrates back up the idea that one 4K composite stream is materially more efficient than four separate 1080p streams.
My Results
You can’t become a famed Streaming Media Influencer (shameless plug) by quoting other sources, so I created my own analysis. Here are the highlights.
- I used Harmonic’s 11-minute football clip as the source material
- I extracted four different 2-minute segments from the file
- I built a 2×2 4K “source” composite from those segments (Figure 3)
- I encoded the 2×2 composite at 14 Mbps using FFmpeg and x265 (medium preset)
- I compared this to the 4K source to compute VMAF
- I encoded four separate 1080p streams at 3.5, 4.0, 4.5, and 5.0 Mbps, again with FFmpeg and the medium preset
- To measure VMAF, I combined the four clips into a 2×2 composite YUV file for each bitrate, then compared that to the 4K source
Key Results from the Test
- The 4K 2×2 composite encoded at 14 Mbps delivered a VMAF of 93.9.
- To reach that same quality level with four 1080p streams, each stream needed to be about 4.24 Mbps (interpolated from the curve). You see this in Figure 4 below.
- Four streams × 4.24 Mbps = 16.96 Mbps total.
Here’s a plot of the result.
The Savings
- Client-side total (4×1080p): ~17.0 Mbps
- Server-side 4K composite: 14.0 Mbps
- Bandwidth savings: 3.0 Mbps, or ~17% less
The Economics of Break-Even
So, server-side delivery saves about 17 percent of bandwidth compared to client-side. Translating that into dollars requires two pieces: the extra encoding cost for server-side, and the cost of delivery.
Regarding transcoding cost, at scale, I assume about $5.00 per service hour. This figure comes from Skreens and reflects the total cost of their managed multiview offering at the highest volumes.
For delivery cost, I used two cents per gigabyte delivered to compute savings, which is high if you’re a tippy top-tier distributor, low if otherwise. A 4K server-side stream at 14 Mbps equals 1.75 MegaBytes per second or about 6.3 GB per hour. Four 1080p client-side streams at 4.24 Mbps each total 16.96 Mbps, which works out to 2.12 MegaBytes per second or approximately 7.6 GB per hour.
Savings per viewer: Client-side delivery is about 7.6 GB per hour at two cents, which equals 15.2 cents per viewer per hour. Server-side delivery is about 6.3 GB per hour at two cents, which equals 12.6 cents per viewer per hour. The difference is about 2.6 cents saved per viewer per hour.
Break-even point: The extra encode costs $5.00 per hour. Divide $5.00 by the 2.6 cents saved per viewer, and you get about 192 viewers. So, at roughly 200 simultaneous viewers, the server-side delivery savings cover the extra encoding cost. Everything beyond that is net savings.
To state the obvious, this breakeven varies with the service cost and the cost of delivery. If the service price is higher or the delivery cost is lower, the breakeven number goes up. If the bandwidth differential is higher, the breakeven decreases. At $0.02/ GB, Apple’s recommendations would break even at 86 viewers, assuming a single 4K encode vs four 1080p encodes.
How significant is 200 viewers? ESPN implemented client-side multiview for Apple TV customers in ESPN Unlimited. All others get to choose from a limited set of canned, presumably server-side multiview streams. I’m guessing that each of those gets well over 200 viewers.
Obviously, if you provide a true build your own multiview (BYOMV) for every client, you’ll never catch up. But if you’re offering limited channels to large numbers of viewers, duplication and multiple use of “custom” channels is assured.
Caveats Aplenty
Results like these will vary by codec and especially by encoder. No one is going to use plain-jane x265 for a 4K service; in practice, you’d expect hardware-based encoders or multicore-optimized software encoders, each with its own efficiency quirks.
I also only tested a single football clip. Sports is about the toughest genre you can throw at a codec. For news or prime time drama, the differences might be smaller.
Delivery pricing is variable. Two cents per gigabyte is a reasonable middle-of-the-road estimate, but large distributors may pay less, and smaller ones may pay more. That means your exact break-even point could move up or down depending on what you actually pay for delivery.
Wrapping Up
It’s easy to dismiss server-side multiview as “too expensive” because of the extra encodes. But once you factor in codec efficiency at higher resolutions, the bandwidth savings can offset those costs surprisingly quickly.
Again, where we sit today, universal compatibility with supported devices is the most compelling server-side advantage. But don’t assume that client-side is the cheapest alternative on clients like Apple TV that support it. Run your own tests and numbers to be sure.
The bottom line is that both client-side and server-side multiviews have specific costs. When you’re running the financial comparison, be sure to include bandwidth costs in your calculation.
