Waarom gebruikt een mediaserver veel CPU tijdens het afspelen?

Hoge CPU-belasting tijdens mediastreaming betekent meestal dat de server meer doet dan het originele bestand verzenden. Het kan video decoderen en opnieuw coderen, ondertitels in elke frame inbranden, HDR converteren voor een SDR-client, resolutie verlagen of een stream met lagere bitrate maken voor een externe verbinding.

Hoge CPU betekent echter niet automatisch dat de processor te zwak is. Hardwareversnelling kan slechts voor een deel van de pijplijn werken, een achtergrondanalysetaak kan tegelijkertijd draaien, of meerdere sessies kunnen om dezelfde bronnen concurreren. De eerste stap is om de afspeelmodus en het proces dat daadwerkelijk de CPU gebruikt te identificeren.

Controleer de afspeelmodus voordat u de hardware de schuld geeft

Open het serverdashboard terwijl de probleemstream actief is. Plex, Jellyfin, Emby en vergelijkbare platforms tonen normaal gesproken of de sessie Direct Play, Direct Stream of Remux gebruikt, audio converteert of volledige videotranscodering uitvoert.

Direct Play stuurt de originele container, video, audio en ondersteunde ondertiteltracks naar de client. Remux of Direct Stream verandert slechts een deel van het afleverformaat, vaak zonder de video opnieuw te coderen. Een videotranscodering decodeert de bron en maakt een nieuwe videostream, waardoor dit het meest waarschijnlijke pad is naar aanhoudend hoge CPU-belasting.

Dit onderscheid bepaalt de volgende test. Hoge CPU tijdens een bevestigde videotranscodering kan worden verwacht als de verwerking in software plaatsvindt. Hoge CPU tijdens Direct Play wijst meestal op een andere sessie, een achtergrondanalysetaak of een ander proces dat op de server draait.

Softwarematige videotranscodering is meestal de hoofdoorzaak

Een mediaserver zet video om wanneer de client de originele combinatie van codec, profiel, resolutie, bitrate, container, audio of ondertitels niet kan accepteren. Het kan ook transcoderen omdat de gebruiker een lagere afspeelkwaliteit heeft gekozen.

De server moet de bronframes decoderen, eventuele benodigde filters toepassen, het beeld schalen of converteren en een nieuwe stream snel genoeg coderen om voor te blijven op de weergave. Een 4K HEVC-bron die wordt omgezet naar een lagere resolutie H.264 vereist aanzienlijk meer verwerking dan het serveren van het originele bestand.

Als al deze stappen op algemene CPU-kernen worden uitgevoerd, kan een hoog gebruik normaal zijn. De relevante vraag is of de transcoder sneller blijft dan de weergave. Een drukke CPU met vloeiende weergave is anders dan een CPU die op zijn limiet draait terwijl de client herhaaldelijk buffert.

De client bepaalt vaak of de CPU nodig is

Hetzelfde bestand kan Direct Play zijn op een streamingbox en een volledige transcodering veroorzaken in een browser, televisie-app, telefoon of oudere speler. Elke client ondersteunt een andere combinatie van containers, videoprofielen, bitdieptes, audioformaten, ondertitels en maximale bitrates.

Zelfs wanneer de videocodec wordt ondersteund, kan een incompatibel audiotrack of ondertitelingsformaat het afspeelpad veranderen. Een client kan HEVC-video accepteren maar vereisen dat TrueHD-audio wordt geconverteerd, of video-transcodering nodig hebben wanneer de geselecteerde ondertitels niet lokaal kunnen worden weergegeven.

Vergelijk hetzelfde bestand op twee clients terwijl je het audiotrack, de ondertitelkeuze en de kwaliteitsinstelling ongewijzigd laat. Als de hoge CPU-belasting bij één client optreedt, richt je dan eerst op de mogelijkheden en instellingen van die client voordat je de serverhardware vervangt.

Lagere kwaliteit kan het CPU-gebruik van de server verhogen

Het kiezen van een lagere kwaliteitsinstelling lijkt misschien de serverbelasting te verminderen. In werkelijkheid moet de server meestal een nieuwe stream maken wanneer de gevraagde resolutie of bitrate afwijkt van de bron.

Bijvoorbeeld, het vragen om 1080p bij 8 Mbps van een 4K-bestand met hoge bitrate vereist decoderen, schalen en opnieuw coderen. Het selecteren van Originele kwaliteit kan Direct Play mogelijk maken wanneer de client het bronformaat ondersteunt en het netwerk de bitrate aankan.

