Wenn Zahlen lügen: Eine CDN-Fallstudie

Echte Streaming-Probleme lassen sich selten auf den ersten Blick erkennen. Beim Betriebsteam eines Fernsehsenders gehen Beschwerden ein. Das Monitoring-Dashboard zeigt eine erhöhte Anzahl an Wiedergabeunterbrechungen. Gleichzeitig sehen die CDN-Logs völlig unauffällig aus: Die Latenz liegt im Normalbereich, die Cache-Trefferquote ist hoch, und es gibt keine Hinweise auf größere Störungen. Trotzdem hängt das Bild bei den Zuschauern immer wieder.

Das war die Ausgangslage einer unserer spannendsten Untersuchungen. Es ging um einen 24/7-Kanal eines großen nationalen Broadcasters mit zweistündigem DVR-Fenster, ausgeliefert an Millionen von Zuschauern. Bei Streaming in Broadcast-Qualität sind die Anforderungen besonders hoch. Die Fehlertoleranzen sind äußerst gering, und bereits Millisekunden können entscheidend sein. Wir konnten die tatsächlichen Ursachen auf vier verschiedenen Ebenen identifizieren und Schritt für Schritt beheben. Als verlässliche Grundlage für die Bewertung der Quality of Experience (QoE) dienten uns dabei die Daten des AVEQ-Teams und seiner Surfmeter-Messsonden.

Die wichtigste Erkenntnis vorweg: Einige Wiedergabeunterbrechungen waren tatsächlich vorhanden. Andere wurden durch fehlerhafte Messungen erfasst. Die interessanteste Ursache war jedoch ein zeitliches Abstimmungsproblem, das auf keinem herkömmlichen Dashboard sichtbar war. Alle drei zu beheben, ist das, was Broadcast-Qualität tatsächlich ausmacht.

QoS und QoE sind nicht dasselbe

Die Begriffe Quality of Service (QoS) und Quality of Experience (QoE) werden häufig als Synonyme verwendet. Genau diese Tatsache kann dazu führen, dass ein Monitoring-Dashboard ausschließlich unauffällige Werte anzeigt, während Zuschauer die Wiedergabe frustriert abbrechen. Denn beide Kennzahlen betrachten grundlegend unterschiedliche Aspekte.

QoS beschreibt die Qualität auf Netzwerkebene: Latenz, Paketverluste, TCP-Retransmissions, Cache-Trefferquoten und HTTP-Statuscodes. Diese Werte sind objektiv messbar und in den entsprechenden Logs verfügbar. Allerdings sagen sie nur bedingt etwas darüber aus, was ein einzelner Zuschauer tatsächlich auf seinem Bildschirm erlebt.

QoE beschreibt die Qualität aus Sicht der Zuschauer: Hängt das Video? Wechselt die Wiedergabe plötzlich auf eine niedrigere Auflösung? Wie lange dauert es, bis das erste Bild erscheint? Diese Werte werden auf der Ebene des Videoplayers und nicht allein innerhalb der Netzwerkinfrastruktur erfasst. Ein Stream kann hervorragende QoS-Werte aufweisen und den Zuschauern trotzdem ein schlechtes Nutzungserlebnis bieten. Entscheidend ist deshalb, diese Lücke zu schließen.

Bei der Bewertung der QoE und der tatsächlich wahrnehmbaren Beeinträchtigungen betrachten wir ein Einfrieren des Videobildes ab einer Dauer von 100 Millisekunden als Wiedergabeunterbrechung (Stall). Laut AVEQ-Untersuchungen werden kürzere Unterbrechungen von den Zuschauern in der Regel nicht wahrgenommen.

Wie sich die Probleme bemerkbar machten

Als Gcore über die Probleme informiert wurde, erfassten wir zunächst konkrete Auffälligkeiten:

• Während der Wiedergabe bemerkten die Zuschauer sichtbare Qualitätseinbußen und häufige Wechsel zwischen verschiedenen Qualitätsstufen. 
• Die Anzahl der Wiedergabeunterbrechungen lag höher als bei den leistungsstärksten CDNs, die denselben Stream unter vergleichbaren Bedingungen auslieferten.
• Der Mean Opinion Score (MOS), der die wahrgenommene Wiedergabequalität anhand der AVEQ-Messungen bewertet, sank von einem guten Wert von 4,5 auf 3,4.
• Ein Internet Service Provider (ISP) zeigte durchgehend schlechtere Ergebnisse als die übrigen Anbieter.

