Upload-Geschwindigkeit fürs Streaming: Was ein schneller Download offenlässt

Besonders hilfreich wird der Vergleich in den höheren Downloadbereichen. Am 1. Oktober 2026 lag der Upload bei fast einem Viertel der berücksichtigten Messpaare mit 100 bis unter 300 Mbit/s Download unter 14,128 Mbit/s. Eine Woche später war der Anteil mit 23,4 % etwas niedriger. Selbst im Bereich ab 300 Mbit/s betrugen die entsprechenden Anteile 9,6 % und 8,8 %.

Jeder Prozentsatz hat je nach Bereich und Datum einen eigenen Nenner. Die Tabelle zeigt alle vier Bereiche, damit sich die schnelleren Ergebnisse einordnen lassen. Gemeint sind gemessene Downloadraten, nicht die in einem Internettarif beworbenen Geschwindigkeiten.

In jedem höheren Downloadbereich kamen Uploads unter 14,128 Mbit/s an beiden Tagen seltener vor. Dieser Zusammenhang ist hilfreich. Die verbleibenden Fälle zeigen aber, warum eine reine Downloadprüfung einen Teil der Vorbereitung offenlässt. Ein Messpaar im schnelleren Downloadbereich hatte nicht zwangsläufig auch einen Upload über der gewählten Video- und Audiodatenrate.

Für das Unternehmen mit der geplanten Demo ist der nächste sinnvolle Schritt, beide Werte des Geschwindigkeitstests festzuhalten. Ist der Upload deutlich niedriger als der Download, sollte das Team die geplante Übertragung mit dem tatsächlichen Aufbau prüfen, bevor es das Format ändert oder Geld für eine andere Verbindung ausgibt.

Die Wahl der Vergleichsgröße ist wichtig. YouTubes Encoder-Empfehlungen nennen für H.264-Video mit 1080p bei 30 Bildern pro Sekunde 14 Mbit/s, dazu 128 Kbit/s für Stereoton. Zusammen ergibt das 14,128 Mbit/s. Dieselbe Anleitung nennt für diese Auflösung und Bildrate ein niedrigeres H.264-Video-Minimum von 5 Mbit/s.^[2]

Eine empfohlene Datenrate für kodiertes Video und Audio ist etwas anderes als eine Mindestgeschwindigkeit des Internetanschlusses. Unsere Messung ist wiederum etwas anderes: ein kurzer Transfer zu einem M-Lab-Server. Die von der Quelle ausgegebene Rate wird aus serverseitigen TCP-Bytes und der verstrichenen Zeit berechnet, nicht aus einer länger laufenden Übertragung an YouTube.^[3][6][7]

Die Tabelle vergleicht daher zwei Größen; sie liefert kein Bestanden-oder-durchgefallen-Ergebnis. Ein Wert unter der Vergleichsgröße ist ein Anlass, den geplanten Aufbau genauer zu prüfen. Er belegt nicht, dass ein bestimmter Stream scheitern würde. Ein höherer Wert garantiert ebenso wenig eine erfolgreiche Veranstaltung. Der Weg zum Streamingdienst, Veränderungen während des Events, anderer Datenverkehr und das Gerät mit dem Encoder spielen weiterhin eine Rolle.

Diese Unterscheidung schützt auch das Budget. Ein Team, das 14,128 Mbit/s als allgemeine Kaufvorgabe versteht, könnte Geld ausgeben, bevor es die eigenen Einstellungen und deren tatsächliche Leistung prüft. Ein anderes könnte einen höheren Wert als Garantie ansehen und die Probe auslassen. Keine dieser Schlussfolgerungen ergibt sich aus den Messungen.

Hilfreicher ist es, zuerst die gewünschten Einstellungen für Bild, Bewegung und Ton zu wählen, deren Datenrate festzuhalten und die tatsächliche Übertragung zu testen. Die Analyse empfiehlt weder einen festen Bandbreitenfaktor noch den Wechsel in einen schnelleren Tarif.

