Warum verwendet ein Mediaserver während der Wiedergabe eine hohe CPU-Auslastung?

Hohe CPU-Auslastung während der Medienwiedergabe bedeutet normalerweise, dass der Server mehr tut, als nur die Originaldatei zu senden. Er kann Video dekodieren und neu kodieren, Untertitel in jeden Frame einbrennen, HDR für einen SDR-Client konvertieren, die Auflösung herunterskalieren oder einen Stream mit niedrigerer Bitrate für eine Remote-Verbindung erstellen.

Hohe CPU-Auslastung beweist jedoch nicht automatisch, dass der Prozessor zu schwach ist. Die Hardwarebeschleunigung kann nur für einen Teil der Pipeline aktiv sein, eine Hintergrundanalyse kann gleichzeitig laufen oder mehrere Sitzungen konkurrieren um dieselben Ressourcen. Der erste Schritt ist, den Wiedergabemodus und den Prozess zu identifizieren, der tatsächlich die CPU belastet.

Überprüfen Sie den Wiedergabemodus, bevor Sie die Hardware beschuldigen

Öffnen Sie das Server-Dashboard, während der problematische Stream aktiv ist. Plex, Jellyfin, Emby und ähnliche Plattformen zeigen normalerweise an, ob die Sitzung Direktwiedergabe, Direktstream oder Remux, Audiokonvertierung oder vollständige Video-Transkodierung verwendet.

Direktwiedergabe sendet den ursprünglichen Container, das Video, Audio und unterstützte Untertitelspuren an den Client. Remux oder Direktstream ändern nur Teile des Lieferformats, oft ohne das Video neu zu kodieren. Eine Video-Transkodierung dekodiert die Quelle und erstellt einen neuen Videostream, was den wahrscheinlichsten Weg für anhaltend hohe CPU-Auslastung darstellt.

Diese Unterscheidung bestimmt den nächsten Test. Hohe CPU-Auslastung während einer bestätigten Video-Transkodierung kann erwartet werden, wenn die Verarbeitung in Software erfolgt. Hohe CPU-Auslastung bei Direktwiedergabe weist normalerweise auf eine andere Sitzung, eine Hintergrundanalyse oder einen anderen Prozess auf dem Server hin.

Software-Video-Transkodierung ist normalerweise die Hauptursache

Ein Medienserver transkodiert Videos, wenn der Client die ursprüngliche Kombination aus Codec, Profil, Auflösung, Bitrate, Container, Audio oder Untertiteln nicht akzeptieren kann. Er kann auch transkodieren, wenn der Benutzer eine niedrigere Wiedergabequalität ausgewählt hat.

Der Server muss die Quellframes dekodieren, erforderliche Filter anwenden, das Bild skalieren oder konvertieren und einen neuen Stream schnell genug kodieren, um der Wiedergabe voraus zu sein. Eine 4K-HEVC-Quelle, die in eine niedrigauflösende H.264-Datei umgewandelt wird, erfordert deutlich mehr Verarbeitung als das Bereitstellen der Originaldatei.

Wenn all diese Stufen auf allgemeinen CPU-Kernen laufen, kann eine hohe Auslastung normal sein. Die entscheidende Frage ist, ob der Transcoder schneller bleibt als die Wiedergabe. Eine ausgelastete CPU mit flüssiger Wiedergabe ist anders als eine CPU, die an ihrer Grenze arbeitet, während der Client ständig puffert.

Der Client entscheidet oft, ob die CPU benötigt wird.

Die gleiche Datei kann auf einer Streaming-Box direkt abgespielt werden, während sie in einem Browser, einer Fernseh-App, einem Telefon oder einem älteren Player eine vollständige Transkodierung auslöst. Jeder Client unterstützt eine andere Kombination aus Containern, Videoprofilen, Farbtiefen, Audioformaten, Untertiteln und maximalen Bitraten.

Selbst wenn der Videocodec unterstützt wird, kann eine inkompatible Audiospur oder ein Untertitelformat den Wiedergabepfad ändern. Ein Client kann HEVC-Video akzeptieren, aber TrueHD-Audio muss konvertiert werden, oder es kann eine Videotranscodierung erforderlich sein, wenn die ausgewählten Untertitel lokal nicht gerendert werden können.

Vergleichen Sie dieselbe Datei auf zwei Clients, während Sie die Audiospur, die Untertitelauswahl und die Qualitätseinstellung unverändert lassen. Wenn die hohe CPU-Auslastung nur bei einem Client auftritt, konzentrieren Sie sich auf dessen Fähigkeiten und Einstellungen, bevor Sie die Serverhardware austauschen.

