# Video processing API tools compared

Canonical: https://rendobar.com/blog/video-processing-api/
Author: Abdelrahman Essawy
Published: 2026-08-20
Updated: 2026-09-13

---

## Key takeaways

- There are 4 categories of video processing tool and they are not substitutes. Picking the wrong category costs more than picking the wrong vendor inside one.
- Raw FFmpeg APIs bill per job or per GB. Our own median across 447 recent FFmpeg jobs was $0.0025 and all 425 were under a cent.
- AWS MediaConvert bills $0.0075 per normalized minute on the Basic tier in US East (Ohio), dropping to $0.0038 above a million minutes, with no free tier.
- Mux bills three separate things: encoding from $0.025/min, storage from $0.0024/min/month, and delivery from $0.0008/min with 100,000 delivery minutes free.
- The question that picks your category is not price. It is whether you are running a command, describing an output, streaming to viewers, or transcoding a library.

I build one of the tools in the first category. Every price below was read off the vendor's own live page on **2026-08-20**, and where a number could not be verified it is marked rather than estimated.

## Short version

"Video processing API" describes four products that do not substitute for each other.

| Category | You send | Billing shape | Examples |
|---|---|---|---|
| **Raw FFmpeg API** | an FFmpeg command | per job, per GB, per command | Rendobar, Rendi, RenderIO, ffmpeg-api.com |
| **Template / timeline API** | a JSON description of the output | per minute of output, per render | Shotstack, Creatomate, Bannerbear, Transloadit |
| **Video platform** | a file, then viewers stream it | encoding plus storage plus delivery | Mux, api.video, Cloudinary |
| **Batch transcoder** | a job spec, inside your own cloud | per normalized minute of output | AWS Elemental MediaConvert |

Most bad choices in this space are category errors rather than vendor errors. Someone picks a streaming platform to do batch transcoding, or a timeline API to run a filter graph, and the price they compared was never the price they were going to pay.

## Category 1: raw FFmpeg APIs

You send the command you would type in a terminal. The service runs it and hands back the output.

This is the right shape when you already know FFmpeg, when your pipeline is a filter graph rather than a layout, and when you want the full surface of the tool rather than the subset a vendor chose to expose.

Costs here are small and per-operation. Across our own **1,770 billed jobs** between 2026-03-17 and 2026-08-20, the median job cost **$0.0028** and **85.1% cost under a cent**. Narrowing to FFmpeg jobs specifically, the last **425 runs had a median of $0.0025**, a 90th percentile of **$0.0042**, and every single one came in under a cent. Those are short clips, and cost scales with compute time.

The category prices in at least four incompatible units, though. Rendi bills per GB from $0.10, RenderIO bills per command from $12/mo for 500, ffmpeg-api.com bills GB-seconds, and Rendobar bills compute time. [FFmpeg API pricing compared](/blog/ffmpeg-api-pricing-compared/) runs one real workload through all of them and two of them come out at $0.

## Category 2: template and timeline APIs

You describe the output as data. A JSON timeline, an Assembly, a template with merge fields. The service figures out the commands.

This is the right shape when the person composing the video is not an engineer, when you are producing many variations of one design, and when the work is layout and text rather than codecs and filters. A marketing team generating ten thousand personalised clips from a spreadsheet wants this and would be miserable writing FFmpeg.

It is the wrong shape when you already have a working FFmpeg pipeline, because you will spend the project translating it into someone else's format and you will hit the edge of that format eventually. Free tiers here often watermark output, which makes them evaluation rather than production.

## Category 3: video platforms

You upload a file and viewers stream it. Encoding is one line item among several, and usually not the largest.

Mux is the clearest example of the pricing shape. It bills **three separate things**: input encoding from **$0.025/min for 720p** on the Plus tier and **$0.0384/min** on Premium, storage from **$0.0024/min/month** at 720p rising to **$0.0096** at 4K, and delivery from **$0.0008/min** at 720p rising to **$0.0032** at 4K. The free tier is **100,000 delivery minutes a month** and up to **10 stored videos**, with no card, and the pay-as-you-go plan carries a **$20 monthly usage credit**.

