Durante Euro 2024, più di 11,5 milioni di famiglie britanniche hanno guardato in streaming almeno una partita delle nazionali del Regno Unito sulla rete a banda larga di BT. BT ha riferito in seguito che il traffico proveniente da BBC e ITV è salito a più di 30 volte il normale volume settimanale, con le due emittenti che hanno brevemente superato Netflix, Facebook e YouTube come maggiori fonti di contenuto sulla sua rete. Il singolo picco di traffico più alto del torneo è arrivato nel momento in cui Cole Palmer ha pareggiato in finale.
La prossima prova di questa portata è a un solo mese di distanza. La Coppa del Mondo FIFA 2026 prende il via a giugno, ospitata tra Stati Uniti, Canada e Messico, e il suo pubblico in diretta ricadrà sulle stesse reti fisse e mobili, che non sono mai state costruite per inviare la stessa partita a ogni famiglia come flusso separato.
Un picco del genere è difficile da assorbire per una rete, e il motivo è strutturale. Ogni formato di streaming oggi ampiamente usato, HLS e DASH compresi, si fonda sull'unicast. Ogni spettatore apre la propria sessione e scarica la propria copia di ogni segmento. Dieci spettatori sullo stesso canale significano dieci flussi identici che attraversano la rete. Un milione di spettatori significa un milione di flussi identici. Il contenuto è lo stesso per tutti, ma la rete lo trasporta come se ogni copia fosse una cosa diversa.
Il Multicast ABR, di solito abbreviato in mABR, è la principale risposta del settore dello streaming a questo problema. Non è una novità, è già standardizzato, e una manciata di grandi operatori di telecomunicazioni lo gestisce già in produzione. Ha anche limiti reali, che è bene capire prima di trattarlo come una soluzione a tutto. Questo articolo spiega che cos'è il mABR, come funziona, che cosa fa risparmiare davvero, dove non basta, chi lo ha messo in campo e perché il lavoro open source guidato da GPAC e Motion Spell conta per il futuro della tecnologia.
Che cos'è il Multicast ABR?
Il Multicast ABR distribuisce contenuti a bitrate adattivo ordinari, gli stessi segmenti HLS o DASH che un normale player già si aspetta, su IP multicast invece che in unicast. Sulla rete gestita di un operatore, un canale viene inviato una sola volta attraverso la rete come flusso multicast a cui può unirsi un numero qualsiasi di famiglie. La riconversione in normale HTTP unicast avviene dentro casa o vicino ad essa, così che il dispositivo e il suo player non sanno mai che qualcosa è cambiato. Dal punto di vista del player, sta ancora richiedendo segmenti via HTTP a quello che sembra un edge CDN vicino.
L'idea di fondo è semplice. In unicast, uno spettatore equivale a un flusso. In multicast, un canale equivale a un flusso, indipendentemente da quante famiglie siano sintonizzate.
Vale la pena precisare due punti. Primo, il mABR è ibrido. Il multicast si occupa del grosso della distribuzione, e l'unicast resta nel circuito come via di riparazione e di ripiego. Secondo, il mABR è pensato per i contenuti dal vivo e lineari. La nota tecnica pubblicata dalla Streaming Video Technology Alliance, un organismo del settore il cui documento sul multicast ABR è stato guidato da un ingegnere di Ericsson con contributi di operatori come Comcast, è esplicita: il video on demand continua ad arrivare da un CDN. Il mABR si giustifica quando molte persone guardano la stessa cosa nello stesso momento, cioè lo sport in diretta e l'informazione in diretta.
Il video in multicast non è una novità, soprattutto in Francia
Va detto chiaramente: la distribuzione della televisione in multicast ha decenni di vita, e la Francia è uno dei migliori esempi del suo funzionamento su larga scala. All'inizio degli anni 2000, quando Free lanciò la Freebox, l'operatore integrò la distribuzione della televisione su IP multicast direttamente nella propria rete DSL disaggregata, qualcosa che i DSLAM dell'operatore storico all'epoca non offrivano. Nel 2008 Free era al primo posto tra i maggiori operatori IPTV al mondo. Il multicast era la ragione per cui i conti tornavano: una sola copia di ogni canale viaggiava sulla rete, indipendentemente da quante famiglie Freebox la stessero guardando.
Free espose quel flusso multicast anche direttamente agli abbonati, tramite un servizio chiamato Multiposte. Permetteva di guardare i canali della Freebox TV su un computer accanto al televisore, aprendo una playlist di canali in VLC. I flussi erano semplice IP multicast trasportato dalla Freebox e raggiunto tramite IGMP, senza alcun decoder di mezzo. Un'intera generazione di utenti della banda larga francese ha avuto, di fatto, un ricevitore televisivo multicast in funzione sul proprio PC.
Nemmeno gli strumenti hanno mai avuto nulla di esotico. VLC, lo stesso player su cui si appoggiava Multiposte, può prendere un flusso unicast in ingresso e riemetterlo verso un indirizzo multicast su UDP o RTP con una singola configurazione di uscita del flusso. Trasformare un flusso unicast in uno multicast è, di per sé, un problema ordinario e risolto da tempo.
Quindi, se il multicast è vecchio e gli strumenti sono ovunque, che cosa c'è davvero di nuovo nel Multicast ABR? L'IPTV multicast classica, il modello Freebox, trasportava un flusso di trasporto fisso e continuo verso il decoder proprietario dell'operatore. Il mABR trasporta invece contenuti moderni a bitrate adattivo, i segmenti HLS e DASH che ogni telefono, tablet, smart TV e chiavetta di streaming già parla, e li indirizza all'intero ecosistema frammentato dei dispositivi anziché a una sola scatola proprietaria. La parte difficile del mABR non è il multicast. È fare multicast per uno streaming segmentato, adattivo e multidispositivo, con la meccanica di gateway, rendezvous e riparazione che ciò richiede.
Come funziona il mABR
La specifica DVB-MABR, sviluppata dal DVB Project e pubblicata dall'ETSI come TS 103 769, definisce un'architettura di riferimento costruita a partire da un piccolo insieme di funzioni con un nome:
- Server multicast. Acquisisce contenuti ABR standard da un origin o da un edge CDN, associa ogni segmento a uno o più oggetti di trasporto multicast e li trasmette in IP multicast. Un operatore gli indica, tramite una API di configurazione, quali flussi catturare e come inviarli.
- Gateway multicast. Riceve il flusso multicast e lo riconverte in semplice HTTP per i player locali. Si comporta come una piccola cache locale e un proxy HTTP.
- Servizio di rendezvous multicast. Instrada la richiesta iniziale di un player, tramite redirect HTTP, verso il gateway giusto in base al piano di servizio e alle regole di business dell'operatore.
- Riparazione unicast. Quando vengono persi pacchetti multicast, il gateway recupera i pezzi mancanti in unicast, di norma tramite richieste HTTP per intervallo di byte, perché la riproduzione non si interrompa.
Dove gira il gateway
La specifica è volutamente flessibile su dove collocare il gateway multicast. Può girare nella rete dell'operatore, nel gateway domestico o nel router, nel terminale di rete ottica, o direttamente dentro il decoder. Quando il gateway e il player si trovano sullo stesso dispositivo, la specifica DVB indica che l'interfaccia tra i due può ridursi a una semplice API locale. La nota della SVTA descriveva lo stesso componente, che chiamava client multicast, come distribuibile su un decoder, un gateway residenziale, un ONT, o dentro la cache edge dell'operatore. Quest'ultima opzione è utile di per sé: un client mABR integrato in un edge CDN può popolare la cache via multicast e ridurre le richieste rimandate verso l'origin.
I protocolli di trasporto
Sotto, il mABR usa protocolli di consegna file pensati per il multicast unidirezionale. Il DVB-MABR ne rende obbligatori due. FLUTE (File Delivery over Unidirectional Transport, RFC 6726) viene dal mondo 3GPP. ROUTE (Real-Time Object Delivery over Unidirectional Transport, RFC 9223) viene da ATSC 3.0. Una revisione del 2023 della specifica ha aggiunto due protocolli opzionali, NORM (NACK-Oriented Reliable Multicast, RFC 5740) e MSYNC. Tutti funzionano su UDP e trasportano il contenuto segmentato insieme alla correzione d'errore in avanti.
Una proprietà utile: il mABR è agnostico rispetto a formato, codec e DRM. Sposta HLS o DASH, MPEG-TS o CMAF, cifrato o meno, e non ricodifica nulla. Cambia il modo in cui i byte viaggiano, non ciò che sono.
I vantaggi del Multicast ABR
La scalabilità, che è tutto il punto
L'argomento centrale a favore del mABR è che il costo di rete di un canale in diretta popolare smette di crescere con il pubblico. La nota tecnica della SVTA lo illustra con due esempi di reti di accesso. Su una rete via cavo DOCSIS, il numero di canali necessari per l'ABR unicast cresce in modo lineare man mano che si aggiungono spettatori, mentre con il mABR sale brevemente e poi si appiattisce, dato che gli spettatori condividono gli stessi flussi multicast. Su una rete in fibra GPON, la nota stima che per un operatore con 500 canali lineari in cui l'80 per cento degli spettatori guarda il 10 per cento dell'offerta, il risparmio di banda sul core di rete raggiunge circa il 50 per cento con 32 clienti per PON, e il fabbisogno di banda per spettatore scende sotto il 3 per cento del valore unicast una volta che il pubblico arriva alle decine di migliaia. La nota lo riassume senza giri di parole: il mABR può ridurre il fabbisogno di banda al bordo della rete, per eventi in diretta estremamente popolari, dall'ordine del petabyte a quello del megabyte.
C'è un dato che viene direttamente da un operatore e non da una stima modellata. A marzo 2025, BT Group ha riferito del suo primo test riuscito di MAUD, il nome che dà alla Multicast-Assisted Unicast Delivery, che portava contenuti in diretta di BBC Two su decoder EE nella rete di produzione. Nelle ore di punta, il test ha convertito più del 60 per cento del traffico da unicast a multicast.
La qualità dell'esperienza
Il mABR viene erogato come servizio gestito anziché come servizio best-effort. La nota della SVTA osserva che questo attenua il jitter di riproduzione, perché l'operatore controlla il percorso invece di affidarsi all'internet aperto tra origin e spettatore. Per una finale in diretta, una distribuzione costante verso tutti quelli che stanno guardando conta quanto il risparmio di banda in sé.
Riutilizza ciò che è già presente
La nota della SVTA sottolinea che il costo infrastrutturale del mABR può essere inferiore a quello di altre opzioni di scalabilità, perché la maggior parte dei router e degli elementi di rete coinvolti è già presente nella rete dell'operatore. Il mABR è inoltre complementare alla cache CDN anziché un suo sostituto, e può fungere da sorgente di contenuto che popola le cache di bordo.
Gli svantaggi del Multicast ABR
Latenza aggiuntiva
Il gateway multicast deve ricevere e riassemblare i segmenti prima di poterli servire, il che aggiunge ritardo al flusso ABR di origine. Un'analisi tecnica, pubblicata da Techne Digitale, stima che il mABR aggiunga all'incirca due segmenti di ritardo a una distribuzione OTT tipica, portando il valore end-to-end da circa 8 secondi a circa 12. La nota della SVTA sostiene che una progettazione attenta, con durate dei segmenti più brevi e il trasferimento a frammenti del CMAF, può mantenere il mABR competitivo con il semplice ABR unicast, o persino al di sotto. In ogni caso, la latenza è una questione concreta per lo sport in diretta, dove uno spettatore che sente un vicino reagire prima che l'azione arrivi sul suo schermo se ne accorgerà.
Il problema dell'ecosistema dei client
La nota della SVTA definisce l'assenza di un ecosistema di client diffuso come il principale ostacolo a un'adozione più ampia del mABR. I vecchi gateway domestici e gli ONT spesso non hanno la CPU e la memoria per far girare un client multicast. L'hardware più recente può farlo, ma i produttori di dispositivi hanno pochi motivi per costruire, testare e mantenere il software client multicast finché non c'è un'infrastruttura che lo usi, e gli operatori hanno pochi motivi per mettere in campo un'infrastruttura finché i dispositivi non sanno usarla. A un evento del CSI Magazine all'inizio del 2023, l'architetto TV di BT Simon Jones ha osservato che BT gestiva la televisione in multicast da oltre un decennio, ma la distribuiva solo ai televisori e non ai dispositivi connessi, e che BT non avrebbe potuto distribuire qualcosa come la Coppa del Mondo con la sua infrastruttura esistente. Bob Hannent, architetto di riproduzione e distribuzione video in DAZN, ha dichiarato nella stessa discussione che il mercato era ancora «davvero immaturo». Entrambi hanno indicato la mancanza di supporto da parte di produttori di dispositivi come Google e Apple come l'ostacolo principale.
Funziona solo sulle reti gestite
Sull'internet pubblico non c'è multicast. Il mABR funziona all'interno della rete gestita di un singolo operatore, tra un server multicast che l'operatore gestisce e un gateway che l'operatore controlla. Un servizio puramente OTT come Netflix non può mettere in campo il mABR end-to-end da solo. Può chiedere agli ISP di supportarlo, ma dipende da ciascun ISP singolarmente.
Frammentazione
Poiché è locale a ogni rete, il mABR è efficace solo quanto lo è l'ISP su cui gira. Se metà degli ISP che servono un pubblico lo supportano, gli spettatori dell'altra metà continuano ad avere l'esperienza unicast e la stessa congestione. A differenza di un CDN unicast, nessuna singola azienda può offrire un'esperienza mABR end-to-end all'intero pubblico.
Il problema forse si sta riducendo sulle reti moderne
L'analisi di Techne Digitale sostiene che sulla fibra GPON moderna, dove uno split 1:64 lascia comunque a ogni famiglia decine di megabit al secondo, la strettoia di banda sull'ultimo miglio per cui il mABR è stato progettato forse non esiste, e che il mABR ha più senso sulle reti via cavo più datate. La stessa nota della SVTA solleva una domanda simile, chiedendosi se anni di costruzione di edge CDN, codec migliori come HEVC, AV1 e VVC e nuovi protocolli di trasporto non abbiano già permesso al settore di restare in vantaggio sulla curva di crescita. Vale la pena ricordare che il primo progetto mABR di Comcast, portato avanti dal suo gruppo di ricerca VIPER intorno al 2015, non è mai arrivato al dispiegamento.
Le molteplici varianti erodono il risparmio
Ogni formato, ogni scaletta di bitrate e ogni variante di DRM che un operatore vuole servire deve essere inviato in multicast separatamente. Più tipi di dispositivo e protezioni del contenuto entrano in gioco, più flussi multicast paralleli servono, e più piccolo diventa il guadagno netto di efficienza.
Chi usa davvero il mABR
Il mABR ha superato la fase di laboratorio. Gli esempi pubblici più chiari vengono da operatori di telecomunicazioni che gestiscono le proprie reti di accesso gestite.
- BT Group, nel Regno Unito, è stato il più trasparente al riguardo. BT ha annunciato la sua iniziativa MAUD nel 2024 e ha riferito del suo primo test in diretta riuscito a marzo 2025, che portava BBC Two su decoder EE e convertiva più del 60 per cento del traffico di punta in multicast. BT ha dichiarato che l'obiettivo è gestire eventi in diretta con pubblico di massa, e la stampa di settore ha riferito che alcune emittenti stanno valutando MAUD per la Coppa del Mondo FIFA 2026.
- Orange, in Spagna, ha comunicato ai propri clienti di essere il primo operatore del Paese a offrire lo streaming mABR per i suoi eventi in diretta a maggiore ascolto, citando LaLiga, la Formula 1 e la MotoGP, e a estenderlo oltre il decoder ad altri dispositivi di casa.
- TIM, in Italia, ha scritto nella propria rivista tecnica che dal 2021 gestisce una piattaforma di distribuzione di contenuti in multicast conforme allo standard M-ABR dell'ETSI, usata per aggiungere scalabilità a eventi in diretta di massa come lo sport, integrata con il modello unicast esistente e con ripiego automatico.
- Bouygues Telecom, in Francia, è stato presentato dalla stampa di settore come il primo operatore francese a trasmettere commercialmente in mABR, a partire dal 2023.
Non tutti gli operatori sono convinti. Deutsche Telekom ha presentato pubblicamente il mABR come una tecnologia di transizione, utile dove l'infrastruttura non può ancora reggere l'unicast puro, più che come una destinazione di lungo periodo.
Un dato ricorrente emerge da questi dispiegamenti. Sono stati quasi tutti costruiti sulla stessa implementazione proprietaria di un singolo fornitore, il nanoCDN di Broadpeak, anziché su stack interoperabili basati su standard. È un dato di mercato, non un avallo tecnico. La specifica DVB-MABR è pubblica, ma per anni non è esistita alcuna implementazione neutrale e disponibile apertamente su cui costruire e fare test, così che un operatore che voleva il mABR in produzione non aveva quasi scelta pratica del fornitore.
Il lato dei dispositivi
Sul lato hardware, i produttori di decoder e di apparati di utente contano quanto gli operatori. CommScope offre una soluzione Multicast ABR che descrive come basata su parti sia dello standard DVB sia di quello CableLabs, con un client che può girare integrato in un decoder o nel gateway domestico, e l'azienda afferma che non serve alcuna modifica ai dispositivi di streaming di casa. Vantiva, ex Technicolor, ha distribuito decoder con software client multicast ABR integrato. I chip per decoder di fornitori come Broadcom assicurano il supporto all'IP multicast a livello di rete, ma il mABR in sé è implementato in software che gira sul dispositivo, e non come una funzione con un nome del chip.
Il divario è più visibile sulla più grande piattaforma di dispositivi. Android TV nella versione standard supporta solo l'unicast, così che il multicast ABR su quei dispositivi dipende da integrazioni a livello di operatore che aggiungono un client multicast. Le stesse librerie di riproduzione di Google, ExoPlayer e Media3, non forniscono il multicast ABR in modo nativo, e c'è una richiesta di funzionalità aperta che lo chiede.
Lo standard esiste. L'interoperabilità è la parte difficile.
È un'idea diffusa che il mABR sia frenato dall'assenza di uno standard. Non è così.
CableLabs ha svolto i primi lavori di architettura sull'IP multicast ABR intorno al 2014. Il DVB Project ha pubblicato la sua architettura di riferimento per il multicast ABR, sottoposta ai commenti del settore, nel 2018, il suo Steering Board ha approvato la specifica completa all'inizio del 2020, ed è stata pubblicata come standard ETSI TS 103 769 a novembre 2020. Da allora è stata rivista più volte, compreso un aggiornamento del 2023 che ha aggiunto i protocolli di trasporto opzionali NORM e MSYNC insieme a funzioni di reporting, autenticità e protezione dalle manomissioni. Il gruppo di lavoro del DVB che ne è all'origine, MCAST, è presieduto da Richard Bradbury di BBC R&D. Esiste davvero uno standard reale, pubblicato e riconosciuto a livello internazionale, accompagnato da lavori collegati come le linee guida di implementazione del DVB-MABR e la specifica di scoperta dei servizi DVB-I. Sul lato mobile, la 3GPP segue una propria via parallela, con l'architettura dei 5G Multicast-Broadcast Services nella Release 17, che condivide la stessa eredità di protocolli FLUTE e ROUTE.
Ciò che è mancato è l'interoperabilità nella pratica. Quasi ogni dispiegamento commerciale di mABR fino a oggi gira sullo stesso stack proprietario, il nanoCDN di Broadpeak. MSYNC, uno dei protocolli di trasporto opzionali integrati nel DVB-MABR nel 2023, è nato come protocollo di Broadpeak prima di essere portato nella specifica. Uno standard implementato per lo più da un solo fornitore è uno standard sulla carta. Ciò che trasforma una specifica sulla carta in un mercato multi-fornitore funzionante è un'implementazione neutrale su cui chiunque possa costruire e fare test.
Dove entrano in gioco GPAC e Motion Spell
È questa la parte della storia del mABR che indica la via verso una vera normalizzazione.
GPAC è un framework multimediale open source di lunga data, distribuito sotto licenza LGPL e sviluppato con Motion Spell, il suo partner commerciale. Ha radici nella ricerca accademica a Telecom Paris ed è stato scaricato quasi 100 milioni di volte. GPAC ha implementato il protocollo ROUTE per ATSC 3.0 anni fa, un lavoro che ha vinto un premio per l'innovazione del NAB nel 2018, ed è l'unico progetto open source a supportare sia ROUTE sia FLUTE, i due protocolli di trasporto obbligatori del DVB-MABR. Nel 2024 ha aggiunto il supporto a FLUTE specificamente per il DVB-MABR. Il media server di GPAC può già fare da gateway multicast-verso-ABR, esponendo una sessione multicast come un normale servizio di streaming HTTP, con riparazione unicast e una finestra di time-shift configurabile.
Il DVB ha poi pubblicato una richiesta di proposte per uno strumento open source destinato a verificare e validare le implementazioni DVB-MABR. Il risultato, i DVB-MABR Reference Tools, si basa su GPAC e Motion Spell. È open source, scritto in Python sopra la libreria GPAC, e funziona in due modalità: una modalità server che genera un flusso multicast a partire da una sorgente HTTP, e una modalità gateway che riceve il multicast e lo riserve via HTTP, riparazione HTTP compresa. È pubblicato nell'organizzazione GitHub dello stesso DVB ed è rivolto a ingegneri, integratori e team di validazione che devono confermare che un server multicast, un gateway e player DASH standard interoperino davvero.
È per questo che questo lavoro conta più di un ennesimo lancio di prodotto. Un'implementazione di riferimento esente da royalty e disponibile apertamente dà a ogni operatore, produttore di dispositivi e fornitore di software una base comune. È il meccanismo concreto con cui il DVB-MABR può passare da un mercato di dispiegamenti a fornitore unico a una vera interoperabilità multi-fornitore, che è la differenza tra uno standard pubblicato e uno standard che l'intero ecosistema può davvero usare. Il coinvolgimento di GPAC lega inoltre il mABR a una ricerca più ampia, compreso il lavoro del consorzio SMART-CD su una distribuzione video più sostenibile, accanto a partner come Telecom Paris, Ateme e Viaccess-Orca.
Un inciso: il peer-to-peer affronta lo stesso problema dall'altra parte
Il mABR non è l'unico modo per evitare che un flusso in diretta popolare venga inviato una volta per spettatore. La distribuzione peer-to-peer affronta lo stesso spreco dalla direzione opposta. Invece di inviare una copia in una rete gestita e poi diramarla vicino alla famiglia, uno strato peer-to-peer lascia che siano i dispositivi degli spettatori stessi a condividere i segmenti tra loro. Ogni player recupera i primi byte dal CDN, poi scambia frammenti direttamente con altri player che stanno guardando la stessa cosa, e ricorre al CDN solo quando è costretto.
L'azienda francese Quanteec ne è un esempio. La sua tecnologia, nata come ricerca accademica, aggiunge uno strato assistito dai pari a un flusso di lavoro HLS o DASH esistente ed è agnostica rispetto al CDN e al DRM. Quanteec riferisce che un dispiegamento con France Télévisions, che serviva centinaia di migliaia di spettatori simultanei, ha scaricato in media circa il 75 per cento del traffico dal CDN, con oltre il 50 per cento di risparmio energetico e meno rebuffering rispetto al semplice unicast.
Il contrasto importante con il mABR è la rete. Il mABR ha bisogno di una rete di accesso gestita e della collaborazione dell'operatore. Il peer-to-peer funziona sull'internet pubblico, tra i dispositivi, senza alcun coinvolgimento dell'operatore, che è esattamente lo spazio che il mABR non riesce a raggiungere. Il compromesso è che il peer-to-peer dipende dall'avere abbastanza spettatori simultanei e dalla capacità di upload e dal comportamento dei dispositivi di consumo. I due approcci non si escludono a vicenda. Un'emittente senza alcun controllo sull'ultimo miglio può usare il peer-to-peer già oggi, un operatore che controlla la propria rete può usare il mABR, e una grande piattaforma potrebbe appoggiarsi a entrambi.
Che cosa significa questo per gli operatori
Il mABR non è una soluzione miracolosa e non è una novità. È uno strumento mirato a un problema preciso e costoso: distribuire lo stesso flusso in diretta a un pubblico molto ampio su una rete gestita senza pagare per ogni copia. Per un operatore che trasmette una grande finale sportiva, quel problema è reale e peggiora a ogni stagione. Per un servizio puramente OTT senza controllo sull'ultimo miglio, il mABR è qualcosa che può chiedere agli ISP di supportare, ma che non può costruire da solo.
Il riassunto onesto è che la tecnologia funziona, lo standard esiste, i dispiegamenti sono reali ma ancora concentrati su stack proprietari a fornitore unico, la latenza e l'ecosistema dei dispositivi restano vincoli concreti, e il lavoro di riferimento open source guidato da GPAC e Motion Spell è la via più credibile per cambiare quella concentrazione.
iReplay.TV è un collettivo di ingegneri del broadcast e dello streaming, quindi i compromessi tra mABR, peer-to-peer e semplice distribuzione CDN unicast sono il genere di cose che i suoi membri soppesano regolarmente. Il Multicast ABR è una leva tra le tante, e aiuta solo all'interno di una rete gestita. Se il tuo pubblico ti raggiunge attraverso l'internet aperto, il risparmio deve venire da altrove: distribuzione assistita dai pari, una progettazione dell'origin più intelligente, scelte di codec migliori e una configurazione CDN più stretta. Sul sito c'è uno strumento gratuito di ottimizzazione dei costi CDN per chiunque voglia guardare i propri numeri.
Riferimenti e approfondimenti
- DVB, «Adaptive media streaming over IP multicast» (pagina della specifica DVB-MABR): dvb.org
- DVB, «DVB-I and DVB-MABR published as ETSI standards»: dvb.org/news
- DVB, «DVB publishes updated Multicast ABR specification and guidelines» (aggiornamento del 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» (repository del codice sorgente): 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, soluzione Multicast Adaptive Bitrate (MABR): commscope.com
- IETF: FLUTE (RFC 6726), ROUTE (RFC 9223), NORM (RFC 5740), disponibili su rfc-editor.org