Jeg leste denne artikkelen og jeg så at en CPU er bedre for videokomprimering enn en GPU.
Artikkelen sier bare at det skjer fordi prosessoren kan håndtere mer komplekse algoritmer enn GPU, men jeg vil ha en mer teknisk forklaring, jeg søkte litt på internett, men jeg gjorde ikke finne noe.
Så, noen som vet å forklare eller koble et nettsted til jeg hadde en dypere forklaring på dette?
Svar
Artikkelen du koblet til er ikke veldig bra.
Normalt konverterer enkeltpass-bitrate-kodinger din bitrate til en RF-verdi med en maksimal bithastighetsgrense og tar den derfra.
x264 «s en-pass ABR ratecontrol er ikke implementert som CRF + -grense. Han har rett i at 2pass er den desidert beste måten å nå en målbithastighet.
Og han skjønner tilsynelatende ikke at han kunne starte x264 med tråder = 3 eller noe, for å la litt CPU-tid være ledig for andre oppgaver. Eller sett x264s prioritet til verylow, så det får bare CPU-tid som ingen andre oppgaver ønsker.
Han blander også tråder = 1 med å bruke CUDA, eller noe. Ikke rart at du har spørsmål, for det artikkelen har en FORFERDELIG forklaring. Hele artikkelen koker i utgangspunktet til: bruk x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, eller bruk kanskje litt lysfiltrering med et inngående AviSynth-skript. Han anbefaler faktisk » placebo «. Det er morsomt. Jeg har aldri sett en piratkopiert fil kodet med placebo. (Du kan fortelle fra me=esa eller me=tesa, i stedet for me=umh for alle forhåndsinnstillingene av god kvalitet, helt opp til veryslow.
Han nevner heller ikke å bruke 10bit fargedybde. kode og dekode, men selv etter å ha konvertert tilbake til 8bit, får du bedre 8-biters SSIM. Å ha mer presisjon for bevegelsesvektorer hjelper tilsynelatende. Også å ikke måtte avrunde til nøyaktig en hel 8-bits verdi hjelper. Du kan tenke på 8 -bit per komponent som en hastighetshack; kvantifisering i frekvensdomenet og deretter komprimering av det med CABAC betyr at høyere bitdybdekoeffisienter ikke trenger å ta mer plass.
(BTW, h. 265 får mindre nytte av 10-biters koder for 8-biters video fordi den allerede har mer presisjon for bevegelsesvektorer. Hvis det er en fordel å bruke 10-biters x265 til 8-biters videoinnganger, er den mindre enn med x264. Så det er mindre sannsynlig at fartsstraff vil Jeg er verdt det.)
For å svare på det faktiske spørsmålet ditt:
rediger: doom9 er oppe igjen nå, så jeg vil rydde opp i lenken. Gå til den for riktig sitering av hvem som sa hva.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
google cacher bare den dumme utskriftsversjonen som ikke viser sitatet riktig. Jeg er ikke helt sikker på hvilke deler av disse meldingene som er sitater, og som tilskrives personen selv.
Svært uregelmessige forgreningsmønstre (hoppmodus) og bitmanipulering (kvantisering / entropikoding) passer ikke til nåværende GPU-er. IMO den eneste virkelig god applikasjon for øyeblikket er fullsøk ME-algoritmer, til slutt er akselerert fullsøk fortsatt tregt selv om det er raskere enn på CPU.
– MfAEgentlig kan i utgangspunktet alt med rimelighet gjøres på GPU unntatt CABAC (som kan gjøres, det kunne bare ikke parallelliseres).
x264 CUDA vil implementere en fullpel og subpel ME-algoritmen til å begynne med; senere kunne vi gjøre noe som RDO med en bit-cost godkjenning ximering i stedet for CABAC.
Fordi det må gjøre alt på ett presis flytende punkt
– MfAFeil, CUDA støtter heltallsmatematikk.
– Dark Shikari
Dark Shikari er x264-vedlikeholder, og utvikler av de fleste funksjonene siden 2007 eller så.
AFAIK, dette CUDA-prosjektet kunne ikke slå ut. Det er støtte for å bruke OpenCL for å laste ned noe arbeid fra lookahead-tråden (rask I / P / B-avgjørelse, ikke en endelig koding av rammen av høy kvalitet).
Min forståelse er at søkeområdet for videokoding er så stort at smarte heuristikker for tidlig avslutning av søkebaner på CPUer slår brute-force GPU-ene ta med til bordet, i det minste for koding av høy kvalitet. Det er bare sammenlignet med -preset ultrafast hvor du med rimelighet kan velge HW-koding over x264, spesielt hvis du har en treg CPU (som bærbar PC med dobbel kjerne og uten hypertråd). På en rask CPU (i7 firekjerne med hypertråd), x264 superfast kommer sannsynligvis til å være like rask, og se bedre ut (med samme bithastighet).
Hvis du lager en kode der hastighetsforvrengning (kvalitet per filstørrelse) teller i det hele tatt, bør du bruke x264 -preset medium eller tregere. Hvis du » Hvis du arkiverer noe igjen, bruker du litt mer CPU-tid nå, sparer byte så lenge du «holder den filen rundt.
sidemerknad, hvis du noen gang ser meldinger fra deadrats på et videoforum, er det» s kommer ikke til å være nyttig. Han har tatt feil om de fleste ting han snakker om i hver tråd jeg noensinne har sett. Innleggene hans dukket opp i et par tråder jeg googlet om x264 GPU-koding. Tilsynelatende forstår han ikke hvorfor det ikke er lett, og har lagt ut flere ganger for å fortelle x264-utviklerne hvorfor de er «dumme …
Svar
2017-oppdatering:
ffmpeg støtter h264 og h265 NVENC GPU-akselerert videokoding . Du kan gjøre 1-pass eller 2-pass koding i den kvaliteten du velger, for enten hevc_nvenc eller h264_nvenc, eller til og med med en GPU på inngangsnivå er det mye raskere enn ikke-akselerert koding og Intel Quick Sync-akselerert koding.
Koding med 2 pass av høy kvalitet:
ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4 Standardkoding for 1-pass:
ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4 NVENC ffmpeg hjelp og alternativer:
ffmpeg -h encoder=nvenc Bruk den, den er mye raskere enn CPU-koding.
Hvis du ikke har en GPU, kan du bruke Intel Quick Sync-kodek, h264_qsv, hevc_qsv eller mpeg2_qsv, som også er mye raskere enn ikke-akselerert koding.
Kommentarer
Svar
Å utdype litt videre om hva Peter sier, generelt bruker flere prosessorer i tilfeller der du har flere uavhengige oppgaver som alle må gjøres, men har ikke avhengighet av hverandre, eller en oppgave der du utfører samme matematikk på enorme datamengder.
Hvis du derimot må utdataene til beregning A som inngang til beregning B, og utdata fra beregning B som inngang til beregning C, så kan du ikke øke hastigheten ved å ha en annen kjernearbeid på hver oppgave (A, B eller C) fordi man ikke kan «t start til den andre er ferdig.
Men selv i ovennevnte tilfelle kan du kanskje t o parallellisere det på en annen måte. Hvis du kan dele inndataene dine i biter, kan det hende du har ett kjernearbeid med å gjøre A, deretter B, deretter C med en del data, mens en annen kjerne jobber med å gjøre A, deretter B, deretter C på en annen del data .
Det er også andre hensyn. Kanskje du kan finne en måte å parallellisere beregningene på, men bare å lese dataene fra disken, eller over nettverket, eller sende dem til GPU vil ta lengre tid enn å gjøre beregningene. I så fall er det ikke fornuftig å parallellisere det, fordi det bare tar lenger tid å spare data ved å gjøre beregningen parallelt.
Med andre ord, det er like mye en kunst som det er en vitenskap.
Kommentarer
- Åh, ja x264 parallelliserer ganske bra på flerkjerners CPUer. Jeg skalerer nesten lineært opp til minst 8 kjerner, og anstendig til og med utover 32. Bevegelsesestimering kan gjøres parallelt, og etterlater bare det nødvendigvis serielle arbeidet for en annen tråd og lignende triks.
- Spørsmålet er ikke ‘ t parallellisme generelt, spesielt ‘ GPUer. De ‘ er mye mer restriktive i koden du kan få dem til å kjøre enn CPUer. Jeg tror det ‘ s fordi du kan ‘ t ha kode med grener som går forskjellige veier på forskjellige blokker av bildet. Jeg forstår ikke ‘ hvorfor, men jeg tror det ‘ er noe sånt. Hver strømprosessor er så enkel, og med så begrensede måter å få den til å kjøre uavhengig av de andre, at enten må du alltid vente på at den tregeste er ferdig, eller så er du i det hele tatt begrenset i forgrening, eller begge deler.
- Hvis du hadde en klynge datamaskiner (CPUer med uavhengig RAM som ikke ‘ ikke konkurrerer med hverandre om minnebåndbredde og CPU-cache), ‘ d bryter inngangsvideoen din inn i GOP-er, og sender deler av den fortsatt komprimerte inngangsvideoen som skal dekodes og komprimeres på andre maskiner i klyngen.Så bare komprimert inngangs- eller utgangsvideo må overføres. Én et flerkjernet delt cache / RAM-system som til og med en multisocket x86-arbeidsstasjon, og du har flere tråder som fungerer på de samme bildene samtidig. (betyr også at du ikke ‘ ikke trenger ny kode for å utføre global ratekontroll for segmentering av koder.)
-c:v libx264 -preset slower(som ikke er så treg, som nær sanntid i 1920x1080p24 på en Skylake i7-6700k.)ffmpegmed-vcodec h264_qsvpå min gamle Intel-bærbare PC med Intel HD Grpahics 4000 gjorde gjengivelsen mye raskere!