Kann 2,5-GbE mehrere gleichzeitige 4K-Direct-Play-Streams bewältigen?

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.

Ja, 2,5-GbE kann in der Regel mehrere 4K-Direct-Play-Streams übertragen, solange ihre kombinierte Spitzenbitrate unter der langsamsten dauerhaft verfügbaren Verbindung bleibt.

Direct Play vermeidet die Videocodierung, beseitigt aber nicht die Einschränkungen durch Netzwerk, Speicher, Container, Switch oder Client. Ein Medienserver zu Hause muss jede Quelle schnell genug lesen, alle Sitzungen über die tatsächlich ausgehandelten Verbindungen übertragen und Bitratenspitzen überstehen, ohne die Puffer der Wiedergabegeräte zu erschöpfen. Die nützliche Antwort ist daher keine feste Anzahl von Streams, sondern ein gemessener Parallelitätsgrenzwert, der auf repräsentativen Dateien und dem schwächsten Gerät im gesamten Pfad basiert.

Bestätigen, dass jede Testsitzung tatsächlich Direct Play verwendet

Starten Sie auf jedem vorgesehenen Client einen repräsentativen 4K-Titel und überprüfen Sie das Dashboard des Medienservers. Notieren Sie, ob Video, Audio und Untertitel Direct Play, Direct Stream oder Transcoding verwenden, einschließlich des angegebenen Grundes und der aktuellen Bitrate.

Eine Sitzung, die wie „4K-Streaming“ aussieht, kann trotzdem Audio umwandeln, den Container neu verpacken oder Untertitel in das Video einbrennen. Ein Jellyfin-Bericht für Android TV zeigt, wie eine Änderung der Client-Bitrate beeinflusste, ob eine große Datei direkt gestreamt oder transcodiert wurde.

Zählen Sie eine Sitzung nicht als Direct-Play-Netzwerktest, wenn der Server das Video codiert. Wählen Sie zunächst kompatibles Audio und kompatible Untertitel, stellen Sie den Client auf Originalqualität ein und bestätigen Sie, dass das Dashboard auch nach dem Springen und Fortsetzen bei dem vorgesehenen Pfad bleibt.

Spitzenbitrate messen, statt sich allein auf die Dateigröße zu verlassen

Notieren Sie für jede Datei die Laufzeit, die durchschnittliche Bitrate und die beobachteten Wiedergabespitzen. Die Dateigröße geteilt durch die Laufzeit ergibt einen Durchschnittswert, aber Actionszenen, verlustfreies Audio und detailreiche Sequenzen können vorübergehend deutlich mehr Bandbreite erfordern.

4K-Titel mit hoher Bitrate können Spitzen von über 100 Mbit/s erzeugen, selbst wenn der Durchschnitt niedriger liegt. Ein Leitfaden zur Fehlerbehebung aus der Plex-Community weist darauf hin, dass 4K-Bitratenspitzen 100 Mbit/s überschreiten können. Deshalb kann der 100-Mbit/s-Ethernetanschluss eines Fernsehers ausfallen, bevor die 2,5-GbE-Serververbindung ausgelastet ist.

Stellen Sie den Testsatz aus den Dateien mit der höchsten Bitrate zusammen, die tatsächlich angesehen werden, und nicht aus einem einzigen komprimierten Democlip. Spielen Sie jeden Titel durch seine datenintensivste Szene und zeichnen Sie die Netzwerkauslastung lange genug auf, damit sich der Puffer des Clients leert oder wieder füllt.

Streams addieren und bewusst Reserven einplanen

Berechnen Sie zunächst den erwarteten Bedarf, indem Sie die gemessene Spitzenbitrate oder die Bitrate eines hohen Perzentils aller gleichzeitig laufenden Streams addieren. Berücksichtigen Sie zusätzlich Audio, Protokoll-Overhead, das Durchsuchen der Bibliothek, die Untertitelübertragung und anderen Datenverkehr über dieselbe Serverschnittstelle.

Eine 2,5-GbE-Verbindung wird mit 2.500 Mbit/s beworben, aber die Anwendung sollte nicht dauerhaft für diesen Wert ausgelegt werden. Reservieren Sie Kapazität für Ethernet- und TCP-Overhead, Bitratenschwankungen, Neuübertragungen, Speicherverzögerungen und einen weiteren Benutzer, der während einer bestehenden Spitze die Wiedergabe startet.

Beispielsweise entsprechen zehn Sitzungen mit Spitzen nahe 100 Mbit/s vor Overhead und anderem Datenverkehr etwa 1.000 Mbit/s. Diese Gesamtlast liegt unter einer leistungsfähigen 2,5-GbE-Serververbindung, aber ein einzelner Client mit einer Begrenzung auf 100 Mbit/s kann bei derselben Quelle trotzdem puffern.

Gemessene Spitze pro Stream Vier Streams Acht Streams Als Nächstes prüfen
50 Mbit/s 200 Mbit/s 400 Mbit/s Clientverbindungen und Speicherlatenz
100 Mbit/s 400 Mbit/s 800 Mbit/s 100-Mbit/s-TV-Anschlüsse und WLAN-Stabilität
150 Mbit/s 600 Mbit/s 1.200 Mbit/s Switch-Uplinks, Laufwerke und dauerhafte Reserven

Diese Werte sind Planungsbeispiele und keine garantierten Stream-Anzahlen. Ersetzen Sie sie durch die tatsächlichen Spitzenwerte Ihrer Bibliothek und erhöhen Sie die Parallelität nicht weiter, sobald Pufferung, Neuübertragungen, Speicherwartezeiten oder eine Sättigung der Verbindung beginnen.

