Wie man überprüft, ob Hardware-Transcoding tatsächlich funktioniert

Das Aktivieren der Hardware-Transkodierung ist nicht dasselbe wie der Nachweis, dass die Hardware-Transkodierung funktioniert. Ein Medienserver kann die Einstellung aktiviert haben, aber der aktuelle Stream kann dennoch direkt abgespielt werden, auf Software-Transkodierung zurückfallen, Hardware nur für einen Teil der Pipeline verwenden oder keinen Zugriff auf die GPU innerhalb von Docker haben.

Der sicherere Weg zur Überprüfung ist, denselben aktiven Stream aus mehreren Blickwinkeln zu verfolgen: Erzwingen Sie eine echte Transkodierung, lesen Sie das Dashboard des Medienservers, bestätigen Sie GPU- oder iGPU-Aktivität auf Host-Ebene, prüfen Sie FFmpeg-Protokolle, wenn das Ergebnis unklar ist, und verifizieren Sie, dass der Client die erwartete Wiedergabeausgabe erhält.

Die Einstellung gibt nur Erlaubnis, keinen Beweis

Eine Hardware-Transkodierungseinstellung ist eine Erlaubnis, kein Testergebnis. Sie teilt Plex, Jellyfin, Emby oder einem anderen Medienserver mit, dass Hardwarebeschleunigung verwendet werden darf, wenn Stream, Codec, Treiber, Gerätezugriff und Wiedergabebedingungen übereinstimmen. Sie beweist nicht, dass der Stream, den Sie gerade ansehen, die GPU verwendet.

Plex beschreibt hardwarebeschleunigtes Streaming als eine Möglichkeit für den Plex Media Server, dedizierte Video-Decoder- und Encoder-Hardware beim Konvertieren von Videos zu verwenden, was die CPU-intensive Transkodierungslast reduzieren kann. Plex weist jedoch auch darauf hin, dass ein Software-Fallback erfolgen kann, wenn Hardwarebeschleunigung nicht verfügbar oder mit einem bestimmten Videopfad nicht kompatibel ist.

Diese Unterscheidung ist wichtig, weil ein Medienserver eine gesunde Einstellungsseite anzeigen kann, während die aktive Sitzung etwas anderes tut. Die Datei könnte direkt abgespielt werden. Der Server könnte nur Audio transkodieren. Das Video könnte auf der Hardware decodiert, aber in der Software enkodiert werden. Oder der Container hat möglicherweise keinen Zugriff auf das Gerät, das das Host-Betriebssystem sehen kann.

Ein zuverlässiger Verifizierungsablauf sollte fünf Fragen beantworten: Wird der Stream tatsächlich transkodiert, zeigt das Dashboard Hardwarebeschleunigung an, zeigt der Host Video-Encode- oder Decode-Aktivität, zeigen die FFmpeg-Protokolle einen Hardwarepfad, und entspricht das Client-Wiedergabeergebnis der erwarteten Auflösung, Bitrate, dem Codec oder dem Untertitelverhalten?

Wenn diese Ebenen übereinstimmen, funktioniert die Hardware-Transkodierung wahrscheinlich. Wenn sie widersprüchlich sind, liegt die Antwort nicht einfach darin, dass die Einstellung defekt ist oder das Dashboard falsch liegt. Die bessere Antwort ist, herauszufinden, welche Ebene der Pipeline sich geändert hat.

Zuerst den Stream tatsächlich transkodieren lassen

Bevor Sie die GPU-Auslastung überprüfen, stellen Sie sicher, dass der Mediaserver wirklich transkodiert. Wenn die Datei direkt abgespielt wird, sendet der Server meist den Originalstream an den Client. In diesem Fall sind niedrige CPU- und GPU-Auslastung normal.

Ein kontrollierter Teststream sollte den Server zwingen, etwas zu konvertieren. Dies erreichen Sie normalerweise, indem Sie die Wiedergabequalität senken, einen Browser oder Client verwenden, der den Quellcodec nicht unterstützt, eine Remote-Bitrate-Begrenzung einstellen, Untertitel aktivieren, die ein Einbrennen erfordern, oder eine Datei mit hoher Bitrate wählen, die für den Client reduziert werden muss.

