In den letzten Jahren hat die Videostreaming-Branche ein großes Interesse an Protokollen für das Videostreaming mit geringer Latenzzeit gezeigt. Das Hauptaugenmerk liegt dabei auf der Bereitstellung von Videos mit einer Verzögerung von weniger als fünf Sekunden, so dass sie mit den Verzögerungen in Live-Fernsehsystemen vergleichbar sind. Eine solch geringe Verzögerung ist entscheidend für das Streaming von Live-Sport, Spielen, Online-Lernen, interaktiven Videoanwendungen und anderen.
ENTWICKLUNG DER TECHNOLOGIE FÜR STREAMING MIT NIEDRIGER LATENZZEIT
Die Verzögerungen bei herkömmlichen OTT-Live-Streaming-Technologien wie HLS und DASH sind viel länger. Sie werden durch relativ lange Segmente (4-10 Sekunden) und ein segmentbasiertes Bereitstellungsmodell verursacht, das die vollständige Bereitstellung jedes Mediensegments vor der Wiedergabe erfordert. In Kombination mit den von den HLS- oder DASH-Streaming-Clients verwendeten Pufferungsstrategien führt dies in der Regel zu Verzögerungen von 10-30 Sekunden oder sogar noch länger.
Um Verzögerungen zu vermeiden, haben die jüngsten Entwicklungen der HLS- und DASH-Standards, die als Low-Latency HLS (LL-HLS) und Low-Latency DASH (LL-DASH) bekannt sind, zwei wichtige Tools eingeführt:
- Chunked Video Encoding. Dabei handelt es sich um eine Kodierungsstrategie, die Videosegmente erzeugt, die als Sequenzen viel kürzerer Teilsegmente oder Chunks strukturiert sind.
- Übertragung von Chunked-Segmenten. Dies ist ein HTTP-Übertragungsmodus, der die Übertragung kürzerer Videoblöcke an Streaming-Clients ermöglicht, sobald diese generiert werden.
Ein Streaming-Client kann einem Live-Stream mit niedriger Latenz von einem beliebigen Stream Access Point (SAP) beitreten, der vom Live-Transcoder an Segment- oder Chunk-Grenzen zur Verfügung gestellt wird. Nach dem Beitritt muss ein Player nur noch den letzten vom Encoder generierten Videochunk zwischenspeichern, bevor er ihn dekodiert und rendert. In Anbetracht der Tatsache, dass jedes Segment in mehrere Chunks (in der Regel 4-10) aufgeteilt werden kann, wird die Verzögerung dadurch erheblich verringert.
Derzeit sind mehrere Open-Source- und proprietäre Implementierungen von Servern und Playern mit niedriger Latenz auf dem Markt erhältlich, darunter auch eine von Brightcove. Viele von ihnen haben eine geringere Streaming-Verzögerung nachgewiesen, wenn nur ein Stream mit einer einzigen Bitrate verwendet wird und wenn sie über Hochgeschwindigkeitsnetzverbindungen streamen. Ihre Leistung in komplexeren und realistischeren Einsatzumgebungen ist jedoch noch nicht ausreichend untersucht worden.
PRÜFUNG DER LEISTUNG VON STREAMING MIT NIEDRIGER LATENZZEIT
In unserem in der ACM Mile-High-Video 2023 veröffentlichten Artikel (Link in Kürze) sowie in einer Präsentation bei Facebook@Scale haben wir einige Ergebnisse nach dem Testen der Leistung von Videosystemen mit niedriger Latenzzeit veröffentlicht.
Zunächst haben wir eine Testumgebung für LL-HLS- und LL-DASH-Systeme entwickelt. Anschließend haben wir verschiedene Player mit niedriger Latenz unter Verwendung dieses Testbeds bewertet, darunter Dash.js, HLS.js, Shaka player und Theo player. Außerdem haben wir mehrere der neuesten Algorithmen zur Bitratenanpassung mit Optimierungen für Live-Player mit niedriger Latenzzeit bewertet. Die Bewertung basierte auf einer Reihe von Live-Streaming-Experimenten. Diese Experimente wurden mit identischen Videoinhalten, Codierungsprofilen und Netzwerkbedingungen (emuliert durch die Verwendung von Spuren realer Netzwerke) wiederholt.
Tabelle 1 zeigt unsere Live-Video-Codierungsprofile für die Erzeugung des DASH/HLS-Streams mit mehreren Bitraten und niedriger Latenz.
| Wiedergabe | Videoauflösung (Pixel) | Videocodec und Profil | Bitrate (kbps) |
|---|---|---|---|
| niedrig | 768 x 432 | H.264 Haupt | 949 |
| Mitte | 1024 x 576 | H.264 Haupt | 1854 |
| hoch | 1600 x 900 | H.264 Haupt | 3624 |
| top | 1920 x 1080 | H.264 Haupt | 5166 |
Tabelle 1. Live-Video-Codierungsprofile
Abbildung 1 zeigt die Arbeitsabläufe unserer DASH- und HLS-Streaming-Testumgebungen mit niedriger Latenz.
Abbildung 1. Systemaufbau für die Bewertung von Playern mit niedriger Latenz.
Abbildung 2 zeigt die verfügbare Netzwerkbandbreite unseres emulierten LTE-Mobilfunknetzes. Die Download-Bandbreite der Low-Latency-Player wird durch unser Netzwerkemulations-Tool und die Netzwerk-Traces gesteuert.
Abbildung 2. Verfügbare Bandbreite der emulierten LTE-Mobilfunknetze (Verizon und T-Mobile)
In unseren Experimenten wurden eine Reihe von Systemleistungskennzahlen (durchschnittliche Stream-Bitrate, Menge der heruntergeladenen Mediendaten, Streaming-Latenz) sowie Pufferungs- und Stream-Switching-Statistiken erfasst und berichtet.
Diese Ergebnisse wurden anschließend verwendet, um die beobachteten Unterschiede in der Leistung von LL-HLS- und LL-DASH-Playern und -Systemen zu beschreiben.
Einige Diagramme aus unserer Studie sind in den folgenden Abbildungen zu sehen.
Abbildung 3. Dynamik der von LL-HLS- und LL-DASH-Playern gemeldeten Bitratenwechsel.
Abbildung 4. Vergleich der von LL-HLS- und LL-DASH-Playern gemeldeten Latenzschwankungen.
Leistungsstatistiken - T-Mobile LTE-Netz
| Spieler/Algorithmus | Durchschnittliche Bitrate [kbps] | Durchschnittliche Höhe [Pixel] | Durchschnittliche Latenzzeit [Sek] | Latenzzeit var. [Sek.] | Geschwindigkeit variabel [%] | Anzahl der Schalter | Ereignisse puffern | Pufferverhältnis [%] | MBs geladen | Geladene Objekte |
|---|---|---|---|---|---|---|---|---|---|---|
| DASH.js Standard | 2770 | 726 | 3.06 | 0.21 | 10.4 | 93 | 38 | 7.99 | 352.2 | 256 |
| DASH.js LolP | 3496 | 853 | 5.65 | 4.59 | 22.7 | 70 | 53 | 21.96 | 369.4 | 210 |
| DASH.js L2all | 3699 | 908 | 4.14 | 3.18 | 19.9 | 5 | 19 | 7.99 | 368 | 147 |
| Shaka Spieler (Bindestrich) | 3818 | 916 | 4.92 | 2.06 | 0 | 16 | 5 | 4.66 | 360.3 | 155 |
| THEO-Spieler (Bindestrich) | 4594 | 993 | 6.16 | 0.01 | 0 | 27 | 0 | 0 | 418.7 | 152 |
| HLS.js Standard 2020 | 1763 | 562 | 10.08 | 10.91 | 8.1 | 26 | 2 | 9.8 | 130.7 | 589 |
| HLS.js LolP 2020 | 1756 | 560 | 5.97 | 0.2 | 6.1 | 24 | 0 | 0 | 148.1 | 688 |
| HLS.js L2all 2020 | 1752 | 560 | 6 | 0.23 | 5.9 | 34 | 0 | 0 | 133.1 | 686 |
| HLS.js Standard 2023 | 3971 | 895 | 8.93 | 1.13 | 0 | 8 | 0 | 0 | 360.8 | 613 |
| Shaka Spieler (HLS) | 3955 | 908 | 7.18 | 2.23 | 0 | 14 | 7 | 3.8 | 230 | 475 |
Tabelle 2. Leistungsstatistiken - T-Mobile LTE-Netz
BEWERTUNG DER LEISTUNG VON STREAMING MIT NIEDRIGER LATENZZEIT
Während LL-HLS und LL-DASH in uneingeschränkten Netzwerkumgebungen gut funktionierten, hatten sie in Netzwerken mit geringer Bandbreite oder stark schwankenden Bandbreiten (typisch für mobile Einsätze) Probleme. Zu den beobachteten Effekten gehörten stark schwankende Verzögerungen, die Unfähigkeit, Pufferung zu verhindern, häufige Bandbreitenwechsel oder die Unfähigkeit, die verfügbare Netzwerkbandbreite zu nutzen. Einige Akteure wechselten unter diesen schwierigen Netzwerkbedingungen einfach zum Streaming ohne niedrige Latenzzeiten.
So vielversprechend LL-HLS oder LL-DASH in der Theorie auch sein mögen, diese Technologien müssen noch ausreifen.
Bei Brightcove arbeiten wir weiterhin an erstklassigen Implementierungen von Algorithmen für Streaming-Clients mit niedriger Latenz sowie an Encoder- und serverseitigen Optimierungen. Wir beabsichtigen, unsere Unterstützung für Streaming mit niedriger Latenz hochgradig skalierbar und zuverlässig zu machen und für die erste Zeit bereit zu sein.
Dieser Blog wurde ursprünglich von Yuriy Reznik im Jahr 2021 verfasst und wurde nun aktualisiert, um ihn zu aktualisieren und zu vervollständigen.
