Alles Streaming oder was?

Das Thema „Streaming“ ist nicht neu – jedoch seit der Corona-Krise und dem damit verbundenen Verbot von Großveranstaltungen aktueller denn je. Unser Grundlagenartikel soll einen Überblick über die Anforderungen und Begriffe aus der Welt des Streamings geben und ein Gefühl dafür vermitteln, was in Eigenleistung machbar und ab wann die Hilfe von Fachleuten gefragt ist.

---

Übersicht:

Grundannahmen und sendefähige Signale
On-Demand vs. Live-Streaming

Encoding
Hardware vs. Software Encoding
Vor- und Nachteile von Hardware und Software Encoding

OVP und CDN

Umfeld: rund um den Stream
Was ist noch zu klären?
Ausspielung: Das Erlebnis des Zuschauers

Fazit

WIKI zum Live-Streaming

---

Das Thema Streaming ist alles andere als neu: weder für die Eventbranche, noch für den normalen Internetnutzer. Mit Online-Angeboten wie Twitch, Facebook live und YouTube prägen Livestreams schon seit Jahren das Unterhaltungsprogramm in Wohnzimmern weltweit – Tendenz steigend. Die Vielzahl an Live-Angeboten führte zu einer Selbstverständlichkeit im Umgang mit dem Begriff „Livestream“. Wer ein Handy und einen Facebook Account hat, ist in Sekunden live. Das Live-Video ist nach der Textform mittlerweile die erste Option bei den Facebook-Statusmitteilungen auf dem Handy. Ein Resultat aus dieser breiten Präsenz ist eine Erwartungshaltung bei Endverbrauchern und Kunden, die sich in Sätzen wie „Na dann machen wir das einfach im Stream“ oder auch „Dann müssen wir den Teil einfach online machen, mit Zoom oder so“ widerspiegeln. Doch was bedeutet es eigentlich genau, „live” zu sein? Können Events wirklich einfach so mir-nichts-dir-nichts ins Internet umziehen und alle werden glücklich? Während bei einer Produktvorstellung sehr viele Menschen auf möglichst vielen Kanälen gleichermaßen erreicht wer-den wollen, benötigt eine interne Veranstaltung zur Produktentwicklung einen sicheren, privaten Hafen. Die Tatsache, dass Apple, SpaceX, NASA oder die Regierung Taiwans die Verwendung von Zoom inzwischen untersagen, zeigt, dass man sich nicht bedenkenlos ins Streaming-Getümmel stürzen sollte. Als technische Dienstleister tragen wir eine hohe Verantwortung und müssen richtig beraten können.

Wer sich schon einmal intensiver mit dem Thema auseinander gesetzt hat, weiß, dass es nicht lange dauert, bis einem die ersten Stolperfallen begegnen. Viele Firmen haben sich deshalb lange von dem Thema ferngehalten. Häufig sind es auf Streaming spezialisierte Anbieter, die diesen Part als separate Dienstleistung abdecken. Das hat auch durchaus Sinn. Inzwischen zwingt uns die Coronakrise jedoch, wieder einen genaueren Blick auf das Thema zu werfen.

Wir möchten mit unserem Grundlagenartikel einen Überblick über Anforderungen und Begriffe aus der Welt des Streamings geben. Er soll außerdem ein Gefühl dafür vermitteln, welchen Aufgaben man sich getrost selbst stellen kann und an welchen Punkten eine intensive Recherche oder die Vermittlung an einen Spezialisten nötig wird.

---

Vielleicht auch interessant?

Im Gespräch mit Streaming-Profis: Tipps für ein gelungenes Streaming

---

>> zurück zum Anfang

Grundannahmen und sendefähige Signale

Die erste Frage, die sich stellt, ist, was die Zuschauer überhaupt zu sehen bekommen sollen. Reicht vielleicht schon eine einzelne Kamera, wird es ein Kamera-Mix, oder müssen andere Medien eingebunden werden? Wir gehen in unserer Betrachtung davon aus, dass diese Frage geklärt ist und wir ein Signal generiert haben, welches in die weite Welt getragen werden kann.

Neben den üblichen Verdächtigen wie Kamera, Präsentation und Filmzuspiel gibt es noch streamspezifische Inhalte wie zum Beispiel:

