Under EM 2024 strömmade mer än 11,5 miljoner brittiska hushåll minst en match med hemmanationernas lag över BT:s bredbandsnät. BT rapporterade senare att trafiken från BBC och ITV steg till mer än 30 gånger den normala veckovolymen, och att båda kanalerna kortvarigt gick om Netflix, Facebook och YouTube som de största innehållskällorna på nätet. Turneringens absolut största trafiktopp inföll i det ögonblick då Cole Palmer kvitterade i finalen.
Nästa prov av den storleken är bara en månad bort. Fotbolls-VM 2026 drar igång i juni, arrangerat i USA, Kanada och Mexiko, och dess livepublik landar på samma fasta och mobila nät, som aldrig byggdes för att skicka samma match till varje hushåll som en separat ström.
En sådan topp är svår för ett nät att ta upp, och orsaken är strukturell. Alla streamingformat som är i bred användning i dag, HLS och DASH inräknade, bygger på unicast. Varje tittare öppnar sin egen session och hämtar sin egen kopia av varje segment. Tio tittare på samma kanal innebär tio identiska strömmar som korsar nätet. En miljon tittare innebär en miljon identiska strömmar. Innehållet är detsamma för alla, men nätet transporterar det som om varje kopia vore något annat.
Multicast ABR, oftast förkortat mABR, är streamingbranschens främsta svar på det problemet. Det är inte nytt, det är redan standardiserat, och en handfull stora teleoperatörer kör det redan i drift. Det har också verkliga begränsningar som det är värt att förstå innan man behandlar det som en lösning på allt. Den här artikeln går igenom vad mABR är, hur det fungerar, vad det faktiskt sparar, var det inte räcker till, vilka som har tagit det i bruk, och varför open source-arbetet som leds av GPAC och Motion Spell har betydelse för teknikens framtid.
Vad är Multicast ABR?
Multicast ABR levererar vanligt innehåll med adaptiv bithastighet, samma HLS- eller DASH-segment som en normal spelare redan väntar sig, över IP-multicast i stället för unicast. På en operatörs hanterade nät skickas en kanal en gång genom nätet som en multicast-ström som ett godtyckligt antal hushåll kan ansluta sig till. Omvandlingen tillbaka till vanlig unicast-HTTP sker inne i eller nära hushållet, så att enheten och dess spelare aldrig märker att något har ändrats. Ur spelarens synvinkel begär den fortfarande segment via HTTP från något som ser ut som en närliggande CDN-edge.
Grundidén är enkel. Med unicast innebär en tittare en ström. Med multicast innebär en kanal en ström, oavsett hur många hushåll som tittar.
Två punkter är värda att vara tydliga med. För det första är mABR hybrid. Multicast sköter huvuddelen av leveransen, och unicast finns kvar i kretsloppet som reparations- och reservväg. För det andra är mABR utformat för direktsänt och linjärt innehåll. Den tekniska rapporten utgiven av Streaming Video Technology Alliance, ett branschorgan vars dokument om multicast ABR leddes av en Ericsson-ingenjör med bidrag från operatörer som Comcast, är tydlig: video on demand kommer fortfarande från ett CDN. mABR gör nytta när många människor tittar på samma sak samtidigt, alltså livesport och livenyheter.
Multicast-video är inget nytt, särskilt inte i Frankrike
Det är värt att vara tydlig med att leverans av tv via multicast har funnits i decennier, och Frankrike är ett av de bästa exemplen på att det fungerar i stor skala. I början av 2000-talet, när Free lanserade Freebox, byggde operatören in tv-leverans över IP-multicast direkt i sitt eget uppdelade DSL-nät, något som den etablerade operatörens DSLAM:er inte erbjöd på den tiden. År 2008 låg Free etta bland världens största IPTV-leverantörer. Multicast var skälet till att ekvationen gick ihop: en enda kopia av varje kanal löpte genom nätet, oavsett hur många Freebox-hushåll som tittade på den.
Free exponerade också den multicast-strömmen direkt för abonnenterna, via en tjänst som hette Multiposte. Den lät dig se Freebox TV-kanalerna på en dator vid sidan av tv:n, genom att öppna en spellista med kanaler i VLC. Strömmarna var enkel IP-multicast som transporterades över Freeboxen och anslöts med IGMP, helt utan en digitalbox. En hel generation franska bredbandsanvändare hade i praktiken en multicast-tv-mottagare igång på sin dator.
Verktygen har aldrig varit exotiska heller. VLC, samma spelare som Multiposte vilade på, kan ta en unicast-ström som indata och återutsända den till en multicast-adress över UDP eller RTP med en enda konfiguration för strömutgång. Att göra om en unicast-ström till en multicast-ström är i sig ett vanligt och sedan länge löst problem.
Så om multicast är gammalt och verktygen finns överallt, vad är egentligen nytt med Multicast ABR? Klassisk multicast-IPTV, Freebox-modellen, transporterade en fast, kontinuerlig transportström till operatörens egen digitalbox. mABR transporterar i stället modernt innehåll med adaptiv bithastighet, de HLS- och DASH-segment som varje telefon, surfplatta, smart-tv och streamingsticka redan talar, och riktar det mot hela det fragmenterade ekosystemet av enheter i stället för mot en enda proprietär box. Den svåra delen av mABR är inte själva multicasten. Det är att göra multicast för segmenterad, adaptiv streaming över många enheter, med den gateway-, rendezvous- och reparationsmekanik som det kräver.
Så fungerar mABR
DVB-MABR-specifikationen, utvecklad av DVB Project och utgiven av ETSI som TS 103 769, definierar en referensarkitektur uppbyggd av en liten uppsättning namngivna funktioner:
- Multicast-server. Den tar in standardiserat ABR-innehåll från en CDN-origin eller -edge, kopplar varje segment till ett eller flera multicast-transportobjekt och sänder dem över IP-multicast. En operatör talar om för den via ett konfigurations-API vilka strömmar den ska fånga upp och hur den ska skicka dem.
- Multicast-gateway. Den tar emot multicast-strömmen och omvandlar den tillbaka till vanlig HTTP för lokala spelare. Den beter sig som en liten lokal cache och HTTP-proxy.
- Multicast-rendezvoustjänst. Den dirigerar en spelares första begäran, via en HTTP-omdirigering, till rätt gateway utifrån operatörens tjänsteplan och affärsregler.
- Unicast-reparation. När multicast-paket går förlorade hämtar gatewayen de saknade delarna via unicast, vanligen med HTTP byte-range-begäran, så att uppspelningen inte bryts.
Var gatewayen körs
Specifikationen är medvetet flexibel kring var multicast-gatewayen sitter. Den kan köras i operatörens nät, i hemmagatewayen eller routern, i den optiska nätterminalen, eller direkt inne i digitalboxen. När gatewayen och spelaren sitter på samma enhet säger DVB-specifikationen att gränssnittet mellan dem helt enkelt kan vara ett lokalt API. SVTA-rapporten beskrev samma komponent, som den kallade multicast-klienten, som möjlig att rulla ut på en digitalbox, en hemmagateway, en ONT eller inuti operatörens edge-cache. Det sista alternativet är användbart i sig: en mABR-klient inbäddad i en CDN-edge kan fylla cachen via multicast och minska antalet begäranden tillbaka till origin.
Transportprotokoll
Under detta använder mABR filleveransprotokoll byggda för enkelriktad multicast. DVB-MABR gör två av dem obligatoriska. FLUTE (File Delivery over Unidirectional Transport, RFC 6726) kommer från 3GPP-världen. ROUTE (Real-Time Object Delivery over Unidirectional Transport, RFC 9223) kommer från ATSC 3.0. En revidering av specifikationen från 2023 lade till två valfria protokoll, NORM (NACK-Oriented Reliable Multicast, RFC 5740) och MSYNC. Alla körs över UDP och transporterar det segmenterade innehållet tillsammans med framåtriktad felkorrigering.
En användbar egenskap: mABR är agnostiskt vad gäller format, codec och DRM. Det flyttar HLS eller DASH, MPEG-TS eller CMAF, krypterat eller inte, och det kodar inte om något. Det ändrar hur byten färdas, inte vad de är.
Fördelarna med Multicast ABR
Skalning, som är hela poängen
Kärnargumentet för mABR är att nätkostnaden för en populär livekanal slutar växa med publiken. SVTA:s tekniska rapport illustrerar detta med två exempel från accessnät. På ett DOCSIS-kabelnät växer antalet kanaler som behövs för unicast ABR linjärt allteftersom tittare tillkommer, medan det med mABR stiger kort och sedan planar ut, eftersom tittarna delar samma multicast-strömmar. För ett GPON-fibernät uppskattar rapporten att för en operatör med 500 linjära kanaler, där 80 procent av tittarna ser 10 procent av utbudet, når bandbreddsbesparingen i kärnnätet runt 50 procent vid 32 kunder per PON, och att bandbreddsbehovet per tittare faller under 3 procent av unicast-siffran när publiken når upp i tiotusental. Rapporten formulerar det rakt på sak: mABR kan minska bandbreddsbehovet i nätets utkant för extremt populära livesändningar från petabyte-storlek till megabyte-storlek.
Det finns en siffra som kommer direkt från en operatör och inte från en modellerad uppskattning. I mars 2025 rapporterade BT Group om sitt första lyckade test av MAUD, företagets namn för Multicast-Assisted Unicast Delivery, som levererade liveinnehåll från BBC Two till EE-digitalboxar i driftsnätet. Under rusningstid omvandlade testet mer än 60 procent av trafiken från unicast till multicast.
Upplevelsekvalitet
mABR levereras som en hanterad tjänst i stället för en best effort-tjänst. SVTA-rapporten påpekar att detta dämpar uppspelningsjitter, eftersom operatören styr vägen i stället för att förlita sig på det öppna internet mellan origin och tittare. För en livefinal betyder en jämn leverans till alla som tittar lika mycket som den rena bandbreddsbesparingen.
Det återanvänder det som redan finns
SVTA-rapporten framhåller att infrastrukturkostnaden för mABR kan vara lägre än för andra skalningsalternativ, eftersom de flesta av de routrar och nätelement som är inblandade redan är utrullade i operatörens nät. mABR är dessutom ett komplement till CDN-cachning snarare än en ersättning, och kan fungera som den innehållskälla som fyller edge-cachar.
Nackdelarna med Multicast ABR
Extra fördröjning
Multicast-gatewayen måste ta emot och sätta ihop segmenten igen innan den kan leverera dem, vilket lägger fördröjning ovanpå ABR-källströmmen. En teknisk analys, utgiven av Techne Digitale, uppskattar att mABR lägger ungefär två segments fördröjning ovanpå en typisk OTT-leverans, och därmed skjuter end-to-end-siffran från omkring 8 sekunder till omkring 12. SVTA-rapporten argumenterar för att en omsorgsfull utformning, bland annat med kortare segmentlängder och CMAF chunked transfer, kan hålla mABR konkurrenskraftigt med vanlig unicast ABR, eller till och med under. Hur som helst är fördröjning en verklig fråga för livesport, där en tittare som hör en granne reagera innan händelsen når den egna skärmen kommer att märka det.
Problemet med klientekosystemet
SVTA-rapporten kallar avsaknaden av ett utrullat klientekosystem för det främsta hindret för en bredare spridning av mABR. Gamla hemmagatewayer och ONT:er har ofta inte den processor och det minne som krävs för att köra en multicast-klient. Nyare hårdvara klarar det, men enhetstillverkare har få skäl att bygga, testa och underhålla programvara för multicast-klienter så länge det inte finns någon infrastruktur som använder den, och operatörer har få skäl att rulla ut infrastruktur så länge enheterna inte kan använda den. Vid ett evenemang i regi av CSI Magazine i början av 2023 noterade BT:s tv-arkitekt Simon Jones att BT hade drivit multicast-tv i över ett decennium, men bara levererat den till tv-apparater och inte till uppkopplade enheter, och att BT inte skulle kunna leverera något som ett VM med sin befintliga infrastruktur. Bob Hannent, arkitekt för videouppspelning och -leverans hos DAZN, sade i samma samtal att marknaden fortfarande var "verkligen omogen". Båda pekade på bristen på stöd från enhetstillverkare som Google och Apple som det främsta hindret.
Det fungerar bara på hanterade nät
Det finns ingen multicast på det publika internet. mABR fungerar inom en enskild operatörs hanterade nät, mellan en multicast-server som operatören driver och en gateway som operatören styr. En renodlad OTT-tjänst som Netflix kan inte rulla ut mABR från ände till ände på egen hand. Den kan be ISP:er att stödja det, men den är beroende av varje ISP för sig.
Fragmentering
Eftersom det är lokalt för varje nät är mABR bara så effektivt som den ISP det körs på. Om hälften av de ISP:er som betjänar en publik stödjer det, får tittarna hos den andra hälften fortfarande unicast-upplevelsen och samma trängsel. Till skillnad från ett unicast-CDN kan inget enskilt företag leverera en mABR-upplevelse från ände till ände till hela publiken.
Problemet krymper kanske på moderna nät
Analysen från Techne Digitale argumenterar för att på modern GPON-fiber, där en 1:64-delning fortfarande lämnar varje hushåll med tiotals megabit per sekund, finns kanske inte den bandbreddsflaskhals på sista milen som mABR utformades för, och att mABR är mest meningsfullt på äldre kabelnät. SVTA-rapporten väcker själv en liknande fråga, och frågar om år av utbyggnad av CDN-edge, bättre codecs som HEVC, AV1 och VVC, och nya transportprotokoll inte redan har låtit branschen hålla sig före tillväxtkurvan. Det är värt att minnas att Comcasts eget tidiga mABR-projekt, drivet av företagets VIPER-forskningsgrupp omkring 2015, aldrig nådde fram till en utrullning.
Flera varianter äter upp besparingen
Varje format, varje bithastighetsstege och varje DRM-variant som en operatör vill leverera måste skickas via multicast var för sig. Ju fler enhetstyper och innehållsskydd som är i spel, desto fler parallella multicast-strömmar krävs, och desto mindre blir den samlade effektivitetsvinsten.
Vem som faktiskt använder mABR
mABR har passerat laboratoriestadiet. De tydligaste offentliga exemplen kommer från teleoperatörer som driver sina egna hanterade accessnät.
- BT Group i Storbritannien har varit mest öppen om det. BT tillkännagav sitt MAUD-initiativ 2024 och rapporterade om sitt första lyckade livetest i mars 2025, som levererade BBC Two till EE-digitalboxar och omvandlade mer än 60 procent av topptrafiken till multicast. BT har sagt att målet är att klara livesändningar med en masspublik, och fackpressen har rapporterat att tv-bolag utvärderar MAUD för fotbolls-VM 2026.
- Orange i Spanien har berättat för sina egna kunder att företaget är den första operatören i landet som erbjuder mABR-streaming för sina livesändningar med störst publik, med hänvisning till LaLiga, Formel 1 och MotoGP, och att det utökas bortom digitalboxen till andra enheter i hemmet.
- TIM i Italien har skrivit i sin egen tekniska tidskrift att företaget sedan 2021 driver en plattform för innehållsdistribution via multicast som följer ETSI:s M-ABR-standard, använd för att lägga till skalbarhet för massiva livesändningar som sport, integrerad med den befintliga unicast-modellen med automatiskt återfall.
- Bouygues Telecom i Frankrike framställdes av fackpressen som den första franska operatören som sänder kommersiellt i mABR, från 2023.
Alla operatörer är inte övertygade. Deutsche Telekom har offentligt framställt mABR som en övergångsteknik, användbar där infrastrukturen ännu inte klarar ren unicast, snarare än som ett långsiktigt mål.
Ett mönster sticker ut tvärs över dessa utrullningar. De har nästan alla byggts på samma proprietära implementering från en enda leverantör, Broadpeaks nanoCDN, i stället för på interoperabla, standardbaserade stackar. Det är ett marknadsfaktum, inte ett tekniskt godkännande. DVB-MABR-specifikationen är offentlig, men i åratal fanns det ingen neutral, öppet tillgänglig implementering av den att bygga på och testa mot, så att en operatör som ville ha mABR i drift hade föga praktiskt val av leverantör.
Enhetssidan
På hårdvarusidan väger tillverkarna av digitalboxar och kundutrustning lika tungt som operatörerna. CommScope erbjuder en Multicast ABR-lösning som företaget beskriver som baserad på delar av både DVB- och CableLabs-standarderna, med en klient som kan köras inbäddad i en digitalbox eller i hemmagatewayen, och företaget anger att inga ändringar behövs på streamingenheterna i hemmet. Vantiva, tidigare Technicolor, har levererat digitalboxar med inbyggd programvara för multicast ABR-klienter. Chipset för digitalboxar från leverantörer som Broadcom säkerställer stöd för IP-multicast på nätnivå, men själva mABR är implementerat i programvara som körs på enheten, och inte som en namngiven chipsetfunktion.
Klyftan är mest synlig på den största enhetsplattformen. Vanlig Android TV stödjer bara unicast, så att multicast ABR på de enheterna är beroende av integrationer på operatörsnivå som lägger till en multicast-klient. Googles egna spelarbibliotek ExoPlayer och Media3 tillhandahåller inte multicast ABR inbyggt, och det finns en öppen funktionsbegäran som efterlyser det.
Standarden finns. Interoperabiliteten är den svåra delen.
Det är ett vanligt antagande att mABR bromsas av en saknad standard. Så är inte fallet.
CableLabs gjorde tidigt arkitekturarbete kring IP-multicast ABR omkring 2014. DVB Project publicerade sin referensarkitektur för multicast ABR för synpunkter från branschen 2018, företagets Steering Board godkände den fullständiga specifikationen i början av 2020, och den gavs ut som ETSI-standarden TS 103 769 i november 2020. Den har reviderats flera gånger sedan dess, däribland en uppdatering 2023 som lade till de valfria transportprotokollen NORM och MSYNC tillsammans med funktioner för rapportering, äkthet och skydd mot manipulering. DVB-arbetsgruppen bakom den, MCAST, leds av Richard Bradbury från BBC R&D. Det finns en verklig, publicerad, internationellt erkänd standard, åtföljd av kompletterande arbete som DVB-MABR:s implementeringsriktlinjer och DVB-I-specifikationen för tjänsteupptäckt. På mobilsidan följer 3GPP sitt eget, parallella spår, med arkitekturen för 5G Multicast-Broadcast Services i Release 17, som delar samma protokollarv från FLUTE och ROUTE.
Det som har saknats är interoperabilitet i praktiken. Nästan varje kommersiell mABR-utrullning hittills körs på samma proprietära stack, Broadpeaks nanoCDN. MSYNC, ett av de valfria transportprotokoll som togs in i DVB-MABR 2023, började som ett Broadpeak-protokoll innan det fördes in i specifikationen. En standard som till största delen implementeras av en enda leverantör är en standard på pappret. Det som gör en pappersspecifikation till en fungerande marknad med flera leverantörer är en neutral implementering som alla kan bygga på och testa mot.
Här kommer GPAC och Motion Spell in
Det här är den del av mABR-historien som pekar mot verklig standardisering.
GPAC är ett långlivat ramverk för multimedia med öppen källkod, distribuerat under LGPL-licensen och utvecklat tillsammans med Motion Spell, dess kommersiella partner. Det har rötter i akademisk forskning vid Telecom Paris och har laddats ner nästan 100 miljoner gånger. GPAC implementerade ROUTE-protokollet för ATSC 3.0 för flera år sedan, ett arbete som vann ett innovationspris från NAB 2018, och det är det enda projektet med öppen källkod som stödjer både ROUTE och FLUTE, de två obligatoriska DVB-MABR-transportprotokollen. År 2024 lade det till FLUTE-stöd specifikt för DVB-MABR. GPAC:s mediaserver kan redan fungera som en gateway från multicast till ABR, och exponera en multicast-session som en vanlig HTTP-streamingtjänst, med unicast-reparation och ett konfigurerbart tidsförskjutningsfönster.
DVB utlyste därefter en anbudsförfrågan om ett verktyg med öppen källkod för att verifiera och validera DVB-MABR-implementeringar. Resultatet, DVB-MABR Reference Tools, bygger på GPAC och Motion Spell. Det är öppen källkod, skrivet i Python ovanpå GPAC-biblioteket, och det körs i två lägen: ett serverläge som skapar en multicast-ström utifrån en HTTP-källa, och ett gatewayläge som tar emot multicast och levererar den igen över HTTP, inklusive HTTP-reparation. Det publiceras i DVB:s egen GitHub-organisation och riktar sig till ingenjörer, integratörer och valideringsteam som behöver bekräfta att en multicast-server, en gateway och vanliga DASH-spelare faktiskt fungerar tillsammans.
Det är därför detta arbete betyder mer än ännu en produktlansering. En royaltyfri, öppet tillgänglig referensimplementering ger varje operatör, enhetstillverkare och programvaruleverantör en gemensam grund. Det är den praktiska mekanism genom vilken DVB-MABR kan gå från en marknad med utrullningar från en enda leverantör mot verklig interoperabilitet mellan flera leverantörer, vilket är skillnaden mellan en publicerad standard och en standard som hela ekosystemet faktiskt kan använda. GPAC:s medverkan knyter också mABR till bredare forskning, däribland SMART-CD-konsortiets arbete med mer hållbar videoleverans, vid sidan av partner som Telecom Paris, Ateme och Viaccess-Orca.
En randanmärkning: peer-to-peer angriper samma problem från andra hållet
mABR är inte det enda sättet att förhindra att en populär liveström skickas en gång per tittare. Peer-to-peer-leverans tar sig an samma slöseri från motsatt håll. I stället för att skicka en kopia in i ett hanterat nät och sedan veckla ut den nära hushållet, låter ett peer-to-peer-lager tittarnas egna enheter dela segment med varandra. Varje spelare hämtar de första byten från CDN:et, utbyter sedan delar direkt med andra spelare som tittar på samma sak, och faller bara tillbaka på CDN:et när den måste.
Det franska företaget Quanteec är ett exempel. Dess teknik, som började som akademisk forskning, lägger ett lager med stöd från jämlikar ovanpå ett befintligt HLS- eller DASH-arbetsflöde och är agnostisk vad gäller CDN och DRM. Quanteec uppger att en utrullning med France Télévisions, som betjänade hundratusentals samtidiga tittare, i genomsnitt avlastade omkring 75 procent av trafiken från CDN:et, med mer än 50 procent energibesparing och mindre rebuffring än ren unicast.
Den viktiga kontrasten mot mABR är nätet. mABR behöver ett hanterat accessnät och operatörens medverkan. Peer-to-peer fungerar över det publika internet, mellan enheter, utan någon inblandning från operatören, vilket är precis den lucka som mABR inte kan nå. Avvägningen är att peer-to-peer beror på att det finns tillräckligt många samtidiga tittare, och på uppladdningskapaciteten och beteendet hos konsumentenheter. De två angreppssätten utesluter inte varandra. Ett tv-bolag utan kontroll över sista milen kan använda peer-to-peer redan i dag, en operatör som styr sitt eget nät kan använda mABR, och en stor plattform kan luta sig mot båda.
Vad detta innebär för operatörerna
mABR är inget universalmedel och det är inte nytt. Det är ett fokuserat verktyg för ett bestämt och dyrt problem: att leverera samma liveström till en mycket stor publik på ett hanterat nät utan att betala för varje kopia. För en operatör som sänder en stor sportfinal är det problemet verkligt, och det blir värre för varje säsong. För en renodlad OTT-tjänst utan kontroll över sista milen är mABR något den kan be ISP:er att stödja, men inte kan bygga ensam.
Den ärliga sammanfattningen är att tekniken fungerar, att standarden finns, att utrullningarna är verkliga men fortfarande koncentrerade till proprietära stackar från en enda leverantör, att fördröjning och enhetsekosystemet förblir verkliga begränsningar, och att det referensarbete med öppen källkod som leds av GPAC och Motion Spell är den mest trovärdiga vägen för att ändra den koncentrationen.
iReplay.TV är ett kollektiv av broadcast- och streamingingenjörer, så avvägningarna mellan mABR, peer-to-peer och vanlig unicast-CDN-leverans är den sortens saker som dess medlemmar väger mot varandra regelbundet. Multicast ABR är en hävstång bland flera, och det hjälper bara inom ett hanterat nät. Om din publik når dig över det öppna internet måste besparingen komma någon annanstans ifrån: leverans med stöd från jämlikar, en smartare origin-design, bättre codec-val och en stramare CDN-konfiguration. Det finns ett gratis verktyg för optimering av CDN-kostnader på webbplatsen för den som vill titta på sina egna siffror.
Källor och vidare läsning
- DVB, "Adaptive media streaming over IP multicast" (sidan om DVB-MABR-specifikationen): dvb.org
- DVB, "DVB-I and DVB-MABR published as ETSI standards": dvb.org/news
- DVB, "DVB publishes updated Multicast ABR specification and guidelines" (uppdatering från 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" (källkodsförråd): 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), tillgängliga på rfc-editor.org