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

Stavo leggendo questo articolo e ho visto che una CPU è migliore per la compressione video di una GPU.

L'articolo dice solo che ciò accade perché il processore può gestire algoritmi più complessi rispetto alla GPU, ma voglio una spiegazione più tecnica, ho fatto alcune ricerche su Internet ma non ho trovato nulla.

Quindi, qualcuno sa spiegare o collegare un sito a cui ho avuto una spiegazione più approfondita di questo?

L'articolo che hai collegato non è molto buono.

Normalmente, le codifiche bitrate single pass convertono il tuo bitrate in un valore RF con un limite massimo di bitrate e lo prende da lì.

Il ratecontrol ABR one-pass di x264 non è implementato come limite CRF +. Ha ragione, tuttavia, che 2pass è di gran lunga il modo migliore per raggiungere un bitrate target.

E a quanto pare non si rende conto che potrebbe iniziare x264 con thread = 3 o qualcosa del genere, per lasciare un po 'di tempo della CPU libero per altre attività. Oppure imposta la priorità di x264 su verylow, in modo da ottenere solo il tempo della CPU che nessun'altra attività desidera.

Mescola anche thread = 1 con l'utilizzo di CUDA o qualcosa del genere. Non c'è da stupirsi che tu abbia domande, perché quell'articolo ha una spiegazione TERRIBILE. L'intero articolo si riduce sostanzialmente a: usa x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, o forse usa un po 'di filtraggio della luce con uno script AviSynth di input. In realtà raccomanda "placebo". È divertente. Non ho mai visto un file piratato codificato con placebo. (puoi dirlo da me=esao me=tesa, anziché me=umhper tutti i preset di buona qualità, fino a veryslow.

Inoltre, non menziona l'uso della profondità del colore a 10 bit. Più lento per codificare e decodificare, ma anche dopo aver convertito indietro a 8 bit, si ottiene un SSIM a 8 bit migliore. Avere più precisione per i vettori di movimento apparentemente aiuta. Inoltre, non dover arrotondare esattamente a un intero valore di 8 bit aiuta. Puoi pensare a 8 bit per componente come uno speed-hack; quantizzare nel dominio della frequenza e comprimerlo successivamente con CABAC significa che coefficienti di profondità in bit più elevati non devono occupare più spazio.

(A proposito, h.265 ottiene meno benefici dai codifiche a 10 bit per i video a 8 bit perché ha già una maggiore precisione per i vettori di movimento. Se c'è un vantaggio nell'uso di x265 a 10 bit per gli ingressi video a 8 bit, è più piccolo di con x264. Quindi è meno probabile che valga la pena la penalità di velocità.)

Per rispondere alla tua vera domanda:

modifica: doom9 è di nuovo attivo ora, quindi sistemerò il link. Vai ad esso per una corretta citazione di chi ha detto cosa.

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

Google memorizza nella cache solo la versione stupida della stampa che non mostra correttamente la citazione. Non sono del tutto sicuro di quali parti di questi messaggi siano citazioni e quali siano attribuite alla persona stessa.

I modelli di ramificazione altamente irregolari (modalità di salto) e la manipolazione dei bit (quantizzazione / codifica entropica) non si adattano alle GPU attuali. L'unica applicazione davvero valida dell'IMO al momento sono gli algoritmi ME di ricerca completa, alla fine sebbene la ricerca completa accelerata sia 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 potrebbe essere parallelizzato).

x264 CUDA implementerà inizialmente un algoritmo ME fullpel e subpel; più tardi potremmo fare qualcosa di simile a RDO con un'approssimazione di bit-cost anziché CABAC.

Perché deve fare tutto in un singolo punto mobile di precisione
- MfA

Sbagliato, CUDA supporta la matematica intera.

- Dark Shikari

Dark Shikari è il manutentore x264 e sviluppatore della maggior parte delle funzionalità dal 2007 in poi.

AFAIK, questo progetto CUDA non ha funzionato. È supportato l'utilizzo di OpenCL per scaricare parte del lavoro dal thread lookahead (rapida decisione 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 l'euristica intelligente per la terminazione anticipata dei percorsi di ricerca sulle CPU supera le GPU a forza bruta che portano sul tavolo, almeno per la codifica di alta qualità. È solo rispetto a -preset ultrafastdove potresti ragionevolmente scegliere la codifica HW su x264, esp. se hai una CPU lenta (come un laptop con dual core e nessun hyperthreading). Su una CPU veloce (i7 quad core con hyperthreading), x264 superfastsarà probabilmente più veloce e avrà un aspetto migliore (allo stesso bitrate).

Se stai eseguendo una codifica in cui la distorsione della frequenza (qualità per dimensione del file) conta, dovresti usare x264 -preset mediumo più lentamente. Se stai archiviando qualcosa, passare un po 'più di tempo sulla CPU ora farà risparmiare byte finché manterrai quel file.

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 abbia mai visto. I suoi post sono stati pubblicati in un paio di thread su cui ho cercato su Google la codifica GPU x264. Apparentemente non capisce perché non sia facile e ha pubblicato diverse volte per dire agli sviluppatori x264 perché sono stupidi ...

Aggiornamento 2017:

ffmpeg supporta la codifica video accelerata GPU NV2 h264 e h265 . Puoi eseguire la codifica a 1 o 2 passaggi con la qualità che scegli, per hevc_nvenc o h264_nvenc, e 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.

Per elaborare un po 'di più su ciò che dice Peter, in generale l'utilizzo di più processori aiuta nei casi in cui hai diverse attività indipendenti che devono essere fatte tutte ma che non hanno dipendenze l'una dall'altra, o un'attività in cui stai eseguendo lo stesso matematica su enormi quantità di dati.

Se, tuttavia, è necessario l'output del calcolo A come input del calcolo B e l'output del calcolo B come input per il calcolo C, non è possibile accelerarlo avendo un core diverso lavoro su ogni attività ( A, B o C) perché uno non può iniziare fino a quando l'altro non termina.

Tuttavia, anche nel caso sopra, potresti essere in grado di parallelizzarlo in un altro modo. Se puoi dividere i tuoi dati di input in blocchi, potresti avere un lavoro di base nel fare A, poi B, quindi C con un blocco di dati, mentre un altro nucleo lavora nel fare A, poi B, quindi C su un blocco di dati diverso .

Ci sono anche altre considerazioni. Forse potresti trovare un modo per parallelizzare i calcoli, ma semplicemente 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 recupero dei dati in memoria richiede più tempo del tempo risparmiato eseguendo il calcolo in parallelo.

In altre parole, è tanto un'arte quanto una scienza.