>>718923>You should use VBR, ideally 2 pass.Of course, but I'm trying to explain the basic structure of an ffmpeg command to someone who lead with
>i'm not that good with commandsIf you want to hit a first-timer with the finer points of 2passing - be my guest. It's better, I use it all the time, I still think it's a terrible intro to encoding with ffmepg or in general.
But isn't this discussion beside the point? That poster complained about "CBR" which I'm still pretty sure is nowhere to be found in my commands. Constant quality mode is very much not constant bitrate mode.
>Get limited by core count (because fuck hyperthreading)Maybe I'm missing something here, but is there a point of using more threads than cores? At least for me it almost maxes out a core per thread anyway.
>and width of videoInteresting. I'll be honest, I can't reproduce it. Encoding a 720p down to 604x340 (ie under the 640 width threshold you linked) with -threads 4 uses 4 cores at ~80% total. If I repeat it with -threads 1 it uses 1 core (~25% total) and takes over three times as long.
Just to confirm I re-encoded 492x280 VP8 with VP8 again (in case the source matters) and got the exact same result (80% vs 25%).
I'm not enough of a programmer to make sense of the code you linked, but your implication is definitely wrong (as is the statement above "libvpx won't use 4 threads"). -threads does *something* (and something quite significant I might add) even on very low-width files.
