Varför använder en mediaserver hög CPU under uppspelning?

Hög CPU-användning under medieuppspelning betyder vanligtvis att servern gör mer än att bara skicka den ursprungliga filen. Den kan avkoda och koda om video, bränna in undertexter i varje bildruta, konvertera HDR för en SDR-klient, skala ner upplösningen eller skapa en ström med lägre bithastighet för en fjärranslutning.

Dock bevisar inte hög CPU automatiskt att processorn är för svag. Hårdvaruacceleration kan fungera endast för en del av processen, en bakgrundsanalysuppgift kan köras samtidigt, eller flera sessioner kan konkurrera om samma resurser. Det första steget är att identifiera uppspelningsläget och processen som faktiskt använder CPU:n.

Kontrollera uppspelningsläget innan du skyller på hårdvaran

Öppna serverns kontrollpanel medan den problematiska strömmen är aktiv. Plex, Jellyfin, Emby och liknande plattformar visar normalt om sessionen använder Direktuppspelning, Direktström eller Remux, ljudkonvertering eller full videotranskodning.

Direktuppspelning skickar den ursprungliga behållaren, videon, ljudet och stödda undertextspår till klienten. Remux eller Direktström ändrar bara en del av leveransformatet, ofta utan att koda om videon. En videotranskodning avkodar källan och skapar en ny videoström, vilket gör det till den mest sannolika orsaken till långvarig hög CPU-användning.

Denna skillnad avgör nästa test. Hög CPU under en bekräftad videotranskodning kan vara väntad om bearbetningen sker i programvara. Hög CPU under Direktuppspelning pekar vanligtvis på en annan session, en bakgrundsanalysuppgift eller en annan process som körs på servern.

Programvarubaserad videotranskodning är vanligtvis huvudorsaken

En mediaserver transkodar video när klienten inte kan acceptera den ursprungliga kombinationen av codec, profil, upplösning, bithastighet, behållare, ljud eller undertexter. Den kan också transkoda eftersom användaren valt en lägre uppspelningskvalitet.

Servern måste avkoda källbilderna, applicera eventuella filter, ändra storlek eller konvertera bilden och koda en ny ström snabbt nog för att ligga före uppspelningen. En 4K HEVC-källa konverterad till lägre upplösning H.264 kräver avsevärt mer bearbetning än att servera originalfilen.

Om alla dessa steg körs på allmänna CPU-kärnor kan hög användning vara normalt. Den viktiga frågan är om transkodern fortfarande är snabbare än uppspelningen. En upptagen CPU med smidig uppspelning skiljer sig från en CPU som är maxad medan klienten upprepade gånger buffrar.

Klienten avgör ofta om CPU behövs.

Samma fil kan Direktuppspelas på en streamingbox och trigga full transkodning i en webbläsare, TV-app, telefon eller äldre spelare. Varje klient stöder en annan kombination av behållare, videoprofiler, bitdjup, ljudformat, undertexter och maximala bithastigheter.

Även när videocodec stöds kan ett inkompatibelt ljudspår eller undertextformat ändra uppspelningsvägen. En klient kan acceptera HEVC-video men kräva att TrueHD-ljud konverteras, eller så kan den kräva videotranskodning när valda undertexter inte kan renderas lokalt.

Jämför samma fil på två klienter medan ljudspår, undertextval och kvalitetsinställning förblir oförändrade. Om hög CPU följer en klient, fokusera på den klientens kapabiliteter och inställningar innan du byter serverhårdvara.

Lägre kvalitet kan öka serverns CPU-användning.

Att välja en lägre kvalitetsinställning kan låta som att det borde minska serverns arbetsbelastning. I verkligheten måste servern oftast skapa en ny ström när den begärda upplösningen eller bithastigheten skiljer sig från källan.

Till exempel kräver en förfrågan om 1080p vid 8 Mbps från en 4K-fil med hög bithastighet avkodning, skalning och omkodning. Att välja Originalkvalitet kan tillåta Direktuppspelning när klienten stöder källformatet och nätverket klarar dess bithastighet.