Gebruik Originele kwaliteit als een diagnostische test op het lokale netwerk. Het is geen universele oplossing: een client met incompatibele codecs, onvoldoende bandbreedte of niet-ondersteunde ondertitels kan nog steeds conversie vereisen.

Het inbranden van ondertitels kan een lichte stream zwaar maken

Als het CPU-gebruik alleen stijgt nadat ondertitels zijn ingeschakeld, is het geselecteerde ondertitelspoor een sterke verdachte. Tekstondertitels zoals SRT worden vaak door de client weergegeven, terwijl PGS en VobSub afbeeldingsgebaseerde formaten zijn. ASS en SSA bevatten tekst maar kunnen ook stijl- en positioneringsinformatie bevatten die sommige clients niet kunnen reproduceren.

Wanneer de client de ondertitelspoor niet kan weergeven, kan de server deze in het beeld branden. Dat vereist het decoderen van de video, het samenvoegen van de ondertitels op elk frame en het coderen van een nieuwe videostream.

Plex heeft specifiek gewerkt aan het verbeteren van de prestaties van ondertitelverbranding tijdens hardwaretranscodering, met resultaten die afhangen van het besturingssysteem, het type GPU en of tone mapping in de pijplijn bleef. Daarom kan dezelfde ondertiteltest verschillend CPU-gebruik opleveren op verschillende servers.

Test de ondertiteltrack afzonderlijk

Speel dezelfde scène opnieuw af met uitgeschakelde ondertitels. Als het CPU-gebruik onmiddellijk daalt en de sessie terugkeert naar Direct Play, veroorzaakt het ondertitelpad – en niet alleen de bronvideo – het extra werk.

Probeer vervolgens een externe SRT-track, een andere ondertiteltaal of een client met bredere ondertitelingsondersteuning. Controleer ook of de server ondertitelverbranding rapporteert in plaats van eenvoudige ondertitelaflevering.

Ga er niet van uit dat elk ondertitelingsformaat dezelfde kosten heeft. Een gestileerde teksttrack kan voor de ene client eenvoudig zijn en voor een andere volledige videobewerking vereisen, terwijl een afbeeldingsondertitel van een Blu-ray bijzonder moeilijk te leveren is zonder verbranding.

Een werkende GPU betekent niet dat de hele pijplijn versneld is

Het is mogelijk om GPU-activiteit te zien terwijl de CPU hoog blijft. Hardwareversnelling kan de video decoderen en encoderen terwijl de CPU nog steeds de ondertitelweergave, audioconversie, schaling, tone mapping of een andere filter afhandelt.

Een community-probleemtoevallige toonde GPU-transcodering die samenwerkt met hoog CPU-gebruik door ondertitelverbranding en audioconversie. Dit geval moet niet als vaste regel voor elke huidige versie worden beschouwd, maar illustreert waarom alleen GPU-gebruik onvolledig bewijs is.

Controleer zowel de GPU-decodeer- als encodeermotoren en inspecteer vervolgens het transcoderlogboek op softwarefilters. Vergelijk het CPU-gebruik met uitgeschakelde ondertitels, een compatibele audiotrack geselecteerd en tone mapping verwijderd uit de test.

Hardwareversnelling kan terugvallen op software

Een optie voor hardwareversnelling kan worden ingeschakeld in de serverinterface, zelfs wanneer de hostdriver, apparaatmachtigingen, runtime of geselecteerde codec niet correct werken.

Sommige bronformaten kunnen de GPU succesvol gebruiken, terwijl andere terugvallen op de CPU. Een GPU kan H.264 en HEVC Main ondersteunen, maar niet de exacte bitdiepte, chroma-indeling, encodeerdoel of tone-mapping-pad die vereist is door een bepaald bestand.

Forceer een bekende transcode en monitor de server in realtime. Bevestig dat de hardwaredecoder en -encoder actief zijn, inspecteer het transcoder-commando en let op initialisatiefouten of softwareterugvalmeldingen in plaats van alleen te vertrouwen op het aangevinkte vakje.

Docker voegt een aparte GPU-toegangslaag toe

Wanneer de mediaserver in Docker draait, bewijst het detecteren van de GPU op de host niet dat de applicatie deze binnen de container kan gebruiken. De container heeft het apparaat, compatibele gebruikersruimbibliotheken, de juiste runtime en toestemming nodig om toegang te krijgen tot de videofuncties.