Niedrigere Qualität kann die CPU-Auslastung des Servers erhöhen.

Die Wahl einer niedrigeren Qualitätseinstellung klingt, als würde sie die Serverlast reduzieren. Tatsächlich muss der Server normalerweise einen neuen Stream erstellen, wenn die angeforderte Auflösung oder Bitrate vom Original abweicht.

Zum Beispiel erfordert die Anforderung von 1080p bei 8 Mbps aus einer 4K-Datei mit hoher Bitrate das Dekodieren, Skalieren und erneute Kodieren. Die Auswahl der Originalqualität kann Direct Play ermöglichen, wenn der Client das Quellformat unterstützt und das Netzwerk die Bitrate tragen kann.

Verwenden Sie Originalqualität als Diagnosetest im lokalen Netzwerk. Es ist keine universelle Lösung: Ein Client mit inkompatiblen Codecs, unzureichender Bandbreite oder nicht unterstützten Untertiteln benötigt möglicherweise weiterhin eine Konvertierung.

Das Einbrennen von Untertiteln kann einen leichten Stream in einen schweren verwandeln.

Wenn die CPU-Auslastung erst nach dem Aktivieren der Untertitel steigt, ist die ausgewählte Untertitelspur ein starker Verdacht. Textuntertitel wie SRT werden oft vom Client gerendert, während PGS und VobSub bildbasierte Formate sind. ASS und SSA enthalten Text, können aber auch Stil- und Positionsangaben enthalten, die einige Clients nicht wiedergeben können.

Wenn der Client die Untertitelspur nicht wiedergeben kann, kann der Server diese ins Bild einbrennen. Das erfordert das Dekodieren des Videos, das Einfügen der Untertitel in jeden Frame und das Kodieren eines neuen Videostreams.

Plex hat speziell an Verbesserungen der Untertitel-Burn-in-Leistung während der Hardware-Transkodierung gearbeitet, mit Ergebnissen, die vom Betriebssystem, dem GPU-Typ und davon abhängen, ob Ton-Mapping in der Pipeline verbleibt. Deshalb kann derselbe Untertiteltest auf verschiedenen Servern unterschiedliche CPU-Auslastungen erzeugen.

Testen Sie die Untertitelspur separat

Spielen Sie dieselbe Szene mit deaktivierten Untertiteln erneut ab. Wenn die CPU-Auslastung sofort sinkt und die Sitzung zu Direct Play zurückkehrt, verursacht der Untertitelpfad – nicht nur das Quellvideo – die zusätzliche Belastung.

Versuchen Sie als Nächstes eine externe SRT-Spur, eine andere Untertitelsprache oder einen Client mit breiterer Untertitelunterstützung. Prüfen Sie auch, ob der Server Untertitel-Burn-in anstelle einer einfachen Untertitelwiedergabe meldet.

Gehen Sie nicht davon aus, dass jedes Untertitelformat den gleichen Aufwand verursacht. Eine gestylte Textspur kann für einen Client einfach sein und für einen anderen eine vollständige Videobearbeitung erfordern, während ein Bilduntertitel von einer Blu-ray besonders schwer ohne Burn-in zu liefern sein kann.

Eine funktionierende GPU bedeutet nicht, dass die gesamte Pipeline beschleunigt wird

Es ist möglich, GPU-Aktivität zu sehen, während die CPU hoch bleibt. Die Hardwarebeschleunigung kann das Video dekodieren und kodieren, während die CPU weiterhin die Untertitelwiedergabe, Audiokonvertierung, Skalierung, Ton-Mapping oder einen anderen Filter übernimmt.

Ein Community-Fehlerfall zeigte GPU-Transkodierung zusammen mit hoher CPU-Auslastung durch Untertitel-Burn-in und Audiokonvertierung. Der Fall sollte nicht als feste Regel für jede aktuelle Version betrachtet werden, aber er verdeutlicht, warum die GPU-Auslastung allein kein vollständiger Beweis ist.

Überprüfen Sie sowohl die GPU-Dekodier- als auch die Kodier-Engines und sehen Sie sich dann das Transcoder-Protokoll auf Softwarefilter an. Vergleichen Sie die CPU-Auslastung mit deaktivierten Untertiteln, einer kompatiblen Audiospur und entferntem Ton-Mapping im Test.