Wir haben geprüft, ob der Befund von einer einzigen Vergleichseinstellung abhängt. Zwei weitere Vergleichsgrößen waren vorab festgelegt: 10,128 und 17,128 Mbit/s, abgeleitet aus anderen empfohlenen Encoder-Einstellungen derselben YouTube-Tabelle.^[2] Die vollständigen Ergebnisse stehen in der herunterladbaren Analyse.

Im Downloadbereich von 100 bis unter 300 Mbit/s ergab die niedrigere Vergleichsgröße Anteile von 18,9 % am 1. Oktober und 18,1 % am 8. Oktober. Bei der höheren waren es 28,0 % und 26,8 %. Die Nenner blieben 212.675 und 194.290 Messpaare. Im Bereich ab 300 Mbit/s reichten die entsprechenden Anteile am 1. Oktober von 7,9 % bis 11,0 % und am 8. Oktober von 7,1 % bis 10,2 %, bei 237.588 beziehungsweise 221.617 Messpaaren. Die Einstellung verändert den Vergleich. Einen einzigen Prozentsatz für „Streaming“ gibt es deshalb nicht.

Wir haben die Berechnung außerdem ohne alle Messpaare wiederholt, deren Upload- oder Download-Zusammenfassungswert null war. Manche Verarbeitungspfade der Quelle können bei fehlenden Abschlussmessungen null liefern. Ein solcher Wert belegt deshalb nicht automatisch, dass bei einem Transfer nichts gesendet wurde.^[6] Im Bereich von 100 bis unter 300 Mbit/s waren es danach 51.313 von 212.136 Messpaaren (24,2 %) am 1. Oktober und 45.047 von 193.832 (23,2 %) am 8. Oktober. Ab 300 Mbit/s waren es entsprechend 22.122 von 236.909 (9,3 %) und 18.764 von 220.928 (8,5 %). Das Entfernen der Nullwerte änderte jeden der vier Hauptanteile an beiden Tagen um weniger als 0,3 Prozentpunkte. Der für die Vorbereitung relevante Unterschied blieb bestehen.

Eine größere Veränderung zeigte sich innerhalb einer Gruppe von Serversoftware. Bei Version v0.25.2 im Downloadbereich ab 300 Mbit/s sank der Anteil der Uploads unter 14,128 Mbit/s von 4.803 aus 26.338 Messpaaren (18,24 %) am 1. Oktober auf 1.418 aus 21.217 (6,68 %) am 8. Oktober. Dieser Unterschied gehört neben das Hauptergebnis. Er zeigt, warum ein Prozentsatz aus dieser Analyse nicht zu einer allgemeinen Planungsregel werden sollte.

Damit ist nicht belegt, dass die Software die Veränderung verursacht hat. Die Zusammensetzung aus Netzen, Geräten, Übertragungswegen und Messclients kann sich zwischen den Tagen unterscheiden. Derselbe Client kann auch mehrfach vorkommen, einschließlich an beiden Terminen. Wir veröffentlichen sämtliche Aufschlüsselungen nach Tageshälfte, Clientbibliothek und Serverversion, damit sich diese Unterschiede über den Gesamtwert hinaus prüfen lassen.^[1]

Halte zunächst den Uploadwert gut sichtbar fest. Notiere, wo und wann die Prüfung stattfand, welches Gerät und welche Verbindung verwendet wurden und was sonst im Netzwerk lief. So lässt sich das Ergebnis später besser einordnen. Außerdem vermeidest du, einen Messwert von einem Ort als Beleg für einen anderen Veranstaltungsort zu behandeln.

Probe anschließend den Teil der Demo, der den tatsächlichen Aufbau am stärksten beansprucht. Bei einer Produktführung kann das bedeuten, während des Sprechens den Bildschirm zu teilen und zwischen Kamera und Produkt zu wechseln. Bei einer physischen Vorführung können Bewegung und detailreiche Nahaufnahmen dazugehören. Nutze den vorgesehenen Encoder, Account, die Plattform und die Verbindung, damit die Probe die Frage des Events beantwortet. Auch YouTube empfiehlt Tests mit repräsentativem Ton und Bewegung sowie die Überwachung des Streamzustands.^[2]

