Oh, ich habe eine Verspätung. Teil 2

    In einem früheren Artikel haben wir über die Reduzierung der Verzögerung beim Senden von Videos gesprochen. Wir haben den Versand erledigt, jetzt reden wir über die Lieferung.



    Der Kunde hat Orte, an denen sich das Video ansammeln und der Echtzeit nacheilen kann:

    • Eingangsnetzwerkpuffer;
    • interner Transportsynchronisationspuffer;
    • Protokollpuffer zum Ausgleichen von Netzwerkgeschwindigkeitsschwankungen;
    • Spielerpuffer;
    • Puffer des Decoders (Grafikkarte);
    • Hardware-Verzögerungen.

    Und das sind wieder Puffer, Puffer und wieder Puffer. Gehen wir in Ordnung.


    (Röhrchenpuffer)

    Netzwerkpuffer eingeben


    Der Client empfängt Daten über einen Netzwerksocket. IP-Sockets verfügen über Puffer, die sich füllen können, wenn der Empfang von Benutzerprogrammdaten nicht schnell genug ist.

    Wenn der Puffer zu klein ist, wird die Videoübertragung ständig unterbrochen, und wenn er zu groß ist, muss der Benutzer warten, bis der Puffer länger als die erforderliche Zeit gefüllt ist, die durch die Datenübertragungsrate bestimmt wird. Im schlimmsten Fall, wenn der Puffer weniger als Megabyte beträgt, können bis zu 4-8 Sekunden Video in den Puffer geladen werden.

    Wenn der Puffer voll ist, kann die Echtzeit entweder durch schnelles Weiterleiten oder durch Löschen eines Teils der Daten wiederhergestellt werden. Tatsächlich passiert dies so gut wie nie, da die Entwickler der Player diese Funktionalität für zukünftige Versionen aufschieben.

    Unter dem Gesichtspunkt der Nähe zur Echtzeit ist ein großer Netzwerkpuffer böse. Unter dem Gesichtspunkt einer reibungslosen Wiedergabe des Fernsehkanals ist dies eine durchaus vernünftige Sache, da der Kernel schnell und gut genug arbeitet, um seine Puffer zu füllen.

    Es ist schwierig, den Zustand des Puffers auf dem Client zu überprüfen, da Sie unter Linux das Dienstprogramm ss ausführen könnten. Das Herausfinden dieser Informationen unter Android oder Windows ist jedoch schwieriger.

    Interner Demuxer Sync Buffer


    In verschiedenen Protokollen ziehen sie sich gerne auf unterschiedliche Weise in Richtung Audio und Video auseinander. Zum Beispiel ist es in MPEG-TS üblich, 3-5 Audio-Frames hintereinander zu nehmen und in ein Paket zu packen, um den Datenverkehr zu reduzieren. Gleichzeitig wird der Frame-Stream von "VAVAAVAVAA" zu "VVAAAAAVVAAAAVAAAVVVAAA".

    Die Zeitstempel werden gleichzeitig gemischt. Wenn Sie sie weiter sortieren möchten (dies ist beispielsweise für das Hochladen in RTMP von entscheidender Bedeutung), müssen Sie einen Puffer starten, der die Frames verlangsamt. Besonders tolles Verhalten eines solchen Puffers tritt auf, wenn der Ton ganz oder auf einem der fünf Kanäle verschwindet.

    Es ist praktisch unmöglich, den Gesamtverlust von einer sehr großen Verzögerung im allgemeinen Fall zu unterscheiden. Daher müssen Sie im Entwicklungsprozess Code schreiben, der „fühlen“ soll, was dort passiert ist.

    Netzwerk-Geschwindigkeitskompensationspuffer


    Hier werden wir über den Puffer sprechen, den wir in HLS haben, oder über den Puffer, der im RTMP-Player gesteuert wurde.

    Ein HLS-Player ist beispielsweise folgendermaßen angeordnet:

    • Der Player lädt drei Segmente herunter.
    • Nach dem Herunterladen des dritten beginnt der Player mit der Wiedergabe des Streams, beginnend mit dem ersten.
    • Ein Prozess nimmt unabhängig das älteste Segment und der andere tauscht das erste aus.

    Im Idealfall werden 2-3 Segmente im Puffer unterstützt, die möglicherweise verschwinden, wenn die Netzwerkgeschwindigkeit zu sinken beginnt.

    In jedem Player ist ein Puffer zum Ausgleich von Netzwerkgeschwindigkeitsschwankungen integriert. Zum Beispiel ist dieser Puffer in RTMP theoretisch 0, in HLS theoretisch 10 Sekunden, in RTSP-Playern normalerweise 0 und in SIP genau 0.

    Wir sagen „theoretisch“, weil die Grenzparameter leer sind wird funktionieren. Beispielsweise können HLS-Player mit 1-Sekunden-Fragmenten extrem instabil werden. Und dies kann auf alltägliche Fehler zurückzuführen sein, z. B., dass die Dauer eines Segments nicht in Millisekunden, sondern in Sekunden angegeben wird.

    Und der RTMP-Flash-Player auf dem Zero Buffer verhält sich einfach „herrlich“ - er beginnt eine Verzögerung von einer Sekunde pro Minute anzusammeln und kann nach ein paar Stunden in schrecklicher Qual sterben.

    Spielerpuffer


    Der Wiedergabemechanismus ist fast immer von dem Mechanismus getrennt, der Videos mithilfe eines beliebigen Protokolls herunterlädt. Frames werden entpackt, von Metadaten getrennt und auf den Player übertragen. Dann beginnt das „Merkwürdige“: Flash und der MSE-Player benötigen möglicherweise mehr als ein Bild, um die Wiedergabe zu starten.

    In diesem Fall beginnen Sie erneut zu verzögern und zu verzögern. Hier liegen die Zahlen in der Größenordnung von 2-5 Rahmen, d.h. bis zu 200 ms.

    Decoderpuffer


    Ein guter Echtzeit-Decoder decodiert den empfangenen Stream sofort und gibt ihn weiter. Die Zugriffsblöcke gelangen kontinuierlich in den Puffer, und die Pufferfüllrate ist proportional zur Geschwindigkeit des codierten Datenstroms. Zugriffsblöcke werden zu unterschiedlichen Zeiten in den Puffer geladen, da codierte Bilder unterschiedliche Datenmengen aufweisen. Die Daten werden in gleichen Intervallen, die der Bildrate des wiedergegebenen Bildes entsprechen, aus dem Puffer heruntergeladen und sofort und vollständig entladen. Wenn beispielsweise die Startverzögerung eines neuen Streams viel größer ist als die Endverzögerung des alten Streams, dauert es nach der Wiedergabe des letzten Bildes des alten Streams und dem Entladen aus dem Puffer lange, das erste Bild des neuen Streams zu dekodieren und abzuspielen. Dies führt zum Beispiel dazu, dass das letzte Bild des alten Stroms eingefroren und merklich verklebt wird.



    Wenn Sie B-Frames in die Codierung des Echtzeit-Streams einbezogen haben, was an sich schon ein wunderbares Unterfangen ist, erhalten Sie sofort eine Verzögerung in Höhe von N * T am Ausgang, wobei:

    • N - maximaler Rahmenpermutationsabstand, normalerweise ungefähr 4
    • T - Frame Dauer. Für 25 fps sind dies 40 ms.

    Aus heiterem Himmel erhalten wir also eine Verzögerung von mindestens 160 ms.

    In der Realität verlangsamt der Decodierer möglicherweise noch ein oder zwei Frames oder verfügt einfach nicht über eine gute Ereignis-API für die rechtzeitige Benachrichtigung über die Frame-Bereitschaft.

    Hardware-Verzögerungen auf dem letzten Meter der Videobereitstellung


    Ein riesiger decodierter Frame muss angezeigt werden. Wenn Sie nicht auf der Grafikkarte, sondern auf dem Prozessor decodiert haben, müssen Sie sie zur Anzeige in den Grafikspeicher kopieren. Dies dauert einige Zeit. Grafikkarten können auch Millisekunden hinzufügen, aber im Vergleich zu Tausenden von Millisekunden in früheren Fällen ist hier normalerweise nicht alles so beängstigend.

    Total


    Nachdem Sie alle Arten von Verzögerungen bei der Lieferung und beim Empfang von Videos behoben haben, können Sie mit der Messung beginnen. Im nächsten Artikel werden wir erklären, wie dies getan werden kann.

    Jetzt auch beliebt: