Vlákno názorů k článku
FFmpeg značně zefektivní vícevláknový běh od Michal Kubeček - osobně budu rád, pokud přestanou platit limity typu...

osobně budu rád, pokud přestanou platit limity typu toho, kdy pro kódování 1080p videa netřeba zásadně více než nějakých šest jader CPU

O takovém limitu nic nevím, u mne jich používá dvanáct (tedy aspoň s libx265).

Jo, ale přijde mi, že to nikdy neběží na plnou 100% efektivitu (ale na to bude mít velký vliv více faktorů, tedy nastavení všech nuancí komprese).

Těžko říct, na první pohled mi je naplno využívá (top ukazuje něco kolem 1100-1200% využití CPU, porovnání CPU a elapsed time vykazuje poměr ne moc pod 12). Ještě bych mohl zkusit ho nějak omezit na méně threadů a podívat se, jak to škáluje, ale to jsem zatím neměl potřebu.

Spíš mi občas vadí, že jak je těch threadů "jen" 12, tak když současně spustím jednu konverzi s niceness 18 a druhou s 0, tak každá obsadí jiných 12 logických CPU, ale v praxi jsou to jen druhé thready stejných fyzických jader (je to dvanáctijádrový Ryzen), takže z pohledu scheduleru si nekonkurují a ve výsledku se tím úplně eliminuje požadovaný efekt nastavené niceness.

Mám stejnou zkušenost. Mám maximálně fyzické 8jádra a konverze v ffmegu vždy jedou všechny a na plný výkon. Takže z mého úhlu pohledu podpora pro plně CPU vláknovou konverzi funguje několik let. Ale pokulhávala podpora pro GPU s CUDA. Nejedná se spíš o tuto podporu?

Bacha, ono není až tak důležité jestli jsou všechna jádra zatížená naplno, ale jak ten algoritmus škáluje. Čekání na spinlock zatíží procesor naplno a nic nespočítá.

Ano, toho jsem si vědom. Možná prostě jenom chtějí přeprogramovat a optimalizovat kód pro CPU. Nicméně radši bych byl proto aby pořádně vyřešily podporu pro GPU a hlavně kvalitně to popsali do dokumentace.

myslíte GPU pomocí hw enkodéru, nebo pomoci shaderů?