Estimate your Mux Video costs before you launch. Use this guide to model scenarios, for example a UGC platform, a new video product, or a move from GB-based pricing.
If there’s one thing to take away from Mux’s video pricing model, it’s that minutes are everything. Minutes encoded, minutes stored, and minutes delivered are the foundation of your video bill. Mux Robots workflows are billed separately in units. We’ve written previously about why we think this is a better way of charging for video.
You can find all of our costs on our pricing page, but you may be wondering how you can calculate estimates using these numbers. We’re going to outline a couple ways you can do this so you can be confident that you can predict your costs at any time.
For a new on-demand project, basic quality is the default and has free input. Each month includes 100,000 free delivery minutes and 100,000 free Mux Robots units, with a $20 monthly usage credit on pay as you go. Include Robots workflows in your estimate when you use them.
If you’re building a user-generated content platform (UGC), then encoding & storage is going to be a big consideration for you. Most UGC platforms follow some kind of power-law distribution, where a small percentage of the content makes up a large amount of views (in YouTube’s case, for example, much less than 1% of the content uploaded makes up much more than 99% of the views.
Your split might not be as extreme, maybe it’s close to 95/5, 90/10 or even 80/20, but this is the general tendency that we see for UGC platforms. You will want to consider using the basic video quality level, which is $0 encoding and pairing that with Automatic Cold Storage so that you get a cheaper storage rate for assets that are rarely viewed.
Keep new uploads, stored video, and viewing separate: a large library can have little delivery. Adding 1,000 minutes each month without deleting any gives you a library of 1,000 minutes at the end of month 1, 6,000 at month 6, and 12,000 at month 12. Include any existing library, but count its migration as input only once. See storage billing for proration and basic quality’s one-month minimum.
If you have an existing application, you can use your existing usage patterns to estimate how much video your users might watch. If you don’t have any existing users to benchmark off of, estimating will be a little trickier. For example:
Use the time people actually watch, rather than assuming they finish every video. If you use an assumed completion rate, label it; measured average watch time already accounts for partial viewing.
If you’re launching something entirely new, then we recommend making 3 separate estimates where you model scenarios that account for how popular your video might be. Here’s some examples:
Now, for each of those 3 scenarios you can plug the results into the pricing calculator and get a range of costs. That range might be large, but you will have a good idea of how your costs will look depending on the uptake of your users.
For live streaming, multiply stream duration by average concurrent viewers. Ten two-hour streams with an average of 50 viewers produce 1,200 input minutes and 60,000 watch minutes, before allowing for buffered delivery. Total registrations and peak concurrency are different from average viewership.
Live streaming requires plus or premium quality, so input is billable. Include storage for recordings you keep and any later on-demand viewing.
Some services charge for video based on file sizes, either stored or as bandwidth for delivery. There’s a couple ways you can compare these costs with Mux’s minute based pricing. These will only be a guide because 1GB of video can vary in duration depending on the bitrate, but we can use some estimates that will work for common video encoding settings and work from there.
For a migration, start with the total duration of your videos, or asset count × average duration. Check whether your current storage includes multiple renditions, backups, or other files; Mux does not multiply ordinary video storage minutes by the number of streaming renditions.
At an assumed average total bitrate of 5.33Mbps, the pricing calculator’s default for 1080p, 1 minute of video is about 40MB, or about 25 minutes per decimal Gigabyte. Resolution alone does not determine bitrate.
Here’s some example conversions based on how many gigabytes you might have using this as a base:
| Video (1080p, assumed 5.33Mbps) | Estimated minutes |
|---|---|
| 1GB | 25 minutes |
| 10GB | 250 minutes |
| 100GB | 2,500 minutes |
These examples use decimal GB and exclude overhead. With a known average total bitrate, minutes = GB × 8,000 / (Mbps × 60). If the bitrate is an assumption, label the resulting estimate accordingly. The pricing calculator lets you adjust that bitrate.
Here’s some estimates using the calculator’s default bitrate for each resolution; your videos may use different bitrates:
| Resolution and assumed bitrate | Estimated minutes per GB |
|---|---|
| 720p (3.33Mbps) | 40 minutes |
| 1080p (5.33Mbps) | 25 minutes |
| 1440p (2K, 8.8Mbps) | 15.2 minutes |
| 2160p (4K, 13.33Mbps) | 10 minutes |
You might be used to thinking of delivery in terms of how many views a video had, as that’s a good metric for how popular a video is. From Mux’s perspective, 1 person viewing a video for 10 minutes is identical to 10 users watching a 1 minute video each. When you add it all up, 10 minutes of video has been delivered, and that’s how it will appear on your bill.
Mux bills on minutes delivered even if they weren’t watched. If a viewer starts playing a 20 minute video, they might only watch 5 minutes. Additionally, the player might have preloaded an extra minute of video that the viewer never saw. From a billing perspective, this is 6 minutes of delivery even though that extra minute was never seen, because we still had to deliver it to the client as requested by the player.
Delivery is also priced by the resolution viewers receive. Uploading at 1080p does not mean every minute is delivered at 1080p.
Whether a looping video is charged for one playthrough or for each time it repeats depends on the caching behavior of the browser and player being used. If the browser is not clearing out its buffers while the video is repeating then subsequent loops are not going to be charged for delivery, because we never see new requests for the video to our infrastructure as the video loops.
It's difficult to predict and control this browser behavior though. There are also physical limitations as to how much video can be stored in memory before some has to be removed.
In general, the shorter a video is, and the fewer renditions that are being switched between during playback, the more likely that the video will remain in the browsers buffers. Videos that are longer than roughly 60 seconds are likely to stretch what can fit in a browser's video buffer and lead to more requests (and delivery charges).
Configuring your player to use a single rendition instead of multiple ones can make it easier for a browser to cache video, but at the cost of forcing a single resolution onto users regardless of their bandwidth. If your videos are particuarly short, you could try using static MP4s instead of the default HLS delivery.
The published tables show pay-as-you-go rates, including automatic volume discounts. Mux also offers custom contract pricing for larger workloads, with additional discounts available above $3,000/month. Contract rates are negotiated separately and aren't published in these tables. A calculation using public rates is a pay-as-you-go estimate; a contract budget requires a quote from Mux.
For more information about Mux video billing see our main pricing page.