Da sich Werbemittel und Zuschauer immer mehr vom herkömmlichen Fernsehen entfernen, suchen Inhaltseigentümer und Sendeanstalten nach werbeunterstütztem Live-Event-Streaming, um neue Zielgruppen zu begeistern und den Umsatz durch Over-the-Top-Streamingzu steigern. OTT bietet neue Vertriebschancen, die es einem Publisher ermöglichen, lizenzierte Inhalte, die bisher im Fernsehen keinen Platz hatten, zu veröffentlichen und zu monetarisieren. Bevor ein Publisher jedoch mit dem Streamen von Live-Events beginnen kann, müssen technische Hürden im ersten Schritt des Streaming-Video-Workflows berücksichtigt werden:
- Die Verbindungsqualität und die Verfügbarkeit der Bandbreite zwischen dem Veranstaltungsort und dem Einspeisepunkt können ein schwaches Glied im Workflow sein. Redundanz und Zuverlässigkeit müssen integriert sein.
- Live-Feeds müssen in verschiedenen Formaten und Protokollen mit adaptiver Bitrate, wie Apple HLS und MPEG-DASH, codiert werden, während die Latenz minimiert wird.
- Upload- und Codierungslösungen müssen zukunftssicher, zuverlässig und skalierbar sein, um die Entstehung von 4K und anderen hochwertigen Formaten bewältigen zu können.
- Der Video-Workflow sollte serverseitige Anzeigeneinblendungen unterstützen, um ein optimales Zuschauererlebnis und optimale Monetarisierungsstrategien zu erzielen.
In diesem Technologie-Blog sehen wir uns an, wie wir unsere Plattform entwickelt haben, damit ein Publisher den ersten Schritt im Video-Streaming-Workflow optimieren kann. Wir betrachten einige der Herausforderungen, die damit verbunden sind, und erklären, wie wir den Live-Stream kodieren, um ein hochleistungsfähiges Livestreaming mit geringer Latenz und werbeunterstütztem Livestreaming zu ermöglichen.
Background: Der Slicer
Bevor wir uns mit den technischen Überlegungen der Kodierung befassen, müssen wir unsere Technologie erklären, die „Slicer“ genannt wird. Ein leistungsstarker Software-Client, der Slicer, überträgt den Livestream Ihres Veranstaltungsorts auf unsere Cloud-Videoplattform. Es vereinfacht eine außerordentlich komplexe Aufgabe, ohne dabei an Flexibilität und Funktionalität zu verlieren. Der Slicer ist ein Hauptgrund dafür, dass Sender mit umfangreichen technischen Ressourcen und ohne solche unsere Plattform nutzen können, um überzeugende, differenzierte OTT-Erlebnisse zu schaffen.
Der Slicer bereitet Ihre Inhalte für die Codierung vor, berechnet ideale Codierungseinstellungen und verwaltet Markierungen für das Einfügen von Anzeigen. Sie können den Slicer auf Ihrer sicheren Hardware ausführen oder die Kosteneinsparungen und Skalierbarkeit von Cloud-unabhängigen Standorten auswählen, die verschiedene Formate unterstützen, darunter SDI, IP Video, RTP/FEC und RTMP.
Der Slicer teilt Ihre Inhalte in kleine Stücke und verschlüsselt sie, bevor er sie an unseren ISO-zertifizierten Cloud-Codierungs-Stack sendet. So haben Sie die Gewissheit, dass Ihre Inhalte stets sicher sind. Es bietet eine flexible Palette von Workflows, von einfachen Konfigurationen mit einem Klick über erweiterte Skripte in der gewünschten Programmiersprache bis hin zum Schreiben von Cloud-Funktionen, die Workflows für Benachrichtigungen, Jobverarbeitung und Integration von maschinellem Lernen auslösen.
Unser „Live Slicer“, eine Version des Slicers, ist für das Streaming von Live-Events optimiert. HD-SDI- oder IP-basierte Feeds werden schnell aufgenommen und in 2-Sekunden- oder 4-Sekunden-verschlüsselte Segmente mit der höchsten gewünschten Bitrate aufgeteilt, wodurch die Bandbreitenanforderungen auf 3–5 Mbit/s für 1080p und etwa 15 Mbit/s für 4K reduziert werden Unser Prozess speichert automatisch bandinterne und außerbandinterne Metadaten und Nachrichten, um Programm- und Werbeunterbrechungen auszulösen oder Inhalte zu ersetzen. Mit unserer Plug-in-Architektur können Sie benutzerdefinierte Skripte erstellen, die Ihre individuellen Anforderungen an Signalisierungsereignisse erfüllen. Live Slicer kann auch SCTE 35 / 104-Nachrichten abhören oder API-Aufrufe empfangen, um Anzeigenunterbrechungen, Inhalte oder Blackout-Trigger einzufügen.
Ein OTT-Stream wird aus einem linearen Live-Feed mit minimalen Vorabinvestitionen und geringen Bandbreitenanforderungen generiert.
Minimierung der Bandbreite
Da Sie nun mit dem Slicer vertraut sind, fragen Sie sich vielleicht, warum wir eine Front-End-Softwarekomponente entwickeln würden, um Livestreams von Ereignissen in die Cloud zu verschieben. Warum konnten Publisher beispielsweise keinen RTMP-Stream (Real-Time Messaging Protocol) senden? (Sie können dies tun, wenn Sie möchten, aber die meisten unserer Kunden nutzen den Slicer.)die Antwort hat genauso viel mit den Erwartungen der Verbraucher an qualitativ hochwertige Livestreams zu tun wie mit der Bewältigung von Bandbreitenproblemen an Live-Standorten. Es geht darum, das richtige Gleichgewicht zwischen vielen konkurrierenden Faktoren zu finden. Zum einen müssen Sie möglichst viel Originalzuführung beibehalten, wobei Sie auf qualitativ hochwertigere Formate und 4K achten müssen Auf der anderen Seite müssen Sie den Stream optimieren, damit er effizient bereitgestellt werden kann, ohne durch zusätzlichen Aufwand, wie personalisierte Werbung, behindert zu werden. Für diesen Schritt des Video-Workflows ist es entscheidend, die richtige Balance zu finden.
Hier ist der Slicer von entscheidender Bedeutung. Wie oben erwähnt, reduziert es die für einen bestimmten Feed erforderliche Bandbreite erheblich, indem das Profil mit der höchsten Bitrate am Standort erstellt und dieses Profil nur an die Cloud gesendet wird. Nach unserer Beobachtung – basierend auf dem Streaming von Millionen Stunden Live-Material an Milliarden von Zuschauern weltweit – führt der alternative Ansatz, einen deutlich größeren RTMP-Stream an die Cloud zu senden, nicht zu einer nennenswerten Verbesserung der Qualität des Fernseherlebnisses. Aber es erhöht die Bandbreite erheblich, was die Kosten in die Höhe treibt.
Backhaul-Kosten können sich schnell summieren. Wenn Ihre Anforderungen so sind, dass Sie einen Satelliten-Uplink benötigen, beispielsweise einen Ka-Band-Lkw, mietet er für etwa 2.000 US-Dollar pro Tag, und die Bandbreite kostet etwa 400 US-Dollar pro Stunde. Angesichts der inkonsistenten und bandbreitenbeschränkten Bedingungen an einigen Orten, wie Hotels, Konferenzzentren oder sogar Sportstätten auf der ganzen Welt, ist es immer eine gute Idee, die Anforderungen an die Upload-Bandbreite so weit wie möglich zu reduzieren und gleichzeitig sicherzustellen, dass Sie Ihren Zuschauern ein Fernseherlebnis bieten.
Codierung von Hürden
Sobald der Live-Video-Feed den Veranstaltungsort verlässt, ist der nächste Schritt im Workflow die Codierung. Hier erstellt ein Video-Encoder mehrere Versionen oder Varianten von Audio und Video mit unterschiedlichen Bitraten, Auflösungen und Qualitätsstufen. Anschließend segmentiert er die Varianten in kleine Dateien oder Mediensegmente. Es müssen mehrere zusätzliche Schritte ausgeführt werden, z. B. das Erstellen einer Medienwiedergabeliste für jede Variante, die eine Liste von URLs enthält, die auf die Mediensegmente der Variante verweisen. Die daraus resultierende Master-Playlist ist die Wahl des Players für die am besten geeignete Variante für das Gerät und die aktuell gemessene oder verfügbare Bandbreite.
Zwei wichtige Video-Streaming-Protokolle erhöhen die Komplexität, und andere müssen möglicherweise unterstützt werden, um die Vielzahl potenzieller Wiedergabegeräte abzudecken. HLS ist ein HTTP-basiertes Media Streaming-Kommunikationsprotokoll, das von Apple implementiert wird. Es bietet Unterstützung für alle Apple-Geräte und die meisten Google-, Android-, Linux- und Microsoft-Browser und -Geräte. Die meisten, aber nicht alle. Sie benötigen auch MPEG-DASH, ein konkurrierendes HTTP-basiertes Medien-Streaming-Protokoll. Möglicherweise müssen Sie auch Unterstützung für Microsoft Smooth Streaming für Spielekonsolen hinzufügen.
DRM kann auch die Codierung komplizieren, indem es eigene Formate benötigt, um die Anforderungen großer Zielgruppen zu erfüllen. Ältere Spieler, die DRM nicht unterstützen, benötigen beispielsweise HLS und AES-128. Ältere iOS-Geräte erfordern HLS und FairPlay. Neuere iOS-Geräte unterstützen HLS und FairPlay sowie CMAF CBC. Ältere Windows und Android unterstützen nur CMAF CTR. Neuere Android-, Windows- und iOS-Versionen sollten alle CMAF-Formate unterstützen. Ihre Inhalte müssen in mehreren Formaten verpackt sein, damit sie auf allen Geräten wiedergegeben werden können.
Wenn das nach viel Codierungsarbeit klingt, haben Sie Recht. Da die Auflösungen zunehmen und Codecs komplexer werden, wird es schwieriger, eine komplette ABR-Codierungsleiter auf einem einzigen Computer zu codieren, sei es in der Cloud oder vor Ort. Wenn Ihre Codierungshardware nicht der Aufgabe gewachsen ist, mit dem Live-Feed Schritt zu halten, müssen Sie möglicherweise die Anzahl der Sprossen auf der Codierleiter reduzieren, was letztendlich die Erfahrung Ihres Publikums beeinträchtigen könnte.
Um mit den komplexeren Codierungsanforderungen Schritt zu halten, müssen Hersteller nach dem herkömmlichen Modell kontinuierlich in neue Hardware investieren, um Geschwindigkeit und Qualität zu erhalten. Für einen Streaming-Dienst wie Edgio, ehemals Verizon Digital Media Services, bietet das 1:1-Stream-Encoder-Modell letztlich nicht die Zuverlässigkeit, Flexibilität und Skalierbarkeit, die wir benötigen, um die Erwartungen unserer Kunden zu erfüllen.
Stattdessen haben wir ein ausgeklügeltes Brokering-System entwickelt, das die Verwendung von so vielen Encodern ermöglicht, wie wir benötigen, die alle in einer Cloud-basierten Infrastruktur ausgeführt werden. Das Brokering-System empfängt die Content-Chunks von Slicer-Instanzen und verschiebt sie in den optimalen Encoder. Durch diese Aktion wird verhindert, dass die Codierungsprozesse einen bestimmten Computer überlasten, und die Blöcke werden durch das System zum Speicher und zu den Viewern weitergeleitet.
Der Broker-Prozess skaliert unsere Cloud-Encoder-Infrastruktur nahtlos und, was noch wichtiger ist, automatisch.
Bei unserer Implementierung fungiert eine Broker-Instanz als Manager, der zwischen dem Slicer und den Encodern spricht. Der Broker stellt sicher, dass jeder neue Slicer seine Daten an den richtigen Encoder weiterleitet, und überprüft, ob der Encoder die Workload verarbeiten kann. Darüber hinaus verfügen wir über eine sehr leistungsfähige Infrastruktur zur Skalierung. Wenn wir plötzlich mit einer Million Stunden VOD-Inhalt, der verschlüsselt werden muss, abgeladen werden, können wir Serverinstanzen schnell hochfahren und Inhalte verarbeiten. Wir können auch genauso schnell nach unten skalieren, um Ressourcen zu sparen. Dieser Broker-Prozess verwaltet unsere gesamte Cloud-Infrastruktur nahtlos und, was noch wichtiger ist, automatisch.
Zustandslose Encoder
Natürlich wäre das Vermittlungssystem von begrenztem Wert, wenn es nur einen Slicer auf einen einzigen Encoder richten könnte, der mit den Anforderungen des Livestreams mithalten kann, ein ernstes Problem mit 4K Die von uns entwickelte Lösung umfasst die Verwendung zustandsloser Encoder. Anstatt eine einzelne Maschine dem gesamten Stream zu widmen, empfängt jeder Encoder jeweils nur ein 2- oder 4-Sekunden-Videosegment. Jedes Segment enthält genügend Informationen, um den Encoder zu entlüften, damit er dieses Segment codieren und alle unnötigen Informationen für die Vorbereitung, wie z. B. Informationen über die Vorlaufleitung und die Vorlaufleitung, verwerfen kann. An diesem Punkt ist das gesamte Segment fertig und einsatzbereit, wodurch der Encoder freigegeben wird, sodass er mit der Codierung eines weiteren Inhalts von einem anderen Kanal oder einem anderen Kanal beginnen kann.
Dieses Modell verfügt auch über eine beträchtliche Redundanz, die in das System integriert ist. Wenn beispielsweise ein Encoder während der Verarbeitung eines Segments abstürzt, startet dasselbe Segment auf einem anderen Computer und wird rechtzeitig erledigt, bevor Probleme im Stream festgestellt werden.
Dieser Ansatz ermöglicht auch den Einsatz kostengünstigerer Hardware. Wenn wir beispielsweise wissen, dass eine langsamere Maschine 8 Sekunden benötigen kann, um eine 4-Sekunden-Datei von einem Slicer zu verarbeiten, können wir die Workload auf mehrere Encoder verteilen, wie unten gezeigt: Server A erhält Schicht 1, Server B erhält Schicht 2 usw. Dann wurden die Chunks ohne Probleme geliefert, da sie alle zu einem vorhersehbaren Zeitpunkt fertiggestellt wurden. Wie in der folgenden Tabelle gezeigt, würde dieses Beispiel eine Latenzzeit von 16 bis 20 Sekunden hinter dem Live-Modus ergeben.
Die Verwendung mehrerer Encoder in der Cloud minimiert die Latenz und ermöglicht die Verwendung von Servern, die sonst nicht mit einem Live-Feed mithalten könnten.
Letztendlich bedeutet das Servervolumen in der Cloud – selbst wenn die einzelnen Server langsamer sind –, dass die Kodierungsprozesse immer mit den aktuellen Anforderungen Schritt halten können. Wenn Sie eine Codierungsinfrastruktur mit einem herkömmlichen Modell einrichten möchten, müssten Sie in teure Hochleistungsmaschinen oder spezielle Hardware investieren, die alle eingehenden Videos ohne Echtzeitunterstützung verarbeiten können. Durch die Nutzung der Skalierbarkeit der Cloud senken wir die Kodierungskosten erheblich.
Ein weiterer Vorteil der zustandslosen Cloud-Codierung besteht darin, dass wir Workloads problemlos an andere Cloud-Anbieter verschieben können, da wir keine speziellen Serveranforderungen haben. Mit einem Netzwerk mit einer Kapazität von mehr als 250 Tbit/s bietet ein Multi-Cloud-Ansatz inhärente Vorteile.
Kostengünstiges Live-Streaming
Für Produzenten von Live-Inhalten können die technischen Überlegungen zur Vorbereitung des Live-Videos für Cloud-Streaming enorme Hindernisse darstellen. Sie werden mit verschiedenen Problemen konfrontiert sein, von Einschränkungen der Bandbreite an Veranstaltungsorten bis hin zu komplexen Fragen rund um Encoder und Streaming-Protokolle. Auch wenn die Notwendigkeit für einige Konnektivität am Veranstaltungsort nicht überflüssig ist, kann ein vereinfachter Workflow mit reduzierten Bandbreitenanforderungen am Front-End die Vorlaufausgaben und laufenden Ausgaben drastisch reduzieren und gleichzeitig die hochwertigen Streams mit geringer Latenz bereitstellen, die Ihre Zuschauer erwarten.
