Re-encode with a higher -crf value. CRF is a quality target, not a size target: 23 is ffmpeg's default, 28 is noticeably smaller and still fine for most footage, and anything past 30 starts to show. Each +6 roughly halves the file.
The ffmpeg command
What you would run locally, for reference.
ffmpeg -i input.mp4 \ -c:v libx264 -crf 28 -preset medium \ -c:a aac -b:a 128k \ output.mp4
The API request
The same flags, sent as JSON. Authenticate with
Authorization: Token <your-api-token>.
{
"global_options": [
"-y"
],
"inputs": [
{
"input_source": "https://example.com/input.mp4"
}
],
"outputs": [
{
"filename": "output.mp4",
"options": [
"-c:v",
"libx264",
"-crf",
"28",
"-preset",
"medium",
"-c:a",
"aac",
"-b:a",
"128k"
]
}
]
}
Worth knowing
-presettrades CPU time for compression:slowgives a smaller file thanmediumat the same CRF, but takes longer — and here CPU time is what you pay for.- There is no quality to recover: compressing an already-compressed file degrades it again. Always re-encode from the highest-quality source you have.
What it costs
Jobs bill in processing seconds — the CPU time this one actually uses — with a floor of 25 seconds per GB pulled out of storage to run it, so a stream-copy still counts. Uploading the output and downloading it afterwards are free. See the plans.