• Bilder und Videos für die Zeit vor und nach dem Stream: Was ist zu sehen, wenn außerhalb der Sendezeit auf den Stream zugegriffen wird?
• Werden Bauchbinden benötigt?
• Benötigt der Stream besondere Pausenfolien?
• Müssen Mittel vorgehalten werden, um jederzeit (dynamische) Texteinblendungen vornehmen zu können?
• Was passiert in stillen Phasen des Streams (beispielsweise bei Arbeitsphasen in Workshops)?
• Gibt es Werbung von Sponsoren zu schalten? Wenn ja, wie soll das aussehen?
• Wird ein Logo oder ein Wasserzeichen eingeblendet?

Auf welche Weise die Signale zu einem sendefähigen Signal zusammengeführt werden, soll nicht Teil unserer Betrachtung sein. Wir werden aber Optionen zur inhaltlichen Bearbeitung ansprechen, die sich im weiteren Verlauf der Streamingkette ergeben. Wir nehmen ebenfalls an, dass keine eigenen Server zur Bereitstellung/Verteilung des Streams zur Verfügung stehen und eine Anmietung von Livestream/CDN-Anbietern (Content Delivery Networks) erforderlich ist, wie YouTube, Facebook Live, Akamai, Wowza usw. Viele Punkte, die für das Thema Onlinestreaming gelten, sind auch für das Streaming in lokalen Netzwerken relevant. Wir legen den Fokus aber auf das Live-Streaming im Internet.

---

On-Demand vs. Live-Streaming

Wenn von Streaming die Rede ist, ist noch nicht klar, ob es sich um eine Live-Wiedergabe oder eine Wiedergabe von auf Servern gespeicherten Medien handelt. Das Prinzip ist allerdings das Gleiche. Ein Merkmal ist die kontinuierliche Übertragung von Video- und/oder Audiodateien von einem Server zu einem Klienten. Dabei werden die Daten in Paketen an den Empfänger gesendet, dort zwischengespeichert, wiedergegeben und anschließend wieder aus dem Zwischenspeicher entfernt.

Aber natürlich gibt es einen großen Unterschied zwischen einer Liveübertragung und einer Wiedergabe bereits gespeicherter Daten – insbesondere, wenn es um die Tragweite von Fehlern geht, die beim Streaming auftreten können. Wenn der Zwischenspeicher (Buffer) nicht so schnell gefüllt wird, wie der Inhalt wiedergegeben werden müsste, kommt es zur Unterbrechung der Wiedergabe und es wird erstmal geladen. Das ist beim Schauen eines Tutorials kein großes Problem. Bei der spannenden Szene im Thriller ist es bereits ärgerlich, aber spätestens beim verpassten Tor im Finale einer Weltmeisterschaft wird laut geflucht.

Eine Wiedergabe von On-Demand-Inhalten zu realisieren ist dabei um einiges einfacher. Die meisten Portale rendern die Videos in einen optimalen Kompromiss aus Qualität und Übertragungsgeschwindigkeit. Die Videos werden automatisch in unterschiedlichen Bitraten und Auflösungen bereitgestellt und ermöglichen Nutzern an nahezu allen Endgeräten eine flüssige Wiedergabe. Beim Live-Streaming müssen wir selbst einen Teil der Optimierungen vornehmen und abwägen, welche Maßnahmen für welches Projekt erforderlich und sinnvoll sind. Unsere Entscheidungen bei der Wahl der Video-Auflösung, des Streaming-Encoders und der Streaming-Plattform nehmen direkten Einfluss auf die Qualität, Erreichbarkeit und letztlich den Erfolg des Livestreams.

---

>> Info: Alle fachspezifischen Begriffen erklären wir nochmal kompakt in unserem WIKI zum Live-Streaming. <<

>> zurück zum Anfang

Encoding

Damit das Videosignal in das Internet eintauchen kann, muss es in einem dafür geeigneten Format codiert werden und mithilfe eines Protokolls in das CDN eingespeist werden. Diese Aufgabe übernehmen Streaming-Encoder. Diese können entweder dedizierte Hardwaregeräte oder Softwarelösungen sein. Der Streaming-Encoder übernimmt beide Aufgaben, also Codierung und Versand des Streams.