Für Plex ist ein einfacher Test, ein Video zu starten und die Wiedergabequalität so zu reduzieren, dass Plex den Stream konvertieren muss. Die Anleitung von Plex beschreibt, die Videoqualität zu senken, z. B. eine Konvertierung auf 480p zu erzwingen, und dann die Wiedergabedetails im Plex-Dashboard auf den Hardwarebeschleunigungsindikator zu überprüfen.

Für Jellyfin oder Emby gilt derselbe kontrollierte Wiedergabetest. Beginnen Sie mit einer Datei, die der Client nicht direkt abspielen kann, oder stellen Sie manuell eine niedrigere Wiedergabequalität ein. Öffnen Sie dann die Wiedergabeinformationen, Details zum aktiven Stream oder Stream-Diagnosen, um zu bestätigen, ob die Sitzung Direct Play, Direct Stream oder Transcode ist.

Verwenden Sie keine zufällige Datei als einzigen Hardware-Transkodierungstest. Ein Film, der auf einem Fernseher perfekt direkt abgespielt wird, berührt möglicherweise nie den Transcoder, während dieselbe Datei im Browser, über Fernzugriff, mit mobilen Daten oder mit aktivierten Untertiteln transkodiert werden kann. Die Testdatei sollte einen klaren Vorher-Nachher-Zustand erzeugen.

Das Dashboard ist der erste Hinweis

Das Dashboard des Mediaservers ist das erste nützliche Signal, da es die aktive Wiedergabesitzung mit der Serverinterpretation dieses Streams verbindet. Es ist jedoch nur ein Hinweis im Dashboard, nicht der vollständige Beweis.

Plex: Achten Sie auf Hardware-Dekodierung und -Kodierung

Starten Sie in Plex einen Stream, von dem Sie wissen, dass er transkodiert wird, öffnen Sie dann das Web-Dashboard und erweitern Sie die Details zu „Jetzt läuft“. Plex zeigt an, dass bei Verwendung der Hardwarebeschleunigung (hw) neben dem Videoformat in den erweiterten Wiedergabedetails angezeigt werden sollte.

Ein starkes Plex-Signal sieht aus wie eine Transcoding-Zeile mit (hw) am Video-Pfad. Je nach Quelldatei, Hardware, Betriebssystem und Plex-Version kann Hardware beim Dekodieren, Kodieren oder beidem beteiligt sein. Der wichtige Schritt ist, die Stream-Details zu erweitern, anstatt nur die Hauptkarte „Jetzt läuft“ anzusehen.

Wenn Plex Direct Play anzeigt, sollte keine Hardware-Transkodierung stattfinden. Wenn Plex Transcode anzeigt, aber kein (hw), könnte der Stream Software-Transcoding verwenden. Wenn Plex (hw) anzeigt, aber die CPU noch aktiv ist, bedeutet das nicht automatisch einen Fehler; Audio-Transcoding, Untertitel, Remuxing, Tonemapping und andere Stufen können weiterhin die CPU nutzen.

Jellyfin und Emby: Prüfen Sie die Stream-Details

In Jellyfin prüfen Sie den aktiven Stream oder die Wiedergabeinformationen nach dem Transcoding-Grund und der Hardwarebeschleunigungsmethode. Die Dokumentation zur Hardwarebeschleunigung von Jellyfin erklärt, dass Jellyfin einen modifizierten FFmpeg-Transcoder verwendet und integrierte oder diskrete GPUs über Methoden wie Intel QSV, NVIDIA NVDEC / NVENC, AMD AMF, VA-API, VideoToolbox und andere plattformspezifische Pfade nutzen kann.

Die nützliche Frage ist nicht nur, ob transkodiert wird, sondern welche Methode verwendet wird. Wenn die Wiedergabedetails QSV, VAAPI, NVENC, AMF oder VideoToolbox anzeigen, ist das ein stärkeres Zeichen als ein generisches Transcoding-Label. Wenn die Stream-Details nur Software-Transcoding zeigen, übernimmt die GPU wahrscheinlich nicht die Verarbeitung dieses Streams.

