FFmpeg API

Rendi ships a documentation MCP server at https://rendi.dev/docs/mcp. Install it in Claude Code, Cursor, or any MCP-compatible assistant, and the assistant gets authoritative access to Rendi's full docs: endpoint schemas, pricing tiers, quickstarts, and examples.

Rendi's docs are also published as plain markdown with an llms.txt index and an OpenAPI spec, so any assistant can fetch and ingest them directly — LLM-ready even without MCP.

Serverless platforms are where Rendi fits best. Vercel functions, Supabase Edge Functions, Netlify Functions, and Cloudflare Workers all have short timeouts (10s–150s) and restricted runtimes that don't allow system binaries like FFmpeg. Running FFmpeg in-process is effectively impossible on these platforms.

With Rendi, your function makes a short outbound HTTP call to submit the command and returns immediately. Rendi processes the job on its own infrastructure and calls your webhook (or you poll from a second short-lived function) when done. No queues, no container infrastructure, no bundled FFmpeg layer.

Self-hosting is fine for very low volume. Beyond that you own the full stack: auto-scaling config, OS and FFmpeg patching, on-call, uptime SLA, and security exposure.

Rendi scales automatically with demand, so architecture stays simpler: no server sizing, no capacity planning, and no video workers to run on your own servers.

FFmpeg's codec parsers have a long history of CVEs exploitable by crafted media files (buffer overflows, heap corruption in libavcodec). Self-hosting means those exploits target your infrastructure — RCE on your servers, lateral movement, data exposure. Rendi isolates every command in a disposable environment; malicious inputs never enter your systems.

Self-host if you're processing a handful of videos a month and already run servers. Run FFmpeg with Rendi for anything production-shaped.

Lambda's free tier looks attractive, but "zero setup" is a myth — Lambda requires layer packaging, IAM, log plumbing, retry logic, and ongoing devops. Hard limits: 15-minute runtime cap, ~6 vCPU ceiling (CPU scales with memory, which maxes at 10 GB), and 10 GB /tmp shared between input and output.

You also own DevOps setup, monitoring, patching, and incident response on Lambda — and FFmpeg codec CVEs still target your AWS account.

With Rendi all of that is managed. Rendi supports unlimited processing time on the unlimited-runtime plan, unlimited file sizes, unlimited processing scalability and up to 32 vCPUs per command (more available by request).

All three are DSL-based, not raw FFmpeg. Cloudinary is image-first with video transforms driven by URL parameters — no -filter_complex graphs, no dynamic expressions, no custom codec flags, and pricing grows fast with transformations plus bandwidth. Shotstack and Creatomate are timeline-based JSON DSLs; they work well for template-shaped video generation but cannot reproduce arbitrary FFmpeg commands.

Rendi runs the full FFmpeg surface — any command you can write locally works in production.

Pricing is also dramatically lower: Rendi is about $0.15 per GB processed, versus Cloudinary at $1.20/GB, Shotstack at $2.30/GB, and Creatomate at $10.25/GB — 8–68× cheaper.

Read the full comparison.

MediaConvert is enterprise-priced, IAM + S3 coupled, and billed per output-minute with separate rates for resolution and codec. Starting takes IAM roles, S3 buckets, and job queue setup.

It's also a curated transcoder, not raw FFmpeg — outputs are limited to AWS-supported codec and container combos, and you can't run arbitrary filter graphs, dynamic expressions, or encoder flags outside AWS's matrix.

Rendi runs the full FFmpeg surface with flat per-processing-GB pricing, no egress or ingress fees, and zero AWS setup — significantly cheaper and quicker to integrate.

Yes. Rendi stores every command output automatically with a stable URL — no egress or ingress fees.

Yes. Rendi runs standard FFmpeg commands — the exact syntax you'd run locally. That includes -filter_complex filter graphs, dynamic expressions (e.g. crop=iw:ih:'if(gte(t,2),...)'), chained filters, complex audio pipelines, and every FFmpeg flag shipped in the standard build. Test locally, send to Rendi, get the same output.

See working FFmpeg examples in the docs.

Rendi runs FFmpeg jobs — you submit a command, it processes, and you get the output. A couple of things are out of scope.

Live streaming commands: continuous RTMP/SRT/HLS push, real-time -re inputs, and device captures (v4l2, x11grab) need a persistent long-running process.

Standard plans are CPU-based — enough for nearly all FFmpeg workloads. GPU gives roughly 30% speedup on heavy encodes and is available on custom requests.