Das am meisten verbreitete Streaming-Protokoll zum Einspeisen von Videosignalen ist das Real-Time Messaging Protocol – kurz RTMP. Damit der Stream den richtigen Weg findet, werden folgende Informationen vom CDN bzw. der Online Video Platform (OVP) zur Verfügung gestellt:

• RTMP Server URL
• RTMP Stream Key / Name
• RTMP Login / Nutzer
• RTMP Passwort

Diese werden im Encoder eingetragen. Nicht immer werden Login und Passwort zur Verfügung gestellt, dann bleiben diese Felder im Encoder leer. Welche Einstellungen für die Videocodierung vorgenommen werden müssen, hängt von dem Portal ab, in welchem der Stream eingespeist und verarbeitet wird. Hierzu sprechen die Portale Empfehlungen aus. Die geläufigsten Parameter sind:

Codec
Der aktuelle Streaming-Standard ist H.264, deshalb betrachten wir diesen. Einige Plattformen unterstützen auch H.265/HEVC, VP8 oder VP9, doch noch nicht viele Encoder unterstützen diese Codecs. Im Zusammenhang mit H.264 wird häufig noch das entsprechende Profil (z. B. Base, Main, High) angegeben. Die richtige Wahl korreliert mit den maximalen Auflösungen, Bitraten und Framerates.

Auflösung
Ob nun in UHD oder in 360p gestreamt wird, hängt ganz vom Projekt ab. In vielen Fällen ist ein Stream in 720p oder 1080p ausreichend.

Video-Bitrate
Hier wird meist eine durchschnittliche Bitrate oder ein Bereich, in dem die Bitrate liegen sollte, empfohlen. Für einen Stream in 720p liegen die Empfehlungen zwischen 1.5 Mbps und 4.5 Mbps. Man kann zwar behaupten, dass eine höhere Bitrate eine höhere Videoqualität nach sich zieht, aber je nachdem wie die Online Video Plattform den Stream weiterverarbeitet, kann es auch negative Folgen haben. Wenn unser Encoder eine höhere Qualität bei 3.0 Mbps erzielen kann, als der Live Transcoder der Plattform beim Herunterrechnen von einer zu hohen Bitrate, dann sollten wir unseren Encoder gleich in der richtigen Bitrate senden lassen.

Audio-Bitrate
Die Audio-Bitrate ist separat festzulegen. In der Regel stoßen wir hier nicht an so offensichtliche Störfaktoren wie bei der Video-Bitrate. Auch 128 kbps reichen für Sprache und Auftrittsmusik aus. Bei Musik und Konzerten, lohnt es sich jedoch hier am höheren Ende der Empfehlungen anzusetzen.

Audio-Codec
Selten hat man eine Wahl diesen am Encoder einzustellen. In der Regel wird in AAC codiert. Das verarbeiten auch alle Plattformen.

Audio-Abtastrate
Häufig sind hier 44,1 kHz gewünscht.

Framerate
Beim Einsatz von Kameras sind wir unseren 50-Hz-Standard gewohnt. Und natürlich können wir mit 50 Hz oder mit 25 Hz in das Internet streamen. Das Internet tickt allerdings eher in 60 Hz. Ob nun auf einem Handy, Tablet, Laptop oder Smart-TV geschaut wird – die Geräte laufen auch in Europa normalerweise mit einer Bildwiederholfrequenz von 60 Hz. Zwar werden 30 Hz bei einer Podiumsdiskussion völlig in Ordnung sein, beim rasanten Sport-Event oder Gaming-Content sind jedoch 60 Hz ratsam. Wer kann, bleibt bei einem geraden Teiler von 60 Hz.

Keyframe-Frequenz / I-Frame Intervall / GOP
Hierfür finden sich viele Bezeichnungen. Gemeint ist aber in jedem Fall die Frequenz, in der ein vollständiges Intraframe (I-Frame) erstellt wird – sprich ein Bild, welches für sich alleine existieren kann und keine anderen Bilder als Referenz benötigt, um codiert zu werden. Wenn nicht anders angegeben, sollte diese Erzeugung alle zwei Sekunden passieren. Ergo: I-Frame Intervall = Framerate × 2.

