Ihr privater HLS-Stream lädt für Sie, nicht für Ihre Zuschauer

Sie testen die Seite auf Ihrem Laptop, der Player startet, und das Ticket wird geschlossen. Der Zuschauer am anderen Ende öffnet dieselbe Seite und bekommt einen Spinner, der nie auflöst. Die übliche Erklärung lautet, das VPN liege auf dem Server, also müsse die Wiedergabe funktionieren — aber der Browser ist die Komponente, die die Playlist anfordert, und er hat seinen eigenen Netzwerkpfad. Eine Seite, die auf einem Server mit privatem Zugang eingebettet ist, verleiht diesen Zugang nicht an jeden, der sie lädt.

Es geht um eine bestehende ASP.NET-Seite, die eine HLS-Quelle wie http://10.5.5.9:8080/live/stream.m3u8 wiedergibt, eine illustrative private Adresse. Zwei Anordnungen funktionieren; eine davon ist wahrscheinlich nicht die, die Sie gebaut haben.

Mythos: eine ladende Seite beweist den Medienpfad

Das HTML dieser Seite kommt von Ihrem Webserver, über welche Route auch immer Ihr Webserver hat. Die Playlist und die Segmente kommen vom Medienursprung, über welche Route auch immer die anfragende Komponente hat. Wenn der Player im Browser des Zuschauers läuft, sind das zwei verschiedene Clients, zwei verschiedene Quelladressen und oft zwei verschiedene Fehlerdomänen. Dass der erste Erfolg hat, sagt nichts über den zweiten.

Was Ihr Test tatsächlich bewiesen hat, ist enger, als es aussah: Ihre Maschine erreicht die öffentliche Seite und den privaten Medienhost gleichzeitig. Die Maschine des Zuschauers war nie Teil des Experiments.

Was die Playlist als Nächstes anfordert

RFC 8216 trennt Medienplaylists, die Segmente auflisten, von Masterplaylists, die andere Playlists auflisten, und löst relative URIs gegen die URI der enthaltenden Playlist auf. Genau diese Regel überspringen die Leute. Eine .m3u8-Datei erfolgreich abzurufen ist kein Wiedergabetest, denn die abgerufene Datei ist ein Index, nicht das Medium.

Folgen Sie der Kette so, wie es der Player tut: Öffnen Sie die gewählte Playlist, fordern Sie dann die Ressourcen an, die sie nennt, und folgen Sie dann jeder Weiterleitung. Eine Playlist, die über einen erreichbaren Webserver ausgeliefert wird, kann den Zuschauer trotzdem auf eine unerreichbare private Adresse verweisen. Ebenso ändert das Verschieben einer relativen Playlist auf eine andere URL die Basis, gegen die ihre Einträge aufgelöst werden, und deshalb erzeugt das Umschreiben der ersten sichtbaren URL mit anschließendem Aufhören meist eine gültig aussehende Playlist, die nicht abspielen kann.

Direktes Ansehen: der Zuschauer braucht den Pfad

Wenn Zuschauer den Medienhost direkt erreichen sollen, brauchen ihre Geräte das genehmigte VPN oder einen anderen privaten Pfad, DNS, der die tatsächlich verwendeten Namen auflöst, die Berechtigung, diese Ziele zu erreichen, und jede Authentifizierung, die der Mediendienst verlangt. Prüfen Sie jedes davon auf dem Gerät des Zuschauers statt auf dem Server. Ein Browser auf einem Telefon mit installiertem, aber nicht verbundenem VPN-Profil ist ein häufiger und vollständig reproduzierbarer Fehler.

Diese Anordnung hält die Quelle privat und verlagert die Zugriffsanforderung auf das Publikum. Das ist eine politische Entscheidung ebenso wie eine technische, also bestätigen Sie vor dem Entwurf, dass jeder vorgesehene Zuschauer diesen Pfad halten darf.

Auslieferung über den Server: ein kontrollierter Einstiegspunkt

Die Alternative ist ein autorisiertes Medien-Frontend, das die Quelle über seinen privaten Pfad holt und nur die zuschauerseitigen Ressourcen erneut veröffentlicht. Halten Sie Playlist, Segmente und etwaige Schlüsselressourcen mit diesem einen Einstiegspunkt konsistent, sonst holt der Player eine umgeschriebene Playlist über das Frontend und die Segmente direkt von einer Adresse, die der Zuschauer nicht erreichen kann.

Beschränken Sie die Quelle und die erlaubten Pfade in diesem Frontend. Eine beliebige, vom Benutzer gelieferte URL macht einen hilfreichen Proxy zu einem uneingeschränkten Abrufer Ihres internen Netzes, was ein weit schlimmeres Problem ist als ein Stream, der nicht abspielt. Setzen Sie Ursprung und Pfadpräfix auf eine Positivliste, statt die Zeichenkette im Nachhinein zu validieren.

Prüfen Sie bei einer bestehenden HLS-Quelle zuerst, ob kontrollierte Weiterleitung ausreicht; ein VPN dazwischen bedeutet nicht, dass Transkodierung nötig ist. Validieren Sie dann die tatsächliche Kombination aus Browser und Codec, denn eine erreichbare Antwort und ein unterstütztes Format sind zwei getrennte Bedingungen. Lassen Sie TLS, Authentifizierung und Browsersicherheitsanforderungen des Ursprungs unangetastet — ein eingebetteter Player ist keine Ausnahme davon.

Testen Sie die Kette, nicht die URL

Führen Sie die Prüfungen aus der Komponente aus, die tatsächlich jede Anfrage stellt, und behandeln Sie jeden Schritt als eigenes Ergebnis:

curl -s http://10.5.5.9:8080/live/stream.m3u8
curl -s -o /dev/null -w '%{http_code}\n' http://10.5.5.9:8080/live/segment-000123.ts

Wiederholen Sie das dann im Browser des Zuschauers selbst mit dem vorgesehenen Stream, nicht mit einem Testmuster von Ihrem Schreibtisch. Seitenladen, Playlist-Laden, Segmentabruf und ein Autorisierungsfehler sind vier verschiedene Ergebnisse, und Sie wollen alle vier beobachtet haben, bevor Sie es als behoben bezeichnen. Installieren Sie kein veraltetes Browser-Plugin, weil ein altes Beispiel einen Stream so abgespielt hat; das fehlende Teil ist meist der Pfad des Zuschauers oder die unsignierte Segment-URL.

Wenn die Anordnung bewusst gewählt ist, schreiben Sie sie in einer Zeile auf: wer die Medien holt, über welchen Pfad, und was der Zuschauer anfordern darf. Dieser Satz entscheidet die meisten künftigen Diskussionen darüber, für wen der Stream wirklich gedacht ist.