Hardwarebeschleunigung kann auf Software zurückfallen

Eine Option zur Hardwarebeschleunigung kann in der Serveroberfläche aktiviert werden, auch wenn der Host-Treiber, die Geräteberechtigungen, die Laufzeit oder der ausgewählte Codec nicht korrekt funktionieren.

Einige Quellformate können die GPU erfolgreich nutzen, während andere auf die CPU zurückgreifen. Eine GPU könnte H.264 und HEVC Main unterstützen, aber nicht die genaue Bit-Tiefe, das Chroma-Format, das Kodierziel oder den Ton-Mapping-Pfad, die für eine bestimmte Datei erforderlich sind.

Erzwingen Sie ein bekanntes Transcoding und überwachen Sie den Server in Echtzeit. Bestätigen Sie, dass der Hardware-Dekoder und -Encoder aktiv sind, prüfen Sie den Transcoder-Befehl und achten Sie auf Initialisierungsfehler oder Software-Fallback-Meldungen, anstatt sich nur auf das aktivierte Kontrollkästchen zu verlassen.

Docker fügt eine separate GPU-Zugriffsschicht hinzu

Wenn der Media-Server in Docker läuft, beweist die Erkennung der GPU auf dem Host nicht, dass die Anwendung sie im Container nutzen kann. Der Container benötigt das Gerät, kompatible Userspace-Bibliotheken, die korrekte Laufzeit und die Berechtigung zum Zugriff auf die Videofunktionen.

Für NVIDIA-Installationen ist eine nützliche Validierungssequenz, zuerst den Host-Treiber zu bestätigen, zu überprüfen, dass Docker die NVIDIA-Laufzeit erkennt, sicherzustellen, dass die erforderlichen Bibliotheken und Geräte im Container vorhanden sind, und die Encoder-Aktivität während eines erzwungenen Transcodings zu beobachten. Ein Container, in dem nvidia-smi Läufe können dennoch Bibliotheken oder Fähigkeiten fehlen, die vom Media-Server benötigt werden.

Ein praktisches Docker-Setup muss daher die NVIDIA-Laufzeit, Userspace-Bibliotheken, Gerätefreigabe und Encoder-Aktivität innerhalb des Containers überprüfen. Vermeiden Sie die dauerhafte Nutzung des privilegierten Modus als Abkürzung; geben Sie nur die Ressourcen frei, die der Dienst benötigt.

Virtuelle Maschinen können dasselbe Fehlerbild erzeugen

Eine virtuelle Maschine kann einen Display-Adapter erkennen, ohne Zugriff auf die für das Media-Transcoding erforderlichen Hardware-Encode- und Decode-Funktionen zu haben. GPU-Passthrough, vermittelte Geräte, Treiber und Gastberechtigungen beeinflussen das Ergebnis.

Validieren Sie die GPU sowohl innerhalb des Gastbetriebssystems als auch aus dem Media-Server-Prozess heraus. GPU-Aktivität auf Host-Ebene beweist nicht, dass die Gastanwendung die vorgesehene Engine verwendet.

Wenn eine native Installation Hardwarebeschleunigung verwendet, eine ansonsten identische VM-Installation jedoch eine hohe CPU-Auslastung zeigt, vergleichen Sie die Gerätefreigabe und Protokolle, bevor Sie Codec-Einstellungen ändern oder die Bibliothek neu kodieren.

HDR-Tonwertkorrektur kann erhebliche Arbeit auf der CPU hinterlassen

Wenn HDR-Medien auf einem SDR-Display oder über einen Client abgespielt werden, der den ursprünglichen HDR-Stream nicht akzeptieren kann, muss der Server möglicherweise zusätzlich zum normalen Transcoding eine Tonwertkorrektur durchführen.

Die Pipeline kann 10-Bit-Dekodierung, Farbraumkonvertierung, Helligkeitsanpassung, Skalierung, Untertitelkomposition und Kodierung umfassen. Hardwareunterstützung für den Quellcodec garantiert nicht, dass jede dieser Stufen auf der GPU verbleiben kann.

Testen Sie dieselbe Datei auf einem HDR-fähigen Client und vergleichen Sie sie dann mit einer SDR-Ausgabe. Wenn gewöhnliche SDR-Transcodes effizient sind, HDR-zu-SDR-Sitzungen aber hohe CPU-Auslastung verursachen, untersuchen Sie die Tonwertzuordnungsmethode und die Hardwareunterstützung, anstatt alle 4K-Medien als gleichwertig zu behandeln.

