Tutorial · Migration guide
Migrate from FFmpeg to an Encoding API
You know FFmpeg. Here is every habit you have, translated into API calls — including the two or three places where the API behaves differently on purpose.
Direct translations
The command map
| FFmpeg | mlslabs API |
|---|---|
| ffmpeg -i in.mp4 -c:v libx264 -crf 23 out.mp4 | quality_target: {vmaf: 93} |
| -preset slow | preset: "archive" |
| -preset veryfast | preset: "streaming" |
| -vf scale=1920:1080 | scale: "1080p" |
| for f in *.mp4; do ...; done | batch queue + webhook per file |
| -fps_mode vfr | frame_rate: "source" |
Where the API differs on purpose
Bitrate → quality target: FFmpeg asks for a bitrate and hopes; the API asks for a VMAF score and guarantees it, letting bitrate vary per scene. Your output sizes will vary — that is the point.
Presets → scene presets: x264 presets trade speed for efficiency globally. The API's presets are content-aware (sports, streaming, archive), so one preset covers what took you three.
What to keep in FFmpeg
Everything pre- and post-encode stays in your pipeline: demuxing, filters, packaging. The API replaces only the encode step — feed it a file, get a file.
A realistic rollout
- 1. Re-encode one catalog with both, compare VMAF and size
- 2. Move the batch pipeline behind the API, keep FFmpeg for filters
- 3. Add webhooks and let the queue run unattended