Bitraten-Codierung
Es wird zwischen „Variable Bit Rate“ (VBR) und „Constant Bit Rate“ (CBR) unterschieden: Bei der VBR trifft der Encoder die Entscheidung, wieviel Mb für die Komprimierung eines Frames benötigt werden. Bei nur marginalen Änderung im Videobild kann die Bitrate sinken, ohne dabei an Qualität einbüßen zu müssen. Ein Sprecher vor einem statischen Hintergrund sorgt zum Beispiel für nur wenige Änderungen im Videobild → die Bitrate sinkt. Eine Tanzgruppe vor einer LED-Wand mit Visuals sorgt für ständige, tiefgreifende Änderungen im Videobild → die Bitrate steigt. Wenn VBR gewählt ist, reflektiert die eingestellte Video-Bitrate in der Regel den Maximalwert, der nicht überschritten werden soll. Manche Encoder ermöglichen auch die Einstellung einer Ziel-Bitrate, um welche sich der Durchschnitt einpendeln soll. Eine variable Bitrate kann den Datendurchsatz schlank halten, plötzliche Spitzen in der Bitrate können aber auch zum erneuten Puffern auf Endgeräten führen und so Unterbrechungen für schlecht angebundene Geräte hervorrufen. Bei der CBR wird für die Codierung stets die gleiche Bitrate genutzt. Plötzliche Peaks werden so unterbunden, aber man erzeugt teilweise unnötigen Traffic. Die Empfehlungen variieren je nach Plattform. Wird keine Empfehlung ausgesprochen, empfiehlt sich ein Test mit geeigneten Inhalten.

Entropie-Codierung
Hierbei handelt es sich um das bevorzugte Kompressionsverfahren. Die moderne und bevorzugte Variante ist CABAC, diese steht nur im Main und High Profil zur Verfügung. Die Alternative ist CAVLC, diese ist für kleinere Bitraten geeignet und benötigt nicht so viel Rechenleistung beim Decodieren auf dem Endgerät.

Mitunter gehen Plattformen noch tiefer ins Detail und geben Intervalle für P-Frames und B-Frames an: P-Frames sind „Predicted Frames“, welche sich auf Inhalte vorhergehender Frames beziehen. B-Frames sind „Bi-directional Frames“, für welche auch Inhalte nachfolgender Frames in die Erzeugung einfließen. Wer in der Lage ist, diese Intervalle mit seinem Encoder abzubilden, sollte das natürlich tun.

Auch wenn das alles erst einmal sehr viel erscheint, so ist die Anwendung dieser Einstellungen doch recht schnell erledigt. Viele Encoder bieten auch Presets für eine Vielzahl an Video-Plattformen.

>> zurück zum Anfang

Hardware- vs. Software-Encoding

Für das Encoding kann man entweder auf Hardware zugreifen oder sich für eine Software-Lösung entscheiden. Dabei gibt es Encoder in unterschiedlichsten Preisklassen. Man kann vorhandene Rechner mit Software und Capture-Karten bestücken und zum Encoder machen, oder man legt sich Hardware zu, deren Zweck es ist, die Anforderungen an Streamings zu erfüllen. Die Preise für Hardwareencoder können zwischen ein paar hundert und mehreren zehntausend Euro liegen. In unserer Branche begegnen uns u. a. Geräte von Lynx, Teradek, AJA Video Systems, Matrox, Kramer, Haivision, Blackmagic Design, NewTek, Epiphan und mehr. Software-Encoder gibt es entweder kostenlos (in Form von OBS oder Streamlabs OBS), bekannte Beispiele für kostenpflichtige Software sind Wirecast, vMix, XSlplit und VidBlasterX. Welche Lösung die Richtige ist, muss jeder für sich und sein Projekt selbst entscheiden.

Unsere Gegenüberstellung der Vor- und Nachteile von Soft- und Hardwarelösungen soll hier eine Hilfestellung bieten:

Hardware Vorteile

