Perché il processore è “ migliore ” per la codifica rispetto alla GPU?

Larticolo che hai collegato non è molto buono.

Normalmente, le codifiche bitrate a passaggio singolo convertono il bitrate in un valore RF con un limite massimo di bitrate e da lì lo prende.

Il controllo della velocità ABR a un passaggio di x264 non è implementato come limite CRF +. Ha ragione che 2pass è di gran lunga il modo migliore per raggiungere un bitrate target, però.

E a quanto pare non si rende conto che potrebbe avviare x264 con thread = 3 o qualcosa del genere, per lasciare un po di tempo di CPU libero per altre attività. Oppure imposta la priorità di x264 su molto bassa, in modo da ottenere solo il tempo di CPU che nessun altro compito vuole.

Inoltre confonde thread = 1 con luso di CUDA, o qualcosa del genere. Non cè da stupirsi che tu abbia domande, perché quello larticolo ha una spiegazione TERRIBILE. Lintero articolo si riduce sostanzialmente a: usa x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, o forse usa un filtro leggero con uno script AviSynth di input. In realtà raccomanda ” placebo “. È divertente. “Non ho mai visto un file piratato codificato con placebo. (Lo puoi capire da me=esa o me=tesa, invece di me=umh per tutte le preimpostazioni di buona qualità, fino a veryslow.

Inoltre non menziona lutilizzo della profondità di colore a 10 bit. codifica e decodifica, ma anche dopo aver convertito di nuovo a 8 bit, ottieni un SSIM a 8 bit migliore. Avere una maggiore precisione per i vettori di movimento apparentemente aiuta. Inoltre, non dover arrotondare esattamente a un valore intero a 8 bit aiuta. Puoi pensare a 8 bit per componente come speed-hack; quantizzare nel dominio della frequenza e quindi comprimerlo con CABAC significa che coefficienti di profondità di bit più alti non devono occupare più spazio.

(BTW, h. 265 ottiene meno vantaggi dalle codifiche a 10 bit per video a 8 bit perché ha già una maggiore precisione per i vettori di movimento. Se cè un vantaggio nellusare x265 a 10 bit per ingressi video a 8 bit, è più piccolo che con x264. Quindi è meno probabile che la penalità di velocità avvenga Ne vale la pena.)

Per rispondere alla tua vera domanda:

edit: doom9 è di nuovo attivo ora, quindi metto in ordine il collegamento. Vai ad esso per citare correttamente chi ha detto cosa.

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

Google memorizza nella cache solo la stupida versione stampata che non mostra correttamente le citazioni. Non sono abbastanza sicuro di quali parti di questi messaggi siano virgolette e quali siano attribuite alla persona stessa.

Schemi di ramificazione altamente irregolari (modalità di salto) e manipolazione dei bit (quantizzazione / codifica entropica) non sono adatti alle GPU presenti. IMO lunico unapplicazione veramente buona al momento sono gli algoritmi di ricerca completa ME, alla fine anche se la ricerca completa accelerata è ancora lenta anche se è più veloce che sulla CPU.
– MfA

In realtà, praticamente tutto può essere ragionevolmente fatto sulla GPU tranne CABAC (che potrebbe essere fatto, semplicemente non poteva essere parallelizzato).

x264 CUDA implementerà un fullpel e lalgoritmo di subpel ME inizialmente; in seguito potremmo fare qualcosa come RDO con un approccio a costo di bit ximation invece di CABAC.

Perché deve fare tutto in virgola mobile a precisione singola
– MfA

Sbagliato, CUDA supporta la matematica intera.

– Dark Shikari

Dark Shikari è il manutentore x264 e sviluppatore della maggior parte delle funzionalità dal 2007 o giù di lì.

AFAIK, questo progetto CUDA non è andato a buon fine. È disponibile il supporto per lutilizzo di OpenCL per scaricare un po di lavoro dal thread lookahead (decisione rapida I / P / B, non una codifica finale di alta qualità del frame).

La mia comprensione è che lo spazio di ricerca per la codifica video è così grande che leuristica intelligente per la terminazione anticipata dei percorsi di ricerca sulle CPU batte le GPU a forza bruta portare in tavola, almeno per la codifica di alta qualità. È solo rispetto a -preset ultrafast dove potresti ragionevolmente scegliere la codifica HW su x264, specialmente se hai una CPU lenta (come un laptop con dual core e senza hyperthreading). CPU (i7 quad core con hyperthreading), x264 superfast sarà probabilmente altrettanto veloce e avrà un aspetto migliore (allo stesso bitrate).

Se stai creando una codifica in cui la distorsione della velocità (qualità per dimensione del file) è importante, dovresti usare x264 -preset medium o più lento. Se lo fai ” archiviando qualcosa, spendendo un po più di tempo della CPU ora risparmierai byte per tutto il tempo in cui “mantieni quel file in giro.

nota a margine, se vedi mai messaggi di deadrats su un forum video,” non sarà utile. Si è sbagliato sulla maggior parte delle cose di cui parla in ogni thread che io abbia mai visto. I suoi post sono apparsi in un paio di thread che ho cercato su Google sulla codifica GPU x264. Apparentemente non capisce perché non è facile, e ha pubblicato diverse volte per dire agli sviluppatori x264 perché “sono stupidi …

Aggiornamento 2017:

ffmpeg supporta la codifica video con accelerazione GPU NVENC h264 e h265 . Puoi eseguire la codifica a 1 o 2 passaggi alla qualità che scegli, per hevc_nvenc o h264_nvenc, o anche con una GPU entry-level è molto più veloce della codifica non accelerata e della codifica accelerata Intel Quick Sync.

Codifica di alta qualità a 2 passaggi:

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

Codifica predefinita a 1 passaggio:

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

Guida e opzioni di NVENC ffmpeg:

ffmpeg -h encoder=nvenc 

Usalo, è molto più veloce della codifica della CPU.

Se non si dispone di una GPU, è possibile utilizzare il codec Intel Quick Sync, h264_qsv, hevc_qsv o mpeg2_qsv, che sono anche molto più veloci della codifica non accelerata.

Commenti

• Usalo se apprezzi la velocità (e il basso utilizzo della CPU) rispetto alla qualità per dimensione del file. In alcuni casi duso, ad esempio streaming su twitch, ‘ è ciò che desideri (soprattutto il basso utilizzo della CPU). In altri, ad esempio, codifica una volta per creare un file che verrà riprodotto in streaming / guardato molte volte, non sei ancora non batterà -c:v libx264 -preset slower (che non è così lento, come quasi in tempo reale per 1920x1080p24 su uno Skylake i7-6700k.)
• Lutilizzo di ffmpeg con -vcodec h264_qsv sul mio vecchio notebook Intel con un Intel HD Grpahics 4000 ha reso il rendering molto più veloce!

Per elaborare un po più in dettaglio ciò che dice Peter, in generale lutilizzo di più processori aiuta nei casi in cui si hanno diversi compiti indipendenti che tutti deve essere fatto ma non avere dipendenze luna dallaltra o unattività in cui stai eseguendo la stessa matematica su enormi quantità di dati.

Se, tuttavia, hai bisogno delloutput del calcolo A come input del calcolo B e loutput del calcolo B come input per il calcolo C, non puoi accelerarlo facendo un lavoro principale diverso su ogni attività (A, B o C) perché non puoi “t inizia fino al termine dellaltro.

Tuttavia, anche nel caso precedente, potresti essere in grado di t o parallelizzalo in un altro modo. Se riesci a suddividere i dati di input in blocchi, potresti avere un core che lavora su A, poi B, poi C con un blocco di dati, mentre un altro core lavora su A, poi B, quindi C su un diverso blocco di dati .

Ci sono anche altre considerazioni. Forse potresti trovare un modo per parallelizzare i calcoli, ma solo leggere i dati dal disco, o sulla rete, o inviarli alla GPU richiederà più tempo rispetto ai calcoli. In tal caso, non ha senso parallelizzarlo perché il solo caricamento dei dati in memoria richiede più tempo del tempo che si risparmia eseguendo il calcolo in parallelo.

In altre parole, tanto unarte quanto una scienza.

Commenti

• Oh, sì x264 si parallelizza abbastanza bene su CPU multicore. Scala in modo quasi lineare fino ad almeno 8 core e decentemente anche oltre 32. La stima del movimento può essere eseguita in parallelo, lasciando solo il lavoro necessariamente seriale per un altro thread e trucchi simili.
• La domanda non è ‘ t parallelismo in generale, in particolare le ‘ GPU. ‘ sono molto più restrittivi nel codice che puoi far funzionare rispetto alle CPU. Penso che ‘ s perché non puoi ‘ avere codice con rami che vanno in modi diversi su diversi blocchi dellimmagine. Non ‘ capisco esattamente perché, ma penso che ‘ sia qualcosa del genere. Ogni stream processor è così semplice e con mezzi così limitati per farlo funzionare indipendentemente dagli altri, che o devi sempre aspettare che finisca quello più lento, o sei limitato nel branching, o entrambi.
• Se avevi un cluster di computer (CPU con RAM indipendente che ‘ non competevano tra loro per la larghezza di banda della memoria e la cache della CPU), ‘ dividere il video in ingresso in GOP e inviare sezioni del video in ingresso ancora compresso da decodificare e comprimere su altre macchine nel cluster.Quindi solo il video in ingresso o in uscita compresso dovrebbe essere trasferito. In un sistema multicore con cache condivisa / RAM come anche una workstation x86 multisocket, hai più thread che operano sugli stessi frame contemporaneamente. (significa anche che non ‘ non è necessario un nuovo codice per eseguire il controllo della velocità globale per la segmentazione delle codifiche.)