Voor NVIDIA-implementaties is een nuttige validatiereeks om eerst de hostdriver te bevestigen, te verifiëren dat Docker de NVIDIA-runtime herkent, te controleren of de vereiste bibliotheken en apparaten binnen de container aanwezig zijn, en encoderactiviteit te observeren tijdens een geforceerde transcode. Een container waar nvidia-smi runs kunnen nog steeds bibliotheken of mogelijkheden missen die door de mediaserver vereist zijn.

Een praktische Docker-setup moet daarom de NVIDIA-runtime, gebruikersruimbibliotheken, apparaatblootstelling en encoderactiviteit binnen de container verifiëren. Vermijd het gebruik van de privileged-modus als permanente oplossing; stel alleen de bronnen bloot die de service nodig heeft.

Virtuele machines kunnen hetzelfde faalpatroon veroorzaken

Een virtuele machine kan een beeldschermadapter detecteren zonder toegang te hebben tot de hardware-encodeer- en decodeerfuncties die nodig zijn voor mediatranscodering. GPU-passthrough, gemedieerde apparaten, drivers en gastrechten beïnvloeden allemaal het resultaat.

Valideer de GPU vanuit het gastbesturingssysteem en vervolgens vanuit het mediaserverproces. GPU-activiteit op hostniveau bewijst niet dat de gastapplicatie de bedoelde engine gebruikt.

Als een native installatie hardwareversnelling gebruikt maar een verder identieke VM-installatie hoge CPU-belasting heeft, vergelijk dan apparaatblootstelling en logs voordat je codec-instellingen wijzigt of de bibliotheek opnieuw codeert.

HDR-toonmapping kan aanzienlijke belasting op de CPU achterlaten

Wanneer HDR-media wordt afgespeeld op een SDR-scherm of via een client die de originele HDR-stream niet kan accepteren, moet de server mogelijk toonmapping uitvoeren naast normale transcoding.

De pijplijn kan 10-bit decodering, kleurenspaceconversie, helderheidsmapping, schaling, ondertitelcompositie en codering omvatten. Hardware-ondersteuning voor de broncodec garandeert niet dat elk van deze stadia op de GPU kan blijven.

Test hetzelfde bestand op een HDR-compatibele client en vergelijk het vervolgens met een SDR-uitvoer. Als gewone SDR-transcodes efficiënt zijn maar HDR-naar-SDR-sessies veel CPU gebruiken, onderzoek dan de toonmappingmethode en hardware-ondersteuning in plaats van alle 4K-media als gelijk te beschouwen.

Audioconversie is meestal niet zo zwaar als videotranscodering

TrueHD, DTS, multikanaals audio of een niet-ondersteunde audiocodec kan worden geconverteerd naar een formaat dat de client kan afspelen. De server kan ook surround sound downmixen naar stereo.

Audio-transcodering verbruikt verwerkingskracht, maar is over het algemeen lichter dan het decoderen en opnieuw coderen van een volledige videostream. Het remuxen van een container behoudt ook de videostream en vereist normaal gesproken veel minder rekenkracht dan videoconversie.

Als het dashboard alleen audio-transcodering meldt terwijl de CPU dicht bij de limiet blijft, controleer dan op ondertitelverwerking, achtergrondanalyse, een andere actieve sessie of een apart transcoderproces. Ga er niet vanuit dat het zichtbare audiolabel de volledige werklast verklaart.

Direct Play met hoge CPU betekent meestal dat een andere taak draait

Direct Play vereist nog steeds bestandslezingen, authenticatie, applicatielogica en netwerklevering, dus CPU-gebruik zal niet precies nul zijn. Het zou normaal gesproken niet de zware videobewerking van een softwaretranscode moeten vereisen.

Plex kan aanzienlijke CPU gebruiken voor intro- en creditdetectie, preview-thumbnails, spraakanalyse, reclame-detectie, media-optimalisatie en downloadvoorbereiding. Sommige van deze taken roepen de transcoder aan, zelfs als niemand actief media bekijkt.

Controleer de proceslijst van het besturingssysteem in plaats van alleen de totale CPU-grafiek. Bepaal of de huidige streamtranscoder, een geplande analyse, een bibliotheekscanner of een niet-gerelateerde container verantwoordelijk is.

Geplande analyse kan eruitzien als afspeellast

Een achtergrondtaak kan ongeveer tegelijk starten met het begin van het afspelen, waardoor het lijkt alsof het afspelen zelf de CPU-piek veroorzaakte. Onderhoudsvensters draaien vaak ’s nachts of kort nadat nieuwe content is toegevoegd.

