Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
When choosing a preset for VOD transcoding, it almost always makes sense to use the highest-quality preset, because any increase in encoding costs will typically be recouped via bandwidth savings delivered by the more efficient encoding. I covered that analysis in detail here.
Note that this conclusion assumes that you deliver at a certain quality level and will boost the bitrate of streams produced with lower-quality presets to equal the quality of the higher-quality preset. Given this assumption, the conclusion is straightforward. You pay for encoding once but pay bandwidth costs each time you deliver the file. As you deliver the file to more and more viewers, the bandwidth costs multiply, and bandwidth savings from an efficient encode outweigh the additional costs associated with a higher-quality preset.
I’ve often wondered what this analysis looked like with live transcoding. The variables, of course, are different. With VOD, assuming that you encode in the cloud, which I conveniently did for my calculations, you can infinitely scale capacity to meet more rigorous encoding demands.
The same is kinda true for live, except that most cloud-based transcoding options are cost-prohibitive for even modest operations. So, owning your own transcoding gear is overwhelmingly the right option for most live producers. When you own your own live transcoding farm, if you use a higher-quality preset, you need to buy additional servers and transcoders to deliver the required streams.
While factoring these purchases into the preset analysis isn’t rocket science, I resisted performing this analysis until my recent visit to United Cloud in Serbia, which is scaling up its live operations.
Contents
Choosing a Live Preset – TL/DR
If you’re in a hurry, the short answer is this. In most cases, it makes the most sense to use the highest quality preset for even modest volume operations, even if you only have a few dozen viewers for each stream. If you’re producing a FAST channel, for example, the numbers indicate that you should buy the additional hardware and use the highest quality preset to reduce bandwidth costs as much as possible.
If you’re running interactive applications like gambling, auctions, or adult entertainment, where each stream might have 5 -15 viewers, the math changes a bit, as it does if you’re buying hardware for very occasional use. We’ll cover all these options below. You can try these options yourself using a Google Sheet, which you can find here. If you can’t change any of the numbers in the sheet, you should be able to save the sheet to a new one that you can change or download it to an Excel spreadsheet you can use as you wish.
Finally, you’ll find a significant difference in throughput and comparative quality with all hardware transcoding options, whether AMD, Intel, NETINT, NVIDIA, or otherwise. Use the numbers herein to guide your testing and analysis but draw your conclusions from your data.
Meet the Calculator
The calculator has two sections: input and calculations. You input your data, including the bitrate and throughout of the two transcoding options, and the calculator computes the comparative costs. The two transcoding options are fundamental to the process. I recommend that you:
- Identify the bitrate necessary to deliver your required quality level using this highest-quality option.
- Then, identify the bitrate necessary to deliver your required quality level using a lower-quality option that should provide superior throughput.
I worked with 1080p30 streams for simplicity, but you should be able to adopt the bitrates and throughput for full encoding ladders.
In my analysis, the two options were as follows:
- Option A (highest quality). This setting produced a 2.5 Mbps HEVC stream for the required quality and 18 1080p30 simultaneous streams.
- Option B (lower quality). This option required a 2.85 Mbps stream HEVC for the same quality and enabled 21 simultaneous 1080p30 streams.
For reference, look at Figure 1, which tracks the performance of x264 software presets. The blue line shows the bandwidth increase necessary to equal the quality of the very slow encode, which produced the highest quality. The red line shows the encoding time for that preset, from which you can compute the encoding costs. For example, using the ultrafast preset would cut encoding costs to 10% of veryslow, but you’d have to boost the bandwidth by 95% to equal the same quality.
With live transcoders, the variable isn’t encoding time; it’s stream throughput. To perform this analysis with hardware, peg the bitrate required to deliver the target quality (say 95 VMAF) using the highest quality/lowest throughput preset. Then, pick another preset, perhaps the lowest quality/highest throughput. Start at the same bitrate as the first stream and encode iteratively using an increasing bitrate until the quality equals that of the first encoding.
Interactive Applications
Let’s explore the calculator through the lens of the interactive application, which has a high volume of streams but only five viewers per stream.
Most of the entries are straightforward, so I’ll be brief.
- Server cost – Cost of the server to house the transcoder
- Card cost – Cost of the transcoder
- Max cards in server – enter the maximum number of cards that you can install in a single server. Along with the number of required streams, this will compute the number of required servers
- Years of service – The number of years to amortize the hardware costs
- Bandwidth cost (per GB) – enter cost per GB for bandwidth costs
- Option A – bitrate in kbps for the required quality and the number of simultaneous output streams (I’m using 1080p 30 streams)
- Option B – same. Note that the bandwidth delta is modest, but the throughput improvement is significant
- Number of required streams – How many streams do you need the hardware to support? This will dictate the number of transcoders and servers you need to buy
- Viewers per stream – How many viewers will watch each stream
- Utilization percentage – all numbers are computed on a 24/7/365 basis. If you’ll be running less than this, enter the percentage here
Calculations – Interactive Applications
The calculations start by presenting the hardware costs, which are much higher with Option A due to the lower throughput of the higher-quality preset. Then, they work through the cost per stream and annual bandwidth costs, add the yearly amortization, and show each alternative’s total cost per year.
In this case, even though the higher-quality preset forced the service to buy an extra server and two extra transcoders, the bandwidth differential made B the more expensive option by $21,344.
24/7/365 Operations
The numbers change for 24/7/365 operation, even with a modest average of 50 viewers per channel. The higher-quality preset is again the best option by $269,690 annually. This translates to over $1 million in extra cash outflow during the four-year term, just to save $35,000 of CAPEX in year 1.
Intermittent Operation
The final scenario shows the cost comparison when the transcoders only run 5 hours a week, or about 3% of the time, with lower required stream counts but higher viewers per stream. Here, the cost differential is insignificant because the amortized hardware cost is the same, and the bandwidth differential is modest. The lesson here is that you should always use the highest-quality preset you can support without requiring additional hardware.
Note that both options are very sensitive to bandwidth cost. I showed $0.02/GB, which is Amazon CloudFront’s most favored pricing in the US and Europe. If that number increases, so does the benefit of the higher-quality preset. If the bandwidth delta between the highest-quality preset and the tested alternative increases, so does the benefit of the higher-quality preset. If the viewer numbers increase, so does
As with all spreadsheet-driven articles, there’s a non-zero chance of some error, large or small. In addition, I’ve never run a live service, so I lack a real-world perspective on these issues. If you spot something questionable or something I haven’t considered, please let me know at [email protected].
