Jeg læste denne artikel og jeg så, at en CPU er bedre til videokomprimering end en GPU.
Artiklen siger kun, at det sker, fordi processoren kan håndtere mere komplekse algoritmer end GPUen, men jeg vil have en mere teknisk forklaring, jeg søgte nogle på internettet, men det gjorde jeg ikke find noget.
Så ved nogen at forklare eller linke et websted til Jeg havde en mere dyb forklaring på dette?
Svar
Den artikel, du linkede, er ikke særlig god.
Normalt konverterer single-pass-bitrate-kodninger din bitrate til en RF-værdi med en maksimal bithastighedsgrænse og tager den derfra.
x264 “s en-pass ABR ratecontrol implementeres ikke som CRF + grænse. Han har ret, at 2 pass er dog langt den bedste måde at ramme et målbithastighed på.
Og han er tilsyneladende ikke klar over, at han kunne starte x264 med tråde = 3 eller noget for at lad noget CPU-tid være frit til andre opgaver. Eller sæt x264 “s prioritet til verylow, så det får kun CPU-tid, som ingen anden opgave ønsker.
Han blander også tråde = 1 med at bruge CUDA eller noget. Ikke underligt, du har spørgsmål, fordi det artiklen har en FORFÆRDELIG forklaring. Hele artiklen koger grundlæggende til: brug x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, eller brug måske lidt lysfiltrering med et input AviSynth-script. Han anbefaler faktisk ” placebo “. Det er sjovt. Jeg har aldrig set en piratkopieret fil kodet med placebo. (Du kan se fra me=esa eller me=tesa i stedet for me=umh for alle forudindstillinger af god kvalitet, lige op til veryslow.
Han nævner heller ikke at bruge 10bit farvedybde. kode og afkode, men selv efter nedkonvertering tilbage til 8bit, får du bedre 8-bit SSIM. At have mere præcision til bevægelsesvektorer hjælper tilsyneladende. Også at ikke behøver at afrunde til nøjagtigt en hel 8 bit værdi hjælper. -bit pr. komponent som et hastighedshack; kvantisering i frekvensdomænet og derefter komprimering af det med CABAC betyder, at højere bitdybdekoefficienter ikke behøver at tage mere plads.
(BTW, h. 265 får mindre fordel af 10-bit-koder til 8-bit video, fordi den allerede har mere præcision for bevægelsesvektorer. Hvis der er en fordel ved at bruge 10-bit x265 til 8-bit videoindgange, er den mindre end med x264. Så det er mindre sandsynligt, at hastighedsstraffen vil Jeg er det værd.)
For at besvare dit aktuelle spørgsmål:
rediger: doom9 er op nu igen, så jeg vil rydde linket op. Gå til det for korrekt citering af, hvem der sagde hvad.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
google cachelagrer kun den dumme udskriftsversion, der ikke citerer ordentligt. Jeg er ikke helt sikker på, hvilke dele af disse meddelelser der er citater, og som tilskrives personen selv.
Meget uregelmæssige forgreningsmønstre (springtilstande) og bitmanipulation (kvantisering / entropikodning) passer ikke til nuværende GPUer. IMO den eneste rigtig god anvendelse i øjeblikket er fuld søgning ME-algoritmer, men i sidste ende er accelereret fuld søgning stadig langsom, selvom den er hurtigere end på CPUen.
– MfAFaktisk kan alting med rimelighed gøres på GPUen undtagen CABAC (hvilket kunne gøres, det kunne bare ikke paralleliseres).
x264 CUDA implementerer en fullpel og subpel ME algoritme oprindeligt; senere kunne vi gøre noget som RDO med en bit-cost godkendelse ximation i stedet for CABAC.
Fordi det skal gøre alt ved et enkelt præcisions flydende punkt
– MfAForkert, CUDA understøtter heltal matematik.
– Dark Shikari
Dark Shikari er x264-vedligeholder og udvikler af de fleste af funktionerne siden 2007 eller deromkring.
AFAIK, dette CUDA-projekt gik ikke ud. Der er støtte til at bruge OpenCL til at aflaste noget arbejde fra lookahead-tråden (hurtig I / P / B-beslutning, ikke en højkvalitets endelige kode for rammen).
Min forståelse er, at søgerummet til videokodning er så stort, at smarte heuristikker til tidlig afslutning af søgestier på CPUer slår brute-force GPUerne bringe til bordet, i det mindste for høj kvalitet kodning. Det er kun sammenlignet med -preset ultrafast hvor du med rimelighed måske vælger HW-kodning frem for x264, især hvis du har en langsom CPU (som bærbar computer med dobbelt kerne og uden hypertråd). På en hurtig CPU (i7 quad core med hyperthreading), x264 superfast vil sandsynligvis være så hurtig og se bedre ud (ved samme bithastighed).
Hvis du “opretter en kode, hvor hastighedsforvrængning (kvalitet pr. filstørrelse) overhovedet betyder noget, skal du bruge x264 -preset medium eller langsommere. Hvis du” ved at arkivere noget, bruge lidt mere CPU-tid nu, spares byte, så længe du “holder den fil rundt.
sidebemærkning, hvis du nogensinde ser meddelelser fra deadrats på et videoforum, er det” s vil ikke være nyttigt. Han har taget fejl af de fleste ting, han taler om i hver tråd, jeg nogensinde har set. Hans indlæg dukkede op i et par tråde, jeg googlede om x264 GPU-kodning. Tilsyneladende forstår han ikke, hvorfor det ikke er let, og har sendt flere gange for at fortælle x264-udviklerne, hvorfor de “er dumme …
Svar
2017-opdatering:
ffmpeg understøtter h264 og h265 NVENC GPU-accelereret videokodning . Du kan foretage 1-pass eller 2-pass kodning i den kvalitet, du vælger, for enten hevc_nvenc eller h264_nvenc, eller endda med en GPU på indgangsniveau er det meget hurtigere end ikke-accelereret kodning og Intel Quick Sync-accelereret kodning.
Kodning i høj kvalitet med 2 pass:
ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4 Standardkodning med 1 pass:
ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4 NVENC ffmpeg hjælp og valgmuligheder:
ffmpeg -h encoder=nvenc Brug det, det er meget hurtigere end CPU-kodning.
Hvis du ikke har en GPU, kan du bruge Intel Quick Sync-codec, h264_qsv, hevc_qsv eller mpeg2_qsv, som også er meget hurtigere end ikke-accelereret kodning.
Kommentarer
Svar
At uddybe lidt videre om, hvad Peter siger, generelt bruger flere processorer det i tilfælde, hvor du har flere uafhængige opgaver, som alle skal gøres, men har ikke afhængigheder af hinanden eller en opgave, hvor du udfører den samme matematik på enorme datamængder.
Hvis du dog skal output til beregning A som input af beregning B, og output for beregning B som input til beregning C, så kan du “ikke fremskynde det ved at have en anden kerne til at arbejde på hver opgave (A, B eller C), fordi man ikke kan” t start, indtil den anden er færdig.
Men selv i ovenstående tilfælde kan du muligvis t o paralleliser det på en anden måde. Hvis du kan bryde dine inputdata i klumper, har du muligvis et kernearbejde med at udføre A, derefter B, derefter C med et stykke data, mens en anden kerne arbejder på at gøre A, derefter B og derefter C på et andet stykke data .
Der er også andre overvejelser. Måske kunne du finde en måde at parallelisere beregningerne på, men bare at læse dataene fra disken eller over netværket eller sende dem til GPUen vil tage længere tid end at udføre beregningerne. I så fald giver det ikke mening at parallelisere det, fordi det bare tager længere tid at gemme dataene i hukommelsen, end du sparer ved at udføre beregningen parallelt.
Med andre ord er det lige så meget en kunst som det er en videnskab.
Kommentarer
- Åh, ja x264 paralleliserer ganske godt på multicore-CPUer. Jeg skalerer næsten lineært op til mindst 8 kerner og anstændigt endda over 32. Bevægelsesestimering kan udføres parallelt, hvilket kun efterlader det nødvendigvis serielle arbejde til en anden tråd og lignende tricks.
- Spørgsmålet er ikke ‘ t generelt er det ‘ s specielt GPUer. De ‘ er meget mere restriktive i koden, du kan få dem til at køre end CPUer. Jeg tror det ‘ s fordi du kan ‘ t har kode med grene, der går forskellige måder på forskellige blokke af billedet. Jeg forstår ikke ‘ hvorfor, men jeg tror, at det ‘ er sådan noget. Hver streamprocessor er så enkel og med så begrænsede midler til at få den til at køre uafhængigt af de andre, at enten skal du altid vente på, at den langsomste er færdig, eller du er overhovedet begrænset i forgrening eller begge dele. >
- Hvis du havde en klynge af computere (CPUer med uafhængig RAM, der ikke ‘ ikke konkurrerede med hinanden om hukommelsesbåndbredde og CPU-cache), ‘ d bryde din inputvideo i GOPer og sende sektioner af den stadig komprimerede inputvideo, der skal afkodes og komprimeres på andre maskiner i klyngen.Så kun komprimeret input eller output-video skal overføres. Et et multicore delt cache / RAM-system som endda en multisocket x86-arbejdsstation, du har flere tråde, der fungerer på de samme rammer på én gang. (betyder også, at du ikke ‘ ikke har brug for ny kode for at udføre global ratekontrol til segmentering af koder.)
-c:v libx264 -preset slower(hvilket ikke er så langsomt, som næsten realtid i 1920x1080p24 på en Skylake i7-6700k.)ffmpegmed-vcodec h264_qsvpå min gamle Intel-notesbog med en Intel HD Grpahics 4000 gjorde gengivelsen meget hurtigere!