Hårdvaruacceleration jämfört med CPU-omkodning för samma 4K-ström

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Hardware Acceleration vs CPU Transcoding for the Same 4K Stream - Zima Store Online

För samma 4K-ström i realtid är hårdvaruacceleration vanligtvis det bättre valet för en medieserver när grafikprocessorn eller mediemotorn stöder alla nödvändiga steg för avkodning, filtrering, tonmappning och kodning. Det flyttar det tyngsta videoarbetet från generella CPU-kärnor, minskar belastningen på CPU:n och skapar större marginal för samtidig bearbetning. CPU-transkodning är fortfarande användbar när hårdvaruvägen inte stöder ett nödvändigt format eller filter, eller när en enstaka programvarukodning prioriterar komprimeringseffektivitet framför genomströmning i realtid. Jämförelsen är meningsfull endast om källfil, målupplösning, bithastighet, klient och bearbetningskrav hålls konstanta.

Håll 4K-jobbet konstant innan du jämför motorerna

En rättvis jämförelse använder samma källfil, utdataupplösning, målbithastighet eller kvalitetsinställning, undertextläge, HDR/SDR-krav och klient. Om någon av dessa variabler ändras kan arbetsmängden påverkas mer än av valet mellan hårdvaru- och CPU-kodning.

HandBrakes prestandadokumentation visar hur kodarens förinställning, kvalitetsmål, bithastighet och filter alla påverkar hastigheten. Dess kontrollerade variabler för kodarprestanda ger rätt testdisciplin: jämför en väg i taget i stället för att jämföra två olika jobb.

Registrera transkodningshastighet, avbruten eller fördröjd uppspelning, CPU-användning, användning av videoenheten, systemets strömförbrukning om den är tillgänglig samt utdatakvalitet. Om båda vägarna är snabbare än realtid handlar nästa beslut om marginal och effektivitet, inte om huruvida någon av vägarna tekniskt kan slutföra arbetet.

Hårdvaruacceleration vinner testet av genomströmning i realtid

Hårdvaruacceleration som stöds använder fastfunktionsblock för avkodning och kodning, särskilt utformade för video. Det undviker att använda generella CPU-cykler för varje makroblock eller transformering och lämnar vanligtvis betydligt mer CPU-kapacitet åt medieapplikationen, lagringsstacken, undertexter, databasarbete och orelaterade tjänster.

Jellyfin listar QSV, NVENC/NVDEC, AMF, VA-API, VideoToolbox och andra hårdvarumetoder och beskriver hur en transkodningspipeline kan avlasta flera steg. Den fastfunktionsbaserade transkodningspipelinjen stöder den praktiska slutsatsen: hårdvara vinner när hela den nödvändiga sökvägen faktiskt är accelererad.

Vinsten är störst när flera strömmar överlappar varandra. En CPU som kan programvarutranskoda en 4K-källa i realtid kan ha mycket lite utrymme kvar för en andra session, medan en lämplig videoenhet ofta kan hantera mer samtidiga arbetsuppgifter utan att förbruka samma allmänna CPU-budget.

CPU-transkodning behåller flexibiliteten där maskinvarusökvägarna tar slut

Programvarutranskodning kan hantera format, kodaralternativ eller filter som en viss maskinvarugeneration inte stöder. Den möjliggör också långsammare förinställningar som använder mer beräkningskraft för att förbättra komprimeringsbesluten, vilket kan vara attraktivt vid förberedelse av offlinebibliotek även om det ofta passar dåligt för direktsänd uppspelning.

Plex aktuella vägledning om maskinvaruaccelererad streaming noterar att maskinvarugenerationen kan påverka utdatakvaliteten och att HEVC-kodning kräver mer resurser än H.264. Dess generationsberoende maskinvaruutdata utgör gränsen: maskinvara är inte en och samma kodare på alla processor- och GPU-generationer.

CPU-transkodning förblir därför reservlösningen när acceleratorn inte kan slutföra det nödvändiga jobbet. Den bör inte väljas enbart för att CPU-kapacitet finns tillgänglig; frågan är om den extra flexibiliteten är värd den högre strömförbrukningen och den minskade samtidigheten vid en direktsänd 4K-session.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Delvis acceleration kan dölja den verkliga flaskhalsen

En session kan visa maskinvarukodning medan CPU:n fortfarande sköter avkodning, inbränning av undertexter, ljudbearbetning, skalning eller något annat filter. I så fall jämför systemet inte en komplett maskinvarupipeline med en komplett CPU-pipeline, utan två hybridlösningar med olika programvarusteg.

NVIDIAs Video Codec SDK skiljer mellan NVDEC- och NVENC-funktioner och dokumenterar maskinvarustöd för specifika kodekar. Dess separata funktioner för maskinvaruavkodning och -kodning visar varför lyckad maskinvarukodning inte bevisar att källavkodningen också har flyttats till maskinvaran.

Övervaka både CPU- och videoenhetsaktiviteten och granska sedan transkodningsloggen. Om ett programvarufilter är flaskhalsen kanske en uppgradering till en snabbare maskinvarukodare inte ändrar uppspelningen förrän filtret också har en accelererad sökväg eller kraven på uppspelningen ändras.