Für Streaming in Broadcast-Qualität liegt der Zielwert bei weniger als fünf Wiedergabeunterbrechungen innerhalb von 24 Stunden. Wir lagen deutlich darüber. Deshalb untersuchten wir die möglichen Ursachen systematisch, Ebene für Ebene.

Nur zuverlässige Messdaten ermöglichen eine gezielte Fehlerbehebung

Eine einzelne Datenquelle kann nie das vollständige Bild liefern. Deshalb kombinierten wir drei unterschiedliche Perspektiven, um die tatsächlichen Ursachen zu identifizieren:

• AVEQ Surfmeter: Eine clientseitige Anwendung zur Messung der QoE, die an mehreren Standorten eingesetzt wurde. Eine der Messsonden war direkt mit dem ISP verbunden, bei dem die größten Probleme auftraten. Surfmeter lieferte Messwerte aus Zuschauersicht, darunter die Anzahl und Dauer der Wiedergabeunterbrechungen, Wechsel zu niedrigeren Qualitätsstufen, das Bitratenverhalten und den MOS. Die Daten ließen sich nach ISP und Player-Version aufschlüsseln. Diese Informationen können CDN-Logs allein nicht liefern.
• Gcore HAS Probe: Unser intern entwickelter HLS/DASH-Emulator verhält sich wie ein Videoplayer, protokolliert dabei jedoch sämtliche relevanten Vorgänge. Dazu gehören Time to First Byte (TTFB), Time to First Frame, die Ladezeiten von Manifesten und Segmenten sowie Fehler beim Parsen von Manifesten. So lassen sich Probleme erkennen, die einen Player beeinträchtigen, in klassischen CDN-Logs jedoch häufig unauffällig bleiben.
• CMCD und CDN-Rohlogs: Wir glichen die von den Videoplayern übermittelten Common Media Client Data (CMCD) mit den Edge-Logs ab. Dadurch konnten wir konkrete Ereignisse innerhalb der Infrastruktur mit ihren unmittelbaren Auswirkungen auf die Wiedergabequalität verknüpfen.

Mehr Kapazitätsreserven für die am stärksten ausgelastete Verbindung

Die erste Ursache fanden wir auf Netzwerkebene. Eine Verbindung zu einem bestimmten ISP verursachte häufiger Qualitätseinbußen als die übrigen Verbindungen. Zudem traten die Probleme unregelmäßig auf. Zu Spitzenlastzeiten stieg die Anzahl der TCP-Retransmissions stärker als gewünscht.

Das ist besonders beim adaptiven Streaming problematisch: Für den Download der Videosegmente steht nur ein begrenztes Zeitfenster zur Verfügung. Schon ein geringer Anstieg der Übertragungszeiten reduziert die Pufferreserve, die Wiedergabeunterbrechungen verhindern soll.

Die Ursache lag in der Verteilung der verfügbaren Netzwerkkapazitäten. Zu Spitzenlastzeiten musste die Auslastung dieses Verbindungspfads besser auf mehrere Standorte verteilt werden. Wir verteilten den Datenverkehr neu, schufen zusätzliche Kapazitätsreserven auf der am stärksten ausgelasteten Transitverbindung und ließen das Routing sich stabilisieren.

Dadurch sank die TCP-Retransmission-Rate auf 0,3 % – eine Verbesserung um den Faktor zehn. Gleichzeitig verbesserten sich die Ladezeiten der Manifeste und Videosegmente.

Eine QoS-Kennzahl lässt sich dabei leicht mit einem Wert aus Zuschauersicht verwechseln: die durchschnittliche Auslieferungsdauer (Mean Delivery Duration). Sie beschreibt die serverseitige Verarbeitungszeit, die direkt aus den Rohlogs ermittelt wird. Die Übertragungszeit zum Client und zurück ist darin nicht enthalten.

Der gemessene Wert lag bei 23,1 Millisekunden und damit innerhalb des Zielwerts von 30 Millisekunden.

Wenn die Messung selbst zum Problem wird

An diesem Punkt wurde die Untersuchung besonders interessant: Einige der Wiedergabeunterbrechungen, denen wir nachgingen, waren für die Zuschauer überhaupt nicht wahrnehmbar.

