Comparing online encoders can be a difficult task, especially when it comes to price. For encoding services like Zencoder, there isn't one pricing model that works perfectly and is easy to understand by everyone, so each encoding service has made their own choice on how to charge customers.
The three models currently used are:
Video Duration (minutes of output video)
Video File Size (gigabytes of input and output)
Encoding Server Time (months of encoding machine usage)
Starting from the bottom.
Encoding Server Time
Encoding server time is probably the easiest method for an encoding service to implement. It's basically the cost that the service pays for the encoding servers (using EC2 or other) plus a margin to cover other costs and the desired profit. This also makes it safest for the service because an encoding job has little chance of costing more for the service than they are charging the customer.
There are a few downsides to this method for customers though.
It's difficult to estimate costs. You have to understand how much time it takes to encode a video, and then what video attributes or encoding settings might affect that time, which you can't know until you try the service and see how fast their machines are or how good their encoding software is.
It doesn't encourage the service to encode faster (through faster hardware or better software). The faster they go, the less money they make.
It doesn't scale well. A service using this method is giving you access to the exact number of encoding servers your plan pays for (typically 1). No more, no less. If you get a spike in traffic, your one server can only encode so much at one time, so encoding slows down and your users wait longer. Alternatively, in times with low traffic (like late at night), your server sits there doing nothing while you're paying for it. Services that use either of the other pricing methods can distribute your jobs across many servers, so you'll see more consistent encoding speeds across traffic volumes, with less waste.
Pricing is less flexible. Services using this method will typically have high entry plan prices (e.g. $100), and large jumps between encoding volume levels. This is because pricing is based on the number of servers, and not the encoding jobs themselves. So if you need $101 worth of encoding time for the month, you have to pay for a whole extra server (another $100). Services using the other methods charge by the encoding job, so pricing is much more granular.
Video File Size
Currently the most popular model for encoding services is to charge by GB in/out. So $x.xx per gigabyte of input file size plus $x.xx per gigabyte of output file size. This model is easier to estimate than encoding server time for most customers. In a sense, the service is taking their bandwidth transfer costs (in/out) and adding a margin to cover their encoding costs and profit margin. With this model, customers can loosely calculate an individual job's cost if they know the input file size, and an estimated compression ratio.
Downsides include:
You can't calculate the exact cost of an encoding job before it's sent, because you don't know what the file size of the output will be (which in some cases could be larger than the input).
The service isn't encouraged to compress the video better. The smaller file sizes they create, the less money they make.
Video Duration (minutes)
The video duration pricing method is based on the length in time of the output video. So if you encode the full-length of a 10 minute video, your total cost is 10 minutes multiplied by the per-minute price of the service.
This is the model that we chose after hours of deliberation. Here's why:
Easiest to estimate costs. If you know how long a video is, you can know exactly how much the job will cost before sending it.
It encourages you to send your highest quality input, so we can send you the HIGHEST QUALITY output possible.
We can encode FASTER without losing money. The sooner we can get your file through, the more server time we have for other customers.
We can encode BETTER without losing money. Smaller files sizes at the same quality are good for everyone.
I hope that helps explain why we made the choice we did. Leave a comment if you have any questions around this.