Jede ausgehandelte Verbindung zwischen Server und Clients überprüfen

Überprüfen Sie den Medienserver, die Switch-Ports, Uplinks, Access Points, Client-Adapter und die Schnittstellen der Fernseher. Der Server kann zwar mit 2,5 GbE verbunden sein, während ein Switch-Uplink mit 1 GbE läuft oder der Ethernetanschluss des Fernsehers auf 100 Mbit/s begrenzt ist.

Die Einschränkungen der Clients bestimmen die 4K-Wiedergabe häufig maßgeblich. Ein Fall aus der Plex-Fehlerbehebung zeigte, dass die 4K-Wiedergabe mit hoher Bitrate durch den Netzwerkpfad des Clients und nicht durch die Fähigkeit des Servers, die Datei zu lesen, eingeschränkt wurde.

Lesen Sie die ausgehandelten Geschwindigkeiten und Fehlerzähler aus, statt sich auf die Beschriftungen der Ports zu verlassen. Der ZimaSpace-Leitfaden zu einem 2,5-GbE-Port, der sich mit 1 GbE verbindet, ist der nächste Prüfschritt, wenn die Serverschnittstelle nie den erwarteten Verbindungsmodus erreicht.

Prüfen, ob der Speicher die aggregierten Lesevorgänge bedienen kann

Führen Sie denselben Test mit gleichzeitiger Wiedergabe durch und überwachen Sie dabei Festplattendurchsatz, Warteschlangentiefe, Latenz, Cache-Verhalten und Dateisystemfehler. Direct Play erfolgt überwiegend sequenziell, aber mehrere Dateien in unterschiedlichen Bereichen eines Laufwerks können konkurrierende Lesevorgänge verursachen.

Der Speicher bietet für einige Streams normalerweise genügend sequenzielle Bandbreite. Ein beschädigtes Array, ein laufender Scrub-Vorgang, ein SMR-Laufwerk, ein entfernt eingebundener Speicher oder ein gleichzeitiger Auftrag zur Erstellung von Vorschaubildern kann jedoch Latenzen verursachen, die in der Netzwerkgrafik nicht sichtbar sind. Das Symptom ist Pufferung, während die 2,5-GbE-Verbindung weit von einer Sättigung entfernt bleibt.

Wiederholen Sie den Test mit Medien, die auf eine nachweislich schnelle lokale SSD kopiert wurden. Stabilisiert sich die Wiedergabe, ohne dass Clients oder Netzwerkpfade geändert wurden, sollten Sie die Bibliothek, den Mount oder die Auslastung des Arrays untersuchen, statt erneut das Ethernet aufzurüsten.

Serverkapazität von clientbezogenen Fehlern unterscheiden

Wenn ein Fernseher puffert, Laptops und Streaming-Boxen aber stabil bleiben, lassen Sie die funktionierenden Sitzungen weiterlaufen und ersetzen Sie nur den fehlerhaften Client durch ein anderes kabelgebundenes Gerät. So lässt sich feststellen, ob der aggregierte Pfad des Servers ausgelastet ist oder ein einzelner Endpunkt seinen Stream nicht dauerhaft bedienen kann.

Eine Direct-Play-Datei mit 120 Mbit/s kann auf einem Player ausfallen, selbst wenn sie über ein Gigabit-LAN übertragen wird, da auch Codec- und Client-Verhalten Teil des Pfads sind. Ein Jellyfin-Fall dokumentiert einen Wiedergabefehler bei einem Client mit hoher Bitrate, trotz lokalem Speicher und Gigabit-Netzwerk.

Protokollieren Sie Fehler nach Gerät, Datei, Audiospur, Untertitelspur und Verbindungstyp. Reduzieren Sie nicht die serverweite Qualität und erklären Sie 2,5 GbE nicht für unzureichend, wenn dieselbe aggregierte Last erfolgreich funktioniert, nachdem ein eingeschränkter Client ersetzt wurde.

Die tatsächliche Parallelitätsgrenze mit einem stufenweisen Lasttest ermitteln

Beginnen Sie mit einem Titel mit hoher Bitrate und fügen Sie anschließend einzeln Sitzungen hinzu, die an unterschiedlichen Zeitpunkten starten, sodass sich ihre Spitzen unvorhersehbar überschneiden. Überwachen Sie die Sendeleistung des Servers, die Switch-Auslastung, Neuübertragungen, die Speicherlatenz, die CPU-Auslastung und Pufferereignisse der Clients.

Wiederholen Sie den Test nach einem Neustart des Servers und während einer normalen Hintergrundaufgabe, beispielsweise einer Bibliotheksprüfung. Der Validierungspfad für einen Medienserver zu Hause von ZimaSpace erklärt, warum die Wiedergabe mit mehr als einem echten Client getestet werden sollte, bevor ein Setup als fertig betrachtet wird.

2,5 GbE reichen aus, wenn die vorgesehene Anzahl von Direct-Play-Sitzungen auch in Spitzenabschnitten mit stabilen Puffern und ausreichenden Reserven funktioniert. Rüsten Sie nur dann auf oder teilen Sie den Datenverkehr auf, wenn die Serververbindung nach dem Ausschluss begrenzter Client-Ports, Switch-Uplinks, Speicherprobleme und versehentlicher Transcodierung als gemessener Engpass übrig bleibt.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.