Miksi prosessori on “ parempi ” koodausta varten kuin GPU?

Linkittämäsi artikkeli ei ole kovin hyvä.

Normaalisti yhden passin bittinopeuskoodaukset muuntavat bittinopeuden RF-arvoksi enimmäisnopeusraja ja vie sen sieltä.

x264 ”: n yhden passin ABR-ohjausta ei toteuteta CRF + -rajana. Hän on oikeassa siinä 2passissa on kuitenkin ylivoimaisesti paras tapa saavuttaa kohdebittinopeus.

Ja hän ei ilmeisesti tiedä, että hän voisi aloittaa x264: n säikeillä = 3 tai jotain, jotta jätä jonkin suorittimen aikaa vapaasti muihin tehtäviin. Tai aseta x264: n prioriteetti hyvin matalaksi, joten se saa vain suorittimen ajan, jota mikään muu tehtävä ei halua.

Hän sekoittaa myös säikeet = 1 CUDA: n tai muun käyttämiseen. Ei ihme, että sinulla on kysyttävää, koska se artikkelilla on KOHDUTTAVA selitys. Koko artikkeli supistuu periaatteessa: käytä x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, tai ehkä käytä jonkin verran valosuodatusta AviSynth-syötteen kanssa. Hän suosittelee ” lumelääke ”. Se on hauskaa. En ole koskaan nähnyt piraattitiedostoa, joka on koodattu lumelääkkeellä. (Voit kertoa me=esa – tai me=tesa -kohdasta kaikille laadukkaille esiasetuksille aina veryslow asti.

Hän ei myöskään mainitse 10-bittisen värisyvyyden käyttämistä. Hitaampi koodata ja purkaa, mutta jopa muunnettuasi takaisin 8-bittiseksi, saat paremman 8-bittisen SSIM: n. Lisää tarkkuutta liikevektoreille ilmeisesti auttaa. Myös se, että sinun ei tarvitse pyöristää täyteen 8-bittiseen arvoon, auttaa. Voit ajatella 8 -bitti komponenttia kohti nopeuden hakkerointina; kvantisointi taajuusalueella ja sen pakkaaminen CABAC: lla tarkoittaa, että suurempien bittisyvyyskertoimien ei tarvitse viedä enemmän tilaa.

(BTW, h. 265 saa vähemmän hyötyä 8-bittisen videon 10-bittisistä koodauksista, koska sillä on jo enemmän tarkkuutta liikevektoreille. Jos 10-bittisen x265: n käytöstä on hyötyä 8-bittisille videotuloille, se on pienempi kuin x264: n kanssa. Joten on vähemmän todennäköistä, että nopeusrangaistus häviää Olen sen arvoinen.)

Vastaamaan todelliseen kysymykseesi:

edit: doom9 on nyt taas toiminnassa, joten ”siivon linkin. Mene siihen, jotta voit lainata oikein, kuka sanoi mitä.

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

google tallentaa välimuistiin vain tyhmän painetun version, joka ei näytä lainausta oikein. En ole aivan varma, mitkä näiden viestien osat ovat lainausmerkkejä ja mitkä osoitetaan itse henkilölle.

Erittäin epäsäännölliset haarautumismallit (ohitustilat) ja bittikäsittely (kvantisointi / entropiakoodaus) eivät sovi nykyisiin GPU: iin. Ainoa IMO todella hyvät sovellukset ovat tällä hetkellä täyden haun ME-algoritmit, vaikka nopeutettu täysi haku on silti hidasta, vaikka se olisi nopeampi kuin suorittimessa.
– MfA

Itse asiassa periaatteessa kaikki voidaan kohtuudella tehdä GPU: lla, paitsi CABAC (mikä voidaan tehdä, sitä ei vain voi rinnastaa).

x264 CUDA toteuttaa täyspelin ja alipittaa ME-algoritmi aluksi; myöhemmin voimme tehdä jotain RDO: ta bittikustannuksilla ximation CABAC: n sijaan.

Koska sen on tehtävä kaikki yhdellä tarkkuudella liukuluvulla
– MfA

Väärä, CUDA tukee kokonaislukumatematiikkaa.

– Tumma Shikari

Tumma Shikari on x264-ylläpitäjä ja useimpien ominaisuuksien kehittäjä vuodesta 2007 lähtien.

AFAIK, tämä CUDA-projekti ei levinnyt. On tukea OpenCL: n käyttämistä joidenkin töiden lataamiseen lookahead-säikeestä (nopea I / P / B-päätös, ei kehyksen korkealaatuinen lopullinen koodaus).

Ymmärtääkseni on, että videokoodauksen hakutila on niin suuri, että älykäs heuristiikka hakupolkujen ennenaikaisessa lopettamisessa prosessoreissa päihittää raakavoiman GPU: t tuo pöydälle ainakin korkealaatuisen koodauksen vuoksi. Sitä verrataan vain -preset ultrafast -ohjelmaan, jossa voit kohtuudella valita HW-koodauksen x264: n yläpuolelle, etenkin jos sinulla on hidas suoritin (kuten kannettava tietokone, jossa on kaksi ydintä eikä hyperlangaa). Suoritin (i7-neliydin, jossa hyperlangoitus), x264 superfast tulee todennäköisesti olemaan yhtä nopea ja näyttämään paremmalta (samalla bittinopeudella).

Jos olet tekemässä koodausta, jossa nopeuden vääristymällä (laatu tiedostokokoa kohti) on merkitystä, sinun tulee käyttää x264 -preset medium tai hitaampaa. Jos arkistoimalla jotain uudelleen, viettämällä hieman enemmän suorittimen aikaa nyt säästät tavuja niin kauan kuin pidät tiedostoa.

sivuhuomautus, jos näet joskus video-keskustelupalstalla deadrats-viestejä, se ” ei tule olemaan hyödyllistä. Hän on väärässä useimmissa asioissa, joista hän puhuu jokaisessa säikeessä, jonka olen koskaan nähnyt. Hänen viestinsä ilmestyivät pari säiettä, jotka googlelin x264 GPU-koodauksesta. Ilmeisesti hän ei ymmärrä, miksi se ei ole helppoa, ja on lähettänyt useita kertoja kertoa x264-kehittäjille, miksi he ovat tyhmä …

2017-päivitys:

ffmpeg tukee h264- ja h265 NVENC GPU -nopeutettua videokoodausta . Voit tehdä 1- tai 2-pass-koodauksen valitsemallasi laadulla joko hevc_nvencille tai h264_nvencille tai jopa lähtötason GPU: lla se on paljon nopeampi kuin kiihdyttämätön koodaus ja Intel Quick Sync -nopeutettu koodaus.

2-passinen korkealaatuinen koodaus:

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

1-pass oletuskoodaus:

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

NVENC ffmpeg -ohjeet ja -vaihtoehdot:

ffmpeg -h encoder=nvenc 

Käytä sitä, se on paljon nopeampi kuin suorittimen koodaus.

Jos sinulla ei ole grafiikkasuoritinta, voit käyttää Intel Quick Sync -koodekkia, h264_qsv, hevc_qsv tai mpeg2_qsv, jotka ovat myös paljon nopeampia kuin kiihdyttämätön koodaus.

Kommentit

• Käytä sitä , jos arvostat nopeutta (ja alhaista suorittimen käyttöä) tiedostokokokohtaiseen laatuun nähden. Joissakin käyttötapauksissa, esimerkiksi suoratoisto nykimiseen, ’ s mitä haluat (varsinkin alhainen suorittimen käyttöaste). Toisissa esim. Koodaamalla kerran luodaksesi tiedoston, jota suoratoistetaan / katsellaan monta kertaa, et edelleenkään ole t aikoo voittaa -c:v libx264 -preset slower (joka ei ole niin hidasta, kuten lähes reaaliaikainen 1920x1080p24: lle Skylake i7-6700k: lla.)
• Käyttämällä ffmpeg ja -vcodec h264_qsv vanhassa Intel-kannettavassani, jossa on Intel HD Grpahics 4000, renderointi oli paljon nopeampaa!

Tarkemmin Peterin sanomasta, useiden prosessorien käyttö auttaa yleensä tapauksissa, joissa sinulla on useita itsenäisiä tehtäviä, jotka kaikki täytyy tehdä, mutta älä riippu toisistasi tai yhdestä tehtävästä, jossa suoritat saman matematiikan suurille tietomäärille.

Jos sinun on kuitenkin suoritettava laskelman A tulos laskennan B tulona ja laskelman B tulona laskennan C tulona, niin et voi ”t nopeuttaa sitä, että jokaisella tehtävällä (A, B tai C) on eri ydintyö, koska ei voida” t aloita, kunnes toinen päättyy.

Jopa edellisessä tapauksessa saatat pystyä t o rinnastaa se toisella tavalla. Jos pystyt jakamaan syöttötiedot paloiksi, sinulla voi olla yksi ydintyö A: n, sitten B: n, sitten C: n kanssa yhdellä palalla dataa, kun taas toinen ydin työskentelee A: n, sitten B: n, C: n tekemisen jälkeen toisella tietojenkerällä. .

On muitakin näkökohtia. Ehkä voisit löytää keinon rinnastaa laskutoimituksia, mutta vain tietojen lukeminen levyltä tai verkon yli tai lähettäminen GPU: lle kestää kauemmin kuin laskelmien tekeminen. Siinä tapauksessa ei ole järkevää rinnastaa sitä, koska vain tietojen saaminen muistiin vie kauemmin kuin aika, jonka säästät tekemällä rinnakkaisen laskutoimituksen.

Toisin sanoen se ” yhtä paljon taidetta kuin tiedettäkin.

Kommentit

• Voi kyllä, x264 rinnastuu melko hyvin moniytimisiin suorittimiin. Skaalaan melkein lineaarisesti vähintään 8 ytimeen ja kohtuullisesti jopa yli 32. Liike-estimointi voidaan tehdä rinnakkain, jättäen vain välttämättä sarjasarjatyö toiselle säikeelle ja vastaavia temppuja.
• Kysymys ei ole ’ t rinnakkaisuus yleensä, se ’ s erityisesti GPU: t. Ne ’ ovat paljon rajoittavampia koodissa, jonka saat heidät suorittamaan kuin suorittimet. Mielestäni se on ’ s, koska ’ ei voi olla koodia haaroilla, jotka kulkevat eri tavoin kuvan eri lohkoissa. En ymmärrä tarkalleen miksi ’, mutta mielestäni se on ’ jotain sellaista. Jokainen suoratoistoprosessori on niin yksinkertainen ja sillä on niin rajalliset keinot, että se toimii muista riippumatta, että joko joudut aina odottamaan hitaimman suorittamista, tai haaroittuminen on rajoitettua ollenkaan tai molemmat.
• Jos sinulla oli joukko tietokoneita (suorittimet, joissa on itsenäinen RAM-muisti, jotka eivät ’ t kilpailleet keskenään muistin kaistanleveydestä ja suorittimen välimuistista), ’ d hajottaa syötevideosi GOP-tiedostoiksi ja lähetä vielä pakatun tulovideon osat dekoodattavaksi ja pakattavaksi muille klusterin koneille.Joten vain pakattu tulo- tai lähtövideo olisi siirrettävä. Yksi moniytiminen jaettu välimuisti / RAM-järjestelmä, kuten jopa monitasoinen x86-työasema, sinulla on useita säikeitä, jotka toimivat samoilla kehyksillä kerralla. (tarkoittaa myös sitä, ettet ’ tarvitse uutta koodia yleisen ohjauksen suorittamiseen koodausten segmentoimiseksi.)