You are reading a single comment by @rhb and its replies.
Click here to read the full conversation.
-
Ta. I appreciate I'm asking a lot of it, but it is interesting see what it can do.
I found crf 51 is poor. Back at 17 for my last timelapse video but it was too dusk by then, after a short youtube stream so I could adjust the focus as it was set for close up bird feeders still. At crf 17 it was about 45 mins to process.
Good point about the vf scale I'll try removing that to see how it behaves as a result.
I tried one other codec earlier, it's in a copy of the script but I've shut it all down now and cba to reopen to get its name. Output quality wasn't upto much but I could explore that avenue again.
From a quick skim google, opencv might give more options too.
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.)