Een Unraid-discussie bracht schijnbaar inactieve CPU-belasting in verband met geplande media-analyse en later met intro- en creditdetectie. Dit is een voorbeeld uit de community en geen bewijs dat elke inactieve belasting hetzelfde veroorzaakt.

Pauzeer tijdelijk previewgeneratie, introdetectie, creditdetectie, optimalisatie en diepe media-analyse. Als het CPU-gebruik daalt zonder de actieve stream te veranderen, verplaats die taken dan naar een ander onderhoudsvenster in plaats van de afspeelinstellingen aan te passen.

Meerdere streams vermenigvuldigen verschillende soorten werk

Een Direct Play-sessie voegt vooral opslag- en netwerkbelasting toe. Eén audiotranscode voegt een kleinere conversietaak toe. Eén softwarematige 4K-videotranscode kan veel meer rekenkracht verbruiken dan meerdere directe streams.

Wanneer een andere gebruiker begint met afspelen, inspecteer elke sessie afzonderlijk. Twee gebruikers creëren niet per se twee keer dezelfde werklast: de één kan Direct Play gebruiken terwijl de ander ondertitels in een HDR-transcode brandt.

Voeg testsessies één voor één toe terwijl je CPU, GPU, netwerk, schijflatentie en transcodesnelheid in de gaten houdt. Dit laat zien of de praktische limiet softwarecodering, hardware-encoder capaciteit, opslagconcurrentie of totale bandbreedte is.

Live TV kan extra verwerking vereisen

Live TV kan binnenkomen in een codec, resolutie, interlaced formaat of bitrate die de afspeelclient niet direct accepteert. De server moet mogelijk de-interlacen, video converteren, audio aanpassen of een stream met lagere bitrate maken.

Deze bewerkingen kunnen live afspelen CPU-intensiever maken dan een gewone film die Direct Playt. Opname en reclame-analyse kunnen ook tegelijk lopen, wat extra serverwerk toevoegt.

Controleer de broncodec, de-interlacingstatus, afspeelmodus en geselecteerde kwaliteit van de live sessie apart van de opgeslagen mediatheek. Een probleem met Live TV bewijst niet dat alle lokale bestanden dezelfde hardware vereisen.

Afstandsweergave dwingt vaak een nieuwe bitrate af

Een bestand met hoge bitrate kan Direct Play zijn via het thuisnetwerk, maar de beschikbare uploadsnelheid van de server via internet overschrijden. De afstandsclient of serverlimiet vraagt dan om een kleinere stream.

Het verlagen van de bitrate betekent meestal dat de server een nieuwe video-uitvoer moet maken. CPU-gebruik kan daarom stijgen tijdens afstandsweergave, zelfs als dezelfde client thuis weinig serverkracht gebruikt.

Vergelijk de bron-bitrate met de duurzame uploadcapaciteit en de afstandsinstelling voor kwaliteit van de client. Als het verlagen van de stream een softwaretranscodering veroorzaakt, kan correct geconfigureerde hardwareversnelling of een vooraf gecodeerde afstandsversie de CPU-belasting verminderen.

Een korte CPU-piek kan normaal zijn

Sommige transcoders werken vooruit op de afspeelpositie om een buffer te creëren. CPU-gebruik kan aan het begin sterk stijgen, dalen wanneer er genoeg segmenten zijn geproduceerd, en weer toenemen wanneer er meer output nodig is.

Een korte piek met vloeiende weergave en stabiele temperaturen vereist niet per se een oplossing. Aanhoudend maximaal gebruik, dalende transcodesnelheid, herhaald bufferen of thermische throttling duidt op een ernstiger capaciteitsprobleem.

Observeer de werklast over meerdere minuten in plaats van te vertrouwen op een enkele CPU-screenshot. Noteer of de processor vast blijft staan, of de transcoder voorloopt en of de serverkloksnelheid daalt naarmate de temperatuur stijgt.

Encodeer niet eerst de hele bibliotheek opnieuw

Het converteren van elk bestand naar een breed ondersteund formaat kan toekomstige realtime transcodering verminderen, maar vereist tijd, extra opslag en een extra verliesgevende encodeerstap voor veel bronnen.

Het kan ook de werkelijke oorzaak niet aanpakken als de hoge CPU komt door ondertitel inbranden, HDR tone mapping, externe bitratebeperkingen, achtergrondanalyse of gebroken GPU-toegang binnen Docker.