Compare the encoding line alone against an FFmpeg API and the platform looks expensive, because $0.025 per minute of 720p input is an order of magnitude above a per-job FFmpeg charge on short clips. That comparison is wrong. You are not buying encoding, you are buying an adaptive bitrate ladder, a player, storage, a CDN and the delivery. If you need all of that, assembling it from an FFmpeg API and an object store is a project, not a saving.

If you do **not** need delivery, and the video is an artifact your application produces rather than something viewers stream, a platform is the wrong category and its storage line will bill you monthly forever for files you touched once. Mux, for one, keeps outputs in Mux and offers the master file as a download link that expires after 24 hours, not as a delivery into your bucket.

## Category 4: batch transcoders

You describe an output spec and it converts a library, inside your own cloud account, with your own storage and IAM.

AWS Elemental MediaConvert prices in **normalized minutes**, where the output duration is multiplied by a factor for resolution, codec and frame rate. On the Basic tier in **US East (Ohio)** the first 100,000 normalized minutes bill at **$0.0075**, the next 900,000 at **$0.0053**, and the next 19 million at **$0.0038**. There is **no free tier**.

At those rates, per unit of output, a large-volume simple transcode is cheap and gets cheaper. That is the whole design. What you pay for it is that the job spec is verbose, the normalized-minute multipliers make forecasting harder than a flat rate, and everything lives inside one cloud's permissions model. It is a poor fit for a handful of jobs and an excellent fit for a million.

We are not going to publish a head-to-head number against our own per-job pricing here, because the units genuinely do not convert. A normalized minute depends on a multiplier table for the exact codec and resolution, and our own figures are per job on short clips. Multiplying our way to a comparison would produce a confident number built on two assumptions, which is the thing this post is arguing against.

## Picking a category in six questions

**Are you running a command, or describing a result?** A command means category 1. A result means category 2. This one question eliminates half the market and almost nobody asks it first.

**Do viewers stream the output?** If yes, you need encoding, storage and delivery, and that is category 3 whether you buy it as a bundle or assemble it. If the output is a file your app hands to one person, you do not.

**How many, and how big?** A few thousand short operations a month is category 1 territory and costs single-digit dollars. Millions of minutes of straightforward transcode is category 4 and the per-unit rate is what matters. In between, both work and the free tiers decide it.

**How long is your longest job?** This is the limit that stops people, it never appears in a headline price, and it varies wildly. RenderIO caps a command at 1 minute on its entry plan and 20 minutes at $99/mo. Rendi's free tier caps at 1 minute. Check it before anything else in the fine print.

**Does the output have to land in a bucket you own?** Platforms keep it, and several raw FFmpeg APIs do too. Batch transcoders write to your storage by design, and some APIs in categories 1 and 2 deliver there with an access key or an IAM role. [Video APIs that deliver output to your own bucket](/blog/video-api-output-to-your-bucket/) sorts 13 services by exactly that.

**Is the caller an AI agent rather than your code?** That changes the answer, because the agent picks the parameters and decides how many jobs to run. [Wiring video tools into an n8n agent](/blog/n8n-ai-agent-video-tools/) covers the three decisions that matter there, starting with never letting an agent poll a long job.

## Where this stops

Prices move. Everything here was verified on 2026-08-20 against the vendor's own page, and the AWS figures in particular are one tier in one region, quoted from the example on their pricing page rather than from a full rate card.

The cost figures for category 1 are our own measured workload of 1,770 jobs, mostly short clips on small files. That is a real distribution and it is not yours. Nothing here extrapolates from short clips to long-form video, and we deliberately did not compute the cross-category comparisons that would require it.

Category 2 and 3 are described from their pricing models rather than from measured jobs, because we have not run production volume through them. Treat those sections as a map of how the billing works, not as a benchmark.

This post does not rank vendors on reliability, latency, support or feature depth. It sorts them into shapes, which is the decision that comes before all of those.

For the FFmpeg-command category specifically, see [the best FFmpeg API in 2026](/blog/best-ffmpeg-api/) and [free FFmpeg API options compared](/blog/free-ffmpeg-api/). For what a single operation costs and why, see [FFmpeg encoding settings measured](/blog/ffmpeg-encoding-settings/).
