Direct Play vs. Direct Stream vs. Transcoding: Welcher Weg nutzt Serverressourcen?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Direct Play vs Direct Stream vs Transcoding: Which Path Uses Server Resources? - Zima Store Online

Direct Play benötigt die geringste Serverleistung, da die Originalmedien ausgeliefert werden können, ohne ihre Streams zu verändern. Direct Stream erfordert mehr Serverarbeit, weil der Server die Medien neu verpackt und möglicherweise einen inkompatiblen Audio- oder Untertitelstream umwandelt, das Video aber unverändert bleiben kann. Vollständiges Transcodieren benötigt die meiste Rechenleistung, da das Video decodiert, verarbeitet und anschließend erneut codiert werden muss. Der richtige Weg ist daher nicht zwangsläufig der mit der niedrigsten CPU-Auslastung; entscheidend ist der leichteste Weg, den Client, Netzwerk und ausgewählte Medienspuren tatsächlich akzeptieren können.

Direct Play funktioniert nur, wenn die gesamte Datei zum Client passt

Direct Play sollte bevorzugt werden, da dabei das Originalvideo und der Originalton ohne erneute Codierung übertragen werden. Serverarbeit fällt dennoch an – etwa für das Lesen aus dem Speicher, die Authentifizierung, die Protokollverarbeitung und die Netzwerkübertragung –, aber die aufwendige Videokonvertierung bleibt inaktiv.

Plex definiert Direct Play als den Weg, bei dem die Medien vom Client ohne Konvertierung verwendet werden können. In der Übersicht zum Streaming wird dieser Weg von Direct Stream und Transcodierung unterschieden. Dieser Übertragungsweg für Originalmedien macht die Client-Fähigkeiten zum entscheidenden Kriterium – nicht die Serverleistung.

Direct Play entfällt, sobald der Client einen wesentlichen Bestandteil ablehnt: Videocodec, Audiocodec, Container, Profil, Auflösung, Bitrate, Untertitelverhalten oder eine andere Wiedergabebeschränkung. Sobald ein erforderliches Element nicht unterstützt wird, muss der Server die Medien entweder neu verpacken oder einen neuen Stream erzeugen.

Direct Stream ist der Mittelweg, wenn das Video unverändert bleiben kann

Direct Stream, häufig auch Remuxing oder Transmuxing genannt, ist für Dateien gedacht, deren Video kopiert werden kann, während der Container oder ein anderer Stream angepasst werden muss. Der Server extrahiert kompatible Streams und verpackt sie in eine Form, die der Client akzeptiert. Das ist deutlich weniger aufwendig, als das Video zu decodieren und erneut zu codieren.

Die Wiedergabedokumentation von Emby beschreibt Direct Stream als eine Echtzeit-Neuverpackung, bei der die Videospur unverändert bleibt, während Audio oder Untertitel möglicherweise konvertiert werden. Der Remuxing-Weg mit unverändertem Video bildet eine wichtige Abgrenzung: „Streaming“ bedeutet nicht automatisch Videotranscodierung.

Dieser Weg eignet sich am besten, wenn nur die Container- oder Audiokompatibilität nicht gegeben ist. Er steht nicht mehr zur Verfügung, wenn das Video selbst geändert werden muss, Untertitel in die Bilder eingebrannt werden müssen oder Bitrate beziehungsweise Auflösung stärker reduziert werden müssen, als es durch das Kopieren von Streams möglich ist.

Transcodierung beginnt, wenn das Video neu aufgebaut werden muss

Die vollständige Videotranscodierung ist der aufwendige Zweig. Der Server decodiert die Quelle, skaliert sie möglicherweise, führt Tonemapping oder Deinterlacing durch, brennt Untertitel ein oder filtert die Bilder auf andere Weise und codiert anschließend einen neuen Videostream für den Client. Der Ton kann dabei kopiert oder ebenfalls konvertiert werden.

Die Transcodierungsdokumentation von Jellyfin unterscheidet zwischen Hardwarebeschleunigung und softwarebasierter Verarbeitung und weist darauf hin, dass moderne GPUs unterstützte Verarbeitungsschritte übernehmen können. Die Echtzeit-Konvertierungspipeline erklärt, warum derselbe Film auf einem Client eine geringe Netzwerkbelastung und auf einem anderen eine hohe Rechenlast verursachen kann.

Transcodierung ist gerechtfertigt, wenn Kompatibilität oder Bandbreite tatsächlich einen neuen Videostream erfordern. Wenn der Client das Originalvideo akzeptiert und das Netzwerk es übertragen kann, kann eine erzwungene niedrigere Qualität Serverlast erzeugen, die zuvor nicht vorhanden war.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Vergleiche die drei Wege anhand von vier gemeinsamen Ressourcen

Die Serverressourcen, die sich verändern, sind Rechenleistung, Speicherbewegungen, temporärer Transcodierungsspeicher und Netzwerkbandbreite. Direct Play minimiert den Rechenaufwand für Konvertierungen, kann aber die Quelle mit voller Bitrate übertragen. Transcodierung kann die ausgehende Bitrate reduzieren, erhöht jedoch die CPU- oder GPU-Auslastung. Direct Stream liegt dazwischen, da Änderungen an der Verpackung meist wenig Leistung benötigen, während eine Audiokonvertierung zusätzlichen Rechenaufwand verursacht.

