jihadjoe wrote:Some options actually do.
--pools=n[,n] changes the number of threads per NUMA node
That doesn't increase the amount of threads used, rather, it tries (rather awkwardly) to ensure that threads are correctly distributed into the appropriate memory domains.
Yes, that has an impact on "core utilization" to a certain extent, but:
1) It's irrelevant unless you actually have a NUMA-machine, which almost always means dual sockets or more. It's almost beyond the scope of these forums these days. If you don't, like everything actually discussed in this thread and virtually everyone on these forums, it does absolutely nothing. EDIT: I guess the new top-tierthreadripper is an exception to this, since it actually forces a NUMA-aware configuration, so perhaps I'm being a little overhasty here. That's still like a $2k CPU alone though... EDIT2: Which means that this a great example of how talking about these things forces me to re-evaluate my pre-existing conclusions and understandings (which are out-of-date) in light of new developments in this space. These discussions are really good at that!
2) The scaling, even with uniform memory access, isn't terribly great when you get into the core counts a typical modern NUMA machine would have, to the point where the "work-around" is generally run multiple jobs in parallel, which you just tie to memory domains at the OS-level when it comes to using a NUMA machine for handbrake. (That is, if your machine costs more than a light truck, you're probably not hobbyist transcoding and likely have a ongoing workflow---to the point of "why handbrake, again"?)
3) This is entirely encoder dependent, not the the other constituent parts of Handbrake (like filters, audio, subtitles etc..). Those other things can easily negate any advantage it provides, because it's not just that one piece.
4) Is this even enabled in the regular handbrake build? It's not in the CLI documentation for it.
jihadjoe wrote:--frame-threads=n will allow encoding multiple frames simultaneously, thus allowing the encoder to use more cores/threads with a corresponding penalty in memory use.
That fundamentally changes the output. It's not the same encode anymore.
This also isn't exposed in the regular Handbrake build, as far as I know (again, not in the CLI documentation).