• In den meisten Umgebungen möchte man einfach ein Gerät, welches einzig für den Stream verantwortlich ist. Einmal konfiguriert laufen Hardware-Encoder zuverlässig und mit geringerem Delay.
• Es gibt spezialisierte Geräte, die an unterschiedliche Anforderungen angepasst sind. So gibt es Encoder, die klar für den mobilen Einsatz gedacht und auch mit LTE-Modulen ausgestattet sind. Konfiguriert wird per App oder am Gerät selbst – und fertig ist der Stream. Andere Geräte eignen sich besonders für Installationen und bieten zusätzliche Funktionen zur Fernsteuerung und Systemintegration.
• Einmal konfiguriert, werden viele Geräte zur Plug & Play-Lösung.
• Sehr viele Hardware-Encoder eignen sich auch als Streaming-Server in lokalen Netzwerken und eröffnen so eine weitere Verwendungsmöglichkeit neben dem Online-Stream.
• Es gibt hybride Geräte, welche das Mischen und Arrangieren von Medienquellen direkt mit der Möglichkeit des Streamens kombinieren.

Hardware Nachteile

• Oft gibt es nur wenig unterstützende Features zum „Aufpeppen“ des Streams. Hier muss meistens alles vor dem Encoder ins Signal eingebunden werden. Das Livebild ist immer nur so flexibel wie das Signalmanagement davor.
• Technologische Weiterentwicklungen wachsen nur bedingt mit den Geräten mit. Firmwareupdates können nur so viele Features nachliefern, wie es die Hardware erlaubt.
• Die Geräte sind teurer als Capture-Karten und somit auch teurer im Austausch.

Software Vorteile

• Softwarelösungen bieten interne Wiedergabemöglichkeiten von unterschiedlichsten Dateien und Quellen: Bild in Bild, Logo-Einblendungen, Überblendeffekte, Jingles und vieles mehr ist selbst mit Freeware möglich. Dabei bleibt das gesamte Setup schlank und mobil.
• Die Anbindung eines Portals oder eines Kanals ist häufig mit wenigen Klicks erledigt. Auf die Kodierungsparameter hat man in Softwarelösungen häufig mehr Einfluss als in Hardwarelösungen.
• Mit einer Software kann man Hardware nutzen, die man schon hat. Mit einer Capture-Karte ausgestattet, wird ein guter Laptop zum Streaming-Encoder, der eine bessere Qualität liefern kann als ein billiger Hardware- Encoder.

Software Nachteile

• Die Komposition der Inhalte und das Encodieren passieren mitunter am gleichen Ort. Wer sich veklickt, verliert.
• Die Software ist immer nur so gut wie der Rechner auf dem sie läuft. Eine schnelle und gute Encodierung erfordert einiges an Rechenleistung.
• Ein alleinstehender Betrieb in Installationsumgebungen ist mit Softwarelösungen nicht sehr praktikabel.

>> zurück zum Anfang

OVP und CDN: Online Video Platform und Content Delivery Network

Nun haben wir ein Signal und einen Encoder. Und jetzt – wohin mit diesem Signal? Ab und zu gibt es den einfachen Fall, in dem ein Kunde nur auf den eigenen YouTube-Kanal oder auf Facebook Live streamen möchte. Diese Anforderung lässt sich recht leicht erfüllen. Aber so einfach ist es leider nur selten. Stattdessen wird vielleicht ein Link zum Embedden in die eigene Homepage erwartet – oder wie wäre es mit Pay per View? Passwortgeschützt soll der Stream auch sein. „Können die Nutzer dann eigentlich auch auf die Dolmetscherkanäle umschalten? Ist der Stream danach noch verfügbar, damit man ihn nächste Woche noch mal schauen kann? Können wir dort gleich die PowerPoint zum Download verlinken? Können die Teilnehmer nicht gleich in einem Chat ihre Fragen stellen? Machen Sie doch mal ein Angebot und sagen Sie uns was das kostet, dann können wir das gleich jede Woche machen.“ So oder so ähnlich entwickeln sich Gespräche nicht selten.