Dashboard-Checks sind besonders nützlich in Kombination mit einer weiteren Frage: Warum transkodiert der Server? Ein Codec-Mismatch, Bitratenlimit, Untertitel-Einbrennung, HDR-Tonemapping, nicht unterstützter Audiostream oder eine entfernte Qualitätseinstellung können jeweils eine andere Pipeline auslösen. Deshalb können zwei Dateien auf demselben Server unterschiedlich behandelt werden.

Host-GPU-Aktivität ist die zweite Beweisschicht

Die nächste Ebene ist die GPU-Aktivität auf Host-Ebene. Wenn die GPU oder iGPU tatsächlich bei einer Live-Transkodierung hilft, sollte der Host normalerweise Aktivität in der Video-Encode- oder Decode-Engine zeigen, während der Stream läuft.

Diese Ebene ist wichtig, weil Dashboards vereinfacht werden können. Ein Dashboard kann die Hardwarebeteiligung anzeigen, ohne zu erklären, welche Stufe beschleunigt wird. Der Host kann zeigen, ob die Video-Engine aktiv wird, wenn der Stream startet, und sich beruhigt, wenn der Stream stoppt.

NVIDIA: Beobachten Sie die Video-Engine, nicht nur die GPU-Auslastung

Für NVIDIA-Systeme verwenden Sie nvidia-smi, während das Test-Transkodieren läuft. Achten Sie auf den Mediaserver- oder Transcoder-Prozess, GPU-Speicherauslastung sowie Encoder- / Decoder-Aktivität. Die NVIDIA-Dokumentation enthält Encoder- und Decoder-Auslastung, und die Prozessüberwachung kann die GPU-Nutzung pro Prozess anzeigen.

Eine grundlegende NVIDIA-Prüfung ist:

nvidia-smi

Für eine aktivere Überwachungsansicht verwenden Sie:

nvidia-smi dmon

Der häufige Fehler ist, nur einen allgemeinen GPU-Prozentsatz zu beobachten. Video-Transkodierung sieht möglicherweise nicht wie 3D-Rendering, Gaming oder KI-Berechnung aus. Achten Sie speziell auf Video-Encode-/Decode-Aktivität, den relevanten Mediaserver-Prozess und ob das Timing mit dem aktiven Stream übereinstimmt.

Intel Quick Sync: Bestätigen, dass die iGPU tatsächlich ausgelastet ist

Für Intel iGPU / Quick Sync Systeme unter Linux ist intel_gpu_top oft das klarste Tool. Starten Sie das erzwungene Transkodieren und beobachten Sie, ob die Video-Engine Aktivität zeigt. Wenn das Mediaserver-Dashboard Hardware-Beschleunigung anzeigt, die Intel-Video-Engine aber inaktiv bleibt, verwendet der Server möglicherweise das falsche Gerät, es fehlen Berechtigungen oder es wird auf Software zurückgegriffen.

Sie können auch prüfen, ob Linux das Grafikgerät erkennt:

lspci -nn | grep -Ei "3d|Anzeige|vga"

Die Hardware-Beschleunigungsdokumentation von Jellyfin weist Benutzer auf hardware-spezifische Prüfungen hin, bevor eine Beschleunigungsmethode gewählt wird, da der verfügbare Beschleunigungspfad vom Gerät, Treiber und Plattform-Support abhängt.

AMD: GPU-Aktivität mit dem aktiven Stream abgleichen

Bei AMD-Systemen hängt das genaue Überwachungstool vom Betriebssystem und dem Treiber-Stack ab. Unter Linux prüfen Benutzer oft VAAPI- / AMF-bezogene Aktivitäten mit Tools wie radeontop oder Plattform-Dashboards. Die Verifikationslogik ist dieselbe: Starten Sie ein erzwungenes Transkodieren, beobachten Sie die GPU-Aktivität im Videobereich, stoppen Sie dann den Stream und prüfen Sie, ob die Aktivität abfällt.

