-
Which pi is it?
Zero W!
Also, what is the command line you're using to invoke ffmpeg? Maybe you're missing some threading/optimisation options..
Most likely yes, it's currently 14 minutes into processing at crf 51 which is lowest quality...
ffmpeg -r 20 -i image%04d.jpg -r 20 -vcodec libx264 -crf 51 -vf scale=1280:720 output.mp4Fwiw the images are captured at 1280:720 too.
I can't figure out why -r 20 is needed as part of the input, it's on my list of things to drop out and see what happens.
rhb-
Ah, Zero W. Not much oompf there as it's a single core 1GHz chip. But they are cheap and great for this kind of thing.
"-r 20" specifies a 20fps frame rate. I don't think specifying it twice would be a cause of any performance problem.
The -crf is the x264 quantizer 'constant rate factor' and the range is 0-51. A lower number is higher quality, so you're already at the lowest (and hopefully fastest) option there.
If the input images are already 1280x720 then I wonder what happens if you remove the whole "-vf scale=1280:720" section. You may be getting a performance hit of it having to pass everything through the scale filter only for it to end up doing nothing. If it is required (as without it you get something a different size) you could try "-s 1280x720" instead but that's just a stab in the dark.
Other than that I think the only other option for making it faster is to use a different vcodec that may not do as much compression (and therefore be faster, but lead to bigger output files).
(I'm not a ffmpeg expert at all, I've used it a couple of times, but on high powered machines where I haven't had to optimise it as stuff just runs quickly regardless.)
Greenbank
Interesting project. Which pi is it? Would have expected a pi 4 to be a bit faster than that, and wouldn't be surprised if an earlier pi was that slow.
Also, what is the command line you're using to invoke ffmpeg? Maybe you're missing some threading/optimisation options...