Gib jeder repräsentativen Szene in den Probenotizen einen Namen: Kameraeinstieg, Nahaufnahme, Bildschirmführung, Publikumsfragen. Notiere den Beginn jeder Szene und welche Details die beobachtende Person sehen oder hören können sollte. Tritt ein Problem auf, halte Szene, Zeitpunkt und sichtbares oder hörbares Symptom fest, damit Präsentation und Beobachtung ihre Notizen vergleichen können.

Trenne Beobachtungen von Erklärungen. „Beim Teilen des Bildschirms gab es Bildstörungen“ ist eine Beobachtung, die festgehalten werden sollte. „Unser Internetanbieter war die Ursache“ ist eine Diagnose, die weitere Belege braucht. Eine kurze M-Lab-Messung kann die Ursache eines Problems auf einem anderen Übertragungsweg zum Streamingdienst nicht bestimmen.

Zeigt die Probe ein Problem, ändere einen Teil des Aufbaus und teste erneut. Wiederhole dieselbe Szene und notiere die geänderte Einstellung, die gleich gebliebenen Bedingungen und die Beobachtungen jeder beteiligten Person. Halte unvermeidbare Unterschiede fest, etwa ein weiteres Gerät, das sich mit dem Netzwerk verbindet. Ein besserer Wiederholungstest liefert hilfreiche Informationen zu diesem Versuch; er isoliert keine Ursache, wenn sich auch andere Bedingungen geändert haben. Ändert sich das Format, teste das neue, statt dich auf das frühere Ergebnis zu verlassen.

Entscheide schließlich, was das Publikum erhalten soll, wenn die Live-Demo unterbrochen wird. Ein vorbereitetes Video oder eine schriftliche Anleitung kann die Erklärung verfügbar halten, während sich das Team um die Unterbrechung kümmert. Benenne eine Person, die dieses Material während des Events bereithält. Unsere Videoskript-Vorlage kann bei der Vorbereitung helfen. Unsere Studie zu Entwicklermarketing und Dokumentation behandelt eine verwandte Frage: Welche hilfreichen Inhalte sollten ein Video begleiten?

Betrachten wir ein fiktives Softwareunternehmen mit fünf Personen, das eine Live-Einführung ins Produkt plant. Seine angenommenen Testwerte sind 180 Mbit/s im Download und 11 Mbit/s im Upload. Diese Zahlen veranschaulichen die Vorlage; sie stammen nicht von einem Unternehmen, das in den M-Lab-Daten beobachtet wurde.

Das Team möchte H.264-Video mit 1080p bei 30 Bildern pro Sekunde und Stereoton verwenden. Der Uploadwert liegt unter der in dieser Studie verwendeten empfohlenen Vergleichsgröße von 14,128 Mbit/s. Das Team notiert den Wert neben den geplanten Encoder-Einstellungen, um ihn mit den Beobachtungen während der Demo in Beziehung zu setzen.

Es plant eine Probe mit demselben Laptop, derselben Verbindung, demselben Encoder und demselben Ablauf wie beim Event. Eine Person präsentiert, eine zweite prüft, was das Publikum sieht, und eine dritte notiert die Angaben der Plattform zum Streamzustand sowie sichtbare oder hörbare Unterbrechungen. Die Bildschirmsequenz, in der Kunden kleine Oberflächendetails lesen müssen, gehört zur Probe.

Vor dem Test vereinbart das Team, was es bei einer unbefriedigenden Probe tun wird: einen anderen Aufbau bewusst auswählen, erneut testen und ein kurzes Video sowie schriftliche Schritte vorbereiten, falls ein anderes Präsentationsformat nötig wird. Weder eine erfolgreiche Probe noch eine Leistungsverbesserung wird hier angenommen. Das Beispiel endet mit einem konkreten Plan, die fehlenden Informationen zu sammeln.

Beginne mit dem Event. Kopiere die vollständige Planungsvorlage ohne Anmeldung in deine Veranstaltungsnotizen und bewahre sie zusammen mit dem Skript auf. Benenne Publikum, Ort, geplantes Datum und Uhrzeit, die präsentierende Person und die Person, die prüft, was das Publikum sieht. Halte fest, welchen Moment die Zuschauer besonders klar sehen oder hören müssen.

