De ce procesorul este “ mai bun ” pentru codificare decât GPU?

Articolul pe care l-ați conectat nu este foarte bun.

În mod normal, codificările ratei de biți cu o singură trecere vă convertesc rata de biți într-o valoare RF cu un limita maximă a ratei de biți și o ia de acolo.

x264 „s-one-pass ABR ratecontrol nu este implementat ca limită CRF +. Are dreptate că 2pass este de departe cel mai bun mod de a atinge un bitrate țintă, totuși.

Și se pare că nu își dă seama că ar putea începe x264 cu fire = 3 sau ceva, lăsați puțin timp CPU pentru alte sarcini. Sau setați prioritatea lui x264 la foarte scăzut, deci obține doar timp de procesare pe care nicio altă sarcină nu îl dorește.

De asemenea, amestecă fire = 1 cu utilizarea CUDA, sau ceva de genul acesta. Nu e de mirare că aveți întrebări, deoarece asta articolul are o explicație TERIBILĂ. Întregul articol se rezumă în principiu la: utilizați x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv sau poate folosiți o filtrare a luminii cu un script AviSynth de intrare. El recomandă de fapt ” placebo „. E hilar. „Nu am văzut niciodată un fișier pirat codificat cu placebo. (Puteți spune din me=esa sau me=tesa, în loc de me=umh pentru toate presetările de bună calitate, până la veryslow.

De asemenea, el nu menționează utilizarea adâncimii culorii de 10 biți. codificați și decodați, dar chiar și după conversia înapoi la 8 biți, veți obține SSIM mai bun pe 8 biți. Având mai multă precizie pentru vectorii de mișcare, vă ajută. De asemenea, nu trebuie să rotunjiți exact la o valoare de 8 biți. Vă puteți gândi la 8 -bit pe componentă ca un hack de viteză; cuantificarea în domeniul frecvenței și apoi comprimarea cu CABAC înseamnă că coeficienții mai mari de adâncime de biți nu trebuie să ocupe mai mult spațiu.

(BTW, h. 265 beneficiază mai puțin de codurile de 10 biți pentru videoclipurile de 8 biți, deoarece are deja mai multă precizie pentru vectorii de mișcare. Dacă există un avantaj al utilizării 10 biți x265 pentru intrările video de 8 biți, este mai mic decât cu x264. Deci, este mai puțin probabil ca pedeapsa de viteză să fie merită.)

Pentru a răspunde la întrebarea dvs. actuală:

edit: doom9 este din nou activat, așa că voi ordona linkul. Accesați-l pentru a cita corect cine a spus ce.

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

Google memorează în cache doar versiunea de tipar stupid care nu afișează corect citatul. Nu sunt foarte sigur ce părți din aceste mesaje sunt ghilimele și care sunt atribuite persoanei înseși.

Modelele de ramificare extrem de neregulate (moduri skip) și manipularea biților (cuantificare / codificare entropie) nu se potrivesc cu GPU-urile prezente. IMO este singurul aplicația foarte bună în acest moment sunt algoritmi ME de căutare completă, în cele din urmă, deși căutarea completă accelerată este încă lentă chiar dacă este „mai rapidă decât pe CPU.
– MfA

De fapt, practic totul poate fi realizat în mod rezonabil pe GPU, cu excepția CABAC (care s-ar putea face, nu poate fi paralelizat).

x264 CUDA va implementa un fullpel și subpelează algoritmul ME inițial; mai târziu am putea face ceva de genul RDO cu o abordare cu costuri de biți ximation în loc de CABAC.

Pentru că trebuie să facă totul la un punct plutitor de precizie
– MfA

Greșit, CUDA acceptă matematica întreagă.

– Dark Shikari

Dark Shikari este programul de întreținere x264 și dezvoltatorul majorității funcțiilor din 2007 sau cam așa ceva.

AFAIK, acest proiect CUDA nu a fost completat. Există suport pentru utilizarea OpenCL pentru a descărca unele lucrări din firul lookahead (decizie rapidă I / P / B, nu o codificare finală de înaltă calitate a cadrului).

Înțelegerea mea este că spațiul de căutare pentru codificarea video este atât de mare încât euristicile inteligente pentru terminarea timpurie a căilor de căutare pe procesoare depășesc GPU-urile cu forță brută aduceți la masă, cel puțin pentru o codificare de înaltă calitate. Este doar în comparație cu -preset ultrafast, unde puteți alege în mod rezonabil codarea HW peste x264, mai ales dacă aveți un procesor lent (cum ar fi laptop cu dual core și fără hiperthreading). CPU (i7 quad core cu hiperthreading), x264 superfast va fi probabil la fel de rapid și va arăta mai bine (la același bitrate).

Dacă „realizați o codificare în care contează deloc distorsiunea ratei (calitatea pe dimensiunea fișierului), ar trebui să utilizați x264 -preset medium sau mai lent. Dacă„ arhivând ceva, cheltuind puțin mai mult timp CPU acum, veți economisi octeți atâta timp cât „păstrați fișierul în jur.

Notă laterală, dacă vedeți vreodată mesaje de la deadrats pe un forum video, acesta” Nu va fi de ajutor. S-a înșelat în legătură cu majoritatea lucrurilor despre care vorbește în fiecare thread pe care l-am văzut vreodată. Postările sale au apărut în câteva fire pe care le-am cercetat despre codificarea GPU x264. Se pare că nu înțelege de ce nu este ușor, și a postat de mai multe ori pentru a le spune dezvoltatorilor x264 de ce „sunt stupizi …

Actualizare 2017:

ffmpeg acceptă codificarea video accelerată GPU h264 și h265 NVENC . Puteți face codificare cu 1 trecere sau 2 treceri la calitatea pe care o alegeți, fie pentru hevc_nvenc, fie pentru h264_nvenc, sau chiar și cu un GPU entry-level, este „mult mai rapid decât codarea non-accelerată și codificarea accelerată Intel Quick Sync.

Codificare de înaltă calitate cu 2 treceri:

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

Codificare implicită cu 1 trecere:

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

NVENC ffmpeg ajutor și opțiuni:

ffmpeg -h encoder=nvenc 

Utilizați-l, este” mult mai rapid decât codarea procesorului.

Dacă nu aveți un GPU, puteți utiliza codecul Intel Quick Sync, h264_qsv, hevc_qsv sau mpeg2_qsv, care sunt, de asemenea, mult mai rapide decât codificarea neaccelerată.

Comentarii

• Folosiți-l dacă apreciați viteza (și utilizarea scăzută a procesorului) peste calitatea pe dimensiunea fișierului. În unele cazuri de utilizare, de exemplu, transmiterea în flux către twitch, ‘ este ceea ce doriți (în special utilizarea redusă a procesorului). În altele, de exemplu, codificați o singură dată pentru a crea un fișier care va fi transmis / urmărit de multe ori, încă nu sunteți nu va bate -c:v libx264 -preset slower (ceea ce nu este atât de lent, ca aproape în timp real pentru 1920x1080p24 pe un Skylake i7-6700k.)
• Folosirea ffmpeg cu -vcodec h264_qsv pe vechiul meu notebook Intel cu un Intel HD Grpahics 4000 a făcut redarea mult mai rapidă!

Pentru a elabora puțin mai departe ceea ce spune Peter, în general folosirea mai multor procesoare ajută în cazurile în care aveți mai multe sarcini independente pe care toate trebuie făcut, dar nu aveți dependențe unul de celălalt sau o sarcină în care efectuați aceeași matematică pentru cantități masive de date.

Dacă, totuși, trebuie să ieșiți din calculul A ca intrare a calculului B și ieșirea calculului B ca intrare în calculul C, atunci nu puteți „accelera având un lucru de bază diferit la fiecare sarcină (A, B sau C) deoarece nu puteți„ t începeți până când celelalte termină.

Cu toate acestea, chiar și în cazul de mai sus, este posibil să nu puteți o paralelizați-l într-un alt mod. Dacă vă puteți împărți datele de intrare în bucăți, este posibil să aveți o lucrare de bază pentru a face A, apoi B, apoi C cu o bucată de date, în timp ce un alt nucleu funcționează pentru a face A, apoi B, apoi C pentru o bucată diferită de date .

Există și alte considerații. Poate ați putea găsi o modalitate de a paralela calculele, dar doar citirea datelor de pe disc sau prin rețea sau trimiterea lor către GPU va dura mai mult decât efectuarea calculelor. În acest caz, nu are sens să-l paralelizăm, deoarece doar obținerea datelor în memorie durează mai mult decât timpul pe care îl economisești făcând calculul în paralel.

Cu alte cuvinte, este atât de multă artă cât și știință.

Comentarii

• Oh, da x264 se paralelizează destul de bine pe procesoarele multicore. Scalare aproape liniar până la cel puțin 8 nuclee și decent chiar și peste 32. Estimarea mișcării se poate face în paralel, lăsând doar lucrarea neapărat serială pentru un alt fir și trucuri similare.
• Întrebarea nu este ‘ t paralelism în general, este ‘ în special GPU-urile. Acestea ‘ sunt mult mai restrictive în codul pe care le puteți face să ruleze decât procesoarele. Cred că ‘ este pentru că nu poți ‘ să ai cod cu ramuri care merg pe căi diferite pe diferite blocuri ale imaginii. Nu ‘ nu înțeleg exact de ce, dar cred că ‘ este ceva de genul acesta. Fiecare procesor de flux este atât de simplu și cu mijloace atât de limitate de a-l rula independent de celelalte, încât fie trebuie să așteptați întotdeauna până la finalizarea celui mai lent, fie că sunteți deloc limitat în ramificare, sau ambele.
• Dacă ați avut un cluster de computere (procesoare cu RAM independentă care nu ‘ nu concurau între ele pentru lățimea de bandă a memoriei și memoria cache a procesorului), împărțiți videoclipul de intrare în GOP-uri și trimiteți secțiuni ale videoclipului de intrare încă comprimat pentru a fi decodat și comprimat pe alte mașini din cluster.Deci, numai video de intrare sau ieșire comprimat ar trebui transferat. Un sistem cu memorie cache / RAM partajată multicore, cum ar fi chiar și o stație de lucru multisocket x86, aveți mai multe fire de operare pe aceleași cadre simultan. (înseamnă, de asemenea, că nu ‘ nu aveți nevoie de un cod nou pentru a efectua controlul global al ratelor pentru segmentarea codurilor.)