Názory k článku
FFmpeg značně zefektivní vícevláknový běh

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ů?

Převáděl jsem nedávno pár VHSek do H.264 (převod z 25 či 30fps PAL/NTSC deinterlacem do 50/60fps PAL/NTSC a upscale na 720p, následně převod do H.264). Během přehrávání výsledného videa jsem v podstatě nepoznal pouhým okem rozdíl mezi tím, když video dlouhé hodiny kódoval procesor (x264, 2-pass, snaha o nějakou kvalitu) a když video kódovala Nvidia (rychlostí přes 300 fps). Takže jak to dělá procesor, mě dneska v podstatě už nezajímá.

Co jsem pochopil z dokumentace, tak 2pass je v podstatě přežitek a hodí se pouze pokud cílíte na konkrétní velikost souboru (např. CD 699MB). Pro běžné účely se mělo používat CRF a nastavit tím kvalitu výstupu, nikoliv bitrate. Z toho vyplývá, že druhý průchod je k ničemu.

Je nějaký rozdíl ve výsledku mezi CRF a 2pass? Připadá mi, že 2pass je jen jemné nastavení CRF podle prvního průchodu, aby to vyšlo na tu velikost.

Ano presne tak to je.

Jen aby bylo jasno - tímhle se zařizuje, že jednodlivé komponenty (decodery, encodery, filtry) mohou běžet současně. V situaci, kdy 95% výpočtu zabere encoding, to nepomůže.