Erwarten Sie nicht, dass jedes Tool Video-Beschleunigung auf die gleiche Weise kennzeichnet. Die praktische Frage ist, ob während genau dieses Streams Aktivität auftritt und ob das Timing mit dem Mediaserver-Dashboard übereinstimmt.

FFmpeg-Protokolle zeigen den tatsächlichen Transkodierpfad

Wenn das Dashboard und die Host-Metriken nicht übereinstimmen, sind FFmpeg-Protokolle normalerweise der nächste Ort, an dem man nachsehen sollte. Die meisten Mediaserver verlassen sich für das Transkodieren auf FFmpeg oder eine modifizierte FFmpeg-Version, daher können die Protokolle zeigen, ob der Stream einen Hardwarepfad verwendet hat, auf Software zurückgefallen ist oder keinen Zugriff auf ein Gerät hatte.

In Protokollen können Hardware-Pfade Namen wie enthalten:

h264_nvenc
hevc_nvenc
h264_qsv
hevc_qsv
h264_vaapi
hevc_vaapi

Software-Codierpfade umfassen oft:

libx264
libx265

Die FFmpeg-Dokumentation beschreibt FFmpeg Hardware-Beschleunigungspfad-Optionen für das Dekodieren passender Streams, mit Methoden wie vaapi, qsv, d3d11va, dxva2 und videotoolbox. Es wird auch erklärt, dass die tatsächliche Verfügbarkeit von der gewählten Methode, Decoder-Unterstützung, Hardware und Treiberumgebung abhängt.

Diese Unterscheidung ist wichtig. Dass FFmpeg mit einer Hardware-Beschleunigungsmethode gebaut wurde, beweist nicht, dass der aktuelle Stream sie verwendet hat. Das Protokoll sollte den tatsächlichen Codec-Pfad, den Gerätezugriff und ob FFmpeg stillschweigend auf Software zurückgefallen ist, zeigen.

Das Auftreten von Software-Codierpfaden wie libx264 oder libx265 in einem Media-Server-Transcode-Protokoll ist oft ein starkes Signal für Software libx264 Fallback oder Software-Codierung, besonders wenn Sie NVENC, QSV, VAAPI, AMF oder VideoToolbox erwartet haben.

Verwenden Sie Protokolle, wenn Dashboard-Beweise und Host-Metriken nicht übereinstimmen, wenn Docker oder Berechtigungen kürzlich geändert wurden, wenn ein Codec funktioniert, ein anderer jedoch nicht, wenn Untertitel oder HDR-Tonemapping das Ergebnis verändern oder wenn der Stream startet, puffert, fehlschlägt oder stillschweigend auf Software-Transcoding umschaltet.

Teilweises Hardware-Transcoding ist normal

Hardware-Transcoding ist nicht immer alles oder nichts. Ein Stream kann Hardware-Dekodierung, aber Software-Codierung verwenden oder Hardware-Codierung, aber Software-Dekodierung. Es kann auch GPU-Beschleunigung für Video nutzen, während Audio, Untertitel, Skalierung, Remuxing oder Tonemapping weiterhin die CPU verwenden.

Jellyfin-Dokumentation ist hier nützlich, da sie die Transcoding-Pipeline-Stufen in Videodekodierung, Entflechtung, Skalierung / Formatkonvertierung, HDR / DV-Tonemapping, Untertitel-Einbrennen, Video-Codierung und Zero-Copy unterteilt. Es wird auch darauf hingewiesen, dass einige Stufen möglicherweise nicht GPU-beschleunigt sind aufgrund von Software-, Hardware- oder Treiberbeschränkungen.

Die richtige Frage ist also nicht, ob die CPU-Auslastung null ist. Eine bessere Hardware-Transcode-Prüfung fragt, ob Video-Decoding auf der Hardware stattfindet, ob Video-Encoding auf der Hardware stattfindet, ob die CPU-Auslastung durch Audio oder Untertitel erklärt wird, ob die Wiedergabe im Vergleich zum reinen Software-Transcoding verbessert ist und ob die Protokolle einen Hardware-Pfad oder einen Software-Fallback zeigen.