Använd Originalkvalitet som ett diagnostiskt test på det lokala nätverket. Det är inte en universell lösning: en klient med inkompatibla codecs, otillräcklig bandbredd eller undertexter som inte stöds kan fortfarande kräva konvertering.

Inbränning av undertexter kan förvandla en lätt ström till en tung.

Om CPU-användningen bara ökar efter att undertexter aktiverats är det valda undertextspåret en stark misstänkt. Textundertexter som SRT renderas ofta av klienten, medan PGS och VobSub är bildbaserade format. ASS och SSA innehåller text men kan inkludera stil och positionering som vissa klienter inte kan återge.

När klienten inte kan visa undertextspåret kan servern bränna in det i bilden. Det kräver att videon avkodas, undertexterna kompositeras på varje bildruta och en ny videoström kodas.

Plex har specifikt arbetat med att förbättra prestandan för inbränning av undertexter under hårdvarutranskodning, med resultat som beror på operativsystem, GPU-typ och om tonmappning fanns kvar i kedjan. Det är därför samma undertexttest kan ge olika CPU-användning på olika servrar.

Testa undertextspåret separat

Spela upp samma scen med undertexter avstängda. Om CPU-användningen omedelbart sjunker och sessionen återgår till Direct Play, är det undertextvägen – inte bara källvideon – som orsakar det extra arbetet.

Prova sedan ett externt SRT-spår, ett annat undertexts språk eller en klient med bredare undertextstöd. Kontrollera också om servern rapporterar inbränning av undertexter snarare än enkel undertextleverans.

Anta inte att alla undertextformat har samma kostnad. Ett stiliserat textspår kan vara enkelt för en klient och kräva full videobehandling på en annan, medan en bildundertext från en Blu-ray kan vara särskilt svår att leverera utan inbränning.

En fungerande GPU betyder inte att hela kedjan är accelererad

Det är möjligt att se GPU-aktivitet medan CPU:n förblir hög. Hårdvaruacceleration kan avkoda och koda videon medan CPU:n fortfarande hanterar rendering av undertexter, ljudkonvertering, skalning, tonmappning eller ett annat filter.

Ett community-felsökningsfall visade GPU-transkodning som körs samtidigt som hög CPU-användning från inbränning av undertexter och ljudkonvertering. Fallet bör inte behandlas som en fast regel för varje aktuell version, men det illustrerar varför GPU-användning ensam är ofullständig bevisning.

Kontrollera både GPU:s avkodnings- och kodningsmotorer, och inspektera sedan transkoderloggen för mjukvarufilter. Jämför CPU-användning med undertexter avstängda, ett kompatibelt ljudspår valt och tonmappning borttagen från testet.

Hårdvaruacceleration kan falla tillbaka på mjukvara

Ett alternativ för hårdvaruacceleration kan aktiveras i servergränssnittet även när värddrivrutinen, enhetsbehörigheter, runtime eller vald codec inte fungerar korrekt.

Vissa källformat kan använda GPU:n framgångsrikt medan andra faller tillbaka på CPU:n. En GPU kan stödja H.264 och HEVC Main men inte exakt den bitdjup, kromformat, kodningsmål eller tonmappningsväg som krävs för en viss fil.

Tvinga en känd transkodning och övervaka servern i realtid. Bekräfta att hårdvaruavkodaren och kodaren är aktiva, inspektera transkodarkommandot och leta efter initialiseringsfel eller meddelanden om mjukvarufall tillbaka istället för att bara förlita dig på den aktiverade kryssrutan.

Docker lägger till ett separat GPU-åtkomstlager

När mediaservern körs i Docker, bevisar det inte att applikationen kan använda GPU:n inuti containern bara för att GPU:n upptäcks på värden. Containern behöver enheten, kompatibla användarbibliotek, rätt runtime och tillstånd att komma åt videofunktionerna.

