Geringe Latenz ist ein universelles Ziel in Medien. Wenn ein Unternehmen wie Wowza das perfekte Diagramm erstellt, um Streaming-Technologien mit geringer Latenz zu erklären, müssen Sie den Hut abnehmen und das Diagramm mit Namensnennung und einigen geringfügigen Änderungen verwenden. Ich präsentiere das Diagramm als Abbildung 1; Lassen Sie uns in der Reihenfolge diskutieren, die durch die hervorgehobenen Nummern gekennzeichnet ist, die ich hinzugefügt habe.
1. Anwendungen für niedrige Latenz
PRODUKTHILFE
Beste PTZ-Kameras für Live-Streaming
Um sicherzustellen, dass wir alle auf derselben Seite sind, bedeutet Latenz im Zusammenhang mit Live-Streaming die Verzögerung von Glas zu Glas. Das erste Glas ist die Kamera beim eigentlichen Live-Event, das zweite ist der Bildschirm, den Sie gerade ansehen. Die Latenz ist die Verzögerung zwischen dem Erscheinen in der Kamera und dem Erscheinen auf Ihrem Telefon. Zur Latenz tragen Faktoren wie die Codierungszeit (auf dem Ereignis), die Transportzeit in die Cloud, die Transcodierungszeit in der Cloud (zum Erstellen der Codierungsleiter), die Lieferzeit und kritisch bei, wie viele Sekunden Ihr Player puffert, bevor er mit dem Spielen beginnt.
Die oberste Ebene zeigt typische Anwendungen und ihre Latenzanforderungen. Beliebte Anwendungen, die aufgrund geringer Latenz und nahezu Echtzeit-Latenz fehlen, sind Glücksspiel- und Auktionsseiten.
Bevor Sie sich mit unserer Technologiediskussion befassen, sollten Sie sich darüber im Klaren sein, dass der Stream umso weniger anfällig für Bandbreitenunterbrechungen ist, je geringer die Latenz Ihres Live-Streams ist. Wenn Sie beispielsweise die Standardeinstellungen verwenden, wird ein HLS-Stream über 15 Sekunden unterbrochener Bandbreite abgespielt. Wenn er zu diesem Zeitpunkt wiederhergestellt wird, weiß der Betrachter möglicherweise nie, dass ein Problem aufgetreten ist. Im Gegensatz dazu wird ein Stream mit geringer Latenz fast unmittelbar nach einer Unterbrechung nicht mehr abgespielt. Daher muss der Vorteil einer Startzeit mit geringer Latenz immer gegen das Negative von Wiedergabestopps abgewogen werden. Wenn Sie keine unbedingt niedrige Latenz benötigen, lohnt es sich möglicherweise nicht, die Ausfallsicherheit zu opfern, um sie zu erhalten.
Es ist jedoch nützlich, die Latenz wie folgt in drei Kategorien zu unterteilen.
PRO NEWSLETTERAudio + Video + IT. Unsere Redakteure sind Experten für die Integration von Audio / Video und IT. Erhalten Sie tägliche Einblicke, Neuigkeiten und professionelles Networking. Abonnieren Sie Pro AV noch heute.
- Schön zu haben - Schneller ist immer besser. Wenn Sie jedoch ein Board of Education-Meeting oder ein High-School-Fußballspiel live streamen, ist die Robustheit des Streams möglicherweise wichtiger als die geringe Latenz, insbesondere wenn viele Zuschauer Verbindungen mit niedriger Bitrate sehen.
- Wettbewerbsvorteil - In einigen Fällen bietet eine niedrige Latenz einen Wettbewerbsvorteil, oder eine langsame Latenz bedeutet einen Wettbewerbsnachteil. Sie werden in der Tabelle feststellen, dass die typische Latenz für Kabelfernsehen etwa fünf Sekunden beträgt. Wenn Ihr Streaming-Dienst mit Kabeln konkurriert, müssen Sie sich in diesem Bereich befinden, wobei eine geringere Latenz einen bescheidenen Wettbewerbsvorteil bietet.
- Echtzeitkommunikation - Wenn Sie eine Glücksspiel- oder Auktionsseite sind oder Ihre Anwendung anderweitig Echtzeitkommunikation erfordert, müssen Sie unbedingt eine geringe Latenz bereitstellen.
- Live-Streaming-Vergleichsanleitung
- So prognostizieren Sie den Erfolg eines Codecs
Nachdem wir die Kategorien kennen, schauen wir uns den effizientesten Weg an, um das erforderliche Maß an geringer Latenz zu erreichen.
2/3 Schön, eine niedrige Latenz zu haben
Die Nummer 2 zeigt, dass Apple HLS und MPEG-DASH, die mit ihren Standardeinstellungen bereitgestellt wurden, zu einer Latenz von etwa 30 Sekunden führen. Die Zahlen sind einfach; Wenn Sie Segmentgrößen von zehn Sekunden verwenden und drei Segmente vor Beginn der Wiedergabe im Player-Puffer sein müssen, sind Sie bei 30 Sekunden. In Wahrheit hat Apple seine Anforderungen vor einigen Jahren von zehn Sekunden auf sechs Sekunden geändert, und die meisten DASH-Hersteller verwenden Segmente mit 4 bis 6 Sekunden, sodass die Standardzahl wirklich näher bei 20 Sekunden liegt.
Nummer 3, HLS Tuned und DASH Tuned, zeigt jedoch eine Latenz von etwa 6-8 Sekunden. Im Wesentlichen bedeutet Tuning, von 10-Sekunden-Segmenten zu 2-Sekunden-Segmenten zu wechseln, was bei gleicher Berechnung die Latenz von 6-8 Sekunden liefert. Wenn also die Latenz angenehm ist, können Sie die Latenz ohne Entwicklungszeit oder -kosten drastisch reduzieren oder das Risiko der Zustellbarkeit erheblich erhöhen.
4. Wettbewerbsvorteil - HTTP-Technologien mit geringer Latenz
Wenn eine geringe Latenz als Wettbewerbsvorteil erforderlich ist, reicht es nicht aus, nur die Segmentgrößen zu reduzieren. Sie müssen eine echte Technologie mit geringer Latenz implementieren. Hier gibt es zwei Klassen; HTTP-Technologien wie HLS mit geringer Latenz und CMAF mit niedriger Latenz für DASH sowie Lösungen, die auf anderen Technologien wie WebSockets und WebRTC basieren.
Für die meisten Hersteller mit Anwendungen in dieser Klasse bieten HTTP-Technologien mit geringer Latenz die beste Mischung aus Erschwinglichkeit, Abwärtskompatibilität, Flexibilität und Funktionsumfang. Daher werde ich in diesem Abschnitt HLS mit niedriger Latenz und CMAF mit niedriger Latenz für DASH und im nächsten Abschnitt andere Technologien behandeln.
Alle HLS / DASH / CMAF-basierten Systeme mit geringer Latenz funktionieren auf dieselbe grundlegende Weise wie in Abbildung 2 dargestellt. Das heißt, anstatt zu warten, bis ein vollständiges Segment codiert ist, was normalerweise zwischen 6 und 10 Sekunden dauert (siehe Abbildung 2 oben). Der Encoder erstellt viel kürzere Blöcke, die an das CDN übertragen werden, sobald sie vollständig sind (unten in Abbildung 2).
Wenn Ihr Encoder beispielsweise Sechs-Sekunden-Segmente erzeugt, haben Sie eine Latenz von mindestens sechs Sekunden. Verdreifachen Sie dies, wenn die normalen drei Segmente vor Beginn der Wiedergabe vom Betrachter empfangen werden mussten. Wenn Ihr Encoder jedoch alle 200 Millisekunden Chunks herausdrückt und der Player so konfiguriert ist, dass die Wiedergabe sofort gestartet wird, sollte die Latenz viel, viel geringer sein. Ein Hauptvorteil dieses Schemas ist die Abwärtskompatibilität. Da noch Segmente erstellt werden, sollten Spieler, die nicht mit dem Schema mit niedriger Latenz kompatibel sind, die Segmente weiterhin spielen können, wenn auch mit längerer Latenz. Diese Segmente sind auch sofort für VoD-Präsentationen aus dem Live-Stream verfügbar.
Abgesehen von diesen Vorteilen unterstützen HTTP-Technologien mit geringer Latenz die meisten Funktionen ihrer Geschwister mit normaler Latenz, einschließlich Verschlüsselung, Einfügung von Werbung und Untertitelung, die in WebRTC- und WebSockets-basierten Technologien nicht allgemein unterstützt werden. Sie können Ihre ausgewählte Technologie mit geringer Latenz wahrscheinlich mithilfe Ihrer vorhandenen Player- und Bereitstellungsinfrastruktur implementieren und so die Entwicklungs- und andere Technologiekosten minimieren.
Auswahl einer HTTP-Technologie mit geringer Latenz
Es gibt zwei Hauptstandards für HTTP Adaptive Streaming, HLS und DASH, sowie ein einheitliches Containerformat, CMAF. Nachdem Apple seine HLS-Lösung mit geringer Latenz angekündigt hatte, verdrängte Apple sofort mehrere Basisanstrengungen und wurde zur Technologie der Wahl für die Bereitstellung einer geringen Latenz für HLS. Obwohl die Spezifikation noch relativ neu ist, wird sie bereits von Technologieanbietern wie Wowza und WMSPanel mit ihrem Nimble Streamer-Produkt unterstützt.
Es gibt einen DVB-Standard für DASH mit geringer Latenz, und das DASH Industry Forum hat mehrere Modi mit niedriger Latenz für DASH genehmigt, die in die nächsten Interoperabilitätsrichtlinien aufgenommen werden sollen. In Übereinstimmung mit all diesen Spezifikationen arbeiten Encoder- und Player-Entwickler sowie Content Delivery-Netzwerke seit mehreren Jahren daran, die Interoperabilität sicherzustellen, damit alle DASH / CMAF-Anwendungen mit geringer Latenz sofort einsatzbereit sind.
Als Beispiel zeigten Harmonic und Akamai bereits in NAB und IBC 2017 CMAF mit geringer Latenz und zeigten eine Live-OTT-Lieferung mit einer Latenz von weniger als fünf Sekunden. Seitdem hat Harmonic DASH-Funktionen mit geringer Latenz in seine Appliance-basierten Produkte (Packager XOS und Electra XOS) und SaaS-Lösungen (VOS Cluster und VOS260) integriert. Viele andere Encoder- und Player-Anbieter haben dasselbe getan.
Unabhängig davon, ob Sie HLS mit geringer Latenz oder Low Latency für DASH oder beides implementieren, sollte der Übergang von Ihrer vorhandenen HLS- und / oder DASH-Bereitstellungsarchitektur relativ nahtlos und kostengünstig sein.
5. Echtzeitkommunikation
WebRTC ist normalerweise die Engine für ein integriertes Paket, das den Encoder, den Player und die Bereitstellungsinfrastruktur enthält. Beispiele für WebRTC-basierte Streaming-Lösungen in großem Maßstab sind Real Time von Phenix, Limelight Realtime Streaming und Millicast von CoSMo Software und Influxis (Abbildung 3). Sie können auch mit Tools wie der Wowza Streaming Engine, der CoSMO-Software und dem Red 5 Pro Server auf die WebRTC-Technologie zugreifen. Die Latenzzeiten für Technologien dieser Klasse reichen von 0,5 Sekunden für 71% der Streams (Phenix) unter 500 Millisekunden (Red5 Pro) bis unter einer Sekunde (Limelight). Wenn Sie eine Latenz von weniger als zwei Sekunden benötigen, ist WebRTC eine Option, die Sie in Betracht ziehen müssen.
Wenn Sie Echtzeitkommunikation benötigen, müssen Sie wahrscheinlich entweder eine WebRTC- oder eine Websockets-basierte Lösung implementieren. WebRTC wurde für die Kommunikation von Browser zu Browser entwickelt und wird von allen gängigen Desktop-Browsern unter Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 und BlackBerry 10 unterstützt. Daher sollte es auf keiner dieser Plattformen ohne Downloads ausgeführt werden. Wie der Name schon sagt, ist WebRTC ein Protokoll zum Bereitstellen von Live-Streams an jeden Betrachter, entweder Peer-to-Peer oder Server-to-Peer.
WebSockets ist ein Echtzeitprotokoll, das eine dauerhafte Verbindung zwischen einem Server und einem Client herstellt und aufrechterhält, über die beide Parteien Daten übertragen können. Diese Verbindung kann verwendet werden, um sowohl die Videoübertragung als auch andere Kommunikationen zu unterstützen. Dies ist praktisch, wenn Ihre Anwendung Interaktivität benötigt. Wie bei WebRTC-Implementierungen werden Dienste, die WebSockets verwenden, normalerweise als Dienst angeboten, der Player und CDN enthält. Sie können jeden Encoder verwenden, der Streams über RTMP oder WebRTC zum Server transportieren kann. Beispiele hierfür sind die nanoStream Cloud von Nanocosmos und die Streaming Cloud von Wowza mit extrem geringer Latenz. Wowza behauptet eine Latenz von weniger als 3 Sekunden für ihre Lösung, während Nanocosmos etwa eine Sekunde Glas zu Glas beansprucht.
Andere Technologien mit geringer Latenz
Es gibt eine vierte Kategorie von Produkten, die am besten als „andere“ bezeichnet werden und unterschiedliche Technologien verwenden, um eine geringe Latenz zu gewährleisten. Diese Kategorie umfasst das High Efficiency Streaming Protocol (HESP) von THEO Technologies, ein proprietäres adaptives HTTP-Streaming-Protokoll, das laut THEO eine Latenz von weniger als 100 Millisekunden bietet und gleichzeitig die Bandbreite im Vergleich zu anderen Technologien mit niedriger Latenz um etwa 10% reduziert. HESP verwendet Standard-Encoder und CDNs, erfordert jedoch benutzerdefinierte Unterstützung im Packager und Player (Abbildung 4). Weitere Informationen zu HESP finden Sie in einem Whitepaper, das Sie hier herunterladen können.
Hier finden Sie eine Liste von Fragen, die Sie berücksichtigen sollten, wenn Sie entscheiden, welche Technologie mit geringer Latenz implementiert werden soll und wie dies zu tun ist.
Bauen oder kaufen?
Wenn Sie die Technologie selbst implementieren, müssen Sie alle unten aufgeführten Fragen beantworten, bevor Sie eine Technologie auswählen. Wenn Sie einen Dienstanbieter auswählen, verwenden Sie diese, um die verschiedenen Dienstanbieter zu vergleichen.
Wählen Sie einen Standard oder einen Partner?
Wir haben oben die verschiedenen Technologien zur Erzielung einer geringen Latenz beschrieben. Die Implementierungen variieren jedoch von Dienstanbieter zu Dienstanbieter. Daher wird nicht jede LL HLS-Implementierung eine ABR-Bereitstellung beinhalten, zumindest zunächst nicht. Die meisten herkömmlichen Broadcast-ähnlichen Anwendungen werden wahrscheinlich auf HTTP-basierte Standards wie HLS / DASH / CMAF mit geringer Latenz migrieren, während Anwendungen, die eine extrem niedrige Latenz erfordern, wie Wetten und Auktionen, sich auf die anderen Technologien konzentrieren werden. In beiden Fällen ist es bei der Auswahl eines Dienstleisters wichtiger zu bestimmen, ob dieser Ihre technologischen und geschäftlichen Ziele erreichen kann, als welche Technologie er tatsächlich implementiert.
Kann es skaliert werden und zu welchem Preis?
Einer der Vorteile von HTTP-basierten Technologien besteht darin, dass sie mit den meisten CDNs zu Standardpreisen skaliert werden können. Im Gegensatz dazu erfordern die meisten WebRTC- und WebSocket-basierten Technologien eine dedizierte Bereitstellungsinfrastruktur, die vom Dienstanbieter implementiert wird. Aus diesem Grund kann die Bereitstellung von nicht HTTP-basierten Diensten teurer sein als die von HLS / DASH / CMAF. Stellen Sie beim Vergleichen von Dienstanbietern die Kosten der Suppe mit den Nüssen des Ereignisses fest, einschließlich Eingang, Transcodierung, Bandbreite, Erstellung von VOD-Dateien, einmaligen oder pro Ereignis stattfindenden Konfigurationen und dergleichen.
Implementierungsbezogene Probleme?
Stellen Sie die folgenden Fragen zur Implementierung und Verwendung der Technologie.
- Welche Latenz ist in einer Größenordnung erreichbar, die für Ihre Zielgruppengröße und geografische Verteilung relevant ist?
- Gibt es Qualitätsbeschränkungen? - Einige Technologien sind möglicherweise auf bestimmte maximale Auflösungen oder H.264-Profile beschränkt.
- Werden die Pakete eine Firewall passieren? HTTP-basierte Systeme verwenden HTTP-Protokolle, die Firewall-freundlich sind. Andere verwenden UDP, das möglicherweise nicht automatisch durch Firewalls geleitet wird. Wenn UDP, gibt es Backchannels, die an blockierte Zuschauer gesendet werden können?
- Welche Plattformen werden unterstützt? Vermutlich Computer und mobile Geräte, aber was ist mit STBs, Dongles, OTT-Geräten und Smart-TVs?
- Kann das System skaliert werden, um Ihre Zielgruppenzahlen zu erreichen? Ist die CDN-Infrastruktur privat und kann sie in diesem Fall allen relevanten Zuschauern in allen relevanten Märkten zur Verfügung gestellt werden? Was sind die voraussichtlichen Kosten für die Skalierung?
- Können Sie Ihren eigenen Player verwenden oder müssen Sie den Player des Systems verwenden? Wenn ja, welche Änderungen sind erforderlich und wie viel kostet das?
- Was wird für die mobile Wiedergabe benötigt? Werden die Streams in einem Browser abgespielt oder ist eine App erforderlich? Wenn eine App erforderlich (oder wünschenswert) ist, sind SDKs verfügbar?
- Welche Encoder kann das System verwenden? Die meisten sollten einen Encoder verwenden, der RTMP-Verbindungen zum Cloud-Transcoder unterstützt. Überprüfen Sie jedoch, ob andere Protokolle erforderlich sind.
- Kann der Inhalt für VoD wiederverwendet werden oder ist eine Neucodierung erforderlich? Keine große Sache, da das Umcodieren auf eine vernünftige Codierungsleiter etwa 20 US-Dollar pro Stunde Video kostet, aber für häufige Sendungen teuer ist.
- Was sind die Redundanzoptionen und wie hoch sind die Kosten? Bei geschäftskritischen Broadcasts möchten Sie wissen, wie Sie den Codierungs- / Broadcast-Workflow duplizieren können, falls eine Systemkomponente während des Ereignisses ausfällt. Wird diese Redundanz unterstützt und wie hoch sind die Kosten?
Welche Funktionen sind in welchem Umfang verfügbar?
Es wird eine Vielzahl von Funktionsangeboten der verschiedenen Anbieter geben, darunter:
- ABR-Streaming - Wie viele Streams und welche relevanten Bitraten- oder Auflösungsbeschränkungen gibt es?
- Was ist mit DVR-Funktionen? Können die Zuschauer die Wiedergabe stoppen und neu starten, ohne Inhalte zu verlieren?
- Videosynchronisation - Kann das System alle Viewer mit demselben Punkt im Stream synchronisieren? Streams können über Standorte und Geräte driften, und ohne diese Funktion haben Benutzer bei einigen Verbindungen möglicherweise einen Vorteil für Auktionen oder Glücksspiele.
- Welcher Inhaltsschutz ist verfügbar? Wenn Sie ein Premium-Content-Produzent sind, benötigen Sie möglicherweise echtes DRM. Andere können mit Authentifizierung oder anderen ähnlichen Techniken auskommen.
- Sind Bildunterschriften verfügbar? Untertitel sind für einige Sendungen gesetzlich vorgeschrieben, aber im Allgemeinen für alle von Vorteil.
- Was ist mit Werbeeinfügung oder einem anderen Monetarisierungsschema? Unterstützt der Technologie- / Dienstleister dies?
Wenn Sie ein Streaming-Shop sind, der Sendezeiten im Bereich von 5 bis 6 Sekunden einhalten oder übertreffen möchte, ist eine standardbasierte HTTP-Technologie wahrscheinlich die beste Wahl, da sie der Unterstützung des gleichen Funktionsumfangs am nächsten kommt. Derzeit werden beispielsweise Inhaltsschutz, Untertitel und Monetarisierung verwendet. Wenn Sie eine Anwendung haben, die eine viel geringere Latenz erfordert, benötigen Sie wahrscheinlich eine WebRTC- oder Websockets-basierte Lösung oder eine proprietäre HTTP-Technologie. In beiden Fällen können Sie anhand der oben aufgeführten Fragen den Technologie- und / oder Dienstanbieter ermitteln, der Ihren Anforderungen am besten entspricht.
