Financial cost of video transcoding
Whether you're transcoding a given video using a serverless code function, or a dedicated transcoding service, you need to consider that it is often an expensive thing to do (in the context of a website).
Cost comparisons
If you're using a serverless code function to do any sort of video transcoding, the chances are it will be for 480p or 720p versions of fairly short videos (anything else will be beyond what a serverless code function is capable of handling).
This is undoubtedly cheaper than dedicated transcoding by a considerable margin, but it is still very expensive when compared to e.g. image transcoding, due to the larger amount of processing time involved. Below are a few reference figures I tested, as an example of the order of magnitude of difference involved.
Table Notes
- The Lambda function is assigned 10240MB of memory, i.e. it is running on the maximum CPU power available to it.
- The cost of transcoding is based on execution time for Lambda, and based on the video runtime for MediaConvert, per AWS' pricing structure for each service.
File details | Resize to | Method | Codec | Time to transcode | Cost | Cost increase vs previous entry |
4000x2500 PNG, 10MB | 640x480 | Lambda | JPEG | 2000ms | ~$0.00034 | N/A |
1920x1080 x264 video, 50s | 640x480 | Lambda | x265/HEVC | 82000ms | ~$0.014 | + ~4000% |
1920x1080 x264 video, 50s | 640x480 | MediaConvert | x265/HEVC | 24000ms | ~$0.028 | + 100% |
1920x1080 x264 video, 50s | 1280x720 | MediaConvert | x265/HEVC | 29000ms | ~$0.056 | + 200% |
Transcoding one 1080p video to 480p costs roughly the same as transcoding 40 images to 480p, whilst transcoding that video to 720p costs roughly the same as transcoding 240 images to 480p. You can see how this grows to be a very large cost if you're transcoding a lot of videos, especially long ones.
Encoding costs versus bandwidth savings
If a video gets a sufficiently high number of views (assuming that 1 view involves viewing the whole video), then the cost to encode it with x265/HEVC will be smaller than the saved CDN costs of serving the video to users. The exact threshold will depend on the cost of your encoding provider, and also the filesize saving of encoding the given video to x265/HEVC versus x264.
For the example scenario below, I'm using BunnyCDN's premium encoding service.
Example scenario
Assume we have a video file with the following attributes:
- Duration: 3 minutes
- Resolution: 1920x1080
- Filesize: 500MB
- Codec: x264
Even if the desired output codec on the CDN is x264, it will still be re-encoded. Let's assume the resulting filesizes look like this:
- Re-encoded to x264: 300MB
- Re-encoded to x265: 150MB
Let us further assume that:
- CDN bandwidth cost is $0.005/GB (BunnyCDN's volume pricing)
- Encoding cost for x265/HEVC is $0.075 per minute of video
We now have a few variables that will give us a formula for determining how many views are needed for encoding this video to x265/HEVC to be worth the encoding cost.
Full encoding cost = $0.075 x 3 = $0.225
Total bandwidth saving per view (assuming each viewer watches the entire video): 300 - 150MB = 150MB
CDN bandwidth cost saving per view = $0.005 x (150 / 1000) = $0.00075
Views required to break even on encoding cost = $0.005 / $0.00075 = 300
If the video gets more than 300 full views, then the encoding cost will be cancelled out by the CDN bandwidth cost reduction, and anything above 300 full views will be a net saving.
Limitations of the example scenario
Video view percentage
In practice, videos are loaded in segments via HLS streaming in most cases, meaning that the majority of views on a video will not be loading the entire video. This means we can't assume one view is equal to using bandwith of the full video's file size; it is better to estimate what percentage of the video an average viewer will watch and estimate from there.
For example, if the average viewer watches 20% of a given video, then 300 views of that video corresponds to total bandwidth use of 60 times the video's filesize.
Video upload permanence
If your site hosts user-uploaded videos, you have no guarantee that a user who uploads a video is definitely going to keep that video uploaded indefinitely, or that they won't immediately delete it to replace it with another video, e.g. in case of an error or testing something.
If you encode the video whenever the upload occurs, you incur the encoding cost regardless, so you will want to add a certain contingency percentage onto your break even calculation to account for videos that get uploaded and encoded, but are then re-uploaded or deleted.