Kvalitet måste jämföras vid den leveransbithastighet du faktiskt använder

En programvarukodare kan använda långsamma förinställningar för att söka mer grundligt efter komprimeringseffektivitet, medan fastfunktionshårdvara är optimerad för genomströmning och begränsad latens. Nyare hårdvarukodare har förbättrats avsevärt, så kvalitetsskillnader bör mätas i stället för att antas utifrån jämförelser med äldre generationer.

Intels dokumentation om Quick Sync betonar att funktionen är implementerad i processorgrafiken och måste stödjas av den exakta CPU:n. Kontrollen av exakt Quick Sync-generation är viktig eftersom ”hårdvaruacceleration” kan innebära mycket olika medieenheter beroende på plattformsgeneration.

Beslutsfaktor	Hårdvaruacceleration	CPU-transkodning
4K-genomströmning i realtid	Vanligtvis bättre när stödet är fullständigt	Beror i hög grad på CPU och kodek
CPU-utrymme	Bevarar mer allmän CPU-kapacitet	Förbrukar allmänna kärnor
Samtidiga strömmar	Vanligtvis mer praktiskt	Skalar med betydande CPU-kostnad
Filter/format som inte stöds	Kan falla tillbaka eller misslyckas	Större flexibilitet i programvaran
Långsam offlinekomprimering	Optimerad för hastighet	Kan använda långsammare programvaruförinställningar

Vid direktuppspelning bör du jämföra den synliga kvaliteten vid den bithastighet som fjärranvändaren eller klienten faktiskt får. Om båda uppfyller hushållets kvalitetskrav bör du välja den väg som lämnar mer resursutrymme i stället för att optimera ett kodarmått som tittaren inte kan se.

Effektförbrukning och samtidighet gör ett test med en ström till ett serverbeslut

Samma 4K-ström kan fungera hållbart med CPU:n, men ändå vara fel standardval för en server som alltid är på. Hög programvarubelastning ökar risken för att en andra ström, en biblioteksskanning, en säkerhetskopiering eller någon annan tjänst konkurrerar med uppspelningen. Hårdvaruacceleration bevarar mer schemaläggningsmarginal för sådana överlappningar.

ZimaSpace-guiden för att kontrollera om hårdvarutranskodning faktiskt fungerar rekommenderar att man verifierar den aktiva strömmen, värdens acceleratoraktivitet och loggarna i stället för att enbart lita på en inställning. Använd samma bevis innan du tillskriver hårdvaruvägen någon effektivitetsfördel.

Om en hårdvaruaccelererad ström är stabil men den andra misslyckas har du hittat en verklig gräns för samtidighet. Om CPU-programvarutranskodning bara fungerar när alla andra tjänster är inaktiva har den klarat en demonstration men misslyckats med serverns arbetsbelastning.

Vanliga frågor

Ger hårdvarutranskodning alltid sämre kvalitet än CPU-transkodning?

Nej. Kvaliteten beror på hårdvarugeneration, codec, kodarinställningar, målbithastighet och den programvarukodares förinställning som används i jämförelsen. Långsamma programvaruförinställningar kan byta mycket mer beräkningsarbete mot komprimeringseffektivitet, men moderna hårdvarumotorer kan fortfarande ge mycket bra realtidsutdata. Jämför vid den bithastighet och visningsstorlek som användarna faktiskt ser.

Varför är CPU-användningen fortfarande hög när hårdvaruacceleration är aktiverad?

Endast en del av bearbetningskedjan kan vara accelererad. Ljudkonvertering, undertexter, tonmappning, skalning, format för avkodning som inte stöds eller andra filter kan fortfarande köras på CPU:n. Använd strömloggar och aktivitet från värdens motorer för att ta reda på vilket steg som fortfarande är programvarubaserat.

Bör du använda CPU-transkodning om servern har många lediga kärnor?

Endast om programvaruvägen uppnår realtidshastighet med tillräcklig marginal för den värsta samtidiga belastningen och du värdesätter dess flexibilitet eller utdataegenskaper. Lediga kärnor ger användbar marginal för databaser, genomsökningar, säkerhetskopieringar och ytterligare sessioner; att förbruka dem bara för att de är tillgängliga kan minska serverns motståndskraft.

Använd hårdvara i första hand för live-4K, och CPU som undantagsväg

Välj hårdvaruacceleration när den exakta vägen från 4K-källa till utdata stöds fullt ut och livegenomströmning, samtidighet och servermarginal är viktiga. Detta är det normala valet för en alltid påslagen mediaserver som betjänar blandade klienter.

Välj CPU-transkodning när hårdvaran inte stöder en nödvändig codec eller ett nödvändigt bearbetningssteg, eller när jobbet är offline och du medvetet accepterar en mycket längre kodningstid för en programvaruförinställning. Det är ett undantag för en viss arbetsbelastning, inte ett tecken på att videohårdvara med fasta funktioner är onödig.

Om strömmen redan använder Direct Play, sluta jämföra dessa två alternativ helt. Varken hårdvaru- eller CPU-transkodning förbättrar en session som inte behöver videokonvertering. Behåll Direct Play och lägg serverresurserna på de konverteringar du inte kan undvika.