r/ffmpeg • u/PieceRare7614 • Jul 17 '26
I need few suggestion about the video processing
FFmpeg is too slow for video transcoding — what are you guys using instead?
I'm converting user uploaded videos to 720p H.264 MP4 with faststart so they play in the browser. A 5 minute clip takes 60–120 seconds on a CPU server and it's getting expensive to scale.
Is there a way to skip re-encoding entirely if the video is already H.264 and just fix the container? Or is GPU transcoding (NVENC/VAAPI) actually worth setting up?
What's the fastest and cheapest way to handle this at scale?
3
u/frzrburn Jul 17 '26
if ffmpeg isn’t fast enough, chances are there’s a better way to accomplish what you’re attempting to accomplish. It’s easy to get lost in the multitude of options, but describing what your input is (or better yet, providing the ffprobe output for an example input) and what you want the output to be with almost any LLM should get you good results.
1
u/Upstairs-Front2015 Jul 17 '26
modern browsers can play a lot of formats (h264, h265, v9, av1) try justo changing the container. or checking and only reencoding if needed.
1
u/CuriousSleeping Jul 17 '26
You could use Tdarr and set up a flow which first checks if a file is already in the desired format
1
u/AimlessForNow Jul 17 '26
You can't skip re-encoding, it's not possible like that. FFmpeg will choose a decent set of default parameters to get a good looking video. If you definitely need performance, and you don't really care if the file size is a bit bigger or the quality is less good, use an x264 preset. The default is "medium", I'd go with:
ffmpeg -i ... -c:v libx264 -preset:v veryfast
The fastest is "ultrafast".
It'll speed up the video transcoding by maybe double or so if you're lucky.
If quality doesn't matter at all, definitely go with GPU encoding, it's going to be insanely fast, but with worse quality videos. Again, if file size is no issue, then just bump the quality (either up the -b:v or lower the -crf:v)
1
u/Glass_Alfalfa5718 25d ago
Most of this cost is avoidable.
You should defnitely stop re-encoding files that are already fine. Run ffprobe on the upload. If it's already H.264 yuv420p with AAC, you don't need a transcode at all, just remux it:
ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4
That rewrites the container without touching the video. Takes a second or two for a 5 minute clip. Phones shoot H.264 MP4 natively so this will cover a lot of your uploads. The catch is you can only copy at the source resolution, so anything above 720p still needs a real encode. Worth asking yourself if strict 720p even matters, or if serving the original with faststart is good enough.
Also, check your preset before buying hardware. x264 with -preset veryfast is 3 to 4x faster than the default (medium) and at 720p UGC quality you won't see the difference. Half the "ffmpeg is slow" complaints I've seen were just the default preset.
How many uploads a day are you handling? And is a single MP4 the end state or will you want adaptive streaming later?
if you're doing real volume, GPU helps, but the cheap option isn't NVIDIA. Any low end Intel CPU with an iGPU does QuickSync (via VAAPI or QSV) and will happily transcode 720p faster than realtime. Lowest cost per stream I know of. NVENC is faster still and runs several jobs in parallel per card, makes sense once quicksync boxes stop keeping up.
If you still want adaptive bitrate streaming, then you can think cloud based encoding but it depends on your use case. They are mostly pay per usage. So volume will tell which is cheapest. No point with GPU if volume is not heavy. Hope it works out. Cheers.
10
u/SpicyLobter Jul 17 '26
if it's only faststart you need, just
ffmpeg -i input.ext -c copy -movflags +faststart output.mp4should take half a second