Jag läste den här artikel och jag såg att en CPU är bättre för videokomprimering än en GPU.
Artikeln säger bara att det händer för att processorn kan hantera mer komplexa algoritmer än GPU: n, men jag vill ha en mer teknisk förklaring, jag gjorde några sökningar på internet men jag visste inte hitta något.
Så vet någon att förklara eller länka en webbplats till jag hade en djupare förklaring av detta?
Svar
Artikeln du länkade är inte särskilt bra.
Normalt omvandlar enkodade bithastighetskodningar din bithastighet till ett RF-värde med en maximal bithastighetsgräns och tar den därifrån.
x264 ”s en-pass ABR ratecontrol implementeras inte som CRF + -gräns. Han har rätt att 2pass är dock det bästa sättet att nå en målbithastighet.
Och han inser tydligen inte att han kunde starta x264 med trådar = 3 eller något, för att lämna lite CPU-tid ledig för andra uppgifter. Eller ställ in x264: s prioritet till verylow, så det får bara CPU-tid som ingen annan uppgift vill ha.
Han blandar också ihop trådar = 1 med att använda CUDA eller något. Inte konstigt att du har frågor, för att artikeln har en FÖRSTÅRIG förklaring. Hela artikeln går i grund och botten ner på: använd x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv, eller använd kanske lite ljusfiltrering med ett ingångsaviSynth-skript. Han rekommenderar faktiskt ” placebo ”. Det är roligt. Jag har aldrig sett en piratkopierad kod kodad med placebo. (Du kan se från me=esa eller me=tesa istället för me=umh för alla förinställningar av god kvalitet, ända upp till veryslow.
Han nämner inte heller att han använder 10 bitars färgdjup. kodar och avkodar, men även efter att du har konverterat tillbaka till 8 bitar blir du bättre 8-bitars SSIM. Att ha mer precision för rörelsevektorer hjälper tydligen. Dessutom behöver du inte behöva avrunda till exakt ett helt 8-bitars värde. Du kan tänka på 8 -bit per komponent som en hastighetshack; att kvantifiera i frekvensdomänen och sedan komprimera det med CABAC betyder att högre bitdjupskoefficienter inte behöver ta mer utrymme.
(BTW, h. 265 får mindre nytta av 10-bitars kod för 8-bitars video eftersom det redan har mer precision för rörelsevektorer. Om det finns en fördel med att använda 10-bitars x265 för 8-bitars videoingångar är den mindre än med x264. Så det är mindre troligt att hastighetsstraffet kommer Jag är värt det.)
För att svara på din faktiska fråga:
redigera: doom9 är uppe nu, så jag ordnar länken. Gå till den för att citera vem som sa vad.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
google cachar bara den dumma utskriftsversionen som inte citerar ordentligt. Jag är inte riktigt säker på vilka delar av dessa meddelanden som är citat och som tillskrivs personen själv.
Mycket oregelbundna förgreningsmönster (hopplägen) och bitmanipulation (kvantisering / entropikodning) passar inte nuvarande GPU: er. IMO den enda riktigt bra applikation för tillfället är ME-algoritmer med full sökning, men i slutändan är det fortfarande långsam sökning även om det är snabbare än på CPU.
– MfAEgentligen kan i princip allt göras rimligt på GPU: n utom CABAC (vilket skulle kunna göras, det kunde bara inte parallelliseras).
x264 CUDA implementerar en fullpelare och subpel ME-algoritmen inledningsvis; senare kunde vi göra något som RDO med en bit-kostnadstillstånd ximation istället för CABAC.
Eftersom det måste göra allt med en enda precisions flytpunkt
– MfAFel, CUDA stöder heltalsmatematik.
– Dark Shikari
Dark Shikari är underhållaren x264 och utvecklar de flesta funktionerna sedan 2007 eller så.
AFAIK, det här CUDA-projektet gick inte ut. Det finns stöd för att använda OpenCL för att ladda ner lite arbete från lookahead-tråden (snabbt I / P / B-beslut, inte en slutkod av hög kvalitet i ramen).
Min förståelse är att sökutrymmet för videokodning är så stort att smarta heuristik för tidig avslutning av sökvägar på processorer slår brute-force GPU: erna ta till bordet, åtminstone för kodning av hög kvalitet. Det är bara jämfört med -preset ultrafast där du rimligen kan välja HW-kodning över x264, särskilt om du har en långsam CPU (som bärbar dator med dubbel kärna och utan hypertråd). På en snabb CPU (i7 fyrkärna med hypertråd), x264 superfast kommer förmodligen att vara lika snabb och se bättre ut (vid samma bithastighet).
Om du gör en kod där hastighetsförvrängning (kvalitet per filstorlek) spelar någon roll bör du använda x264 -preset medium eller långsammare. Om du ” om du arkiverar något, spenderar lite mer CPU-tid nu sparar byte så länge du ”håller den filen kvar.
sidnot, om du någonsin ser meddelanden från deadrats på ett videoforum, är det” s kommer inte att vara till hjälp. Han har tagit fel om de flesta saker som han pratat om i varje tråd jag någonsin sett. Hans inlägg visade sig i några trådar. Jag googlade om x264 GPU-kodning. Tydligen förstår han inte varför det inte är lätt, och har lagt upp flera gånger för att berätta för x264-utvecklarna varför de är ”dumma …
Svar
2017-uppdatering:
ffmpeg stöder h264 och h265 NVENC GPU-accelererad videokodning . Du kan göra 1-pass eller 2-pass kodning i den kvalitet du väljer, antingen för hevc_nvenc eller h264_nvenc, eller till och med med en ingångs-GPU är det mycket snabbare än icke-accelererad kodning och Intel Quick Sync accelererad kodning.
Kodning av hög kvalitet med två 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 och alternativ:
ffmpeg -h encoder=nvenc Använd den, den är mycket snabbare än CPU-kodning.
Om du inte har en GPU kan du använda Intel Quick Sync-codec, h264_qsv, hevc_qsv eller mpeg2_qsv, som också är mycket snabbare än icke-accelererad kodning.
Kommentarer
Svar
Att utarbeta lite längre om vad Peter säger, i allmänhet hjälper det med att använda flera processorer i fall där du har flera oberoende uppgifter som alla måste göras men inte ha beroenden på varandra, eller en uppgift där du utför samma matematik på stora mängder data.
Om du emellertid måste utdata för beräkning A som inmatning av beräkning B, och utmatning av beräkning B som inmatning för beräkning C, då kan du ”inte påskynda det genom att ha olika kärnarbeten på varje uppgift (A, B eller C) eftersom man inte kan börja tills den andra är klar.
Men även i ovanstående fall kan du t o parallellisera det på ett annat sätt. Om du kan dela dina inmatade data i bitar kan du ha ett kärnarbete på att göra A, sedan B, sedan C med en bit data, medan en annan kärna fungerar på att göra A, sedan B, sedan C på en annan bit data .
Det finns också andra överväganden. Kanske kan du hitta ett sätt att parallellisera beräkningarna, men bara att läsa data från disk eller över nätverket eller skicka det till GPU tar längre tid än att göra beräkningarna. I så fall är det inte meningsfullt att parallellisera det eftersom det bara tar längre tid att spara data genom att göra beräkningen parallellt.
Med andra ord är det lika mycket en konst som det är en vetenskap.
Kommentarer
- Åh, ja x264 parallelliserar ganska bra på flerkärniga processorer. Jag skalar nästan linjärt upp till minst åtta kärnor och anständigt till och med mer än 32. Rörelseuppskattning kan göras parallellt och lämnar bara det nödvändigtvis seriella arbetet för en annan tråd och liknande knep.
- Frågan är inte ’ t parallellism i allmänhet är det ’ i synnerhet GPU: er. De ’ är mycket mer begränsande i koden som du kan få dem att köra än processorer. Jag tror att det ’ s eftersom du kan ’ t har kod med grenar som går olika vägar på olika bildblock. Jag förstår inte ’ varför, men jag tror att det ’ är något sådant. Varje strömprocessor är så enkel och med så begränsade sätt att få den att köra oberoende av de andra, att antingen måste du alltid vänta på att den långsammaste är klar, eller så är du begränsad till att förgrena dig alls, eller båda.
- Om du hade ett kluster av datorer (processorer med oberoende RAM som inte ’ tävlade med varandra om minnesbandbredd och CPU-cache), så ’ d bryter din ingångsvideo till GOP och skickar delar av den fortfarande komprimerade ingångsvideon som ska avkodas och komprimeras på andra maskiner i klustret.Så endast komprimerad ingångs- eller utgångsvideo måste överföras. Ett multicore-delat cache / RAM-system som till och med en multisocket x86-arbetsstation, du har flera trådar som fungerar på samma ramar samtidigt. (betyder också att du inte ’ inte behöver ny kod för att göra global ratkontroll för segmentering av koder.)
-c:v libx264 -preset slower(vilket inte är så långsamt, som nära realtid för 1920x1080p24 på en Skylake i7-6700k.)ffmpegmed-vcodec h264_qsvpå min gamla Intel-anteckningsbok med Intel HD Grpahics 4000 gjorde rendering mycket snabbare!