Für den Kunden sind wir der Ansprechpartner für technische Fragen. Die Erwartung, dass alles was jetzt irgendwie im entferntesten mit dem Stream zu tun hat, von uns abgedeckt wird, ist aus Kundensicht zwar irgendwie logisch, aber nicht unbedingt realistisch. Schnell explodieren die Anforderungen und aus dem einfachen Stream soll plötzlich ein Kollaborationsevent über fünf Kontinente werden. Ein Livestream allein ist aber kein virtuelles Event. Es gibt jedoch auch bei CDN- und Streaming-Anbietern unterschiedliche Features, die einen Einfluss auf unsere Auswahl haben können.

Öffentliche Social-Media-Plattformen wie Facebook Live oder YouTube verlangen kein Geld für das Hosten von Live-Content, bieten aber dennoch interessante Funktionen. So kommt bei YouTube ein eigener Transcoder zum Einsatz, welcher den Stream in unterschiedlichen Auflösungen zur Verfügung stellt. Dies stellt die Inhalte einer größeren Nutzergruppe zur Verfügung, da der Stream auch bei einer eher langsamen Internetverbindung erreichbar bleibt. Bei vielen Portalen ist dieser Service nicht dabei. Wer den Stream in mehreren Auflösungen bereitstellen möchte, kann das aber häufig erreichen, indem bereits in mehreren Auflösungen eingespeist wird – und schon ist ein Punkt erreicht, bei dem die Entscheidung für die Plattform von den Möglichkeiten des Encoder beeinflusst werden kann.

Im Folgenden geben wir eine Auswahl möglicher Features von Online-Video-Plattformen:

• Transcoding: Einige Plattformen rechnen den Stream in verschiedene, kleinere Auflösungen und Bitraten um.
• Passwortgeschützter Zugang: Damit ein Link allein nicht zur Verbreitung reicht, bieten manche OVP die Möglichkeit zum Setzen eines Passwortes, bevor man Zugang zum Livestream erhält.
• Monetarisierung: Den Zugang zum Stream an eine Paywall koppeln zu können, kann von Interesse sein.
• Splash-Images: Wenn kein Stream an den Server übermittelt wird, wird ein Bild gezeigt, welches man hochladen kann. Manchmal kann man für den Zeitraum vor dem Stream ein anderes wählen als für die Zeit danach. Zudem gibt es Dienste, die einen Countdown bis zum Start der Live-Übertragung anbieten.
• Logo: Die Einblendung eines Logos kann auch erst in der Plattform realisiert werden.
• Mehrere Audiokanäle: Für Events mit Simultanübersetzung ist das durchaus ein Verkaufsargument. Dies muss nicht nur von der Online-Video-Plattform unterstützt werden, sondern auch vom Encoder. Wer mehrsprachige Streams anbieten möchte, sollte genau recherchieren.
• Recording: Das generelle Vorhandensein einer Aufzeichnung des Streams nach dem Ende des Events ist keine Selbstverständlichkeit, sondern ein Feature.
• Reduced Latency Streaming: Für alle, die zeitkritische Events übertragen, bei denen es auf eine halbe oder ganze Minute ankommen kann, ist das ein Stichwort. Die Anforderungen auf Encoderseite variieren von Anbieter zu Anbieter.
• Statistische Auswertungen: Viele Kunden wollen nach dem Event wissen, wie sich die Besucherzahlen entwickelten. Eigene Statistiken oder eine Anbindung an Google-Analytics-Profile werden angeboten.
• Video-Player: Je nach Anbieter stehen entweder eigene Videoplayer für die Onlinewiedergabe zur Verfügung, oder es werden Streams für HTML5 Player aufbereitet (nutzt browserinterne Mittel zur Wiedergabe).
• Sharing-Möglichkeiten: Nutzer wünschen sich Codes zum Embedden des Streams in ihre eigenen Webseiten oder zum Teilen in sozialen Medien. Da nimmt einem das eine Portal mal mehr Arbeit als das andere ab.
• Zugriffsbeschränkungen: Das Einbinden des Streams nur für bestimmte Domains zu gestatten, oder den Zugriff geografisch einzuschränken, kann auch gefordert sein.
• Backup Entry Points: Es gibt Portale, die das parallele Senden des Streams an eine Backupadresse erlauben. Falls die Verbindung zum ersten Stream abbricht, leitet das System automatisch an das Backup weiter. Das hat nur wirklich Sinn, wenn der Stream auch von zwei Encodern gesendet wird.
• Lizenzmodell: Während die meisten Anbieter mit Abonnements arbeiten, gibt es auch Anbieter, bei denen man Event-bezogene Abrechnungsmodelle vorfindet. Eine Kontaktaufnahme für ein individuelles Angebot ist auch für kleine Anwendungsfälle eine gute Idee.