Beschreibe den geplanten Aufbau. Notiere Streamingplattform, Gerät, Encoder und Verbindung sowie Auflösung, Bildrate, Videocodec und konfigurierte Video- und Audiodatenraten. Ergänze andere erwartete Aktivitäten auf dem Gerät oder im Netzwerk, damit die Notizen die vorgesehenen Bedingungen beschreiben.

Halte den gesonderten Geschwindigkeitstest fest. Notiere Datum, Uhrzeit, Ort und Werkzeug sowie Download- und Uploadwerte mit Einheiten. Beschreibe, worin sich dieser Test vom geplanten Streamingaufbau unterscheidet. Einen Wert ohne Kontext kann ein Teammitglied später schlechter einordnen.

Dokumentiere die Probe. Beschreibe die tatsächlich getestete Abfolge mit Bewegung, Ton und Bildschirmfreigabe. Sammle die Beobachtungen aus Sicht des Publikums zusammen mit den Angaben der Plattform zum Streamzustand. Wenn du eine Einstellung geändert hast, notiere das Ergebnis des nächsten Tests. Fülle diese Felder erst nach dem Test aus; kennzeichne offene Prüfungen als offen und ordne jeder eine verantwortliche Person zu.

Entscheide über die Präsentation. Halte das nach der Probe gewählte Format und die Einstellungen samt Begründung fest. Benenne das Ersatzmaterial für den Fall einer Unterbrechung und die Person, die Änderungen an das Publikum kommuniziert. Lass die hilfreiche Erklärung auch nach dem Event zugänglich. Eine Vorlage für die YouTube-Beschreibung kann dabei helfen, Video und ergänzende Links für Kunden zu ordnen, die nicht live teilnehmen konnten.

Wir haben die öffentliche NDT7-Union-View von M-Lab für Datensätze mit US-Geolokalisierung vom 1. und 8. Oktober 2026 verwendet. Jedes aufgenommene Paar bestand aus genau einem Upload- und einem Downloaddatensatz mit demselben Autorisierungstoken und derselben Serveridentität. Ihre Starts durften höchstens 60 Sekunden auseinanderliegen und mussten beide in den ausgewählten UTC-Tag fallen. Weitere Prüfungen betrafen Zeitstempel, Verbindungskennungen und Quellversionen.^[1][3]

Nach diesen Prüfungen und dem Ausschluss ungültiger Raten blieben am 1. Oktober 745.186 und am 8. Oktober 698.882 Messpaare in der Analyse. Datensätze ohne Upload- oder Downloadpartner wurden ausgeschlossen und niemals durch null ergänzt. Jeder Tabellenprozentsatz teilt die Zahl der Messpaare mit Upload unter der Vergleichsgröße durch alle berücksichtigten Paare im Downloadbereich dieses Tages.

Frühere Forschung hat bereits Upload- und Downloadbeobachtungen von M-Lab gepaart und ihren Kontext untersucht.^[4] Unser Beitrag ist dieser datierte, reproduzierbare Vergleich für eine praktische Frage der Streamingvorbereitung. Er beschreibt die ausgewählten Messungen, nicht die Verbreitung langsamer Uploads unter US-Unternehmen oder Creatorn.

Der Download ohne Anmeldung enthält das festgelegte Protokoll, die exakten Abfragen, Quellenhinweise, vollständige Auswahlzählungen und alle 264 geplanten Ergebniszellen für jeden Tag.^[8] Dazu gehören sich überschneidende Aufschlüsselungen, nicht 264 unabhängige Studien. Das Offline-Skript reproduziert die aggregierten Berechnungen; die erneute Ausführung der Quellabfragen ist ein gesonderter Schritt. Für die nächste Demo ist die praktische Aufgabe kleiner: den Uploadwert behalten, die tatsächliche Präsentation proben und anhand der Beobachtungen des Teams entscheiden, wie sie übertragen wird.