För NVIDIA-distributioner är en användbar valideringssekvens att först bekräfta värddrivrutinen, verifiera att Docker känner igen NVIDIA runtime, kontrollera att nödvändiga bibliotek och enheter finns i containern och observera kodaraktivitet under en tvingad transkodning. En container där nvidia-smi körningar kan fortfarande sakna bibliotek eller kapabiliteter som krävs av mediaservern.

En praktisk Docker-konfiguration behöver därför verifiera NVIDIA runtime, användarbibliotek, enhetsexponering och kodaraktivitet inuti containern. Undvik att använda privilegierat läge som en permanent genväg; exponera endast de resurser tjänsten behöver.

Virtuella maskiner kan skapa samma felmönster

En virtuell maskin kan upptäcka en bildskärmsadapter utan att ha tillgång till hårdvarans kodnings- och avkodningsfunktioner som krävs för medietranskodning. GPU-passthrough, medierade enheter, drivrutiner och gästbehörigheter påverkar alla resultatet.

Verifiera GPU:n från gästoperativsystemet och sedan från mediaserverprocessen. GPU-aktivitet på värdnivå bevisar inte att gästapplikationen använder den avsedda motorn.

Om en native-installation använder hårdvaruacceleration men en annars identisk VM-installation använder hög CPU, jämför enhetsexponering och loggar innan du ändrar kodekinställningar eller kodar om biblioteket.

HDR-tonmappning kan lämna betydande arbete åt CPU:n

När HDR-media spelas upp på en SDR-skärm eller via en klient som inte kan ta emot den ursprungliga HDR-strömmen kan servern behöva utföra tonmappning utöver normal transkodning.

Pipeline kan inkludera 10-bitars avkodning, färgrymdskonvertering, ljusstyrkekartläggning, skalning, undertextkomposition och kodning. Hårdvarustöd för källkodeken garanterar inte att varje steg kan förbli på GPU:n.

Testa samma fil på en HDR-kompatibel klient och jämför sedan med en SDR-utgång. Om vanliga SDR-transkoder är effektiva men HDR-till-SDR-sessioner använder hög CPU, undersök tonmappningsmetoden och hårdvarustödet istället för att behandla all 4K-media som likvärdig.

Ljudkonvertering är vanligtvis inte lika tungt som videotranskodning

TrueHD, DTS, flerkanaligt ljud eller en icke understödd ljudcodec kan konverteras till ett format som klienten kan spela upp. Servern kan också mixa ner surroundljud till stereo.

Ljudtranskodning använder processorkraft, men är generellt lättare än att avkoda och koda om en hel videoström. Remuxing av en container bevarar också videoströmmen och kräver normalt mycket mindre beräkning än videokonvertering.

Om instrumentpanelen endast rapporterar ljudtranskodning medan CPU:n ligger nära sin gräns, kontrollera om det pågår undertextbehandling, bakgrundsanalys, en annan aktiv session eller en separat transkoderprocess. Anta inte att den synliga ljudetiketten förklarar hela arbetsbelastningen.

Direct Play med hög CPU betyder vanligtvis att en annan uppgift körs

Direct Play kräver fortfarande filavläsning, autentisering, applikationslogik och nätverksleverans, så CPU-användningen blir aldrig exakt noll. Det bör normalt inte kräva den tunga videobehandlingen som är förknippad med mjukvarutranskodning.

Plex kan använda betydande CPU för intro- och kreditdetektion, förhandsgranskningsminiatyrer, röstanalys, reklamdetektion, medieoptimering och nedladdningsförberedelse. Vissa av dessa jobb använder transkodern även när ingen aktivt tittar på media.

Kontrollera operativsystemets processlista istället för bara den totala CPU-grafen. Identifiera om den aktuella strömmens transkoder, en schemalagd analysprocess, en biblioteksskanner eller en orelaterad container är ansvarig.

Schemalagd analys kan se ut som uppspelningsbelastning

Ett bakgrundsjobb kan starta ungefär samtidigt som någon börjar titta, vilket gör att det verkar som att själva uppspelningen orsakade CPU-toppen. Underhållsfönster körs ofta över natten eller strax efter att nytt innehåll lagts till.

