Proč je procesor “ lepší ” pro kódování než GPU?

Článek, který jste propojili, není příliš dobrý.

Jednopásmové kódování bitrate obvykle převede váš bitrate na hodnotu RF pomocí maximální limit bitrate a odtud jej vezme.

x264 „one-pass ABR ratecontrol není implementován jako limit CRF +. Má pravdu, že 2pass je zdaleka nejlepší způsob, jak zasáhnout cílový datový tok.

A zjevně si neuvědomuje, že by mohl spustit x264 s threads = 3 nebo tak něco, aby ponechat trochu času CPU pro další úkoly. Nebo nastavte prioritu x264 na velmi nízkou, takže získá pouze čas CPU, který žádný jiný úkol nechce.

Také míchá vlákna = 1 s použitím CUDA nebo tak něco. Není divu, že máte otázky, protože to článek má DŮLEŽITÉ vysvětlení. Celý článek se v zásadě scvrkává na: použijte x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, nebo možná použijte filtrování světla se vstupním skriptem AviSynth. Vlastně doporučuje “ placebo „. To je povedené. Nikdy jsem neviděl pirátský soubor kódovaný placebem. (Poznáte to z me=esa nebo me=tesa, místo me=umh pro všechny přednastavení dobré kvality, a to až do veryslow.

Nezmínil také použití 10bitové barevné hloubky. Pomaleji kódování a dekódování, ale i po downconvertingu zpět na 8bit získáte lepší 8bitový SSIM. Zjevně pomáhá mít větší přesnost pohybových vektorů. Také nemusí být zaokrouhleno na přesně celou 8bitovou hodnotu. Můžete myslet na 8 -bit na komponentu jako speed-hack; kvantování ve frekvenční doméně a následná komprese pomocí CABAC znamená, že vyšší koeficienty bitové hloubky nemusí zabírat více místa.

(BTW, h. 265 získává menší výhodu z 10bitového kódování pro 8bitové video, protože již má větší přesnost pohybových vektorů. Pokud je výhodou použití 10bitového x265 pro 8bitové video vstupy, je to menší než u x264. Je tedy méně pravděpodobné, že rychlostní trest bude vadný Stálo by mi to za to.)

Odpověď na vaši aktuální otázku:

edit: doom9 je nyní opět nahoru, takže uklidím odkaz. Přejděte na to a správně citujte, kdo co řekl.

http://forum.doom9.org/showthread.php?p=1135399#post1135399

Google ukládá do mezipaměti pouze tu hloupou tiskovou verzi, která řádně nezobrazuje citace. Nejsem si úplně jistý, které části těchto zpráv jsou uvozovky a které jsou připisovány samotné osobě.

Vysoce nepravidelné vzory větvení (režimy přeskočení) a bitová manipulace (kvantování / entropické kódování) nevyhovují GPU. IMO jediný opravdu dobrou aplikací v tuto chvíli jsou plně prohledávané algoritmy ME, nakonec je zrychlené úplné vyhledávání stále pomalé, i když je rychlejší než na CPU.
– MfA

Ve skutečnosti lze na GPU v podstatě všechno rozumně udělat, kromě CABAC (což by se dalo udělat, prostě by to nebylo možné paralelizovat).

x264 CUDA implementuje fullpel a zpočátku subpelovat algoritmus ME; později jsme mohli udělat něco jako RDO s přístupem s bitovými náklady ximation místo CABAC.

Protože musí dělat vše s plovoucí desetinnou čárkou s jedinou přesností
– MfA

Špatně, CUDA podporuje celočíselnou matematiku.

– Dark Shikari

Dark Shikari je správcem x264 a vývojářem většiny funkcí od roku 2007 nebo tak nějak.

AFAIK, tento projekt CUDA se neprojevil. Existuje podpora pro použití OpenCL k odlehčení práce z vlákna lookahead (rychlé rozhodnutí I / P / B, ne vysoce kvalitní konečné kódování rámce).

Moje chápání je, že vyhledávací prostor pro kódování videa je tak velký, že inteligentní heuristika pro předčasné ukončení vyhledávacích cest na procesorech porazí GPU hrubou silou přinést ke stolu, alespoň pro vysoce kvalitní kódování. Je to jen ve srovnání s -preset ultrafast, kde byste mohli rozumně zvolit HW kódování nad x264, zejména pokud máte pomalý procesor (jako notebook se dvěma jádry a bez hyperthreadingu). Rychle CPU (čtyřjádrový procesor i7 s hyperthreadingem), x264 superfast bude pravděpodobně stejně rychlý a bude vypadat lépe (se stejnou bitovou rychlostí).

Pokud vytváříte kódování, kde vůbec záleží na zkreslení rychlosti (kvalitě na velikost souboru), měli byste použít x264 -preset medium nebo pomalejší. Pokud ano “ znovu archivujete něco a nyní strávíte trochu více času procesoru a ušetříte bajty, dokud „budete tento soubor stále udržovat.

poznámka, pokud se vám někdy ve videohovoru zobrazí zprávy od deadratů, tak“ to nebude užitečné. Ve většině témat, o kterých mluví, se mýlil v každém vlákně, které jsem kdy viděl. Jeho příspěvky se objevily v několika vláknech. Vyzkoušel jsem kódování x264 GPU. Zjevně nechápe, proč to není snadné, a několikrát zveřejnil, aby vývojářům x264 řekl, proč jsou „hloupí …

Aktualizace pro rok 2017:

ffmpeg podporuje kódování videa h264 a h265 NVENC pomocí akcelerovaného GPU . Můžete provádět 1pásmové nebo 2pásmové kódování v kvalitě, kterou si vyberete, buď pro hevc_nvenc nebo h264_nvenc, nebo dokonce s GPU základní úrovně je to mnohem rychlejší než nezrychlené kódování a zrychlené kódování Intel Quick Sync.

Vysoce kvalitní dvouprůchodové kódování:

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4 

Jednoprůchodové výchozí kódování:

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4 

Nápověda a možnosti NVENC ffmpeg:

ffmpeg -h encoder=nvenc 

Použijte jej, je to mnohem rychlejší než kódování CPU.

Pokud nemáte GPU, můžete použít kodek Intel Quick Sync, h264_qsv, hevc_qsv nebo mpeg2_qsv, které jsou také mnohem rychlejší než nezrychlené kódování.

Komentáře

• Použijte jej pokud oceníte rychlost (a nízké využití procesoru) nad kvalitou na velikost souboru. V některých případech použití, např. streamování na twitch, ‚ je to, co chcete (zejména nízké využití procesoru). V jiných případech, například kódováním jednou vytvoříte soubor, který bude mnohokrát streamován / sledován, stále ještě nebude porazit -c:v libx264 -preset slower (což není tak pomalé, jako v reálném čase pro 1920x1080p24 na Skylake i7-6700k.)
• Díky použití ffmpeg s -vcodec h264_qsv na mém starém notebooku Intel s Intel HD Grpahics 4000 bylo vykreslení mnohem rychlejší!

Chcete-li dále rozvinout, co říká Peter, obecně použití více procesorů pomáhá v případech, kdy máte několik nezávislých úkolů, které všechny je třeba udělat, ale nemáte na sobě vzájemné závislosti, ani jeden úkol, kde provádíte stejnou matematiku na velkém množství dat.

Pokud však potřebujete výstup výpočtu A jako vstup výpočtu B a výstup výpočtu B jako vstup do výpočtu C, pak jej můžete „zrychlit tím, že budete na každé úloze (A, B nebo C) pracovat s jiným jádrem, protože začněte, dokud nedojde k dokončení druhého.

I ve výše uvedeném případě však můžete být schopni t o paralelizovat to jiným způsobem. Pokud můžete rozdělit vstupní data na bloky, můžete mít jednu základní práci na tom, že A, pak B, pak C s jedním blokem dat, zatímco jiné jádro pracuje na tom, že A, pak B, pak C na jiném bloku dat .

Existují i další úvahy. Možná byste mohli najít způsob, jak paralelizovat výpočty, ale jen čtení dat z disku nebo přes síť nebo jejich odeslání na GPU bude trvat déle než provádění výpočtů. V takovém případě nemá smysl to paralelizovat, protože pouze získání dat do paměti trvá déle, než kolik času ušetříte paralelním výpočtem.

Jinými slovy, stejně umění jako věda.

Komentáře

• Ach ano, x264 docela dobře paralelizuje na vícejádrových procesorech. Škálovám téměř lineárně až na nejméně 8 jader a slušně dokonce i nad 32. Odhad pohybu lze provádět paralelně, takže pro další vlákno zbývá jen nutně sériová práce a podobné triky.
• Otázka není ‚ T paralelnost obecně, zejména ‚ s GPU. ‚ jsou v kódu mnohem přísnější než v případě CPU. Myslím, že je to ‚ s, protože ‚ nemůžete mít kód s větvemi, které jdou různými způsoby na různých blocích obrazu. Nerozumím přesně proč, ale myslím si, že to ‚ něco takového je. Každý procesor streamů je tak jednoduchý as tak omezenými prostředky, jak ho spustit nezávisle na ostatních, že buď musíte vždy čekat na dokončení toho nejpomalejšího, nebo máte omezené větvení vůbec, nebo obojí.
• Pokud jste měli klastr počítačů (CPU s nezávislou pamětí RAM, které ‚ navzájem nekonkurovaly o šířku pásma paměti a mezipaměť CPU), ‚ d rozdělíte své vstupní video na GOP a odešlete části stále komprimovaného vstupního videa k dekódování a komprimaci na jiných počítačích v klastru.Muselo by tedy být přeneseno pouze komprimované vstupní nebo výstupní video. Jeden vícejádrový systém sdílené mezipaměti / RAM, jako je dokonce i pracovní stanice multisocket x86, máte více vláken pracujících na stejných rámcích najednou. (také znamená, že ‚ nepotřebujete nový kód k provádění globální kontroly rychlosti pro segmentování kódování.)