Multimedia-Streaming – Die Kunst der Balance zwischen hoher Qualität, niedriger Latenz und großer Teilnehmerzahl
Zusammenfassung: Das Ziel beim Multimedia-Streaming ist es, mitunter umfangreiche Datenmengen an möglichst viele Teilnehmer in beinahe Echtzeit zu übertragen. Als größte Hürde stellt sich dabei die Latenz heraus. Je niedriger sie ist, desto angenehmer fällt für die Zuschauer das Erlebnis aus. Sie summiert sich aber sehr schnell aufgrund vieler kleinerer Verzögerungen. Deshalb gilt es, zwischen Qualität, Teilnehmerzahl und Latenz die richtige Balance zu finden.
Seit vielen Jahren verbinden sich Computerspieler über das Internet, um gemeinsam ihrer Spieleleidenschaft nachzugehen. Dabei nehmen sie gemeinsam an Massively Multiplayer Online Games teil, unterhalten sich in Echtzeit über Discord [1] und senden in einigen Fällen ihre Spielsitzungen in hoher Videoqualität (Auflösung 1080p/Full-HD, 60 Frames-Per-Second/FPS) an tausende von fremden Zuschauern als Twitch Streams [2] oder YouTube Live Events [3]. Aber wieso findet dabei die Kommunikation mit den Zuschauern immer nur verzögert mit Chat-Nachrichten statt?
Seit der Pandemie machen wir auf der anderen Seite exzessiv Gebrauch von Zoom Meetings [4], Microsoft Teams Meetings [5] und ähnlichen Onlinekonferenzlösungen. Angenehm sind diese Besprechungen dann, wenn die Verzögerung (Latenz) gering ausfällt, also meist unter einer Sekunde bei der sprachlichen Interaktion bleibt. Man kann sich fast ins Wort fallen.
Auch die Bildqualität soll möglichst gut sein. Die beste 4K-Webcam nützt jedoch überhaupt nichts, wenn das eigene Bild bei mehr als 2 Teilnehmern in einer Onlinekonferenz von den Lösungen nur in niedriger Auflösung von 480p übertragen wird. Gibt man dagegen statt der Webcam seinen Bildschirm frei, erzielt man durchaus höhere Auflösungen von mindestens 1080p. Die Bildrate des Videos sinkt dann aber wiederum auf abschreckende 5–10 Bilder pro Sekunde.
Erhöht sich in Onlinekonferenzen dann noch die Teilnehmerzahl auf über 6–10 Personen, werden die Videos nur noch teilweise dargestellt. Mehr als 10 Personen dürfen ohnehin bei fast keiner Lösung aktiv präsentieren, sondern nur konsumieren. Und selbst 250–500 lediglich konsumierende Teilnehmer gelten weitläufig als Obergrenze.
Aber wieso können dann bei Twitch Streams und YouTube Live Events viele tausende Zuschauer teilnehmen? Kann man denn heutzutage nicht gleichzeitig eine hohe Qualität, eine niedrige Latenz und eine große Teilnehmerzahl (vergleiche Abb. 1) beim Multimedia-Streaming erreichen?
Abb. 1
Wie funktioniert Multimedia-Streaming?
Beim Multimedia-Streaming wird eine Kombination aus Video und Audio kontinuierlich von einem Sender zu einem oder mehreren Empfängern über ein Computernetzwerk übertragen (vergleiche Abb. 2). Die Empfänger verarbeiten den Video-Audio-Stream zwar mit einer gewissen Latenz weiter, müssen aber insbesondere nicht erst auf das Ende der Übertragung warten.
Dies bedeutet, dass beispielsweise ein 2 Stunden langer Film bereits nach nur 2–4 Sekunden abgespielt werden kann – vorausgesetzt, die weitere Übertragung des Films als Multimedia-Stream kann schneller erfolgen, als das Abspielen des Films in Echtzeit benötigt. Dies ist aber selbst bei schwächeren Internetzugängen mit nur 8 –16 Mbit/s Downstream immer noch der Fall.
Um dieses Verfahren zu realisieren, wird ein Multimedia-Stream üblicherweise aus 3 Komponenten aufgebaut: einem Video-Stream, basierend auf einem komprimierenden Video-Codec wie AVC/H.264 [6], VP9 [7] oder HEVC/H.265 [8], einem Audio-Stream, basierend auf einem komprimierenden Audio-Codec wie AAC [9] oder Opus [10], und einem segmentierten Container-Format, wie Matroska [11], MPEG‑4 [12] oder MPEG-TS [13], um den Video- und Audio-Stream als verschränkte Datensegmente zu übertragen.
Die Eingabe für den Video-Stream sind Einzelbilder einer spezifischen Auflösung (Breite × Höhe), einer Farbinformation (Farbkanäle RGB plus Alpha-Kanal) und einer Bildrate (Frames-per-Second, FPS). Die Eingabe für den Audio-Stream sind üblicherweise zeit- und wertdiskrete digitale Daten, die über ein Pulsmodulationsverfahren aus den zeit- und wertkontinuierlichen analogen Tonsignalen abgetastet wurden. Aus diesen Eingabeparametern ergibt sich die zu übertragende Datenmenge.
Abb. 2
Was bedeutet eine hohe Qualität, niedrige Latenz und große Teilnehmerzahl?
Wann empfindet man einen Multimedia-Stream als hochqualitativ? Üblicherweise, wenn das Video eine hohe Auflösung, eine gute Farbdarstellung und eine hohe Bildrate hat und wenn das Audio ausreichend Lautstärkestufen, eine große Frequenzbandbreite und wenig Störgeräusche besitzt.
In der Praxis bedeutet dies heute in etwa, dass ein Video-Stream einer Webcam mindestens 1080p/720p Auflösung, 32-Bit RGBA-Farbinformation und 24/30 FPS aufweisen sollte. Der Audio-Stream eines Mikrofons muss mindestens eine Lautstärkespanne von −60 bis −3 dB, eine Frequenzbandbreite von 20 Hz/40 Hz bis 10/20 kHz und eine angewandte Rauschunterdrückung liefern.
Was ist eine niedrige Latenz? Allgemein ist Latenz die Verzögerung zwischen Ursache und Wirkung in einem System. Die Latenz zwischen dem Einspeisen des Video- und Audiosignals beim Sender und dem Abspielen beim Empfänger sollte laut [17] höchstens 200–300 ms betragen. Nur dann fallen sich die Personen eines Gesprächs nicht gegenseitig ins Wort und empfinden die Kommunikation als natürlich.
Es gibt aber noch eine zweite Zeitverzögerung, die beim Multimedia-Streaming zu beachten ist: der zeitliche Versatz zwischen Audio und Video [14], gerne als Lippensynchronität bezeichnet. Zuschauer empfinden bereits bei einem Versatz von etwa +45 ms (Audio schneller als Video) respektive −120 ms (Audio langsamer als Video) als störend und asynchron. Von [15] wird sogar nur zu +40 ms und −60 ms geraten, beim Film wird heute üblicherweise sogar ±22 ms gefordert [16], damit keinerlei Irritationen beim Zuschauer entstehen und die Wiedergabe als lippensynchron wahrgenommen wird.
Und was bedeutet nun eine große Teilnehmerzahl? In der Praxis haben wir es beim Multimedia-Streaming üblicherweise mit den folgenden 3 Kommunikationsvarianten zu tun: der Paarkommunikation mit nur 2 aktiven Teilnehmern, der Gruppenkommunikation mit bis zu 10 aktiven und etwa 250–500 passiven Teilnehmern sowie der Massenkommunikation mit bis zu 10 aktiven und weit über 500 passiven Teilnehmern. Diese Größen gelten in der Praxis üblicherweise als große Teilnehmerzahl bei der jeweiligen Kommunikationsvariante.
Was behindert die gleichzeitige hohe Qualität, niedrige Latenz und große Teilnehmerzahl?
Ein 1080p30-RGBA-Video-Stream (1920 Pixel × 1080 Pixel × 4 Bit Farbtiefe × 30 Bilder pro Sekunde) entspricht unkomprimiert einer Datenmenge von 237 MB/s bzw. 1800 Mbit/s. Das übertrifft selbst die Bandbreite von privaten Gigabit-Kabel-Internet-Zugängen fast um das Doppelte. Diese Datenmenge muss einerseits über den Internetanschluss des Senders als auch der Empfänger übertragen werden. Eine starke Datenkompression ist also unumgänglich, um das zu erreichen.
Dazu wird ein sogenannter Video-Codec verwendet, der eine verlustbehaftete Kompression nutzt, um die zu übertragende Datenmenge zu reduzieren. Im Falle des populären und verbreiteten Video-Codec AVC/H.264 liegt die Kompressionsrate in der Praxis bei etwa 100:1 bis 400:1 – primär ist sie davon abhängig, wie viel Bewegung in dem Video stattfindet [18]. Der modernere Video-Codec HEVC/H.265 benötigt sogar nur etwa 50 % der Übertragungsrate von AVC/H.264 [19] und verbessert somit dieses Ergebnis nochmals zu einer praktischen Kompressionsrate von 200:1 bis 800:1.
Diese starken Kompressionsraten werden, neben der Tatsache der Verlustbehaftung des Verfahrens, allerdings dadurch erzielt, dass nicht alle Bilder des Videos vollständig übertragen werden. Stattdessen werden zwischen den jeweiligen Vollbildern (Key-Frames) nur Vorwärts- und Rückwärts-Differenz-Bildbereiche übertragen. Der Nachteil dieses Verfahrens ist somit, dass beim Sender und beim Empfänger ein Buffering zwischen den Key-Frames notwendig wird und der Empfänger beim Quereinstieg in einen Multimedia-Stream bei der Wiedergabe des Videos bis zum nächsten Key-Frame warten muss. Da bei AVC/H.264 in der Praxis üblicherweise nur alle 0,2–2,0 s ein Key-Frame übertragen wird, erzeugt dieses Vorgehen eine spürbare Latenz.
Außerdem ist die Laufzeit zur Kompression eines Video-Frames abhängig von der Auflösung und der Farbtiefe des Video-Streams. Für einen 1080p60-Video-Stream (Full-HD) muss beispielsweise innerhalb von 16 ms (1000/60) bereits eine Datenmenge von knapp 8 MByte (1920 Pixel × 1080 Pixel × 4 Bit) vom Video-Codec verarbeitet werden. Dies ist auf den meisten Rechnern, auch ohne eine unterstützende Graphics Processing Unit (GPU), noch realisierbar, solange man keine zu große Kompressionsleistung fordert. Ein 2160p60-Video-Stream (4K UHD) setzt dagegen innerhalb der 16 ms bereits die Kompression von knapp 32 MByte (3840 Pixel × 2160 Pixel × 4 Bit) an Daten voraus, was ohne GPU-Unterstützung für viele Rechner ein Problem darstellt. Deshalb wird auch nie mehr als 60 FPS übertragen, selbst wenn der Sender mehr FPS lokal anzeigen lässt, da dies die zur Verfügung stehende Zeit für das Encoding noch weiter reduzieren würde. Die reine Rechenleistung auf der Senderseite limitiert somit die maximale Qualität des Video-Streams ebenfalls.
Das Encoding des Multimedia-Streams auf der Senderseite dauert, abhängig vom konkreten Video-Codec, dessen Qualitätsparameter und der Performance der unterliegenden CPU/GPU, etwa 2–20 ms, das Decoding auf Empfängerseite etwa 1–5 ms. Beides erhöht ebenfalls die Latenz.
Für den Audio-Stream wird ein Audio-Codec verwendet, der, ähnlich wie der Video-Codec, üblicherweise verlustbehaftet ist. Die populärsten Audio-Codecs sind AAC und Opus. Auch hier tritt aufgrund des Audio-Samplings über ein Buffering bereits eine geringe Latenz auf. Der Hauptgrund für eine oft hohe Latenz der Audio-Streams ist allerdings dem Umstand geschuldet, dass sich die Tonspur so gut wie nie ungefiltert nutzen lässt. Ein hochwertiges Mikrofon ist so sensibel, dass es jeden PC-Lüfter, jedes auf der Straße vorbeifahrende Auto und jeden bellenden Nachbarshund gut hörbar mit aufnimmt.
Um einen qualitativ hochwertigen Ton zu erhalten, muss in der Praxis deshalb auf der Senderseite so gut wie immer eine Kette von sogenannten Audio-Filtern zwischengeschaltet sein: ein Noise Suppressor für eine Rauschunterdrückung, ein Noise Gate zum Stummschalten unterhalb einer bestimmten dB-Grenze, ein Compressor für das Anheben leiser Töne und das weiche Herunterdrücken von zu lauten Tönen, und ein Limiter für das harte Herunterdrücken von Tönen kurz unterhalb von 0 dB, um ein sogenanntes Audio-Clipping zu vermeiden. Diese Filter benötigen für ihre Arbeit ebenfalls ein eigenes Buffering, was in der Praxis für diese Kette von Audio-Filtern eine weitere Gesamtlatenz von sogar bis zu 100 ms erzeugen kann. Um die Lippensynchronität nicht zu gefährden, müssen der Video-Stream und der Audio-Stream zusätzlich aufeinander warten, was wiederum weitere Latenz erzeugt.
Dann müssen Video- und Audio-Stream zeitgleich übertragen werden. Dazu werden beide in Segmente aufgeteilt und die Segmente in einem Containerformat, wie Matroska, MPEG‑4 oder MPEG-TS, verschränkt als Multimedia-Stream übertragen. Die dazu notwendigen Muxer- und Demuxer-Komponenten benötigen für ihre Arbeit ebenfalls eigene Buffer und diese erzeugen abermals eine zusätzliche Latenz.
Zu guter Letzt folgt die Übermittlung des gesamten Streams noch über das Internet vom Sender zum Empfänger. Selbst wenn für eine Paarkommunikation über ein Peer-to-Peer-basiertes Netzwerkprotokoll wie WebRTC [20] der direkte Weg gewählt wird, besitzt die reine Paketübertragung eine übliche Latenz von 15–30 ms.
Da bei einer Gruppenkommunikation ein Peer-to-Peer-Verfahren wie WebRTC allerdings nicht sinnvoll ist und man zusätzlich die üblichen netztopologischen Einschränkungen durch Network Address Translation und Firewalling gerne vermeiden möchte, wird hier von den meisten Lösungen ein sogenannter Relay-Service in der Cloud als Zwischenstation verwendet. Der Multimedia-Stream gelangt also zuerst vom Sender zum Relay und dann vom Relay zu allen Empfängern. Dadurch entsteht in Summe eine Latenz im Bereich von 30–60 ms.
Der Einsatz eines Relay-Service stellt in der Praxis außerdem einen Engpass dar. Die Übertragung eines 2160p60-Video-Streams benötigt pro Empfänger in der Praxis mindestens 25 Mbit/s. In der Praxis übliche Relay-Services auf einem Rechner in einem Datacenter weisen aber nur maximal eine Anbindung von 10 Gbit/s auf. Rein rechnerisch lassen sich so nur rund 400 Empfänger versorgen. Für eine höhere Anzahl an Empfängern muss der Relay-Service bereits als performanter Cluster ausgelegt sein, was bei hoher Teilnehmerzahl auch relativ hohe Kosten nach sich zieht.
Um Netzwerkbandbreite zu sparen und insbesondere die Empfängeranforderungen zu entlasten, bietet es sich an, auf dem Relay-Service den Multimedia-Stream adaptiv auf verschiedene niedrigere Qualitätsstufen zu konvertieren. Leider hat dies zur Folge, dass der Relay-Service ein sehr rechenintensiver Service wird und somit die Kosten für die Hardware erneut stark ansteigen.
Das Resultat: In der Praxis summieren sich die angesprochenen Latenzen im Idealfall schnell auf mindestens 0,5–1,5 s – üblicherweise aber auf 2,0–4,0 s.
Wie lassen sich diese Herausforderungen meistern?
Da man aufgrund der angesprochenen Latenzen und schnell ansteigenden Kosten für einen adaptiven Relay-Service in der Praxis nur sehr schwer gleichzeitig eine hohe Qualität, eine niedrige Latenz und eine große Teilnehmerzahl erreichen kann, muss man Kompromisse eingehen. Man fängt deshalb bereits bei den Anforderungen an und unterscheidet beim Multimedia-Streaming in der Praxis zunächst zwischen 2 wesentlichen Anwendungsfällen: Beim Conferencing geht es um hohe bidirektionale Interaktion zwischen einer mittleren Anzahl von Teilnehmern, während es beim Broadcasting um das Erreichen vieler tausender Teilnehmer über eine unidirektionale Kommunikation geht.
Beim Conferencing optimiert man deshalb bewusst auf eine niedrige Latenz (unter 1,5 s) zulasten einer niedrigeren Qualität (720p30 und niedriger) und einer geringen Teilnehmerzahl (unter 250–500). Beim Broadcasting optimiert man dagegen die hohe Qualität (1080p30 und höher) und die hohe Teilnehmerzahl (über 250–500 bzw. bis weit über 10.000) zulasten einer hohen Latenz (über 4 s).
Zusätzlich kann man für beide Anwendungsfälle die große Problematik der Latenz versuchen, etwas zu reduzieren. Moderne Übertragungsprotokolle für Multimedia-Streams wie WebRTC weisen per se eine geringe Latenz auf, sind aber inhärent problematisch bei vielen Teilnehmern. Neuere Übertragungsprotokolle wie SRT [21] und RIST [22] kommen sogar mit zwischengeschalteten Relay-Services schon recht nahe an die niedrige Latenz von WebRTC heran und erlauben somit auch höhere Teilnehmerzahlen.
Zusätzlich nutzen viele Anbieter ihre Relay-Services, um wie bei Teams alle eingehenden Audio-Streams bereits in der Cloud – und nicht erst beim Empfänger – zu mischen. Auch adaptives Verhalten der Sender- und Empfängerseite etabliert sich: beispielsweise wird nur der Sprecher im Fokus höher aufgelöst vom Sender übertragen und nur ein geringer Teil der Teilnehmervideos wird überhaupt übertragen und beim Empfänger angezeigt.
Credo
Beim populären Multimedia-Streaming kann man auch heute aufgrund der vielen technischen Herausforderungen und den verbundenen Kosten nur sehr schwer gleichzeitig eine hohe Qualität, eine niedrige Latenz und eine große Teilnehmerzahl erreichen. Hier ist in der Praxis immer eine Balance gefragt, bei der man nur eine Dimension optimiert und kompromissbereit notwendige Einbußen bei den anderen akzeptiert.
Deswegen sollte man sich nicht wundern, wenn sich selbst mit aktuellen populären Lösungen wie Teams oder Zoom bei einem Onlinevortrag vor 500 Teilnehmern das eigene 4K-Webcam-Video nicht „einfach mal so“ in Full-HD übertragen lässt. Das ist kein Produkt-Problem – sondern ein Prinzip-Problem!
Literatur
Discord. https://discord.com/. Zugegriffen: 12. Sept. 2021
Twitch: „Twitch Stream“. https://www.twitch.tv/p/en/stream/. Zugegriffen: 12. Sept. 2021
YouTube: „Playbook für digitale Events“. https://bit.ly/3tBoByC. Zugegriffen: 12. Sept. 2021
Zoom: „Zoom Meetings“. https://explore.zoom.us/en/products/meetings/. Zugegriffen: 12. Sept. 2021
Microsoft: „Microsoft Teams“. https://www.microsoft.com/en-us/microsoft-teams/group-chat-software. Zugegriffen: 12. Sept. 2021
Wikipedia: „Advanced Video Coding“. https://en.wikipedia.org/wiki/Advanced_Video_Coding. Zugegriffen: 12. Sept. 2021
Google: „VP9 Bitstream & Decoding Process Specification“. https://bit.ly/3k50dCd. Zugegriffen: 12. Sept. 2021
Rec. ITU-REC‑H.265-202108‑P. https://www.itu.int/rec/T-REC-H.265-202108-P/en. Zugegriffen: 12. Sept. 2021
ISO/IEC 13818-7:2006: „Information technology—Generic coding of moving pictures and associated audio information—Part 7: Advanced Audio Coding (AAC)“, 2006.
Internet Engineering Task Force (IETF) (2012) Request for Comments 6716: „Definition of the Opus Audio Codec“. https://datatracker.ietf.org/doc/html/rfc6716. Zugegriffen: 12. Sept. 2021
Matroska: „Matroska Media Container“. https://www.matroska.org/. Zugegriffen: 12. Sept. 2021
ISO/IEC 14496–14:2018: „Information technology—Coding of audio-visual objects—Part 14: MP4 file format“, 2018.
ISO/IEC 13818–1:2019: „Information technology—Generic coding of moving pictures and associated audio information—Part 1: Systems“, 2019.
Rec. ITU‑R BT.1359–1: „Relative Timing of Sound and Vision for Broadcasting“. https://bit.ly/391WGhK. Zugegriffen: 12. Sept. 2021
EBU Recommendation R37-2007: „The relative timing of the sound and vision components of a television signal“. https://tech.ebu.ch/docs/r/r037.pdf. Zugegriffen: 12. Sept. 2021
(2003) ITU‑T Recommendation G.114: „One-way transmission time“. https://bit.ly/3k2s2ez. Zugegriffen: 12. Sept. 2021
Kush Amerasinghe (Hrsg) (2010) „H.264 For The Rest Of Us“ („H264 Primer“). https://issuu.com/konu/docs/h264_primer. Zugegriffen: 12. Sept. 2021
Ohm R et al (2012) Comparison of the Coding Efficiency of Video Coding Standards—Including High Efficiency Video Coding (HEVC). Ieee Trans Circuits Syst Video Technol 22(12):1669–1684 (https://bit.ly/2XcG6cg, zuletzt aufgerufen am 12.09.2021)
W3C: „WebRTC 1.0: Real-Time Communication Between Browsers“. https://www.w3.org/TR/webrtc/. Zugegriffen: 12. Sept. 2021
Haivision: „SRT Open Source Protocol“. https://www.haivision.com/products/srt-secure-reliable-transport/. Zugegriffen: 12. Sept. 2021
Video Services Forum: „Reliable Internet Stream Transport (RIST)“. https://www.videoservicesforum.org/RIST.shtml. Zugegriffen: 12. Sept. 2021
Autor und Copyright
Ralf S. Engelschall
msg Research, msg systems ag,
Robert-Bürkle-Straße 1, 85737 Ismaning,
© Springer-Verlag Berlin Heidelberg 2021
Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht.