Während der EM 2024 haben mehr als 11,5 Millionen britische Haushalte mindestens ein Spiel der Heimnationen über das Breitbandnetz von BT gestreamt. BT berichtete später, dass der Datenverkehr von BBC und ITV auf mehr als das 30-Fache des normalen Wochenvolumens stieg und beide Sender kurzzeitig Netflix, Facebook und YouTube als größte Inhaltequellen im Netz überholten. Die einzelne größte Verkehrsspitze des Turniers fiel auf den Moment, als Cole Palmer im Finale ausglich.
Der nächste Test dieser Größenordnung ist nur einen Monat entfernt. Die FIFA-Weltmeisterschaft 2026 beginnt im Juni, ausgetragen in den Vereinigten Staaten, Kanada und Mexiko, und ihr Live-Publikum landet auf denselben Festnetz- und Mobilfunknetzen, die nie dafür gebaut wurden, dasselbe Spiel an jeden Haushalt als eigenen Stream zu schicken.
Eine solche Spitze ist für ein Netz schwer zu verkraften, und der Grund ist struktureller Natur. Jedes heute weit verbreitete Streaming-Format, HLS und DASH eingeschlossen, basiert auf Unicast. Jeder Zuschauer öffnet seine eigene Sitzung und holt sich seine eigene Kopie jedes Segments. Zehn Zuschauer auf demselben Kanal bedeuten zehn identische Streams, die das Netz durchqueren. Eine Million Zuschauer bedeutet eine Million identischer Streams. Der Inhalt ist für alle derselbe, aber das Netz transportiert ihn, als wäre jede Kopie eine andere Sache.
Multicast ABR, meist zu mABR abgekürzt, ist die wichtigste Antwort der Streaming-Branche auf dieses Problem. Es ist nicht neu, es ist bereits standardisiert, und eine Handvoll großer Telekommunikationsanbieter betreibt es bereits produktiv. Es hat auch echte Grenzen, die man verstehen sollte, bevor man es als Allheilmittel betrachtet. Dieser Artikel behandelt, was mABR ist, wie es funktioniert, was es tatsächlich einspart, wo es zu kurz greift, wer es eingesetzt hat und warum die von GPAC und Motion Spell geführte Open-Source-Arbeit für die Zukunft der Technologie wichtig ist.
Was ist Multicast ABR?
Multicast ABR liefert gewöhnliche Inhalte mit adaptiver Bitrate, dieselben HLS- oder DASH-Segmente, die ein normaler Player ohnehin erwartet, über IP-Multicast statt über Unicast. In einem gemanagten Betreibernetz wird ein Kanal einmal als Multicast-Stream durch das Netz geschickt, dem sich beliebig viele Haushalte anschließen können. Die Rückumwandlung in normales Unicast-HTTP geschieht im Haushalt oder in dessen Nähe, sodass das Gerät und sein Player nie merken, dass sich etwas geändert hat. Aus Sicht des Players fordert er weiterhin Segmente per HTTP von etwas an, das wie ein nahegelegener CDN-Edge aussieht.
Die Grundidee ist einfach. Bei Unicast bedeutet ein Zuschauer einen Stream. Bei Multicast bedeutet ein Kanal einen Stream, unabhängig davon, wie viele Haushalte zuschauen.
Zwei Punkte sollten klar benannt werden. Erstens ist mABR hybrid. Multicast übernimmt die Massenauslieferung, und Unicast bleibt als Reparatur- und Rückfallweg im Spiel. Zweitens ist mABR für Live- und lineare Inhalte konzipiert. Das Tech-Brief der Streaming Video Technology Alliance, eines Branchengremiums, dessen Multicast-ABR-Papier von einem Ericsson-Ingenieur mit Beiträgen von Betreibern wie Comcast geleitet wurde, sagt ausdrücklich, dass Video on Demand weiterhin von einem CDN kommt. mABR rechtfertigt sich, wenn viele Menschen gleichzeitig dasselbe schauen, also bei Live-Sport und Live-Nachrichten.
Multicast-Video ist nicht neu, besonders nicht in Frankreich
Man sollte sich klarmachen, dass die Multicast-Auslieferung von Fernsehen Jahrzehnte alt ist, und Frankreich ist eines der besten Beispiele dafür, dass sie im großen Maßstab funktioniert. Als Free Anfang der 2000er-Jahre die Freebox einführte, baute der Anbieter die Fernsehauslieferung über IP-Multicast direkt in sein eigenes entbündeltes DSL-Netz ein, etwas, das die DSLAMs des etablierten Betreibers damals nicht boten. Bis 2008 war Free der größte IPTV-Anbieter der Welt. Multicast war der Grund, warum die Rechnung aufging: Eine einzige Kopie jedes Kanals lief durch das Netz, ganz gleich, wie viele Freebox-Haushalte sie gerade ansahen.
Free stellte diesen Multicast-Feed den Abonnenten auch direkt zur Verfügung, über einen Dienst namens Multiposte. Damit konnte man die Freebox-TV-Kanäle neben dem Fernseher auch auf einem Computer ansehen, indem man eine Playlist der Kanäle in VLC öffnete. Die Streams waren schlichtes IP-Multicast, über die Freebox transportiert und per IGMP beigetreten, ganz ohne Set-Top-Box. Eine Generation französischer Breitbandnutzer hatte faktisch einen Multicast-Fernsehempfänger auf ihrem PC laufen.
Auch das Werkzeug war nie exotisch. VLC, derselbe Player, auf den sich Multiposte stützte, kann einen Unicast-Stream als Eingang nehmen und ihn über UDP oder RTP mit einer einzigen Stream-Output-Konfiguration an eine Multicast-Adresse weitersenden. Einen Unicast-Feed in einen Multicast-Feed zu verwandeln ist für sich genommen ein gewöhnliches und längst gelöstes Problem.
Wenn Multicast also alt ist und die Werkzeuge überall verfügbar sind, was ist dann wirklich neu an Multicast ABR? Klassisches Multicast-IPTV, das Freebox-Modell, transportierte einen festen, kontinuierlichen Transportstrom zur betreibereigenen Set-Top-Box. mABR transportiert stattdessen moderne Inhalte mit adaptiver Bitrate, die HLS- und DASH-Segmente, die jedes Smartphone, Tablet, jeder Smart-TV und jeder Streaming-Stick bereits spricht, und zielt damit auf das gesamte fragmentierte Geräte-Ökosystem statt auf eine einzige proprietäre Box. Der schwierige Teil von mABR ist nicht das Multicast. Es ist, Multicast für segmentiertes, adaptives Streaming über viele Geräte zu betreiben, mit der dafür nötigen Mechanik aus Gateway, Rendezvous und Reparatur.
Wie mABR funktioniert
Die DVB-MABR-Spezifikation, vom DVB Project entwickelt und von ETSI als TS 103 769 veröffentlicht, definiert eine Referenzarchitektur aus einem kleinen Satz benannter Funktionen:
- Multicast-Server. Er nimmt Standard-ABR-Inhalte von einem CDN-Origin oder -Edge auf, ordnet jedes Segment einem oder mehreren Multicast-Transportobjekten zu und überträgt sie per IP-Multicast. Ein Betreiber sagt ihm über eine Konfigurations-API, welche Streams er erfassen und wie er sie senden soll.
- Multicast-Gateway. Es empfängt den Multicast-Stream und wandelt ihn für lokale Player wieder in einfaches HTTP um. Es verhält sich wie ein kleiner lokaler Cache und HTTP-Proxy.
- Multicast-Rendezvous-Dienst. Er leitet die erste Anfrage eines Players per HTTP-Weiterleitung an das richtige Gateway, basierend auf dem Diensteplan und den Geschäftsregeln des Betreibers.
- Unicast-Reparatur. Gehen Multicast-Pakete verloren, holt das Gateway die fehlenden Teile per Unicast nach, typischerweise über HTTP-Byte-Range-Anfragen, damit die Wiedergabe nicht abbricht.
Wo das Gateway läuft
Die Spezifikation ist bewusst flexibel, wo das Multicast-Gateway sitzt. Es kann im Netz des Betreibers laufen, im Heim-Gateway oder Router, im optischen Netzabschluss oder direkt in der Set-Top-Box. Wenn Gateway und Player auf demselben Gerät sitzen, kann die Schnittstelle zwischen beiden laut DVB-Spezifikation einfach eine lokale API sein. Das SVTA-Brief beschrieb dieselbe Komponente, die es Multicast-Client nannte, als einsetzbar auf einer Set-Top-Box, einem Heim-Gateway, einem ONT oder im Edge-Cache des Betreibers. Letztere Option ist für sich genommen nützlich: Ein in einen CDN-Edge eingebetteter mABR-Client kann den Cache per Multicast befüllen und Anfragen zurück zum Origin reduzieren.
Transportprotokolle
Darunter nutzt mABR Dateiauslieferungsprotokolle, die für einseitiges Multicast gebaut wurden. DVB-MABR macht zwei davon verpflichtend. FLUTE (File Delivery over Unidirectional Transport, RFC 6726) stammt aus der 3GPP-Welt. ROUTE (Real-Time Object Delivery over Unidirectional Transport, RFC 9223) stammt aus ATSC 3.0. Eine Überarbeitung der Spezifikation von 2023 fügte zwei optionale Protokolle hinzu, NORM (NACK-Oriented Reliable Multicast, RFC 5740) und MSYNC. Alle laufen über UDP und transportieren die segmentierten Inhalte zusammen mit Vorwärtsfehlerkorrektur.
Eine nützliche Eigenschaft: mABR ist format-, codec- und DRM-agnostisch. Es bewegt HLS oder DASH, MPEG-TS oder CMAF, verschlüsselt oder nicht, und es kodiert nichts neu. Es ändert, wie die Bytes reisen, nicht, was sie sind.
Die Vorteile von Multicast ABR
Skalierung, worum es eigentlich geht
Das Kernargument für mABR ist, dass die Netzkosten eines beliebten Live-Kanals aufhören, mit dem Publikum zu wachsen. Das SVTA-Tech-Brief veranschaulicht das mit zwei Beispielen aus Zugangsnetzen. In einem DOCSIS-Kabelnetz wächst die Zahl der für Unicast-ABR nötigen Kanäle linear, je mehr Zuschauer hinzukommen, während sie mit mABR kurz ansteigt und sich dann abflacht, weil die Zuschauer dieselben Multicast-Streams teilen. Für ein GPON-Glasfasernetz schätzt das Brief, dass bei einem Betreiber mit 500 linearen Kanälen, bei dem 80 Prozent der Zuschauer 10 Prozent des Angebots schauen, die Einsparungen an Bandbreite im Kernnetz bei 32 Kunden pro PON rund 50 Prozent erreichen und der Bandbreitenbedarf pro Zuschauer unter 3 Prozent des Unicast-Werts fällt, sobald das Publikum in die Zehntausende geht. Das Brief formuliert es unverblümt: mABR kann den Bandbreitenbedarf am Netzrand für extrem beliebte Live-Events von Petabyte auf Megabyte senken.
Es gibt eine Zahl, die direkt von einem Betreiber stammt und nicht aus einer modellierten Schätzung. Im März 2025 berichtete BT Group von seinem ersten erfolgreichen Test von MAUD, seinem Namen für Multicast-Assisted Unicast Delivery, der Live-Inhalte von BBC Two an EE-Set-Top-Boxen im produktiven Netz auslieferte. In Spitzenzeiten wandelte der Test mehr als 60 Prozent des Verkehrs von Unicast in Multicast um.
Quality of Experience
mABR wird als gemanagter Dienst statt als Best-Effort-Dienst geliefert. Das SVTA-Brief weist darauf hin, dass dies den Wiedergabe-Jitter mindert, weil der Betreiber den Pfad kontrolliert, statt sich auf das offene Internet zwischen Origin und Zuschauer zu verlassen. Bei einem Live-Finale zählt eine gleichmäßige Auslieferung an alle Zuschauer ebenso viel wie die reine Bandbreitenersparnis.
Es nutzt, was schon da ist
Das SVTA-Brief betont, dass die Infrastrukturkosten von mABR niedriger sein können als bei anderen Skalierungsoptionen, weil die meisten beteiligten Router und Netzelemente bereits im Netz des Betreibers vorhanden sind. mABR ergänzt das CDN-Caching, statt es zu ersetzen, und kann als Inhaltsquelle dienen, die Edge-Caches befüllt.
Die Nachteile von Multicast ABR
Zusätzliche Latenz
Das Multicast-Gateway muss Segmente empfangen und wieder zusammensetzen, bevor es sie ausliefern kann, was dem ABR-Quellstream Verzögerung hinzufügt. Eine technische Analyse von Techne Digitale schätzt, dass mABR einer typischen OTT-Auslieferung rund zwei Segmente Verzögerung hinzufügt und den Ende-zu-Ende-Wert von etwa 8 Sekunden auf etwa 12 treibt. Das SVTA-Brief argumentiert, dass ein sorgfältiges Design, etwa mit kürzeren Segmentdauern und CMAF-Chunked-Transfer, mABR mit reinem Unicast-ABR konkurrenzfähig oder sogar darunter halten kann. So oder so ist Latenz ein echtes Thema für Live-Sport, wo ein Zuschauer, der einen Nachbarn reagieren hört, bevor die Aktion auf seinem eigenen Bildschirm ankommt, das merken wird.
Das Problem des Client-Ökosystems
Das SVTA-Brief nennt das Fehlen eines verbreiteten Client-Ökosystems das wichtigste Hindernis für eine breitere mABR-Einführung. Alte Heim-Gateways und ONTs haben oft nicht die CPU und den Speicher, um einen Multicast-Client zu betreiben. Neuere Hardware kann das, aber Gerätehersteller haben wenig Grund, Multicast-Client-Software zu bauen, zu testen und zu pflegen, solange es keine Infrastruktur dafür gibt, und Betreiber haben wenig Grund, Infrastruktur einzusetzen, solange die Geräte sie nicht nutzen können. Bei einer Veranstaltung des CSI Magazine Anfang 2023 merkte BTs TV-Architekt Simon Jones an, dass BT seit über einem Jahrzehnt Multicast-Fernsehen betreibe, es aber nur an Fernseher und nicht an verbundene Geräte ausliefere, und dass BT mit seiner bestehenden Infrastruktur etwas wie die Weltmeisterschaft nicht ausliefern könne. Bob Hannent, Architekt für Videowiedergabe und -auslieferung bei DAZN, sagte in derselben Diskussion, der Markt sei noch „wirklich unreif“. Beide nannten den Mangel an Unterstützung durch Gerätehersteller wie Google und Apple als das Haupthindernis.
Es funktioniert nur in gemanagten Netzen
Im öffentlichen Internet gibt es kein Multicast. mABR funktioniert innerhalb des gemanagten Netzes eines einzelnen Betreibers, zwischen einem Multicast-Server, den der Betreiber betreibt, und einem Gateway, das der Betreiber kontrolliert. Ein reiner OTT-Dienst wie Netflix kann mABR nicht eigenständig Ende zu Ende einsetzen. Er kann ISPs bitten, es zu unterstützen, aber er hängt von jedem ISP einzeln ab.
Fragmentierung
Weil es lokal zu jedem Netz ist, ist mABR nur so wirksam wie der ISP, auf dem es läuft. Wenn die Hälfte der ISPs, die ein Publikum versorgen, es unterstützt, bekommen die Zuschauer der anderen Hälfte weiterhin das Unicast-Erlebnis und dieselbe Überlastung. Anders als ein Unicast-CDN kann kein einzelnes Unternehmen ein mABR-Erlebnis Ende zu Ende über das gesamte Publikum hinweg liefern.
Das Problem schrumpft womöglich in modernen Netzen
Die Analyse von Techne Digitale argumentiert, dass auf moderner GPON-Glasfaser, wo ein 1:64-Split jedem Haushalt immer noch zig Megabit pro Sekunde lässt, die Bandbreitenenge auf der letzten Meile, für die mABR entworfen wurde, womöglich gar nicht existiert, und dass mABR am ehesten in älteren Kabelnetzen Sinn ergibt. Das SVTA-Brief wirft selbst eine ähnliche Frage auf und fragt, ob Jahre des CDN-Edge-Ausbaus, bessere Codecs wie HEVC, AV1 und VVC und neue Transportprotokolle der Branche nicht bereits einen Vorsprung vor der Wachstumskurve verschafft haben. Es lohnt sich, daran zu erinnern, dass Comcasts eigenes frühes mABR-Projekt, das seine VIPER-Forschungsgruppe um 2015 betrieb, nie zum Einsatz kam.
Mehrere Varianten zehren an der Ersparnis
Jedes Format, jede Bitratenstaffel und jede DRM-Variante, die ein Betreiber ausliefern will, muss separat per Multicast gesendet werden. Je mehr Gerätetypen und Inhaltsschutzverfahren im Spiel sind, desto mehr parallele Multicast-Streams werden benötigt, und desto kleiner wird der Netto-Effizienzgewinn.
Wer mABR tatsächlich einsetzt
mABR hat das Laborstadium hinter sich. Die klarsten öffentlichen Beispiele kommen von Telekommunikationsanbietern, die ihre eigenen gemanagten Zugangsnetze betreiben.
- BT Group im Vereinigten Königreich war am offensten dazu. BT kündigte 2024 seine MAUD-Initiative an und berichtete im März 2025 von seinem ersten erfolgreichen Live-Test, der BBC Two an EE-Set-Top-Boxen auslieferte und mehr als 60 Prozent des Spitzenverkehrs in Multicast umwandelte. BT hat erklärt, das Ziel sei, Live-Events mit Massenpublikum zu bewältigen, und Fachmedien haben berichtet, dass Sender MAUD für die FIFA-Weltmeisterschaft 2026 prüfen.
- Orange in Spanien hat seinen eigenen Kunden mitgeteilt, dass es der erste Betreiber des Landes ist, der mABR-Streaming für seine auflagenstärksten Live-Events anbietet, unter Nennung von LaLiga, Formel 1 und MotoGP, und es über die Set-Top-Box hinaus auf andere Geräte im Haushalt ausweitet.
- TIM in Italien hat in seiner eigenen Fachzeitschrift geschrieben, dass es seit 2021 eine Plattform für Multicast-Inhalteverteilung betreibt, die dem ETSI-M-ABR-Standard entspricht und genutzt wird, um massiven Live-Events wie Sport Skalierbarkeit hinzuzufügen, in das bestehende Unicast-Modell mit automatischem Rückfall integriert.
- Bouygues Telecom in Frankreich wurde von der Fachpresse als der erste französische Betreiber bezeichnet, der ab 2023 kommerziell in mABR streamt.
Nicht jeder Betreiber ist überzeugt. Die Deutsche Telekom hat mABR öffentlich als Übergangstechnologie eingeordnet, nützlich dort, wo die Infrastruktur reines Unicast noch nicht tragen kann, statt als langfristiges Ziel.
Ein Muster sticht über diese Einsätze hinweg hervor. Sie wurden fast alle auf derselben proprietären Implementierung eines einzelnen Anbieters gebaut, dem nanoCDN von Broadpeak, statt auf interoperablen, standardbasierten Stacks. Das ist eine Marktrealität, kein technisches Gütesiegel. Die DVB-MABR-Spezifikation ist öffentlich, aber jahrelang gab es keine neutrale, offen verfügbare Implementierung davon, an der man bauen und testen konnte, sodass ein Betreiber, der mABR produktiv wollte, kaum eine praktische Lieferantenwahl hatte.
Die Geräteseite
Auf der Hardwareseite zählen die Hersteller von Set-Top-Boxen und CPE ebenso viel wie die Betreiber. CommScope bietet eine Multicast-ABR-Lösung an, die es als auf Teilen sowohl des DVB- als auch des CableLabs-Standards basierend beschreibt, mit einem Client, der eingebettet in einer Set-Top-Box oder im Heim-Gateway laufen kann, und das Unternehmen erklärt, dass an den Streaming-Geräten im Haushalt keine Änderungen nötig sind. Vantiva, ehemals Technicolor, hat Set-Top-Boxen mit integrierter Multicast-ABR-Client-Software ausgeliefert. Set-Top-Box-Chipsätze von Anbietern wie Broadcom bieten IP-Multicast-Unterstützung auf Netzebene, aber mABR selbst ist als Software implementiert, die auf dem Gerät läuft, und nicht als benannte Chipsatzfunktion.
Die Lücke ist auf der größten Geräteplattform am sichtbarsten. Standard-Android-TV unterstützt nur Unicast, sodass Multicast ABR auf diesen Geräten von Integrationen auf Betreiberebene abhängt, die einen Multicast-Client hinzufügen. Googles eigene Player-Bibliotheken ExoPlayer und Media3 bieten Multicast ABR nicht von Haus aus, und es gibt eine offene Funktionsanfrage, die danach verlangt.
Der Standard existiert. Die Interoperabilität ist der schwierige Teil.
Es ist eine verbreitete Annahme, dass mABR durch einen fehlenden Standard ausgebremst wird. Das ist nicht der Fall.
CableLabs leistete um 2014 frühe Architekturarbeit zu IP-Multicast-ABR. Das DVB Project veröffentlichte seine Referenzarchitektur für Multicast ABR 2018 zur Kommentierung durch die Branche, sein Steering Board genehmigte die vollständige Spezifikation Anfang 2020, und sie wurde im November 2020 als ETSI-Standard TS 103 769 veröffentlicht. Sie wurde seither mehrfach überarbeitet, darunter ein Update von 2023, das die optionalen Transportprotokolle NORM und MSYNC sowie Funktionen für Reporting, Authentizität und Manipulationsschutz hinzufügte. Die dahinterstehende DVB-Arbeitsgruppe MCAST wird von Richard Bradbury von BBC R&D geleitet. Es gibt einen echten, veröffentlichten, international anerkannten Standard, begleitet von ergänzenden Arbeiten wie den DVB-MABR-Implementierungsrichtlinien und der DVB-I-Spezifikation zur Dienstefindung. Auf der Mobilfunkseite verfolgt 3GPP einen eigenen, parallelen Weg, mit der Architektur der 5G Multicast-Broadcast Services in Release 17, die dasselbe Protokollerbe von FLUTE und ROUTE teilt.
Was gefehlt hat, ist Interoperabilität in der Praxis. Fast jeder kommerzielle mABR-Einsatz bis heute läuft auf demselben proprietären Stack, dem nanoCDN von Broadpeak. MSYNC, eines der optionalen Transportprotokolle, die 2023 in DVB-MABR aufgenommen wurden, begann als Broadpeak-Protokoll, bevor es in die Spezifikation übernommen wurde. Ein Standard, der überwiegend von einem Anbieter implementiert wird, ist ein Standard auf dem Papier. Was eine Papierspezifikation in einen funktionierenden Markt mit mehreren Anbietern verwandelt, ist eine neutrale Implementierung, an der jeder bauen und testen kann.
Wo GPAC und Motion Spell ins Spiel kommen
Das ist der Teil der mABR-Geschichte, der den Weg zu echter Standardisierung weist.
GPAC ist ein langjähriges Open-Source-Multimedia-Framework, vertrieben unter der LGPL-Lizenz und entwickelt mit Motion Spell, seinem kommerziellen Partner. Es wurzelt in akademischer Forschung an der Telecom Paris und wurde fast 100 Millionen Mal heruntergeladen. GPAC implementierte vor Jahren das ROUTE-Protokoll für ATSC 3.0, eine Arbeit, die 2018 einen NAB-Innovationspreis gewann, und es ist das einzige Open-Source-Projekt, das sowohl ROUTE als auch FLUTE unterstützt, die beiden verpflichtenden DVB-MABR-Transportprotokolle. 2024 fügte es FLUTE-Unterstützung speziell für DVB-MABR hinzu. Der Media Server von GPAC kann bereits als Multicast-zu-ABR-Gateway fungieren und eine Multicast-Sitzung als normalen HTTP-Streaming-Dienst bereitstellen, mit Unicast-Reparatur und einem konfigurierbaren Zeitversatzfenster.
DVB schrieb daraufhin eine Ausschreibung für ein Open-Source-Werkzeug zur Verifizierung und Validierung von DVB-MABR-Implementierungen aus. Das Ergebnis, die DVB-MABR Reference Tools, baut auf GPAC und Motion Spell auf. Es ist Open Source, in Python auf der GPAC-Bibliothek geschrieben, und läuft in zwei Modi: einem Servermodus, der einen Multicast-Stream aus einer HTTP-Quelle erzeugt, und einem Gateway-Modus, der Multicast empfängt und über HTTP wieder ausliefert, einschließlich HTTP-Reparatur. Es ist in der GitHub-Organisation von DVB selbst veröffentlicht und richtet sich an Ingenieure, Integratoren und Validierungsteams, die bestätigen müssen, dass ein Multicast-Server, ein Gateway und Standard-DASH-Player tatsächlich interoperieren.
Deshalb zählt diese Arbeit mehr als eine weitere Produkteinführung. Eine lizenzfreie, offen verfügbare Referenzimplementierung gibt jedem Betreiber, Gerätehersteller und Softwareanbieter eine gemeinsame Grundlage. Sie ist der praktische Mechanismus, durch den DVB-MABR von einem Markt aus Einzelanbieter-Einsätzen zu echter Interoperabilität über mehrere Anbieter hinweg gelangen kann, was den Unterschied ausmacht zwischen einem veröffentlichten Standard und einem Standard, den das ganze Ökosystem tatsächlich nutzen kann. Die Beteiligung von GPAC verbindet mABR auch mit breiterer Forschung, darunter die Arbeit des SMART-CD-Konsortiums an einer nachhaltigeren Videoauslieferung, neben Partnern wie Telecom Paris, Ateme und Viaccess-Orca.
Am Rande: Peer-to-Peer greift dasselbe Problem von der anderen Seite an
mABR ist nicht der einzige Weg, zu verhindern, dass ein beliebter Live-Stream einmal pro Zuschauer gesendet wird. Die Peer-to-Peer-Auslieferung geht dieselbe Verschwendung aus der entgegengesetzten Richtung an. Statt eine Kopie in ein gemanagtes Netz zu schicken und sie nahe am Haushalt aufzufächern, lässt eine Peer-to-Peer-Schicht die Geräte der Zuschauer selbst Segmente untereinander teilen. Jeder Player holt die ersten Bytes vom CDN, tauscht dann Chunks direkt mit anderen Playern aus, die dasselbe schauen, und fällt nur dann auf das CDN zurück, wenn er muss.
Das französische Unternehmen Quanteec ist ein Beispiel. Seine Technologie, die als akademische Forschung begann, fügt einem bestehenden HLS- oder DASH-Workflow eine peer-unterstützte Schicht hinzu und ist CDN- und DRM-agnostisch. Quanteec berichtet, dass ein Einsatz mit France Télévisions, der Hunderttausende gleichzeitiger Zuschauer versorgte, im Durchschnitt rund 75 Prozent des Verkehrs vom CDN entlastete, bei mehr als 50 Prozent Energieeinsparung und weniger Pufferung als reines Unicast.
Der wichtige Kontrast zu mABR ist das Netz. mABR braucht ein gemanagtes Zugangsnetz und die Mitwirkung des Betreibers. Peer-to-Peer funktioniert über das öffentliche Internet, zwischen Geräten, ganz ohne Beteiligung des Betreibers, was genau die Lücke ist, die mABR nicht erreichen kann. Der Kompromiss ist, dass Peer-to-Peer davon abhängt, genug gleichzeitige Zuschauer zu haben, sowie von der Upload-Kapazität und dem Verhalten der Endkundengeräte. Die beiden Ansätze schließen sich nicht gegenseitig aus. Ein Sender ohne Kontrolle über die letzte Meile kann Peer-to-Peer heute nutzen, ein Betreiber, der sein eigenes Netz kontrolliert, kann mABR nutzen, und eine große Plattform könnte sich auf beides stützen.
Was das für Betreiber bedeutet
mABR ist kein Allheilmittel und es ist nicht neu. Es ist ein gezieltes Werkzeug für ein bestimmtes und teures Problem: denselben Live-Stream an ein sehr großes Publikum in einem gemanagten Netz auszuliefern, ohne für jede Kopie zu zahlen. Für einen Betreiber, der ein großes Sportfinale überträgt, ist dieses Problem real und es wird mit jeder Saison schlimmer. Für einen reinen OTT-Dienst ohne Kontrolle über die letzte Meile ist mABR etwas, das er ISPs zu unterstützen bitten, aber nicht allein bauen kann.
Die ehrliche Zusammenfassung ist, dass die Technologie funktioniert, der Standard existiert, die Einsätze real, aber noch auf proprietäre Einzelanbieter-Stacks konzentriert sind, dass Latenz und das Geräte-Ökosystem echte Einschränkungen bleiben, und dass die von GPAC und Motion Spell geführte Open-Source-Referenzarbeit der glaubwürdigste Weg ist, diese Konzentration zu verändern.
iReplay.TV ist ein Kollektiv von Broadcast- und Streaming-Ingenieuren, sodass die Abwägungen zwischen mABR, Peer-to-Peer und einfacher Unicast-CDN-Auslieferung zu dem gehören, was seine Mitglieder regelmäßig abwägen. Multicast ABR ist ein Hebel unter mehreren, und es hilft nur innerhalb eines gemanagten Netzes. Wenn Ihr Publikum Sie über das offene Internet erreicht, müssen die Einsparungen von woanders kommen: peer-unterstützte Auslieferung, klügeres Origin-Design, bessere Codec-Entscheidungen und straffere CDN-Konfiguration. Es gibt ein kostenloses CDN-Kostenoptimierungswerkzeug auf der Website für alle, die ihre eigenen Zahlen ansehen wollen.
Quellen und weiterführende Lektüre
- DVB, „Adaptive media streaming over IP multicast“ (DVB-MABR-Spezifikationsseite): dvb.org
- DVB, „DVB-I and DVB-MABR published as ETSI standards“: dvb.org/news
- DVB, „DVB publishes updated Multicast ABR specification and guidelines“ (Update von 2023): dvb.org/news
- DVB, „DVB-MABR Reference Tools“: dvb.org
- GPAC, „MABR: Multicast Adaptive BitRate“: gpac.io
- Motion Spell, „DVB-MABR Open-Source Tool“ (Quellcode-Repository): github.com/MotionSpell
- Streaming Video Technology Alliance, „The Viability of Multicast ABR in Future Streaming Architectures“: svta.org
- BT Group, „BT delivers first successful trial of new live streaming technology“: newsroom.bt.com
- CommScope, Multicast Adaptive Bitrate (MABR) Solution: commscope.com
- IETF: FLUTE (RFC 6726), ROUTE (RFC 9223), NORM (RFC 5740), verfügbar auf rfc-editor.org