---

Beispiele für OVP und CDN

AKAMAI
AWS
Azure Media Services
Brightcove
DaCast
Facebook Live
Livestream
Microsoft Stream
Twitch
Wowza
YouTube

---

>> zurück zum Anfang

Umfeld: rund um den Stream

Die Optionen, die allein schon durch die Features der verschiedenen OVPs für den Kunden relevant werden, gilt es mit einem entsprechenden Fingerspitzengefühl in Erfahrung zu bringen. Im gleichen Atemzug sind die Limits der avisierten Lösung klar deutlich zu machen.

Es gibt Plattformen, die noch weitere Türen öffnen und die Brücke zum virtuellen Event schlagen. Hier verlassen wir jedoch das Feld des Streamings und landen im Bereich der Web-Programmierung. Interaktionen zwischen Teilnehmern, Umfragen, Chats, Downloadzugriff auf Präsentationen und weiterführende Dateien sind Features, die nicht mehr im direkten Zusammenhang mit dem Stream stehen. Plattformen für virtuelle Events bieten häufig auch nur an, Streams einzubinden anstatt selbst einen Server zur Verfügung zu stellen. Eine kurze Google-Suche mit den Schlagworten „virtual event platform“ führt schnell zu ersten Anbietern. Natürlich steht es jedem frei, die nötigen Bausteine für den Kunden selbst zu entwickeln und in eine Weboberfläche zu integrieren. Dabei ist nur wichtig zu verstehen, dass der Stream in diese Lösung integriert wird – und nicht anders herum. Die Weboberfläche verweist lediglich auf den Stream und bindet diesen ein. Welches Nutzererlebnis aus der Weboberfläche resultiert, kann zum Knackpunkt werden. Dies ist aber nicht mehr Teil unserer Betrachtung, denn hier gibt es eigentlich keine Limits.

Was ist noch zu klären?

Neben all den Punkten, die sich aus den Kapazitäten der gewählten Plattform ergeben, gibt es noch weitere Aspekte, die es vor dem Streaming mit dem Kunden zu klären gilt. Beispiele hierfür können sein:

• Nutzt der Kunde bereits eine Plattform, die sich für die Übertragung des Streams eignet? Soll nur auf eine Plattform gestreamt werden?
• Wie hoch ist die Anzahl der voraussichtlichen Nutzer? (Dient zur Kalkulation für benötigte Zuschauerstunden)
• Welche Internetanbindung ist vorhanden? Welche Netzwerkbeschränkungen bestehen? Wer ist der Ansprechpartner? Steht ausreichend Bandbreite für den Stream zur Verfügung? Als Faustregel gilt: mindestens doppelt so viel Mbps zur Verfügung haben, als der Stream theoretisch benötigt, um genügend Spielraum für Spitzen in der Kodierung und Schwankungen in der Leitung zu haben.
• Soll der Stream im Anschluss noch zu sehen sein oder zugänglich gemacht werden? Wenn ja, auf welchen Kanälen und in wessen Verantwortung soll das liegen?
• Muss der Stream in mehreren Sprachen vorliegen? Welche Lösung ist dafür praktikabel? (Mehrere Streams vs. ein Stream mit mehreren Audiospuren)
• Gibt es datenschutzrechtliche Anforderungen, welche eine Verwendung eines Portals einschränken oder unmöglich machen könnten?
• Der Kunde muss darüber aufgeklärt werden, dass die Nutzung bestimmter Portale mit Einschränkungen durch Lizenzverwaltungen einhergehen können. Beispiel: Das Abspielen GEMA-geschützter Musik auf YouTube oder Facebook kann zum Ende des Streams oder zur Stummschaltung führen. Inhalte müssen also im Einklang mit den Richtlinien der Portale sein.

Ausspielung: Das Erlebnis des Zuschauers