Wiedergabeweg	Videoverarbeitung	Typischer Rechenbedarf	Netzwerkverhalten	Wichtigste Grenze
Direct Play	Originalvideo und Originalton	Am geringsten	Quellbitrate	Inkompatibilität von Client oder Datei
Direct Stream	Video kopiert; Container und möglicherweise Audio geändert	Gering bis mittel	Oft nahe der ursprünglichen Videobitrate	Das Video selbst muss konvertiert werden
Transcodierung	Video decodiert und erneut codiert	Am höchsten	Kann auf eine niedrigere Bitrate oder Auflösung zielen	Rechenleistung oder Durchsatz des Beschleunigers

Die Übersicht zur Hardwarebeschleunigung von FFmpeg dokumentiert spezielle APIs wie NVENC/NVDEC und QSV für die Videoverarbeitung. Diese Hardwarebeschleunigung ist nur beim Transcodierungszweig relevant; sie macht Direct Play nicht noch direkter.

Ordne die Wege nicht anhand nur einer Ressource. Ein entfernter Benutzer mit langsamer Upload-Verbindung kann Transcodierung benötigen, obwohl der Server über ausreichend Rechenleistung verfügt. Ein lokaler 4K-Client an einer kabelgebundenen Ethernet-Verbindung ist dagegen möglicherweise mit Direct Play bei voller Originalbitrate besser bedient.

Untertitel und Audio können den Weg ändern, ohne die Filmdatei zu verändern

Durch die Auswahl einer anderen Untertitel- oder Audiospur kann eine Sitzung auf einen anderen Zweig wechseln. Textuntertitel, die der Client selbst darstellen kann, ermöglichen möglicherweise weiterhin Direct Play. Bilduntertitel oder nicht unterstütztes Untertitelverhalten können dagegen das Einbrennen in die Bilder und damit Videotranscodierung erfordern. Nicht unterstützter Mehrkanalton kann eine Audiokonvertierung auslösen, während das Video weiterhin kopiert wird.

Die Leistungsdokumentation von HandBrake ist hier hilfreich, weil sie die aufwendige Videocodierung von anderen Verarbeitungsschritten unterscheidet und zeigt, dass Filter selbst bei Verwendung eines Hardware-Encoders zu Engpässen werden können. Die Trennung von Filter- und Encoderlast erklärt, warum „Hardwaretranscodierung aktiviert“ nicht bedeutet, dass jeder Verarbeitungsschritt kostenlos ist.

Wenn ein Titel unerwartet mehr Serverressourcen verbraucht als ein anderer, vergleiche zunächst die ausgewählten Spuren und den Wiedergabegrund, bevor du CPUs oder GPUs vergleichst. Die sichtbare Auflösung kann identisch sein, während der Verarbeitungspfad völlig anders ist.

Verwende das Wiedergabe-Dashboard als Entscheidungsinstrument

Leite den Verarbeitungsweg nicht allein aus der CPU-Auslastung ab. Öffne die Sitzungsdetails des Medienservers und prüfe, ob das Video per Direct Play wiedergegeben, kopiert beziehungsweise remuxt oder transcodiert wird. Kontrolliere anschließend, ob das Audio kopiert oder konvertiert wird und ob die Untertitel vom Client dargestellt oder in das Video eingebrannt werden.

Der ZimaSpace-Leitfaden zu hoher CPU-Auslastung während der Medienwiedergabe folgt derselben Regel: Ermittle zunächst die Verarbeitungsentscheidung, bevor du eine hohe Auslastung als Hinweis auf fehlende Hardwareleistung wertest.

Führe eine typische lokale Sitzung, eine entfernte oder bandbreitenbegrenzte Sitzung und eine Sitzung mit vielen Untertiteln durch. Wenn das Dashboard bereits Direct Play meldet und die Wiedergabe trotzdem puffert, solltest du nicht weiter die Transcodierungsleistung vergleichen, sondern Speicher, Übertragung oder den Client untersuchen.

Wähle den leichtesten Weg, der die Übertragungsanforderung erfüllt

Bevorzuge Direct Play, wenn der Client die vollständige Mediendatei unterstützt und das Netzwerk ihre Bitrate übertragen kann. So bleibt die Quelle erhalten und dem Server steht die meiste Kapazität für andere Benutzer zur Verfügung.

Verwende Direct Stream, wenn die Videokompatibilität bereits gewährleistet ist, aber Container, Audio oder Verpackung angepasst werden müssen. Verwende Transcodierung nur, wenn das Video selbst aufgrund von Kompatibilität, Bandbreite, Auflösung, HDR-/SDR-Konvertierung, eingebrannten Untertiteln oder einer anderen tatsächlichen Übertragungsanforderung geändert werden muss.

Kein Weg ist grundsätzlich überlegen. Direct Play minimiert den Rechenaufwand, Direct Stream behebt Abweichungen bei der Verpackung kostengünstig, und Transcodierung ermöglicht Kompatibilität sowie Bitratenkontrolle auf Kosten von Serverressourcen. Das richtige Design eines Medienservers maximiert die ersten beiden Wege und hält gleichzeitig genügend Transcodierungskapazität für Sitzungen bereit, die den dritten Weg nicht vermeiden können.