Odpověď na názor

"Enkódování totiž nesvědčí multithread."

Svědčí ve smyslu výkonu. Odsuď-podsuď, ale svědčí, těch 24 vláken obvykle enkódování využívá, 32 možná míň, ale jak je vidět v testech, výkon pořád škáleuje.

"Protože je to sice rychlé, ale výsledkem je méně kvalitní obraz."

Na tomhle je zrnko pravdy, ale IMHO to pro praxi není moc relevantní.

Je to teda na delší povídání, ale v krátkosti vzniká neefektivita daná tím, že se snímek dělí na kusy, které se zpracovávají paralelně. Se zvyšováním počtu vláken se tedy trošku zhoršuje, alespoň teoreticky, efektivita komprese. Ale jako je třeba neleknout se hned, že "zhoršení komprese, néééé!!", je třeba brát v kontextu. Ve většině případů by mělo být hodně malé a nepostřehnutelné. Dá se to naměřit v SSIM a podobných metrikách, ale vizuálně a na výsledné bitrate to asi nepoznáte.
A taky: třeba mezi enkódováním v jednom vlákně a s 32 vlákny byste naměřili určitý rozdíl, ale mezi 24 a 32 vlákny bude rozdíl mnohem menší. Ještě ted důležitý detail: ten postih bude asi větší v nízkých rozlišeních, víceméně závisí na poměru vertikálního rozměru videa v pixelech a počtu threadů - takže když budete enkódovat 4K, tak je v tom bezpečně prostor pro víc vláken, než v 1080p a ten teoretický pokles kvality se značně umenší. Když budete s 32 vlákny zkoušet kódovat 720p nebo dokonce 360p video, tak si logicky koledujete o něco víc (ale lidi to dělají...)

Jako z toho, co znám enkódéry a tu praxi, tak tohle prakticky nikdo neřeší. Určitě ne rozdíl mezi 24 a 32 vlákny. Ten rozdíl tam prostě bude hrozně mizivý. Pokud by vás to trápilo, tak pořád uděláte líp (tedy když si odmyslím cenu), když pořídíte 32vlákno a použijete náročnější nastavení výkonu tak, abyste se dostali na stejný výkon, který by 24vlákno zvládlo se slabšími. A asi získáte kvality víc, než jste ztratili.

(Poznámka k tomu: ten dopad na kvalitu je hodně malý u x264, který používá frame-threading, který má obecně nejmenší pokles kvality kvůli rostoucímu počtu vláken, o něco málo horší to může být u x265, které používá frame threading+WPP, přičemž WPP (Wavefront Parallel Processing) teoreticky asi může vycházet o trošku hůř. Co je pravda, je že u kodeků Googlu - VP9 a AV1 s jejich enkodéry jako je libaom může být propad kvality o něco horší, protože používají nejméně efektivní formu threadingu - tile threads, v podstatě něco jako slice threads u H.264, jen jsou to šahcovnicoidní dlaždice místo pruhů přes celou šířku obrazu. Tudíž ienkódování v AV1, včetně asi při použití enkodéru SVT-AV1 bude ztráta kvality relativně o něco vyšší. V praxi to asi pořád není něco, čím se má cenu zabývat).
U x264 a x265 vám IMHO pravdu nehrozí, že třeba nastavíte --crf 16 a tím, že použijete 32vlákno místo 24vlákna se vám z toho stane ekvivalent crf 16.5. Dimenze té ztráty kvality bude na mnohem menší úrovni.

A závěrečná poznámka číslo dvě:
Pro lidi, které ten možný malý propad kvality štve, je tu řešení: můžete si video rozdělit na části a ty pak enkódovat paralelně, každou v jedné instanci enkodéru s parametrem --threads 1, prostě s vypnutým použitím více vláken. Po dokončení se výsledné fragmenty poskládají dohromady a máte video netrpící touhle teoretickou ztrátou.
Má to jednu nevýhodu: je pakárna mít otevřených 24 nebo 32 oken CMD.exe :) a žere to spoustu RAM. Ale ta možnost tu je.
Má to teda i praktičtější formu - stačí si to rozdělit třeba do čtyř kusů a každému nastavit použití čtvrtiny vláken (není to ale úplně přímočaře čtvrtina vláken procesoru...) proti tomu, kolik enkodér nastavuje automaticky. To není tak nezvladatelné a už jste eliminovali dost velkou část té teoretické ztráty.
BTW, v některých případech třeba s těma šestnáctijádrovými procesroama se použitím dvou instancí dá dostat z procesoru celkově vyšší výkon enkódování, takže přínos může být i v tom.
A obecně použití třeba dvou instancí je cesta, jak ten přínos 16jádrového/32vláknového modelu proti třeba 8/12jádru využijete a důvod, proč 16jádra (respektive 32vlákna) a eventuálně 48vlákna a 64vlákna mají nebo budou mít pro enkódování smysl.

TL;DR Ať tak nebo tak, nakonec pro enkódování ten vyšší počet vláken užitečný bude.