Computing Breakeven on New Codec Deployments

This article and the associated Google Sheet present an analytical model for computing breakeven on new codec deployments. 

On a LinkedIn post here, Johan Skaneby asked:

Technical comparisons and documentation on different codec performance are very interesting and important, but all development of technologies are always closely related to market requirements and business models.

My experience is that the challenge for decision-makers in existing and profitable distribution workflows is to understand the business value of introducing new technologies such as for example a new codec. Because there are for sure significant costs in implementation and verification for a new distribution workflow. Have you covered any real-world conclusions on this topic?

As it happened, I addressed this in a very basic way in a blog post that I never posted (was part of a longer blog and this bit got cut). So, it’s not a comprehensive response to Johan’s question, but perhaps there is a nugget of value here.

When to Adopt a New Codec

Here are some points to consider when considering deploying a new codec.

First, there are two potential benefits; bandwidth cost reduction and improved quality of experience (QoE) from the improved video quality. How much of each you will realize depends upon which rungs of your encoding ladder your viewers consume.

For example, if 100% of viewers consumed your top rung, switching from AVC to AV1 should reduce bandwidth costs by around 50% but would have little impact on QoE because the quality of the AV1 top run will be similar to your AVC top rung. On the other hand, if 100% of viewers consumed your 2 Mbps 540p AVC rung, they would still consume a 2 Mbps AV1 rung, so there’s no bandwidth saving, though the AV1 rung might be 720p with much higher quality improving QoE. So start your analysis by viewing your consumption statistics.

The best way to assess both bandwidth savings and QoE is to create a new encoding ladder using the new codec and measure the comparative quality of the different rungs, preferably via subjective tests, but if those aren’t available use a metric like VMAF or SSIMPLUS. Note that BD-Rate stats are computed by comparing four 1080p files encoded at different data rates. Your encoding ladder looks nothing like that, and bitrate savings at the lower end will be much lower. So, build your encoding ladder with the new codec and apply the rung usage stats discussed in the first paragraph to determine both bandwidth savings and QoE improvement.

Here’s what the analysis might look like (click to view at full resolution. These numbers are estimates and for illustrative purposes only. Once this data is known, you can create a simple breakeven analysis to determine how many hours a video must be viewed to justify using the more efficient codec. Obviously, the more times a video is watched, the more bandwidth savings accrue. That’s why YouTube uses AVC for most low-volume videos but VP9 for videos that break a certain threshold which is actually pretty low.

For example, looking at my own videos on YouTube, one with 400 views was encoded with AVC, another with 1300 views was encoded with VP9. All of the normal sports and commentary videos that I watch, which typically accrue tens of thousands of views or higher, are encoded with VP9. Encoding with VP9 should take about five times longer than AVC, which means five times the cost. That’s only justified when views exceed a certain level. Ditto for encoding with AV1 where the threshold is even higher.

Computing Breakeven

In addition to encoding costs, to compute breakeven, you’d have to include other expenses like development, testing, and quality control, and licensing. Then divide this number by the bandwidth saved per hour of video to compute how many hours of video views you’d need to financially justify deploying a new codec. If a substantial component of the benefit is QoE, you could reduce your total costs by reduction of churn.

I created the basic breakeven analysis shown above in a Google Sheet that you can access here. To run the analysis, download the spreadsheet as an Excel file (File > Download > Microsoft Excel), and run it in Excel, or import it back into Sheets and run it there. Here’s the procedure.

  1. Insert fixed implementation costs. This would include encoding testing, QC, consulting expense (hint, hint), and other implementation costs.
  2. Insert bandwidth savings in GB/hour of the encoded video. Compute this using the comparative encoding ladders discussed above. Obviously, you should only include savings on the platforms that support the new codec, not your total distribution bandwidth. For example, for HEVC, include video distributed to iOS, Smart TVs, and Android (if you have an App), but exclude video consumed by browsers like Chrome and Firefox.
  3. Insert the number of hours of video to be encoded with the new codec to spread implementation costs over all videos.
  4. If desired, change encoding cost and bandwidth cost per GB.

The result is the number of hours of viewing to break even on encoding and allocation of fixed costs.

In the interest of full disclosure, I’ll note that I took my last college accounting course where I studied breakeven analysis before a depressing majority of those reading this blog were born. So, if there are any errors in logic or math, please let me know (janozer@gmail.com).

What is clear is that the higher the encoding costs or lower the bandwidth costs, the harder it is to financially justify adding a new codec. If you’re encoding a large number of video hours, the impact of implementation costs is relatively modest.

About Jan Ozer

I help companies train new technical hires in streaming media-related positions; I also help companies optimize their codec selections and encoding stacks, and evaluate new encoders and codecs.

Check Also

Which Codec Does YouTube Use, Part III

This article analyzes the codecs used by YouTube for 4K videos with millions of views, …

Leave a Reply

Your email address will not be published. Required fields are marked *