Teilweise Beschleunigung kann immer noch ein erfolgreiches Ergebnis sein, wenn die schwere Videophase ausgelagert wird und die verbleibende CPU-Arbeit erwartet wird. Es wird problematisch, wenn der Server für die Phase, die Sie der GPU zugewiesen haben, auf Software zurückfällt.

Warum die CPU-Auslastung trotzdem hoch aussehen kann

Hohe CPU-Auslastung bedeutet nicht automatisch, dass das Hardware-Transcoding fehlgeschlagen ist. Video-Encoding und -Decoding sind nur Teile der Wiedergabekette. Die CPU kann weiterhin Audio-Transcoding, Untertitel-Einbrennen, Container-Remuxing, Datei-I/O, Skalierung, Metadatenaufgaben, Netzwerk-Overhead oder Teile der HDR-Tonwertzuordnung übernehmen.

Untertitel sind ein häufiges Beispiel. Wenn der Client ein Untertitelformat nicht direkt verarbeiten kann, kann der Server die Untertitel ins Video einbrennen. Das kann den Transcode-Pfad ändern und zusätzliche Arbeit auf die CPU verlagern. Audio ist ein weiteres Beispiel: Hardware-Video-Beschleunigung bedeutet normalerweise nicht, dass die GPU Audio transkodiert.

Eine gute Methode, die CPU-intensive Phase zu unterscheiden, ist das Testen mehrerer kontrollierter Dateien: eine einfache H.264-Datei ohne Untertitel, eine HEVC-Datei, eine Datei mit deaktivierten Untertiteln, eine Datei mit aktivierten Untertiteln, eine Datei, die im Browser abgespielt wird, und eine Datei, die auf einem Fernseher oder mobilen Client abgespielt wird.

Wenn die einfache Datei GPU-Aktivität zeigt, aber die Untertitel- oder HDR-Datei die CPU stark beansprucht, funktioniert das Hardware-Transcoding möglicherweise, aber diese spezielle Pipeline hat eine CPU-intensive Phase.

Wenn Docker der eigentliche Engpass ist

In einem Docker-Setup beweist es nicht, dass der Container die GPU nutzen kann, nur weil der Host die GPU sieht. Plex, Jellyfin, Emby oder Frigate können normal starten, eine gesunde Benutzeroberfläche anzeigen und trotzdem auf die CPU zurückgreifen, weil der Container keinen richtigen Gerätezugriff hat.

Für Intel Quick Sync- oder VAAPI-Pfade ist das wichtigste Gerät oft /dev/dri. Die Hardware-Beschleunigungsanleitung von Plex weist darauf hin, dass Docker-Hardware-Transcoding eine zusätzliche Konfiguration erfordert, und Plex-Docker-Setups benötigen häufig, dass das relevante Kernel-Gerät für Intel Quick Sync in den Container weitergereicht wird.

Für NVIDIA-Systeme kann der Docker-GPU-Zugriff --gpus, NVIDIA Container Toolkit, Laufzeitkonfiguration und Treiberfähigkeiten umfassen. Die Dokumentation des NVIDIA Container Toolkits erklärt Docker GPU-Zugriff über Optionen wie --gpus oder NVIDIA_VISIBLE_DEVICES, abhängig von der Laufzeitkonfiguration.

Docker Compose hat sein eigenes GPU-Reservierungsmodell. Der offizielle Docker Compose GPU-Support-Leitfaden erklärt, dass Dienste GPU-Geräte reservieren können und dass Fähigkeiten für GPU-Reservierungen gesetzt werden müssen. Dies ist Teil desselben Container-Gerätezugriffs-Problems.

Überprüfen Sie Docker, wenn die Host-GPU sichtbar ist, das Media-Server-Dashboard jedoch Software-Transcoding anzeigt, wenn nvidia-smi auf dem Host funktioniert, aber nicht im Container, wenn /dev/dri auf dem Host vorhanden, aber im Container fehlt, oder wenn ein Container-Update Berechtigungen, Gruppen, Laufzeit oder Geräte-Mapping geändert hat.

