Waarom is de processor “ beter ” voor codering dan GPU?

Het artikel dat u heeft gelinkt, is niet erg goed.

Normaal gesproken zetten bitrate-coderingen met één doorgang uw bitrate om in een RF-waarde met een maximale bitrate-limiet en neemt het vanaf daar over.

x264 “s one-pass ABR ratecontrole is niet geïmplementeerd als CRF + limiet. Hij heeft gelijk dat 2pass is verreweg de beste manier om een beoogde bitrate te halen.

En hij realiseert zich blijkbaar niet dat hij x264 zou kunnen starten met threads = 3 of zoiets, om laat wat CPU-tijd vrij voor andere taken. Of stel de prioriteit van x264 in op zeer laag, zodat het alleen CPU-tijd krijgt die geen enkele andere taak wil.

Hij verwisselt ook threads = 1 met het gebruik van CUDA of zoiets. Geen wonder dat je vragen hebt, want dat artikel heeft een verschrikkelijke uitleg. Het hele artikel komt in feite neer op: gebruik x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, of gebruik misschien wat lichtfiltering met een invoer AviSynth-script. Hij raadt eigenlijk placebo “. Dat is hilarisch. Ik heb nog nooit een illegaal bestand gezien dat is gecodeerd met een placebo. (U kunt zien aan me=esa of me=tesa, in plaats van me=umh voor alle voorinstellingen van goede kwaliteit, tot aan veryslow.

Hij noemt ook niet het gebruik van 10-bits kleurdiepte. coderen en decoderen, maar zelfs na terugconversie naar 8 bit, krijg je een betere 8-bit SSIM. Meer precisie voor bewegingsvectoren helpt blijkbaar. Ook helpt het niet om af te ronden tot precies een hele 8 bit-waarde. Je kunt denken aan 8 -bit per component als een speed-hack; kwantiseren in het frequentiedomein en dat vervolgens comprimeren met CABAC betekent dat hogere bitdiepte coëfficiënten niet meer ruimte in beslag hoeven te nemen.

(BTW, h. 265 haalt minder voordeel uit 10-bits coderingen voor 8-bits video omdat het al meer precisie heeft voor bewegingsvectoren. Als het een voordeel is om 10-bits x265 te gebruiken voor 8-bits video-ingangen, is het kleiner dan met x264. Het is dus minder waarschijnlijk dat de snelheidstraf zal gebeuren Ik ben het waard.)

Om je eigenlijke vraag te beantwoorden:

edit: doom9 is nu weer beschikbaar, dus ik ruim de link op. Ga ernaar toe om correct te citeren wie wat heeft gezegd.

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

Google slaat alleen de stomme gedrukte versie op, die het citaat niet goed weergeeft. Ik weet niet precies welke delen van deze berichten aanhalingstekens zijn en welke aan de persoon zelf worden toegeschreven.

Zeer onregelmatige vertakkingspatronen (overslaan-modi) en bitmanipulatie (kwantisatie / entropiecodering) passen niet bij de huidige GPUs. IMO de enige echt goede applicaties zijn momenteel volledige zoek-ME-algoritmen, maar uiteindelijk is versneld zoeken nog steeds traag, zelfs als het sneller is dan op de CPU.
– MfA

Eigenlijk kan eigenlijk alles redelijkerwijs worden gedaan op de GPU behalve CABAC (wat zou kunnen worden gedaan, het kon gewoon niet” parallelized worden).

x264 CUDA zal een fullpel implementeren en aanvankelijk het ME-algoritme onderdrukken; later zouden we zoiets als RDO kunnen doen met een bit-cost goedkeuring ximation in plaats van CABAC.

Omdat het alles moet doen met een enkele precisie drijvende komma
– MfA

Fout, CUDA ondersteunt wiskunde met gehele getallen.

– Dark Shikari

Dark Shikari is de x264-onderhouder en ontwikkelaar van de meeste functies sinds 2007 of zo.

AFAIK, dit CUDA-project is niet gelukt. Er is ondersteuning voor het gebruik van OpenCL om wat werk te ontlasten van de lookahead-thread (snelle I / P / B-beslissing, geen hoge kwaliteit definitieve codering van het frame).

Ik heb begrepen is dat de zoekruimte voor videocodering ZO groot is dat slimme heuristieken voor vroegtijdige beëindiging van zoekpaden op CPUs de brute GPUs verslaan naar de tafel brengen, althans voor codering van hoge kwaliteit. Het wordt alleen vergeleken met -preset ultrafast waar je redelijkerwijs HW-codering zou kunnen kiezen boven x264, vooral als je een langzame CPU hebt (zoals een laptop met dual-core en geen hyperthreading). CPU (i7 quad core met hyperthreading), x264 superfast zal waarschijnlijk net zo snel zijn, en er beter uitzien (met dezelfde bitrate).

Als u “een codering maakt waarbij vervorming van de snelheid (kwaliteit per bestandsgrootte) überhaupt van belang is, moet u x264 -preset medium of langzamer gebruiken. Als u” door iets te archiveren en nu wat meer CPU-tijd te besteden, worden bytes bespaard zolang je “dat bestand bewaart.

kanttekening, als je ooit berichten van deadrats op een videoforum ziet, het” Het zal niet nuttig zijn. Hij heeft het bij het verkeerde eind over de meeste dingen waarover hij praat in elke thread die ik ooit heb gezien. Zijn berichten verschenen in een paar threads die ik googlede over x264 GPU-codering. Blijkbaar begrijpt hij niet waarom het niet gemakkelijk is, en heeft verschillende keren gepost om de x264-ontwikkelaars te vertellen waarom ze “dom zijn …

Update 2017:

ffmpeg ondersteunt h264 en h265 NVENC GPU-versnelde videocodering . U kunt 1-pass of 2-pass codering uitvoeren met de kwaliteit die u kiest, voor hevc_nvenc of h264_nvenc, of zelfs met een GPU op instapniveau is het veel sneller dan niet-versnelde codering en Intel Quick Sync versnelde codering.

2-pass hoogwaardige codering:

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

1-pass standaardcodering:

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

NVENC ffmpeg help en opties:

ffmpeg -h encoder=nvenc 

Gebruik het, het is veel sneller dan CPU-codering.

Als je geen GPU hebt, kun je de Intel Quick Sync-codec, h264_qsv, hevc_qsv of mpeg2_qsv gebruiken, die ook veel sneller zijn dan niet-versnelde codering.

Opmerkingen

• Gebruik het als je snelheid (en laag CPU-gebruik) belangrijker vindt dan kwaliteit per bestandsgrootte. In sommige gevallen, bijvoorbeeld streamen naar twitch, dat ‘ is wat je wilt (vooral het lage CPU-gebruik). In andere gevallen, bijvoorbeeld één keer coderen om een bestand te maken dat vaak wordt gestreamd / bekeken, ben je nog steeds t gaat -c:v libx264 -preset slower verslaan (wat niet zo langzaam is, zoals bijna realtime voor 1920x1080p24 op een Skylake i7-6700k.)
• Het gebruik van ffmpeg met -vcodec h264_qsv op mijn oude Intel-notebook met een Intel HD Grpahics 4000 maakte de weergave veel sneller!

Om wat verder uit te werken over wat Peter zegt, helpt het in het algemeen om meerdere processors te gebruiken in gevallen waarin je verschillende onafhankelijke taken hebt die allemaal moeten worden gedaan, maar ze zijn niet afhankelijk van elkaar, of een taak waarbij u dezelfde wiskunde uitvoert op enorme hoeveelheden gegevens.

Als u echter de uitvoer van berekening A als de invoer van berekening B, en de uitvoer van berekening B als de invoer voor berekening C, dan kun je t versnellen door voor elke taak een ander kernwerk te hebben (A, B of C), omdat je t begin totdat de andere klaar is.

Maar zelfs in het bovenstaande geval kunt u t o parallelize het op een andere manier. Als je je invoergegevens in stukken kunt opsplitsen, heb je misschien een kernwerk aan het doen van A, dan B, dan C met een stuk gegevens, terwijl een andere kern werkt aan het doen van A, dan B en dan C aan een ander stuk gegevens .

Er zijn ook andere overwegingen. Misschien zou je een manier kunnen vinden om de berekeningen parallel te zetten, maar alleen het lezen van de gegevens van de schijf of via het netwerk, of het verzenden naar de GPU, duurt langer dan het uitvoeren van de berekeningen. In dat geval heeft het geen zin om het parallel te zetten, want het duurt langer om de gegevens in het geheugen te krijgen dan de hoeveelheid tijd die u bespaart door de berekening parallel uit te voeren.

Met andere woorden, het is evenzeer een kunst als een wetenschap.

Opmerkingen

• Oh, ja, x264 parallelleert redelijk goed op multicore CPUs. Ik schalen bijna lineair tot ten minste 8 cores, en behoorlijk zelfs verder dan 32. Bewegingsschatting kan parallel worden gedaan, waardoor alleen het noodzakelijkerwijs seriële werk overblijft voor een andere thread en soortgelijke trucs.
• De vraag isn ‘ t parallellisme in het algemeen, het ‘ s GPUs in het bijzonder. Ze ‘ zijn veel beperkter in de code die je ze kunt laten draaien dan CPUs. Ik denk dat het ‘ s is omdat je ‘ geen code kunt hebben met vertakkingen die verschillende kanten op gaan in verschillende blokken van de afbeelding. Ik ‘ begrijp niet precies waarom, maar ik denk dat het ‘ zoiets is. Elke streamprocessor is zo eenvoudig, en met zulke beperkte middelen om hem onafhankelijk van de anderen te laten werken, dat je ofwel altijd moet wachten tot de langzaamste klaar is, of je bent beperkt in vertakkingen, of beide.
• Als u een cluster van computers had (CPUs met onafhankelijke RAM die niet ‘ met elkaar concurreerden om geheugenbandbreedte en CPU-cache), ‘ d je inputvideo opsplitsen in GOPs, en delen van de nog gecomprimeerde inputvideo verzenden om te worden gedecodeerd en gecomprimeerd naar andere machines in het cluster.Dus alleen gecomprimeerde input- of outputvideo zou moeten worden overgedragen. Als een multicore shared-cache / RAM-systeem zoals zelfs een multisocket x86-werkstation, heb je meerdere threads die tegelijkertijd op dezelfde frames werken. (betekent ook dat je geen ‘ nieuwe code nodig hebt om globale controle uit te voeren voor het segmenteren van coderingen.)