Audio-Konvertierung ist normalerweise nicht so aufwändig wie Video-Transcoding

TrueHD, DTS, Mehrkanal-Audio oder ein nicht unterstützter Audiocodec können in ein Format konvertiert werden, das der Client abspielen kann. Der Server kann auch Surround-Sound auf Stereo heruntermischen.

Audio-Transcoding verbraucht Rechenleistung, ist aber in der Regel leichter als das Dekodieren und erneute Kodieren eines gesamten Videostreams. Das Remuxen eines Containers erhält auch den Videostream und erfordert normalerweise viel weniger Rechenleistung als die Videokonvertierung.

Wenn das Dashboard nur Audio-Transcoding meldet, die CPU aber nahe ihrer Grenze bleibt, prüfen Sie Untertitelverarbeitung, Hintergrundanalysen, eine weitere aktive Sitzung oder einen separaten Transcoder-Prozess. Gehen Sie nicht davon aus, dass das sichtbare Audio-Label die gesamte Arbeitslast erklärt.

Direct Play mit hoher CPU-Auslastung bedeutet normalerweise, dass eine andere Aufgabe läuft

Direct Play erfordert dennoch Dateizugriffe, Authentifizierung, Anwendungslogik und Netzwerkübertragung, daher wird die CPU-Auslastung nicht genau null sein. Normalerweise sollte es nicht die aufwändige Videobearbeitung erfordern, die mit einem Software-Transcoding verbunden ist.

Plex kann erhebliche CPU-Ressourcen für Intro- und Abspann-Erkennung, Vorschauthumbnails, Sprachanalyse, Werbeerkennung, Medienoptimierung und Downloadvorbereitung verbrauchen. Einige dieser Aufgaben rufen den Transcoder auf, auch wenn niemand aktiv Medien anschaut.

Überprüfen Sie die Prozessliste des Betriebssystems und nicht nur die Gesamt-CPU-Grafik. Ermitteln Sie, ob der Transcoder des aktuellen Streams, ein geplanter Analyseprozess, ein Bibliotheksscanner oder ein nicht verwandter Container verantwortlich ist.

Geplante Analysen können wie Wiedergabelast aussehen

Ein Hintergrundprozess kann ungefähr zur gleichen Zeit starten, wenn jemand mit dem Ansehen beginnt, wodurch es so aussieht, als ob die Wiedergabe selbst den CPU-Anstieg verursacht hat. Wartungsfenster laufen oft über Nacht oder kurz nachdem neue Inhalte hinzugefügt wurden.

Eine Unraid-Diskussion führte scheinbar die Leerlauf-CPU-Auslastung auf geplante Medienanalysen und später auf Intro- und Abspann-Erkennung zurück. Dies ist ein Beispiel aus der Community und kein Beweis dafür, dass jeder Fall von Leerlauf-Auslastung die gleiche Ursache hat.

Pausieren Sie vorübergehend die Vorschauerstellung, Intro-Erkennung, Abspann-Erkennung, Optimierung und tiefgehende Medienanalyse. Wenn die CPU-Auslastung ohne Änderung des aktiven Streams sinkt, verschieben Sie diese Aufgaben in ein anderes Wartungsfenster, anstatt die Wiedergabeeinstellungen zu ändern.

Mehrere Streams multiplizieren verschiedene Arten von Arbeit

Eine Direct-Play-Sitzung erhöht hauptsächlich Speicher- und Netzwerkbelastung. Eine Audio-Transkodierung fügt eine kleinere Umwandlungsaufgabe hinzu. Eine Software-4K-Video-Transkodierung kann viel mehr Rechenleistung verbrauchen als mehrere direkte Streams.

Wenn ein anderer Benutzer die Wiedergabe startet, prüfen Sie jede Sitzung einzeln. Zwei Benutzer erzeugen nicht unbedingt die doppelte Arbeitslast: Einer kann direkt abspielen, während der andere Untertitel in eine HDR-Transkodierung einbrennt.

Fügen Sie Test-Sitzungen einzeln hinzu, während Sie CPU, GPU, Netzwerk, Festplattenlatenz und Transkodiergeschwindigkeit beobachten. So erkennen Sie, ob die praktische Grenze Software-Codierung, Hardware-Encoder-Kapazität, Speicher-Konkurrenz oder Gesamtbandbreite ist.

Live-TV kann zusätzliche Verarbeitung erfordern