Ein containerisierter Media-Server sollte den Gerätezugriff von innerhalb des Containers nachweisen, nicht nur vom Host. Andernfalls debuggen Sie möglicherweise die falsche Ebene.

Eine sauberere Testsequenz für Plex, Jellyfin und Emby

Verwenden Sie eine saubere Testsequenz anstelle vieler gleichzeitiger Einstellungen. Eine stabile Sequenz erleichtert den Nachweis von Hardware-Transcoding und die Fehlersuche.

1. Wählen Sie eine Videodatei, die Transcoding auslösen kann.
2. Starten Sie die Wiedergabe auf einem Client, bei dem Sie die Qualität steuern können.
3. Senken Sie die Wiedergabequalität, um ein Transcoding zu erzwingen.
4. Öffnen Sie das Media-Server-Dashboard.
5. Bestätigen Sie, dass der Stream Transcode anzeigt, nicht Direct Play.
6. Überprüfen Sie, ob das Dashboard anzeigt (hw) oder eine Hardware-Methode.
7. Beobachten Sie die Aktivität der Host-GPU / iGPU-Videomotor während des Streams.
8. Öffnen Sie das FFmpeg-Transcode-Protokoll für genau diese Sitzung.
9. Suchen Sie nach Hardware-Codec-Pfaden oder Software-Fallback.
10. Deaktivieren Sie die Untertitel und testen Sie erneut.
11. Stoppen Sie den Stream und bestätigen Sie, dass die GPU-Aktivität sinkt.
12. Wiederholen Sie den Test mit nur einem anderen Codec oder Client, nachdem der erste Test klar ist.

Diese Sequenz vermeidet die häufigste Fehldiagnose: gleichzeitiges Ändern von Qualität, Untertiteln, Client-Typ, Treibereinstellungen und Docker-Mapping. Wenn sich das Ergebnis ändert, sollten Sie wissen, welche Variable es verursacht hat.

Wie eine erfolgreiche Hardware-Transkodierung aussieht

Eine erfolgreiche Hardware-Transkodierung ist kein einzelner Screenshot. Es ist eine Reihe von Signalen, die übereinstimmen.

Der stärkste Beweis kommt vom Abgleich desselben aktiven Streams über Dashboard, Host-Metriken, Protokolle und Wiedergabeergebnis. Wenn eine Ebene widerspricht, vereinfache den Test, bevor du Einstellungen änderst.

Wie dieselbe Prüfung auf Video-AI- und Kamera-Workflows angewendet wird

Die gleiche Überprüfungsmentalität gilt über Plex oder Jellyfin hinaus. Video-AI und Kamera-Workflows können ebenfalls installiert aussehen, während der tatsächliche Hardware-Pfad, der Container-Gerätezugriff, der Modellendpunkt, die Protokollausgabe oder das endgültige Analyseergebnis nicht korrekt funktionieren.

Ein ZimaOS Kamera-AI-Workflow ist ein nützliches Beispiel. Die ZimaSpace-Anleitung für Frigate und Ollama Kamera-AI zeigt eine Einrichtung, die RTSP-Kameras, Objekterkennung, lokale Modellendpunkte, Schnappschüsse, Speicher, Gerätezuordnungen, Container-Berechtigungen und Protokolle umfassen kann. In einem solchen Workflow ist die installierte Benutzeroberfläche nur die erste Schicht; die eigentliche Prüfung besteht darin, ob Streams ankommen, der Container auf die richtigen Geräte zugreifen kann, der Modellendpunkt reagiert, die Protokolle sauber bleiben und die erwartete Erkennungs- oder Beschreibungs-Ausgabe erscheint.

Dies ist nicht dasselbe wie die Hardware-Transkodierung von Plex, aber die selbstgehostete Regel ist ähnlich: Vertraue nicht auf eine einzige Einstellung. Bei Video-Workloads überprüfe den aktiven Stream, den Gerätezugriff, die Protokolle, das Modell oder den Encoder-Pfad und die endgültige Ausgabe.