En Unraid-diskussion spårade uppenbarligen inaktiv CPU-belastning till schemalagd medieanalys och senare till intro- och kreditdetektion. Detta är ett exempel från communityn snarare än bevis för att varje fall av inaktiv belastning har samma orsak.

Pausa tillfälligt förhandsgranskning, introduktionsdetektion, eftertextdetektion, optimering och djup medieanalys. Om CPU-användningen sjunker utan att den aktiva strömmen ändras, flytta dessa uppgifter till ett annat underhållsfönster istället för att ändra uppspelningsinställningarna.

Flera strömmar multiplicerar olika typer av arbete

En Direct Play-session ökar främst lagrings- och nätverksbelastning. En ljudtranskodning lägger till en mindre konverteringsuppgift. En mjukvarutranskodning av 4K-video kan förbruka mycket mer beräkningskraft än flera direkta strömmar.

När en annan användare startar uppspelning, inspektera varje session individuellt. Två användare skapar inte nödvändigtvis dubbelt så mycket arbete: en kan Direct Play medan den andra bränner in undertexter i en HDR-transkodning.

Lägg till testsessioner en i taget medan du övervakar CPU, GPU, nätverk, disklatens och transkodningshastighet. Detta visar om den praktiska gränsen är mjukvarukodning, hårdvarukodarkapacitet, lagringskonflikt eller total bandbredd.

Live TV kan kräva ytterligare bearbetning

Live TV kan komma i en kodek, upplösning, flätad format eller bithastighet som uppspelningsklienten inte kan acceptera direkt. Servern kan behöva avfläta, konvertera video, ändra ljud eller skapa en ström med lägre hastighet.

Dessa operationer kan göra liveuppspelning mer CPU-intensiv än en vanlig film som Direct Play. Inspelning och reklamanalys kan också köras parallellt med visning, vilket ökar serverns arbetsbelastning.

Kontrollera live-sessionens källkodek, avflätning, uppspelningsläge och valda kvalitet separat från det lagrade mediebiblioteket. Ett problem med Live TV bevisar inte att alla lokala filer kräver samma hårdvara.

Fjärruppspelning tvingar ofta fram en ny bithastighet

En fil med hög bithastighet kan Direct Play över det lokala nätverket men överstiga serverns tillgängliga internetuppladdningshastighet. Den fjärranslutna klienten eller serverns gräns begär då en mindre ström.

Att minska bithastigheten innebär normalt att servern måste skapa en ny videooutput. CPU-användningen kan därför öka under fjärruppspelning även när samma klient använder lite serverresurser hemma.

Jämför källans bithastighet med hållbar uppladdningskapacitet och klientens fjärrkvalitetsinställning. Om en sänkning av strömmen skapar en mjukvarutranskodning kan korrekt konfigurerad hårdvaruacceleration eller en förkodad fjärrversion minska CPU-belastningen.

En kort CPU-topp kan vara normal

Vissa transkodare arbetar före uppspelningspositionen för att skapa en buffert. CPU-användningen kan stiga kraftigt i början, sjunka när tillräckligt många segment har producerats och öka igen när mer output behövs.

En kort topp med smidig uppspelning och stabila temperaturer kräver inte nödvändigtvis en åtgärd. Ihållande maximal användning, fallande transkodningshastighet, upprepad buffring eller termisk nedtrappning indikerar ett mer betydande kapacitetsproblem.

Observera arbetsbelastningen under flera minuter istället för att förlita dig på en enda CPU-skärmdump. Registrera om processorn förblir fastlåst, om transkodern håller sig före och om serverns klockfrekvens sjunker när temperaturen ökar.

Koda inte om hela biblioteket först

Att konvertera varje fil till ett brett stödd format kan minska framtida realtids-transkodning, men det kräver tid, extra lagring och ett ytterligare förlustfyllt kodningssteg för många källor.

Det kan också misslyckas med att åtgärda den faktiska orsaken om den höga CPU:n kommer från inbränning av undertexter, HDR-tonmappning, fjärrbitratebegränsningar, bakgrundsanalys eller bruten GPU-åtkomst inuti Docker.

