Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
Number of hours of streaming required to recoup 60-minute encoding cost.
Author’s note: The author would like to acknowledge the shocking fact that he is not perfect and that this lack of perfection often reveals itself, quite embarrassingly, in spreadsheet-intensive articles. I did the best I could and checked every number and assumption multiple times, but if something doesn’t look right, please contact me at [email protected]. I’ll make any corrections as quickly as possible.
This is the fifth and final installment of a series on saving on encoding and streaming. Here are the previous articles.
Save on Encoding Costs: Cut Cloud Encoding Charges
Saving on Encoding and Delivery: Dynamic Packaging
Saving on Encoding and Streaming: Deploy Capped CRF
Saving on Encoding: Adjust Encoding Configuration to Increase Capacity
Contents
Introduction
The calculus for adding a new codec sounds simple, as in, “HEVC is 50% more efficient than H.264, so implementing HEVC will shave 50% of your bandwidth costs. That will cover encoding costs in no time.” Well, maybe yes, maybe no. We can say that adding a new codec will improve the quality of experience of your viewers, or save bandwidth costs, and maybe do a bit of both. Be we can’t say any of that without first doing a lot of analysis.
In this article, you’ll learn how to compute how many times you need to distribute an hour of video to recover the encoding costs. This certainly isn’t the complete picture of the cost/benefit of deploying a new codec, but it’s a critical component of that analysis, and the most I could bite off in a reasonably-sized post. This analysis is for VOD only, not live, which has a complete different set of numbers.
The breakeven formula itself is simple; divide encoding cost per hour by bandwidth savings per hour, and you have the number of hours necessary to recoup the encoding cost. Unfortunately, while the formula is simple, the components of the numerator and denominator may be challenging to derive.
Let’s begin with the numerator, which is the easier of the two values to nail down.
Encoding Cost/Per Hour
Obviously, your encoding costs will depend upon your encoding ladder, and for the purposes of this discussion, we’ll use the ladder shown in Table 1. This also shows the HEVC encoding cost from Bitmovin. To compute these numbers, I assumed the lowest per-minute cost published on the Bitmovin site ($0.013), which is a tier that will cost you $1,299/month and includes 100,000 minutes.
The per-minute cost is for H.264 encoding, which Bitmovin doubles for HEVC and VP9. There’s a 2X premium for HD videos (1280×720 – 1920×1080), producing the multiple of 4 for those resolutions. Multiply the per-minute cost ($0.013) times the multiple (2x or 4x) times 60 minutes to get per-hour cost for each rung, with the total at the bottom.
If you’re using a different cloud facility, you can run the same analysis as Table 1. If you run your own encoding facilities, and you know the per-minute cost for H.264 encoding, multiply that by four for both HEVC and VP9. If you’re encoding AV1, multiply that by 800 to calculate the encoding cost (seriously).
A couple of observations here. First, the higher the cost per hour the more streams necessary to recoup that cost. In addition, since you may be converting existing libraries into the new format, you could be looking a huge up-front expense. The bottom line is that if you decide to start encoding with a new codec or codecs you should make absolutely sure that you’re encoding at the lowest possible cost. I covered cloud encoding costs in this article; see the section entitled, Otherwise, Consider other Encoding Shops for inexpensive alternatives.
Second, don’t forget transmux charges. For example, if you decide to start encoding with HEVC, you’ll need HLS formatted video for Apple devices, and DASH formatted video for Smart TVs and other devices. You might be able to use a single set of files in CMAF format, but then again, you may not, and you certainly won’t be able to if your encoder/packager doesn’t support it.
There can be huge cost differentials for producing the same set of files in multiple formats as I discuss in this article. Be sure to fully flesh out the costs involved with supporting the formats necessary to deploy the new codec.
Bandwidth Savings Per Hour
This is where things start to get hairy. There are two components to this number, how efficient the new codec is compared to H.264, and how much of this efficiency you’ll actually be able to utilize. Let’s start with quality.
The Real Quality Differential Between H.264 and Newer Codecs
I just finished a preliminary review of the AV1 codec for Streaming Media Magazine, and I’ll share some summary data. By way of background, I ran two sets of tests, the first comparing four clips at data rates ranging from 2-6 Mbps, the second comparing two more challenging clips at data rates ranging from 1-3.5 Mbps. I encoded all clips with FFmpeg 4.x. Note that the AV1 team from Google reviewed my FFmpeg scripts for AV1 and VP9 while engineers from MulticoreWare reviewed my x265 scripts.
Table 3 shows the BD-Rate savings delivered by each codec over x.264. Briefly, BD-Rate represents the data rate reduction the new codec achieves while delivering exactly the same quality, in this case measured by Netflix’s VMAF metric.
According to the BD-Rate metric, on average, AV1 can deliver the same quality as x264 with a bitrate reduction of 53%, x265 can deliver the same quality with a bitrate reduction of 34.65%, and VP9 can deliver the same quality with a data rate reduction of 30.21%. Note that these clips are all 1080p resolution, and the benefit will be less at lower resolutions.
Want some verification for these numbers? I recently ran a comparison of x265 and x264 when producing 1080p video at CRF 23. By way of background, with CRF encoding, the codec adjusts the data rate to achieve a specific quality level. I’ve found that CRF 23 delivers around 93 VMAF points or higher, which makes it useful as the starting point for per-title encoding (as discussed in this article on Capped CRF). Table 4 shows the results; at a virtually identical VMAF average, x265 only delivered a data rate improvement of 24.57%. Note that when I tested this back in 2016 with PSNR, x265 delivered a bitrate savings of 39.57%. I contacted MulticoreWare about these results, but never really resolved the issue.
level at CRF 23.
Another proof point comes from Nigel Lee, PhD, and Chief Science Officer at EuclidIQ, which markets video optimization technology and related products and services., including a cloud encoder. Nigel has been kind enough to review several articles that I’ve written that involve heavy math computations like the AV1 article and this one on how to compute BD-Rate functions. Upon reviewing the first set of results from the AV1 review, Nigel commented, “One side observation I would make from Fig. 2 is that the savings for HEVC relative to H.264 ranges from 20 to 33%, which is well below the 50% widely trumpeted by HEVC advocates. The lower gain numbers match our own testing with HEVC.” Note that Nigel is referring to figures in the AV1 article, not those in this article, and that I bolded the statement, not Nigel.
What about VP9 and AV1? In his post, AV1 beats x264 and libvpx-vp9 in practical use case, Facebook researcher Yu Liu compared AV1 with VP9 and x264 encoded using the Main and High profiles (I used the High Profile) using over 400 Facebook videos. Overall, Liu found that AV1 offered 54.3% savings compared to x264 High profile (compared to 53.07 in my tests), and a 37.93% data rate reduction for VP9, compared to 30.21 in my tests. So, I’m certainly in the ballpark, particularly with the second set of tests.
Regarding all the technologies, understand that there are multiple H.264, HEVC, VP9, and even AV1 codecs available that will perform differently. I’m reasonably confident that my results are accurate for the codecs I tested, but HEVC codecs from other vendors like Beamr or MainConcept will deliver completely different results. Even other implementations of x265 might deliver different results.
The point is that by adding a codec and reencoding your libraries, you’re making a decision that could cost hundreds of thousands of dollars or more. Don’t assume that you’ll achieve the savings quoted by technology vendors. Run a few tests to make sure.
If you’re a codec vendor and you disagree with these findings, drop me a note at [email protected]. I’d be glad to send you the source files and x264/x265 encoded files if you’ll send back HEVC/VP9/AV1 encoded video with the code and instructions necessary to duplicate your efforts. Note that if you request the files and don’t return your own files, I’ll assume that your results weren’t any better and I’ll report that on this blog (#nofreelooks).
Going forward, I’ll use an overall bitrate savings of 30% for HEVC, and I would use 25% for VP9. By the time AV1 becomes practical for most users, I’m sure the number will change, but for now, about 50% sounds right.
Now that we know the potential savings, the big question is how much of these savings can you actually harvest. For that, you’ll have to visit your log files.
How Much Savings?
Table 5 shows our encoding ladder with a column for percent viewed, which is the percentage this particular rung is watched by a viewer, a statistic you’ll have to harvest from your log files.
Here’s the funky part; you only achieve bandwidth savings from viewers who are watching your lowest quality and your highest quality streams. I’ll explain. In Table 5, assume that today, 15% of your viewers are watching your 540p stream encoded at 2,200 kbps. Tomorrow, after switching to HEVC, these viewers will almost certainly be watching the 720p stream encoded at the same bitrate. The quality of the video should improve, but the outbound bandwidth will be exactly the same. Higher QoE, but no bandwidth savings.
Up and down the encoding ladder the result is the same; perhaps some small decreases or increases in the switch, but no wholesale benefits except for the lowest and highest rung.
Viewers connecting at 200 kbps will most likely connect at 140 kbps with HEVC, but the data rate is very low so the savings are
Compare that to Table 6 which has a top-heavy distribution pattern, and shows a bandwidth savings of about half a GB per hour. Interestingly, as the bandwidth savings increase, the QoE improvement decreases, at least as measured solely by video quality. That is, a viewer previously watching the 1080p H.264 video encoded at 6,500 kbps is now watching the 1080p video encoded at 4,550, which should be nearly identical in quality. There may be other quality-of-experience benefits from retrieving a lower bitrate stream, like reduced stream switching or more available bandwidth for other users, but the video quality should be the same.
Note that the encoding ladders that you actually deploy for HEVC will be different than for H.264 for reasons I explain in Apple Got It Wrong: Encoding Specs for HEVC in HLS. However, as presented, Tables 5 and 6 simplify the point I’m trying to make in this section.
Note also that your savings will reflect the actual rungs that you deploy with the new codec. To save encoding costs, some producers are adding HEVC rungs only at 720p and higher resolutions, an approach I explored here, while others are creating two completely different ladders with H264 and HEVC (like Apple here). Most producers that use VP9 seem to deploy a completely separate ladder. Obviously, your bandwidth savings/QoE improvements will reflect these decisions.
The takeaway from this section? You need to compute the GB saved per hour by switching to the new codec. This combines the estimated bandwidth savings from the codec and how much of that savings you’ll achieve based upon your encoding ladder analysis.
Putting it All Together
Table 7 computes the hours to breakeven at multiple cost per hours and bandwidth costs. The only input is the bandwidth savings per hour of video on the top left. Find your video cost per hour and bandwidth cost, and you’ll see the hours of videos necessary to recoup the cost of encoding a single hour.
You can download an Excel file with this table and Tables 1 and 5/6 in separate tabs, here.
Your ability to achieve and surpass these hours depends upon a number of factors, including which platforms support each new codec and how that maps with your typical viewers. If you’re distributing solely to Smart TVs, HEVC should make a lot of sense. If distributing primarily to computers for browser-based playback, VP9 is a natural. For a discussion of this and other codec-implementation issues, check out Return of the Codec Wars: A New Hope—a Streaming Summer Sequel.
Final Thoughts
Some final thoughts. First, this isn’t a total break-even analysis, it’s a hopefully useful computation to figure out whether deploying a new codec makes sense of not. But there are many additional expenses to add into the breakeven analysis, including player development costs, encoder selection costs, ladder development costs, and debug and quality control costs. For many OTT providers, the math should be pretty compelling. For the vast majority of smaller sites that distribute each video in the low hundreds of hours, it probably isn’t.
Second, the $16,000 cost per hour for encoding in Table 7 isn’t a joke, it’s a rough estimate of the encoding cost of AV1 and shows why AV1 makes sense for Netflix, Hulu, Facebook, Amazon, and others who distribute videos in the millions of copies. Famously, over 16 million people watched the premiere of Game of Thrones season 7 on the first night it was available; had AV1 been around back then, it would have been the gift that keeps on giving.
Third, the HEVC royalty situation has slowed adoption since the codec first became available in 2013. While two of the three royalty groups have abandoned royalties on non-physical content (i.e. streamed or downloaded), the Velos pool refuses to make the same decision. I checked the Velos FAQ today, and it still states “As it relates to content, we will take our time to fully understand the dynamics of the ecosystem and ensure that our model best supports the advancement and adoption of HEVC technology.”
If Velos didn’t intend to pursue content royalties, you would assume they would have said so by now, since it’s such a substantial issue for so many producers. So, at the very least, you need to get your CFO and/or corporate counsel involved in the decision to implement HEVC. If you need to estimate royalty costs to include in your break even analysis, note that MPEG LA charges $0.02/title for H.264 with a 9.75M annual cap, while HEVC Advance charges $0.0225 for HEVC video shipped on physical media with a $2.5 million annual cap.
Where to Go From Here
Adding and configuring a new codec involves many steps, from analysis to encoder selection to ladder creation. If you’d like some help running this analysis, contact me (Jan Ozer) at [email protected]. This is it for the series, I hope you found at least some of the articles useful.
Resources
Here are other resources to assist your analysis or implementation decisions.
Video Encoding by the Numbers: Eliminate the Guesswork from Your Streaming Video (PDF version)(Amazon). A good resource if you’re looking for assistance with running objective quality metrics and encoding trials and comparisons.
Learn to Produce Video with FFmpeg in 30 Minutes or Less (2018 Edition). Get up to speed quickly with FFmpeg for testing or production. Contains extensive description regarding how to encode HEVC for HLS and package with Bento4, including how to formulate a hybrid encoding ladder with HEVC and H264.
Return of the Codec Wars: A New Hope—a Streaming Summer Sequel, Streaming Media Magazine, July/August 2018.
Download Handout from Encoding Live and VOD for HEVC in HLS, Streaming Learning Center, May 9, 2018. From a workshop at Streaming Media East, a very useful resource.
Please Help Me Test HEVC Playback in HLS, LinkedIn, April 30, 2018.
Congratulations to Me (Er, Apple Changes HEVC Encoding Recommendations), LinkedIn, April 27, 2018 (discusses Apple’s changes to their HEVC encoding recommendations).
HEVC in HLS: 10 Key Questions for Streaming Video Developers, Streaming Learning Center, January 15, 2018.
Apple Got it Wrong: Encoding Specs for HEVC in HLS, Streaming Media Magazine, November 21, 2017 (how an HEVC encoding ladder should be different than H264).
Apple Embraces HEVC: What Does it Mean for Encoding?, Streaming Media Magazine, June 8, 2017.
HLS Authoring Specification for Apple Devices, the controlling document for encoding for HLS, including HEVC.
Hey, Jan. I love the blog, and I’m anxious to read the full, upcoming test results you’ve generated (and mentioned a couple of time). However, I have a slight quibble with your specific language used at various points in this article.
Essentially, when you don’t use reference encoders for all of your encodes, you’re just testing a specific implementation of an encoder, not the underlying codec itself. So, comparing the AV1 results with x264 shows how well the AV1 reference encoder does over a specific implementation of the H.264 encoder, not actually AV1 vs H.264. If you were to compare the reference encoders, that would be the ideal when you’re comparing codecs (vs various implementations). While a test comparing reference encoders is still testing specific implementations, it’s pretty close to testing the actual codecs’ capabilities. Also, reference encoding times (i.e. how long does it take to transcode each minute of content) give us a pretty good estimate as to roughly where vendor transcode times will approach as the codec comes to market. Reference coders have historically been roughly 10x slower than professional vendor implementations so that with some anticipated compute increases would be a decent guess as to what transcode times would be in 2021.
W/R/T the subject of this article, testing specific implementations instead of reference encoders makes sense as when you’re calculating the costs of paying a company to transcode your videos for you, you care specifically about the implementations they’re using to do so.
Another useful data point would be the compute time spent transcoding with various implementations since that information can be important for people at various levels. While Bitmovin will certainly do their due diligence for each implementation themselves, they represent a company that will care since they will want to effectively plan the infrastructure costs and capacity on their end. On the other end of the spectrum, there may be someone who has a stronger interest in getting their encodes published more quickly (time-sensitive information, for instance), at which point they probably would be interested in how long of a turnaround time each of their acceptable options take, and choose for each video depending on its time sensitivity.
FYI, using reference encoders vs. specific implementations likely explains the different results Thierry found vs. Facebook/BitMovin/MSU.
Matthew: thanks for the thoughtful and useful comment. The article is up now on Streaming Media, so you can have a look.
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/AV1-A-First-Look-127133.aspx
I address the reference encoder situation, probably demonstrating my ignorance. But have a look and let me know if I’ve addressed your concerns.