Wir arbeiten daran, die HLS-Wiedergabe im Brightcove-Player zu verbessern, zu beschleunigen und zu stabilisieren. Dazu mussten wir unsere Annahmen über Bord werfen und das Problem ohne Vorurteile angehen.
DIE HERAUSFORDERUNG
Eine der Hauptaufgaben einer Wiedergabe-Engine, die Medienquellenerweiterungen (MSE) nutzt, besteht darin, Entscheidungen darüber zu treffen, welche Videodaten (Segmente oder Fragmente genannt) zu einem bestimmten Zeitpunkt vom Server angefordert werden sollen.
Bei HLS-Quellen für Video-on-Demand (VOD) sind die Entscheidungen relativ einfach. Wir kennen alle Segmente und (ungefähr) ihre Dauer. Die Entscheidung, welches Segment heruntergeladen werden soll, ist angesichts dieser Informationen einfach zu treffen.
Leider sind die Dinge bei einem HLS-Livestream nicht so einfach. Es fehlt nicht nur die gesamte Historie der Segmente, sondern ohne die PROGRAM-DATETIME Tag in HLS (eine neue Ergänzung der HLS-Spezifikation) haben wir auch keine einfache Möglichkeit, Segmente über verschiedene Wiedergabelisten hinweg zu korrelieren. Die einzige Möglichkeit, die dem Player bleibt, ist das spekulative Herunterladen von Segmenten, um die internen Zeitstempel der Medien zu verwenden.
Kurz gesagt, das Problem bei der Live-Wiedergabe ist, dass die vielen "Unbekannten" die Auswahl des richtigen Segments beim ersten Mal erschweren.
ABRUFALGORITHMUS
Um die Tendenz eines jeden Fetch-Algorithmus zu bekämpfen, das falsche Segment auszuwählen, haben wir einige Konzepte aus der Kontrolltheorie übernommen. Zuvor würde der Abrufalgorithmus:
- Angesichts der begrenzten Informationen die bestmögliche Vermutung anstellen
- Wenn die Schätzung falsch war, verwenden Sie die aus dieser Anfrage gewonnenen Informationen, um eine bessere Schätzung vorzunehmen (verringern Sie den "Fehler")
- Wiederholen Sie
Die Hoffnung war, dass sich der Algorithmus iterativ verbessern und schließlich das richtige Segment herunterladen würde. Das Problem tritt auf, wenn man sich überlegt, was ein "Fehler" ist. Für unseren Algorithmus definierten wir einen Fehler als einen Bereich des Videopuffers, in dem Daten fehlten.
Der Gedanke dahinter ist, dass wir, wenn wir Segment A gefolgt von Segment C abrufen würden, eine Lücke in der Größe von B geschaffen hätten, die gefüllt werden müsste. Der Algorithmus sollte dann zurückgehen, um diesen Fehler zu füllen, und Segment B auswählen, bevor er mit D fortfährt.
Die gute Nachricht ist, dass dies in 99 % der Fälle funktionierte und zwar ziemlich gut. Die schlechte Nachricht ist, dass es in 1 % der Fälle bei dem Versuch stecken blieb, eine Lücke zu füllen, die eigentlich nicht zu füllen war. Wenn dies geschah, lag es in der Regel an der Art der Quellen, die wir abspielten. Einige HLS-Quellen sind schlecht segmentiert, so dass Audio und Video nicht über alle Varianten hinweg zum gleichen Zeitpunkt segmentiert werden, was zu Lücken führt. Einige HLS-Quellen haben beschädigte oder fehlende Frames (Audio oder Video), was ebenfalls zu Lücken führt.
Unabhängig von der Ursache führten diese nicht füllbaren Teile des Puffers zu Situationen, in denen der Algorithmus beim Versuch, ihn zu füllen, stecken blieb. Wir haben schließlich viele Ansätze eingebaut, um zu verhindern, dass der Abrufer stecken bleibt:
- Betrachten Sie sehr kleine Lücken als etwas, das der Quelle innewohnt, und ignorieren Sie sie.
- Den Algorithmus zwingen, ein oder mehrere Segmente vorwärts zu holen, wenn er schon einmal versucht hat, das gleiche Segment wie bei der letzten Iteration zu holen
- Berücksichtigung von Segmenten, deren Grenzen zu 90 % oder mehr im Puffer vertreten waren, als geladen, um eine unnötige Verschwendung von Bandbreite zu vermeiden
Das Problem bei jeder dieser Strategien ist, dass sie unter ganz bestimmten Umständen versagen. Mit jedem "Fix", den wir versuchten, vervielfachte sich die Anzahl der Eckfälle. In vielen Fällen entdeckten wir, dass selbst kleine Änderungen am Abrufalgorithmus in seltsamen Szenarien versagten, die zuvor funktionierten.
FRISCH ANFANGEN
All diese Probleme führten uns zu einer unausweichlichen Schlussfolgerung: Wir brauchten eine drastische Änderung unseres Ansatzes. Bei der Untersuchung des Problems wurde uns klar, dass wir viele Annahmen über die Funktionsweise des Abrufalgorithmus hatten, die uns die Sache erschwerten.
Eine dieser Annahmen war, dass der Abrufalgorithmus stets vermeiden sollte, Segmente anzufordern, die bereits gepuffert waren. Das Problem ist, dass der Zustand des Puffers sehr schwer zu ergründen ist, wenn man die Auswirkungen des Suchvorgangs, der Puffer-Garbage-Collection (etwas, das MSE automatisch im Hintergrund durchführt) und Quellen, die natürlich Lücken verursachen, kombiniert. Letztendlich bedeutete dies, dass unser Algorithmus untrennbar mit dem sich ständig ändernden Puffer von MSE verbunden war.
Der neue Fetcher hebt diese und viele andere Annahmen auf, um die Dinge so weit wie möglich zu vereinfachen. Zum Beispiel bereinigt der Player jetzt den Puffer nach jeder Suche, so dass der Zustand des Puffers einfacher zu verstehen ist und nicht versucht, ein Segment zu laden, das bereits im Puffer vorhanden ist.
EINEN SCHRITT WEITERGEHEN
Nachdem wir unsere Annahmen überprüft hatten, stellten wir fest, dass es unmöglich ist, zu 100 % genau zu raten, aber es ist durchaus möglich, zu 100 % konservativ zu raten. Eine konservative Schätzung ist eine Schätzung, die das Segment am oder vor dem gewünschten Segment ist. Eine konservative Schätzung bedeutet, dass Sie immer das richtige Segment finden können, indem Sie einfach durch die Segmente in einer Wiedergabeliste vorwärts gehen.
Mit dieser Erkenntnis ändert sich die Art des Problems drastisch. Jetzt holen wir immer zusammenhängende Regionen, nachdem wir eine erste Schätzung vorgenommen haben. Das bedeutet, dass Details über den Zustand des Puffers - Lücken - für uns nicht mehr von Belang sind, da sie per Definition den Medien eigen sind und nicht auf das Verhalten des Abrufalgorithmus zurückzuführen sind.
Die einzige verbleibende Frage war, wie wir Segmente und Zeiten zwischen Varianten in einer Live-Wiedergabeliste korrelieren können. Zu diesem Zweck führen wir das Konzept des "Sync-Points" ein. Ein Sync-Point ist definiert als eine bekannte Zuordnung zwischen einem Segmentindex und einer Anzeigezeit - der Zeit, die man durch den Aufruf von player.currentTime().
Der neue Abrufalgorithmus hat nur drei Betriebsmodi:
- Vorsichtiges Schätzen, in welchem Segment das Herunterladen beginnen soll
- Einfach vorwärts durch die Wiedergabeliste gehen
- Versuch, einen Sync-Punkt zu erstellen
Dieser letzte Zustand wird nur dann erreicht, wenn der Fetcher keine der gespeicherten Informationen verwenden kann, um eine Vermutung anzustellen. Es ist ein seltenes Ereignis, aber wenn das passiert, müssen wir ein Segment herunterladen - irgendein Segment - und die internen Zeitstempel in den Medien nutzen, um einen "Sync-Punkt" zu erzeugen, den der Abrufalgorithmus dann nutzen kann, um eine vorsichtige Schätzung vorzunehmen, bevor er weitergeht.
Das Endergebnis dieser Änderungen ist ein verbessertes HLS-Wiedergabeerlebnis. Insbesondere die Live-Wiedergabe sollte schneller starten und zuverlässiger ablaufen.