Mikrounterbrechungen: Fehler in der Zählung. Bei Tests mit Surfmeter für einzelne Qualitätsprofile stellten wir fest, dass manche als Stalls erfassten Unterbrechungen extrem kurz waren – deutlich unterhalb der Schwelle von 100 Millisekunden. Diese Mikrounterbrechungen erhöhten sowohl unsere Messwerte als auch die Referenzstatistiken des Fernsehsenders.

Um die Analyse auf tatsächlich relevante Beeinträchtigungen zu konzentrieren, konfigurierte AVEQ Surfmeter so, dass Unterbrechungen unter 100 Millisekunden nicht mehr berücksichtigt wurden. Anschließend berechneten wir sämtliche betroffenen Testergebnisse neu. Dadurch sank die gemessene Ausgangsrate der Wiedergabeunterbrechungen.

Player-Fehler, die wie Infrastrukturprobleme aussahen. Durch die Zusammenarbeit mit dem Fernsehsender erhielten wir Zugriff auf mehrere Versionen des eingesetzten Referenzplayers, darunter auch ältere Versionen. Dabei zeigte sich, dass diese älteren Player-Versionen selbst fälschlicherweise Wiedergabeunterbrechungen meldeten.

Mithilfe der AVEQ-Daten und unserer CDN-Loganalyse konnte das Player-Team den Auslöser identifizieren. Zwei Software-Releases behoben einen Großteil der Probleme. Bereits das erste Update reduzierte die Anzahl der gemeldeten Wiedergabeunterbrechungen um rund 20 %.

Der Videoplayer und die eingesetzten Messwerkzeuge sind Teil der gesamten Qualitätskette – keine neutralen Beobachter. Wer bei einer CDN-Fehleranalyse den Player nicht berücksichtigt, läuft Gefahr, Probleme dauerhaft der falschen Ursache zuzuordnen.

Da Surfmeter das gesamte Multi-CDN-Setup gleichzeitig überwachte und denselben Stream sowohl über Gcore als auch über die anderen CDNs und sämtliche Player-Versionen hinweg analysierte, konnten wir die Wiedergabeunterbrechungen gezielt nach CDN und Player-Version aufschlüsseln.

Dadurch konnten wir die Wiedergabeunterbrechungen sowohl nach Player-Version als auch nach CDN auswerten und zwischen Player-spezifischen Auffälligkeiten und tatsächlichen CDN-Problemen unterscheiden.

Vor der Fehlerbehebung kam es bei allen CDN-Anbietern, einschließlich der Wettbewerber, zu häufigen Aussetzern. Nach den Korrekturen verbesserten sich die Werte von Gcore erheblich. Die Anzahl der Wiedergabeunterbrechungen sank auf ein niedriges, stabiles Niveau und blieb bei allen Player-Versionen gering, während bei einigen anderen CDNs weiterhin vermehrt Spitzen auftraten.

Eine Race Condition, die kein Dashboard erkennen konnte

Die interessanteste Erkenntnis lieferte die Analyse der Manifest-Ladezeiten mit Gcore HAS Probe. Dabei entdeckten wir einen Fehler, der auf herkömmlichen Monitoring-Dashboards nicht sichtbar war.

Im untersuchten Fall verwendete der Fernsehsender Videosegmente mit einer Länge von zwei Sekunden und ein umfangreiches Manifest. Durch das zweistündige DVR-Fenster erreichte dieses eine Größe von rund 500 KB. In Kombination mit mehreren vorgeschalteten Caching-Ebenen entstand dadurch eine Race Condition – ein zeitliches Abstimmungsproblem zwischen verschiedenen Verarbeitungsvorgängen.

Das kritische Zeitfenster war äußerst klein. Es entstand nur dann, wenn ein Player das Manifest unmittelbar vor dem Übergang zum nächsten Videosegment anforderte. Bei Millionen von Zuschauern führten jedoch selbst diese kurzen Zeitfenster zu regelmäßig auftretenden Wiedergabeunterbrechungen.

Unsere CDN-Logs zeigten, dass Fehler bei der Aktualisierung der Manifeste zeitlich genau mit den von Surfmeter gemessenen Wiedergabeunterbrechungen zusammenfielen. Damit konnten wir die zuvor vermutete Ursache eindeutig bestätigen.