Eine private Cloud- oder Heimserver-Lösung wie ZimaCube 2 AI NAS kann reichhaltigere selbstgehostete Medien- und Video-KI-Workflows unterstützen, wenn Speicher, GPU- oder iGPU-Zugriff, Container und Protokolle als ein System behandelt werden. Die wichtige Erkenntnis ist nicht der Produktname, sondern das Verifizierungsmuster. Wenn die Benutzeroberfläche aktiviert anzeigt, der Stream, das Gerät, die Protokolle und die Ausgabe jedoch widersprechen, ist die Arbeitslast noch nicht vollständig verifiziert.

FAQ

Wie erkenne ich, ob Plex-Hardware-Transkodierung funktioniert?

Erzwingen Sie eine Plex-Transkodierung, indem Sie die Wiedergabequalität verringern, öffnen Sie dann die Plex Web App, gehen Sie zum Dashboard, erweitern Sie Jetzt Wiedergabe und suchen Sie nach (hw) neben dem Videoformat. Für einen stärkeren Nachweis prüfen Sie auch die GPU-Aktivität des Hosts und die Plex-Transkodierungsprotokolle.

Wie überprüfe ich Hardware-Transkodierung in Jellyfin?

Starten Sie einen Stream, der Jellyfin-Transkodierung erfordert, und öffnen Sie dann die Wiedergabeinformationen oder Details zum aktiven Stream. Suchen Sie nach dem Transkodierungsgrund und der Hardwarebeschleunigungsmethode wie QSV, VAAPI, NVENC, AMF oder VideoToolbox. Wenn das Dashboard unklar ist, prüfen Sie die GPU-Aktivität des Hosts und die FFmpeg-Protokolle.

Warum ist meine CPU-Auslastung noch hoch, wenn Hardware-Transkodierung aktiviert ist?

CPU-Auslastung kann hoch bleiben, weil Hardwarebeschleunigung möglicherweise nur das Video-Decoding oder -Encoding abdeckt. Audio-Transkodierung, Untertitel-Einbrennen, Remuxing, Skalierung, Tonemapping, Datei-I/O und einige Filter können weiterhin CPU-Ressourcen nutzen. Prüfen Sie die Protokolle, bevor Sie annehmen, dass die Hardware-Transkodierung fehlgeschlagen ist.

Was bedeutet teilweise Hardware-Transkodierung?

Teilweise Hardware-Transkodierung bedeutet, dass nur ein Teil der Pipeline beschleunigt wird. Zum Beispiel kann die GPU das Quellvideo decodieren, während die CPU Untertitel, Audio oder eine andere Stufe verarbeitet. Es kann auch bedeuten, dass Hardware-Encoding aktiv ist, das Decoding jedoch auf Software zurückfällt.

Was sollte ich überprüfen, wenn Hardware-Transkodierung auf dem Host funktioniert, aber nicht in Docker?

Überprüfen Sie den Container-Gerätezugriff. Für Intel iGPU bestätigen Sie, dass /dev/dri in den Container weitergegeben wird. Für NVIDIA prüfen Sie den Host-Treiber, das NVIDIA Container Toolkit, die Docker-Laufzeit, den --gpus-Zugriff und die videobezogenen Treiberfähigkeiten. Prüfen Sie auch, ob der Mediaserver-Benutzer im Container die Berechtigung hat, auf das Gerät zuzugreifen.

Hardware-Transkodierung funktioniert nur, wenn der aktive Stream tatsächlich transkodiert wird, der Mediaserver Hardwarebeschleunigung meldet, der Host Video-Encoding- oder Decoding-Aktivität anzeigt und die Protokolle den erwarteten Hardwarepfad statt eines Software-Fallbacks bestätigen. Wenn eine Ebene widerspricht, testen Sie mit einer einfacheren Datei, reduzieren Sie Variablen und überprüfen Sie die Pipeline Schritt für Schritt.