Identifiera först kombinationerna som upprepade gånger misslyckas på de klienter du faktiskt använder. Skapa optimerade kopior endast för media med högfrekventa problem, eller använd en mer kapabel klient där det är enklare än att underhålla flera versioner av biblioteket.

Använd denna felsökningsordning

1. Återskapa sessionen med hög CPU med samma fil och klient.
2. Registrera om det är Direktuppspelning, Remux, ljudtranskodning eller videotranskodning.
3. Identifiera exakt process som använder CPU.
4. Registrera angiven anledning till konvertering.
5. Testa originalkvalitet på det lokala nätverket.
6. Inaktivera undertexter och välj ett annat ljudspår.
7. Spela samma fil på en annan klient.
8. Övervaka GPU-avkodnings- och kodningsmotorer.
9. Inspektera transkoderns eller FFmpeg-loggen för mjukvarureserv.
10. Verifiera GPU-åtkomst från insidan av Docker eller den virtuella maskinen.
11. Pausa medieanalys, förhandsgranskning och optimeringsjobb.
12. Lägg till ytterligare strömmar en i taget.
13. Kontrollera temperatur och CPU-klockfrekvens.
14. Uppgradera hårdvara först efter att flaskhalsen bekräftats.

Slutsats

Hög CPU under medieuppspelning är vanligtvis resultatet av ett bearbetningsval, inte en diagnos i sig. Fullständig mjukvaruvideotranskodning är den vanligaste orsaken, men inbränning av undertexter, HDR-tonmappning, partiell hårdvaruacceleration, fjärrkvalitetsbegränsningar och samtidiga sessioner kan skapa liknande belastning.

Börja med att identifiera uppspelningsläge och exakt process som använder CPU:n. Om sessionen transkodas, testa klientkompatibilitet, originalkvalitet, undertexter, ljudspår och hela hårdvaruaccelerationskedjan. Om det är direktuppspelning, inspektera bakgrundsanalys och andra aktiva uppgifter.

Uppgradera servern först efter att loggar och kontrollerade tester visar att nödvändig realtidsbearbetning överstiger tillgänglig kapacitet. Många fall med hög CPU kan lösas genom att ändra uppspelningsvägen, korrigera Docker GPU-åtkomst, schemalägga analys utanför visningstider eller välja en klient som kan spela originalmediet direkt.

Vanliga frågor

Varför ökar CPU-användningen när undertexter är aktiverade?

Klienten kanske inte kan rendera det valda undertextformatet. Servern bränner då in undertexterna i varje videobildruta, vilket kräver avkodning och omkodning av videon. Testa med undertexter avstängda eller välj en stödd textbaserad spår.

Varför är CPU fortfarande hög när hårdvarutranskodning är aktiverad?

GPU:n kan bara påskynda videodekodning och kodning medan CPU:n hanterar undertexter, ljud, tonmappning, skalning eller andra filter. Hårdvaruåtkomst kan också vara ofullständig i Docker eller en virtuell maskin.

Använder Direktuppspelning ingen CPU?

Nej. Direktuppspelning kräver fortfarande filåtkomst, nätverk, autentisering och applikationsbearbetning. Det bör normalt använda mycket mindre CPU än videotranskodning, så en ihållande hög belastning bör leda till kontroll av bakgrundsjobb eller andra processer.

Varför ökar CPU-användningen när streamingkvaliteten sänks?

En lägre upplösning eller bithastighet kräver vanligtvis att servern skapar en ny videoström. Om originalfilen kunde spela direkt, ändrar valet av lägre kvalitet sessionen till en transkodning och ökar serverns belastning.

Kan medieskanning orsaka hög CPU-användning medan en film spelas upp?

Ja. Förhandsgranskning av miniatyrbilder, introduktions- eller krediteringsdetektion, optimering, röstanalys och andra bakgrundsjobb kan köras samtidigt som uppspelning pågår. Kontrollera processlistan och status för schemalagda uppgifter innan du tillskriver all CPU-användning till den aktiva strömmen.