Die Lösung: Cache-Aktualisierung im Subsekundenbereich, ohne Änderungen am Origin.

Grundsätzlich gab es zwei Lösungsansätze.

Die erste, strukturell einfachere Lösung klingt zunächst widersprüchlich: die Videosegmente von zwei auf vier Sekunden verlängern. Dadurch erhält der Cache mehr zeitlichen Spielraum gegenüber den regelmäßigen Manifest-Abfragen des Players. Die Wahrscheinlichkeit, dass ein veraltetes Manifest ausgeliefert wird, sinkt erheblich.

Wir schlugen diese Anpassung vor. Allerdings nutzten sämtliche CDNs der Multi-CDN-Konfiguration denselben Origin, der bereits im Produktivbetrieb lief. Eine Änderung der Segmentlänge ausschließlich für einen einzelnen CDN-Anbieter kam für den Fernsehsender deshalb nicht infrage – eine nachvollziehbare Entscheidung.

Also entwickelten wir eine Lösung vollständig innerhalb unserer eigenen Infrastruktur.

Dafür setzten wir auf eine Gcore-Funktion, die wir für diesen Anwendungsfall entwickelt und erfolgreich getestet hatten: Sub-Second Caching. Dabei wird das Manifest in Intervallen von weniger als einer Sekunde beim Origin revalidiert. So kann der Edge-Cache stets die aktuellsten Segmentinformationen bereitstellen, ohne dass Änderungen am Origin erforderlich sind.

Wir validierten die Funktion auf einer Testressource. Sie kann auf Anfrage auch für die Hauptkanäle aktiviert werden.

Zusätzlich passten wir die Größe des aktiv genutzten Shield-Caches an, damit das gesamte zweistündige DVR-Fenster im Cache vorgehalten werden kann.

Was wir aus diesem Fall gelernt haben

Aus dieser Untersuchung lassen sich mehrere Erkenntnisse ableiten, die für alle relevant sind, die Live-Streaming in großem Maßstab betreiben:

• QoS und QoE müssen getrennt gemessen werden. Infrastrukturmetriken allein können weder Player-Fehler noch Messartefakte oder zeitliche Probleme bei der Manifest-Aktualisierung zuverlässig aufdecken. Dafür ist die Perspektive des Videoplayers unverzichtbar.
• Ein spezialisierter Messpartner schafft einen entscheidenden Mehrwert. Die nach ISP und Player-Version aufgeschlüsselten Daten von AVEQ ermöglichten es uns, tatsächliche Ursachen zu identifizieren, statt lediglich Vermutungen anzustellen.
• Manifeste sind ein häufig unterschätzter Faktor für die Streaming-Qualität. Cache-TTL, Segmentlänge und Abfrageintervalle beeinflussen sich gegenseitig. Die daraus entstehenden Probleme bleiben auf herkömmlichen Monitoring-Dashboards häufig unsichtbar.

Broadcast-Qualität entsteht nicht durch eine einzelne optimal konfigurierte Komponente. Sie erfordert das abgestimmte Zusammenspiel sämtlicher Ebenen – und zuverlässige Messungen, die die tatsächliche Qualität bestätigen.

Live-Streaming für höchste Broadcast-Anforderungen

Gcore ermöglicht Live-Streaming mit niedriger Latenz für Millionen gleichzeitiger Zuschauer. Dafür setzen wir auf proaktives CMCD-Monitoring, Sub-Second Caching und ein Expertenteam, das unauffällige Messwerte nicht als Abschluss, sondern als möglichen Ausgangspunkt einer weiterführenden Untersuchung betrachtet.

Zuverlässige QoE-Messungen mit AVEQ Surfmeter

Surfmeter von AVEQ misst die Quality of Experience direkt aus Zuschauersicht. Dazu gehören die Anzahl der Wiedergabeunterbrechungen, Qualitätswechsel, das Bitratenverhalten und der Mean Opinion Score (MOS). Die Ergebnisse lassen sich nach ISP und Player-Version aufschlüsseln.

Diese zusätzliche Messebene war entscheidend, um tatsächliche Wiedergabeunterbrechungen von fehlerhaften Messungen zu unterscheiden. Für professionelle Streaming-Umgebungen ist eine solche Lösung daher besonders empfehlenswert.

Kontaktieren Sie uns, um mehr zu erfahren.