Identificeer eerst de combinaties die herhaaldelijk falen op de clients die je daadwerkelijk gebruikt. Maak geoptimaliseerde kopieën alleen voor media met veelvoorkomende problemen, of gebruik een capabelere client als dat eenvoudiger is dan meerdere versies van de bibliotheek te onderhouden.

Gebruik deze volgorde voor probleemoplossing

1. Reproduceer de hoge-CPU-sessie met hetzelfde bestand en dezelfde client.
2. Noteer of het Direct Play, Remux, audio transcodering of video transcodering is.
3. Identificeer het exacte proces dat CPU verbruikt.
4. Noteer de opgegeven reden voor conversie.
5. Test originele kwaliteit op het lokale netwerk.
6. Schakel ondertitels uit en selecteer een andere audiotrack.
7. Speel hetzelfde bestand af op een andere client.
8. Monitor GPU decodeer- en encodeer-engines.
9. Inspecteer de transcoder- of FFmpeg-log voor software fallback.
10. Verifieer GPU-toegang vanuit Docker of de virtuele machine.
11. Pauzeer media-analyse, previewgeneratie en optimalisatietaken.
12. Voeg extra streams één voor één toe.
13. Controleer temperatuur en CPU-kloksnelheid.
14. Upgrade hardware alleen nadat de bottleneck is bevestigd.

Laatste conclusie

Hoge CPU tijdens mediaplayback is meestal het resultaat van een verwerkingsbeslissing, niet een diagnose op zich. Volledige softwarevideotranscodering is de meest voorkomende oorzaak, maar ondertitelingsinbranding, HDR-toonmapping, gedeeltelijke hardwareversnelling, externe kwaliteitslimieten en gelijktijdige sessies kunnen een vergelijkbare belasting veroorzaken.

Begin met het identificeren van de afspeelmodus en het exacte proces dat de CPU gebruikt. Als de sessie aan het transcoderen is, test dan clientcompatibiliteit, originele kwaliteit, ondertitels, audiotracks en de volledige hardwareversnellingspijplijn. Als het Direct Play is, controleer dan achtergrondanalyse en andere actieve taken.

Upgrade de server alleen nadat logs en gecontroleerde tests aantonen dat de vereiste realtimeverwerking de beschikbare capaciteit overschrijdt. Veel gevallen van hoge CPU kunnen worden opgelost door het afspeelpad te wijzigen, Docker GPU-toegang te corrigeren, analyse buiten kijktijden te plannen of een client te selecteren die het originele medium kan Direct Playen.

FAQ

Waarom neemt het CPU-gebruik toe wanneer ondertitels zijn ingeschakeld?

De client kan het geselecteerde ondertitelingsformaat mogelijk niet weergeven. De server brandt dan de ondertitels in elk videoframe, wat decodering en hercodering van de video vereist. Test met uitgeschakelde ondertitels of selecteer een ondersteunde tekstgebaseerde track.

Waarom is de CPU nog steeds hoog wanneer hardwaretranscodering is ingeschakeld?

De GPU kan mogelijk alleen videodecodering en -codering versnellen, terwijl de CPU ondertitels, audio, toonmapping, schaling of een ander filter verwerkt. Hardwaretoegang kan ook onvolledig zijn binnen Docker of een virtuele machine.

Gebruikt Direct Play geen CPU?

Nee. Direct Play vereist nog steeds bestands toegang, netwerken, authenticatie en applicatieverwerking. Het zou normaal gesproken veel minder CPU moeten gebruiken dan videotranscodering, dus aanhoudende zware belasting moet aanleiding geven om achtergrondtaken of een ander proces te controleren.

Waarom verhoogt het verlagen van de streamingkwaliteit het CPU-gebruik?

Een lagere resolutie of bitrate vereist meestal dat de server een nieuwe videostream aanmaakt. Als het originele bestand Direct Play kon, verandert het selecteren van een lagere kwaliteit de sessie in een transcode en verhoogt het de serververwerking.

Kan mediascanning hoge CPU veroorzaken terwijl een film wordt afgespeeld?

Ja. Voorvertoning van miniatuurafbeeldingen, detectie van intro of credits, optimalisatie, spraakanalyse en andere achtergrondtaken kunnen tegelijkertijd met het afspelen worden uitgevoerd. Controleer de proceslijst en de status van geplande taken voordat u alle CPU-gebruik toeschrijft aan de actieve stream.