Přesně tak. Ještě bych zvážil, pokud tolik nezáleží na času a CPU komprese:
Ano, výběr výpočetně náročnějšího presetu je samozřejmě další možnost. Ale většinou to opravdu začne dávat smysl v momentě, kdy jsem omezený velikostí/bitratem a mám třeba trochu komplikovanější scény (šum, déšť, kresba v tmavých plochách nebo hodně pohybu).
Ještě dodám, spíš pro info a tazatele, kdyby si s tím chtěl hrát (přestože zrovna u tohohle relativně jednoduchého videa z MSG, mi přijde, že by se to začalo výrazněji projevovat až tak na polovičním bitrate okolo 6-8 Mbit/s, pro pokusy bych dal spíš typově něco jako sport nebo jízdu na horské dráze
Pokud se u x265 jen přepne na vyšší preset (z medium na slow, případně slower), tak se bez úpravy CRF výsledný soubor typicky zvětší. Krom zmíněného delšího lookaheadu, to ovlivní např. i pohybovou analýzu - zapne to pokročilejší partitioning v prediktoru, star ME, zvýší se počet iterací v subpel ME atp.
Jinak řečeno, je tam víc detailů k zakódování.
Takže je třeba kompenzovat vyšším CRF nebo QP pro případné snížení velikosti, pokud o to jde.
- -x265-params pools=none (nebo třeba 4) - vypnutí multithreadingu, x265 nějak paralelizuje přes snímky a má pak prý horší kompresi, protože nemůže využít všech rozdílů mezi snímky
Tohle bych úplně nedělal. Sám jsem šoupal s poolem akorát v případě, kdy jsem řešil souběžný běh na dvou-socketovém transkódovacím serveru, s více souběžnými úlohami.
Ale k meritu věci. Ano teoreticky při nějakých hodně dynamických scénách a specifickém nastavení to může zhoršit predikci pohybu, i alokaci (RC). Ale mimo nějaké patologie to bude ve výsledku se budeme bavit max. o nějakých hodnotách třeba do procenta velikosti se stejnou degradací.
Pokud bych měl tvrdý velikostní limit, čas si s tím hrát a něco by se mi třeba začalo obrazově sypat, bylo by to až někde na konci těch možných optimalizací. Je tam x dalších a podle mě zásadnějších parametrů, které můžou ovlivnit kompresi (např. ten výčet, co ovládá, parametr film-grain, různé parametrizace přes vážení).
A když už bych chtěl tohle vypnout, tak spíš sáhnu po parametru --frame-threads a ten nastavím na 1 (nebo kolik chci).
Pokud nastavím pools=none, tak nejen že to komplet vše serializuju (včetně věcí, co nemají vliv na výstup) a bude to líné jak vandrácká hůl, protože komplet vypnu asynchronní workery, ale implicitně vyruším i paralelizaci při zpracování CTU (32x36 nebo 64x64 px ekvivalent makrobloku z MPEGu) v rámci snímku.
Tam se používá tzv. WPP, kdy se každý z nich se referencuje na dva okolní (první nad, druhý nad a vpravo). Takže jakmile se udělají první dva CTU, může se spustit další paralelní počítání na řádku pod ním. Což samozřejmě výrazně zrychlí kódování a obráceně i dekódování. Je tam s tím i nějaký drobný overhead ve streamu, protože se musí přidat nějaká metadata a pointery pro skoky na začátky každého řádku, plus se lehce může dál zvětšit stream, kvůli zvýšené entropii z paralelního kódování řádků (vs celého snímku).
Pokud ve streamu tyhle metadata a pointery vůbec nejsou, tzn. když se implicitně vypne WPP, tak pak nemůže paralelizovat ani dekodér a vypneš jednu z výrazných fíčur HEVC. Což já většinou nechci (bude samozřejmě rozdíl, jestli je tam nějaký HW offload, kterému to nevadí dekódovat sekvenčně po jednom CTU a jestli je tam třeba 480p vs 8K. atd.).