Live-TV kann in einem Codec, einer Auflösung, einem interlaced Format oder einer Bitrate ankommen, die der Wiedergabe-Client nicht direkt akzeptieren kann. Der Server muss möglicherweise deinterlacen, Video konvertieren, Audio ändern oder einen Stream mit niedrigerer Rate erstellen.

Diese Vorgänge können die Live-Wiedergabe CPU-intensiver machen als einen gewöhnlichen Film, der direkt abgespielt wird. Aufnahme und Werbeanalyse können ebenfalls parallel zum Ansehen laufen und mehr Serverarbeit verursachen.

Überprüfen Sie den Quellcodec der Live-Sitzung, den Deinterlacing-Status, den Wiedergabemodus und die ausgewählte Qualität separat von der gespeicherten Medienbibliothek. Ein Problem bei Live-TV beweist nicht, dass alle lokalen Dateien dieselbe Hardware benötigen.

Remote-Wiedergabe erzwingt oft eine neue Bitrate

Eine Datei mit hoher Bitrate kann über das Heim-LAN direkt abgespielt werden, aber die verfügbare Internet-Upload-Geschwindigkeit des Servers überschreiten. Dann fordert der Remote-Client oder die Serverbegrenzung einen kleineren Stream an.

Die Reduzierung der Bitrate bedeutet normalerweise, dass der Server eine neue Videoausgabe erstellen muss. Die CPU-Auslastung kann daher während der Remote-Wiedergabe steigen, selbst wenn derselbe Client zu Hause wenig Server-Rechenleistung nutzt.

Vergleichen Sie die Quell-Bitrate mit der nachhaltigen Upload-Kapazität und der Remote-Qualitätseinstellung des Clients. Wenn das Herabsetzen des Streams eine Software-Transkodierung erzeugt, kann korrekt konfigurierte Hardwarebeschleunigung oder eine vorcodierte Remote-Version die CPU-Belastung reduzieren.

Ein kurzer CPU-Spitzenwert kann normal sein

Einige Transcoder arbeiten vor der Wiedergabeposition, um einen Puffer zu erstellen. Die CPU-Auslastung kann zu Beginn stark ansteigen, fallen, wenn genügend Segmente produziert wurden, und wieder steigen, wenn mehr Ausgabe benötigt wird.

Ein kurzer Spitzenwert mit flüssiger Wiedergabe und stabilen Temperaturen erfordert nicht unbedingt eine Lösung. Anhaltende Maximalnutzung, sinkende Transcodiergeschwindigkeit, wiederholtes Puffern oder thermisches Drosseln weisen auf ein ernsthafteres Kapazitätsproblem hin.

Beobachten Sie die Auslastung über mehrere Minuten, anstatt sich auf einen einzelnen CPU-Screenshot zu verlassen. Notieren Sie, ob der Prozessor fest ausgelastet bleibt, ob der Transcoder voraus bleibt und ob die Server-Taktfrequenz mit steigender Temperatur sinkt.

Kodieren Sie nicht zuerst die gesamte Bibliothek neu

Die Umwandlung jeder Datei in ein breit unterstütztes Format kann zukünftiges Echtzeit-Transcoding reduzieren, erfordert jedoch Zeit, zusätzlichen Speicherplatz und einen weiteren verlustbehafteten Kodierungsschritt für viele Quellen.

Es kann auch sein, dass die tatsächliche Ursache nicht behoben wird, wenn die hohe CPU-Auslastung durch Untertitel-Einbrennen, HDR-Tonemapping, Remote-Bitrate-Limits, Hintergrundanalyse oder defekten GPU-Zugriff innerhalb von Docker verursacht wird.

Identifizieren Sie zuerst die Kombinationen, die bei den von Ihnen tatsächlich verwendeten Clients wiederholt fehlschlagen. Erstellen Sie optimierte Kopien nur für Medien mit häufigen Problemen oder verwenden Sie einen leistungsfähigeren Client, wenn dies einfacher ist, als mehrere Versionen der Bibliothek zu pflegen.

Verwenden Sie diese Fehlerbehebungsreihenfolge