Bei den Absprachen im Vorfeld eines Streams sollte man sich immer wieder in die Perspektive des Zuschauers versetzen und hinterfragen, ob die avisierte Technik und der Ablauf dem Zuschauererlebnis gerecht werden. Ein klarer Regieplan ist umso wichtiger, wenn die Teilnehmer keinen Kontext aus dem Raum und der Atmosphäre ziehen können.

Ein Stream ist keine verlängerte LED-Wand, sondern ein eigenes „Event im Event“, welches auch auf einem Handybildschirm erlebbar gemacht werden will.

>> zurück zum Anfang

Fazit

Einen funktionierenden Stream zu realisieren, ist mit ein wenig Einarbeitung in die technischen Grundlagen keine große Zauberei. Die größere Herausforderung liegt in der Kommunikation mit dem Kunden und im Abstecken von Grenzen. Hierzu muss man sich die gesamte Kette vom Bühnenakteur bis zum Zuschauer vor Augen führen und selbst ehrlich entscheiden, an welchem Punkt in der Kette man die Dienstleistung als abgeschlossen betrachtet. Wenn alle Beteiligten diesen Übergabeort verstehen und akzeptieren, dann steht einem erfolgreichen Stream nichts mehr im Wege.

---

WIKI: Begriffe aus dem Live-Streaming

CDN – Content Delivery Network
Ein CDN ist für die Auslieferung des Streams an Knotenpunkte im Internet verantwortlich. Ein Stream, der in Deutschland eingespeist, aber in Japan abgerufen wird, wird so nicht für jeden Nutzer aus Deutschland nach Japan übertragen. Das CDN sorgt dafür, dass der Stream an den nächstgelegenen Server in der Nähe des Nutzers übertragen wird. Dort wird der Stream zwischengespeichert und weitere Anfragen aus der Region werden von diesem Server bedient. Der Stream wandert also nur einmal um den halben Erdball und wird dann von dort verteilt.

OVP – Online Video Platform
Die OVP ist eine Plattform für das Bereitstellen von Videocontent – oft für sowohl Live- als auch On-Demand-Inhalte. In der Regel betreiben oder nutzen Online-Video-Plattformen CDNs zur Distribution der Inhalte.

Viewing Hour – Zuschauerstunde
Eine Abrechnung der Kosten für OVPs oder CDNs basiert häufig auf sog. Viewing Hours – den Zuschauerstunden. Wie der Name schon vermuten lässt, entspricht eine Zuschauerstunde einem Zuschauer, der eine Stunde zuschaut … aber eben auch zwei Zuschauern, die jeweils eine halbe Stunde zuschauen usw.

RTMP – Real Time Messaging Protocol
Das RTMP ist ein Protokoll zur Datenübertragung in Netzwerken, welches auf Adobe Flash basiert. Obwohl Flash auf der Endverbraucherseite und in der eigentlichen Distribution durch CDNs eine immer kleinere Rolle spielt, so ist es noch immer das häufigste Protokoll zur Einspeisung von Streams in das Internet.

HLS – HTTP Live Streaming
HLS ist eine Apple-Entwicklung als Alternative zum unsicheren Flashplayer. Die zurzeit häufigste Methode zur Übertragung von Streams an Endgeräte passiert über dieses Protokoll. Da es auf HTML basiert, benötigt es keine weiteren Tools und Plug-Ins im Browser zur Darstellung von Streams.

HDS – HTTP Dynamic Streaming
Zu HLS in „Konkurrenz“ steht HDS: Es ist eine neue Generation von Streaming-Protokoll für die Darstellung in Flash.

MSS – Microsoft Smooth Streaming
Ein weiteres Protokoll ist MSS – ein Streaming-Protokoll von Microsoft mit adaptiver Bitrate. MSS verliert allerdings zusehends an Bedeutung.

MPEG-DASH – MPEG Dynamic Adaptive Streaming (über HTTP)
MPEG-DASH ist das erste international standardisierte Streaming Protokoll auf HTTP-Basis. Es bietet umfangreiche Möglichkeiten bei der Wahl des Codecs und wird sich über die nächsten Jahre vermutlich zum neuen Standard entwickeln.

---

>> zurück zum Anfang