1. Reproduzieren Sie die Sitzung mit hoher CPU-Auslastung mit derselben Datei und demselben Client.
2. Notieren Sie, ob es sich um Direct Play, Remux, Audiotranskodierung oder Videotranskodierung handelt.
3. Identifizieren Sie den genauen Prozess, der CPU verbraucht.
4. Notieren Sie den angegebenen Grund für die Umwandlung.
5. Testen Sie die Originalqualität im lokalen Netzwerk.
6. Deaktivieren Sie Untertitel und wählen Sie eine andere Audiospur.
7. Spielen Sie dieselbe Datei auf einem anderen Client ab.
8. Überwachen Sie GPU-Dekodierungs- und Kodierungs-Engines.
9. Untersuchen Sie das Transcoder- oder FFmpeg-Protokoll auf Software-Fallback.
10. Überprüfen Sie den GPU-Zugriff von innerhalb von Docker oder der virtuellen Maschine.
11. Pausieren Sie Medienanalyse, Vorschau-Generierung und Optimierungsaufgaben.
12. Fügen Sie zusätzliche Streams einzeln hinzu.
13. Überprüfen Sie Temperatur und CPU-Taktfrequenz.
14. Hardware nur nach Bestätigung des Engpasses aufrüsten.

Fazit

Hohe CPU-Auslastung während der Medienwiedergabe ist meist das Ergebnis einer Verarbeitungsentscheidung und keine Diagnose an sich. Vollständiges Software-Video-Transcoding ist die häufigste Ursache, aber auch Untertitel-Einbrennung, HDR-Tonemapping, teilweise Hardware-Beschleunigung, entfernte Qualitätsbegrenzungen und gleichzeitige Sitzungen können ähnliche Last erzeugen.

Beginnen Sie damit, den Wiedergabemodus und den genauen Prozess zu identifizieren, der die CPU verwendet. Wenn die Sitzung transkodiert, testen Sie die Client-Kompatibilität, Originalqualität, Untertitel, Audiotracks und die vollständige Hardware-Beschleunigungskette. Wenn Direct Play verwendet wird, prüfen Sie Hintergrundanalysen und andere aktive Aufgaben.

Rüsten Sie den Server nur auf, wenn Protokolle und kontrollierte Tests zeigen, dass die erforderliche Echtzeitverarbeitung die verfügbare Rechenleistung übersteigt. Viele Fälle mit hoher CPU-Auslastung lassen sich durch Änderung des Wiedergabepfads, Korrektur des Docker-GPU-Zugriffs, Planung der Analyse außerhalb der Sehzeiten oder Auswahl eines Clients, der das Originalmedium direkt abspielen kann, lösen.

FAQ

Warum steigt die CPU-Auslastung, wenn Untertitel aktiviert sind?

Der Client kann das ausgewählte Untertitelformat möglicherweise nicht darstellen. Der Server fügt dann die Untertitel in jeden Videoframe ein, was das Dekodieren und erneute Kodieren des Videos erfordert. Testen Sie mit deaktivierten Untertiteln oder wählen Sie eine unterstützte textbasierte Spur.

Warum ist die CPU-Auslastung trotz aktivierter Hardware-Transkodierung noch hoch?

Die GPU kann nur die Video-Dekodierung und -Kodierung beschleunigen, während die CPU Untertitel, Audio, Tonemapping, Skalierung oder andere Filter verarbeitet. Der Hardwarezugriff kann auch innerhalb von Docker oder einer virtuellen Maschine unvollständig sein.

Verwendet Direct Play keine CPU?

Nein. Direct Play erfordert dennoch Datei-Zugriff, Netzwerk, Authentifizierung und Anwendungsprozesse. Es sollte normalerweise deutlich weniger CPU als Video-Transcoding verwenden, daher sollte eine anhaltend hohe Last auf Hintergrundaufgaben oder einen anderen Prozess hin überprüft werden.

Warum erhöht das Senken der Streaming-Qualität die CPU-Auslastung?

Eine niedrigere Auflösung oder Bitrate erfordert normalerweise, dass der Server einen neuen Videostream erstellt. Wenn die Originaldatei direkt abgespielt werden konnte, ändert die Auswahl einer niedrigeren Qualität die Sitzung in ein Transcoding und erhöht die Serververarbeitung.

Kann das Scannen von Medien während eines laufenden Films eine hohe CPU-Auslastung verursachen?

Ja. Die Generierung von Vorschaubildern, die Erkennung von Einleitungen oder Credits, Optimierungen, Sprachanalysen und andere Hintergrundaufgaben können gleichzeitig mit der Wiedergabe laufen. Überprüfen Sie die Prozessliste und den Status geplanter Aufgaben, bevor Sie die gesamte CPU-Auslastung dem aktiven Stream zuordnen.