Durante o Euro 2024, mais de 11,5 milhões de lares britânicos assistiram em streaming a pelo menos um jogo das seleções do Reino Unido através da rede de banda larga da BT. A BT relatou depois que o tráfego vindo da BBC e da ITV subiu para mais de 30 vezes o volume semanal normal, com as duas emissoras a ultrapassarem brevemente a Netflix, o Facebook e o YouTube como maiores fontes de conteúdo na sua rede. O maior pico de tráfego do torneio aconteceu no momento em que Cole Palmer empatou na final.
O próximo teste dessa dimensão está a apenas um mês de distância. O Campeonato do Mundo de Futebol da FIFA de 2026 começa em junho, organizado nos Estados Unidos, no Canadá e no México, e a sua audiência ao vivo vai recair sobre as mesmas redes fixas e móveis, que nunca foram construídas para enviar o mesmo jogo a cada lar como um fluxo separado.
Um pico desses é difícil de absorver para uma rede, e a razão é estrutural. Todos os formatos de streaming amplamente usados hoje, HLS e DASH incluídos, assentam em unicast. Cada espetador abre a sua própria sessão e obtém a sua própria cópia de cada segmento. Dez espetadores no mesmo canal significam dez fluxos idênticos a atravessar a rede. Um milhão de espetadores significa um milhão de fluxos idênticos. O conteúdo é o mesmo para todos, mas a rede transporta-o como se cada cópia fosse uma coisa diferente.
O Multicast ABR, normalmente abreviado para mABR, é a principal resposta do setor do streaming a esse problema. Não é novo, já está padronizado, e um punhado de grandes operadoras de telecomunicações já o explora em produção. Também tem limites reais que vale a pena compreender antes de o tratar como uma solução para tudo. Este artigo aborda o que é o mABR, como funciona, o que poupa realmente, onde fica aquém, quem o implementou e por que o trabalho de código aberto liderado pela GPAC e pela Motion Spell importa para o futuro da tecnologia.
O que é o Multicast ABR?
O Multicast ABR entrega conteúdo de taxa de bits adaptativa comum, os mesmos segmentos HLS ou DASH que um leitor normal já espera, por IP multicast em vez de unicast. Na rede gerida de uma operadora, um canal é enviado uma única vez através da rede como um fluxo multicast a que qualquer número de lares se pode juntar. A reconversão para HTTP unicast padrão acontece dentro do lar ou perto dele, pelo que o dispositivo e o seu leitor nunca sabem que algo mudou. Do ponto de vista do leitor, ele continua a pedir segmentos por HTTP ao que parece ser um edge de CDN próximo.
A ideia de fundo é simples. Em unicast, um espetador equivale a um fluxo. Em multicast, um canal equivale a um fluxo, independentemente de quantos lares estejam sintonizados.
Vale a pena precisar dois pontos. Primeiro, o mABR é híbrido. O multicast trata do grosso da entrega, e o unicast continua no circuito como via de reparação e de recurso. Segundo, o mABR foi concebido para conteúdo ao vivo e linear. A nota técnica publicada pela Streaming Video Technology Alliance, um organismo do setor cujo documento sobre multicast ABR foi liderado por um engenheiro da Ericsson com contributos de operadoras como a Comcast, é explícita: o vídeo a pedido continua a vir de um CDN. O mABR justifica o seu valor quando muitas pessoas veem a mesma coisa ao mesmo tempo, ou seja, o desporto ao vivo e as notícias ao vivo.
O vídeo em multicast não é novo, sobretudo em França
Convém ser claro: a entrega de televisão em multicast tem décadas, e a França é um dos melhores exemplos do seu funcionamento em grande escala. No início dos anos 2000, quando a Free lançou a Freebox, a operadora integrou a entrega de televisão sobre IP multicast diretamente na sua própria rede DSL desagregada, algo que os DSLAM da operadora histórica não ofereciam na altura. Em 2008, a Free figurava como a maior operadora de IPTV do mundo. O multicast era a razão pela qual as contas batiam certo: uma única cópia de cada canal circulava pela rede, independentemente de quantos lares Freebox a estivessem a ver.
A Free também expôs esse fluxo multicast diretamente aos assinantes, através de um serviço chamado Multiposte. Permitia ver os canais da Freebox TV num computador a par do televisor, abrindo uma lista de reprodução de canais no VLC. Os fluxos eram simples IP multicast transportado pela Freebox e juntado via IGMP, sem qualquer descodificador pelo meio. Toda uma geração de utilizadores de banda larga franceses teve, de facto, um recetor de televisão multicast a funcionar no seu PC.
As ferramentas também nunca tiveram nada de exótico. O VLC, o mesmo leitor em que o Multiposte se apoiava, consegue receber um fluxo unicast como entrada e reemiti-lo para um endereço multicast por UDP ou RTP com uma única configuração de saída de fluxo. Transformar um fluxo unicast num fluxo multicast é, por si só, um problema comum e há muito resolvido.
Então, se o multicast é antigo e as ferramentas estão por todo o lado, o que há realmente de novo no Multicast ABR? A IPTV multicast clássica, o modelo Freebox, transportava um fluxo de transporte fixo e contínuo para o descodificador próprio da operadora. O mABR transporta, em vez disso, conteúdo moderno de taxa de bits adaptativa, os segmentos HLS e DASH que todos os telefones, tablets, smart TV e dongles de streaming já falam, e direciona-o para todo o ecossistema fragmentado de dispositivos em vez de para uma única caixa proprietária. A parte difícil do mABR não é o multicast. É fazer multicast para streaming segmentado, adaptativo e multidispositivo, com a maquinaria de gateway, rendezvous e reparação que isso exige.
Como funciona o mABR
A especificação DVB-MABR, desenvolvida pelo DVB Project e publicada pela ETSI como TS 103 769, define uma arquitetura de referência construída a partir de um pequeno conjunto de funções nomeadas:
- Servidor multicast. Recebe conteúdo ABR padrão de uma origem ou de um edge de CDN, associa cada segmento a um ou mais objetos de transporte multicast e transmite-os por IP multicast. Uma operadora indica-lhe, através de uma API de configuração, que fluxos capturar e como enviá-los.
- Gateway multicast. Recebe o fluxo multicast e reconverte-o em HTTP simples para os leitores locais. Comporta-se como uma pequena cache local e um proxy HTTP.
- Serviço de rendezvous multicast. Encaminha o pedido inicial de um leitor, por redireção HTTP, para a gateway certa, com base no plano de serviço e nas regras de negócio da operadora.
- Reparação unicast. Quando se perdem pacotes multicast, a gateway recupera as partes em falta por unicast, normalmente através de pedidos HTTP por intervalo de bytes, para que a reprodução não se interrompa.
Onde corre a gateway
A especificação é deliberadamente flexível quanto ao local onde a gateway multicast fica. Pode correr na rede da operadora, na gateway doméstica ou no router, no terminal de rede ótica, ou diretamente dentro do descodificador. Quando a gateway e o leitor estão no mesmo dispositivo, a especificação do DVB indica que a interface entre os dois se pode reduzir a uma simples API local. A nota da SVTA descrevia o mesmo componente, a que chamava cliente multicast, como passível de ser implantado num descodificador, numa gateway residencial, num ONT, ou dentro da cache de edge da operadora. Esta última opção é útil por si só: um cliente mABR integrado num edge de CDN pode preencher a cache por multicast e reduzir os pedidos de volta à origem.
Protocolos de transporte
Por baixo, o mABR usa protocolos de entrega de ficheiros concebidos para multicast unidirecional. O DVB-MABR torna dois deles obrigatórios. O FLUTE (File Delivery over Unidirectional Transport, RFC 6726) vem do mundo do 3GPP. O ROUTE (Real-Time Object Delivery over Unidirectional Transport, RFC 9223) vem do ATSC 3.0. Uma revisão de 2023 da especificação acrescentou dois protocolos opcionais, o NORM (NACK-Oriented Reliable Multicast, RFC 5740) e o MSYNC. Todos funcionam sobre UDP e transportam o conteúdo segmentado juntamente com correção de erros para a frente.
Uma propriedade útil: o mABR é agnóstico em relação ao formato, ao codec e ao DRM. Move HLS ou DASH, MPEG-TS ou CMAF, cifrado ou não, e não recodifica nada. Muda a forma como os bytes viajam, não o que eles são.
As vantagens do Multicast ABR
A escala, que é tudo o que importa
O argumento central a favor do mABR é que o custo de rede de um canal ao vivo popular deixa de crescer com a audiência. A nota técnica da SVTA ilustra isto com dois exemplos de redes de acesso. Numa rede de cabo DOCSIS, o número de canais necessários para o ABR unicast cresce de forma linear à medida que se juntam espetadores, enquanto com o mABR sobe brevemente e depois estabiliza, já que os espetadores partilham os mesmos fluxos multicast. Numa rede de fibra GPON, a nota estima que para uma operadora com 500 canais lineares em que 80 por cento dos espetadores veem 10 por cento da grelha, a poupança de largura de banda no núcleo da rede atinge cerca de 50 por cento com 32 clientes por PON, e a necessidade de largura de banda por espetador cai abaixo dos 3 por cento do valor unicast assim que a audiência chega às dezenas de milhares. A nota resume sem rodeios: o mABR pode reduzir as necessidades de largura de banda na borda da rede, para eventos ao vivo extremamente populares, da ordem do petabyte para a do megabyte.
Há um número que vem diretamente de uma operadora e não de uma estimativa modelada. Em março de 2025, a BT Group relatou o seu primeiro ensaio bem-sucedido do MAUD, o nome que dá à Multicast-Assisted Unicast Delivery, que levava conteúdo ao vivo da BBC Two a descodificadores EE na rede de produção. Nas horas de ponta, o ensaio converteu mais de 60 por cento do tráfego de unicast para multicast.
A qualidade da experiência
O mABR é entregue como um serviço gerido em vez de um serviço de melhor esforço. A nota da SVTA observa que isto atenua a instabilidade da reprodução, porque a operadora controla o caminho em vez de depender da internet aberta entre a origem e o espetador. Para uma final ao vivo, uma entrega constante a todos os que estão a ver conta tanto como a poupança bruta de largura de banda.
Reaproveita o que já existe
A nota da SVTA destaca que o custo de infraestrutura do mABR pode ser inferior ao de outras opções de escalonamento, porque a maioria dos routers e elementos de rede envolvidos já está implantada na rede da operadora. O mABR é também complementar à cache de CDN em vez de um substituto, e pode servir de fonte de conteúdo que preenche as caches de borda.
As desvantagens do Multicast ABR
Latência acrescida
A gateway multicast tem de receber e voltar a montar os segmentos antes de os poder servir, o que acrescenta atraso ao fluxo ABR de origem. Uma análise técnica, publicada pela Techne Digitale, estima que o mABR acrescenta cerca de dois segmentos de atraso a uma entrega OTT típica, levando o valor ponta a ponta de cerca de 8 segundos para cerca de 12. A nota da SVTA defende que um desenho cuidadoso, com durações de segmento mais curtas e transferência por fragmentos do CMAF, pode manter o mABR competitivo com o ABR unicast simples, ou até abaixo dele. Seja como for, a latência é uma consideração real para o desporto ao vivo, onde um espetador que ouve um vizinho reagir antes de a ação chegar ao seu próprio ecrã vai notar.
O problema do ecossistema de clientes
A nota da SVTA qualifica a falta de um ecossistema de clientes implantado como o principal entrave a uma adoção mais ampla do mABR. As gateways domésticas e os ONT antigos muitas vezes não têm o processador e a memória para correr um cliente multicast. O hardware mais recente consegue, mas os fabricantes de dispositivos têm poucas razões para construir, testar e manter software de cliente multicast enquanto não houver infraestrutura para o usar, e as operadoras têm poucas razões para implantar infraestrutura enquanto os dispositivos não a souberem usar. Num evento da CSI Magazine no início de 2023, o arquiteto de TV da BT, Simon Jones, notou que a BT operava televisão em multicast havia mais de uma década, mas que só a entregava a televisores e não a dispositivos ligados, e que a BT não conseguiria entregar algo como o Campeonato do Mundo com a sua infraestrutura existente. Bob Hannent, arquiteto de reprodução e entrega de vídeo na DAZN, disse na mesma conversa que o mercado ainda estava "verdadeiramente imaturo". Ambos apontaram a falta de apoio por parte de fabricantes de dispositivos como a Google e a Apple como o principal obstáculo.
Só funciona em redes geridas
Não há multicast na internet pública. O mABR funciona dentro da rede gerida de uma única operadora, entre um servidor multicast que a operadora explora e uma gateway que a operadora controla. Um serviço puramente OTT como a Netflix não pode implantar o mABR de ponta a ponta por si só. Pode pedir aos ISP que o suportem, mas depende de cada ISP individualmente.
Fragmentação
Por ser local a cada rede, o mABR só é tão eficaz quanto o ISP em que corre. Se metade dos ISP que servem uma audiência o suportarem, os espetadores da outra metade continuam a ter a experiência unicast e a mesma congestão. Ao contrário de um CDN unicast, nenhuma empresa sozinha consegue entregar uma experiência mABR de ponta a ponta a toda a audiência.
O problema talvez esteja a diminuir nas redes modernas
A análise da Techne Digitale defende que na fibra GPON moderna, onde uma divisão 1:64 ainda deixa a cada lar dezenas de megabits por segundo, o estrangulamento de largura de banda no último quilómetro para o qual o mABR foi concebido talvez não exista, e que o mABR faz mais sentido em redes de cabo mais antigas. A própria nota da SVTA levanta uma questão semelhante, ao perguntar se anos de construção de edges de CDN, melhores codecs como o HEVC, o AV1 e o VVC, e novos protocolos de transporte não terão já permitido ao setor manter-se à frente da curva de crescimento. Vale a pena recordar que o próprio projeto inicial de mABR da Comcast, conduzido pelo seu grupo de investigação VIPER por volta de 2015, nunca chegou a ser implantado.
As múltiplas variantes corroem a poupança
Cada formato, cada escada de taxas de bits e cada variante de DRM que uma operadora queira servir tem de ser enviado por multicast separadamente. Quantos mais tipos de dispositivo e proteções de conteúdo estiverem em jogo, mais fluxos multicast em paralelo são necessários, e menor se torna o ganho líquido de eficiência.
Quem usa realmente o mABR
O mABR ultrapassou a fase de laboratório. Os exemplos públicos mais claros vêm de operadoras de telecomunicações que exploram as suas próprias redes de acesso geridas.
- A BT Group, no Reino Unido, foi a mais transparente quanto a isto. A BT anunciou a sua iniciativa MAUD em 2024 e relatou o seu primeiro ensaio ao vivo bem-sucedido em março de 2025, que levava a BBC Two a descodificadores EE e convertia mais de 60 por cento do tráfego de pico para multicast. A BT disse que o objetivo é dar resposta a eventos ao vivo de audiência massiva, e a imprensa especializada noticiou que há emissoras a avaliar o MAUD para o Campeonato do Mundo de Futebol da FIFA de 2026.
- A Orange, em Espanha, comunicou aos seus próprios clientes que é a primeira operadora do país a oferecer streaming mABR para os seus eventos ao vivo de maior audiência, citando a LaLiga, a Fórmula 1 e o MotoGP, e a estendê-lo para além do descodificador a outros dispositivos do lar.
- A TIM, em Itália, escreveu na sua própria revista técnica que desde 2021 explora uma plataforma de distribuição de conteúdo em multicast em conformidade com a norma M-ABR da ETSI, usada para acrescentar escalabilidade a eventos ao vivo massivos como o desporto, integrada com o modelo unicast existente, com recurso automático.
- A Bouygues Telecom, em França, foi apresentada pela imprensa especializada como a primeira operadora francesa a transmitir comercialmente em mABR, a partir de 2023.
Nem todas as operadoras estão convencidas. A Deutsche Telekom apresentou publicamente o mABR como uma tecnologia de transição, útil onde a infraestrutura ainda não aguenta o unicast puro, mais do que como um destino de longo prazo.
Um padrão sobressai ao longo destas implementações. Foram quase todas construídas sobre a mesma implementação proprietária de um único fornecedor, o nanoCDN da Broadpeak, em vez de sobre pilhas interoperáveis baseadas em normas. É um facto de mercado, não um aval técnico. A especificação DVB-MABR é pública, mas durante anos não existiu nenhuma implementação neutra e abertamente disponível sobre a qual construir e testar, pelo que uma operadora que quisesse mABR em produção tinha pouca escolha prática de fornecedor.
O lado dos dispositivos
No lado do hardware, os fabricantes de descodificadores e de equipamento de cliente contam tanto como as operadoras. A CommScope oferece uma solução Multicast ABR que descreve como baseada em partes tanto da norma DVB como da da CableLabs, com um cliente que pode correr embutido num descodificador ou na gateway doméstica, e a empresa afirma que não são necessárias alterações aos dispositivos de streaming do lar. A Vantiva, antiga Technicolor, entregou descodificadores com software de cliente multicast ABR integrado. Os chips de descodificador de fornecedores como a Broadcom asseguram o suporte de IP multicast ao nível da rede, mas o próprio mABR está implementado em software que corre no dispositivo, e não como uma função nomeada do chip.
A lacuna é mais visível na maior plataforma de dispositivos. O Android TV na versão padrão só suporta unicast, pelo que o multicast ABR nesses dispositivos depende de integrações ao nível da operadora que acrescentam um cliente multicast. As próprias bibliotecas de reprodução da Google, o ExoPlayer e o Media3, não fornecem multicast ABR de forma nativa, e existe um pedido de funcionalidade em aberto a reclamá-lo.
A norma existe. A interoperabilidade é a parte difícil.
É uma suposição comum que o mABR está travado pela ausência de uma norma. Não é o caso.
A CableLabs fez trabalho inicial de arquitetura sobre IP multicast ABR por volta de 2014. O DVB Project publicou a sua arquitetura de referência para multicast ABR para comentários do setor em 2018, o seu Steering Board aprovou a especificação completa no início de 2020, e ela foi publicada como a norma ETSI TS 103 769 em novembro de 2020. Foi revista várias vezes desde então, incluindo uma atualização de 2023 que acrescentou os protocolos de transporte opcionais NORM e MSYNC, juntamente com funções de relatório, autenticidade e proteção contra adulteração. O grupo de trabalho do DVB que está por trás, o MCAST, é presidido por Richard Bradbury, da BBC R&D. Existe uma norma real, publicada e reconhecida internacionalmente, acompanhada de trabalhos complementares como as diretrizes de implementação do DVB-MABR e a especificação de descoberta de serviços DVB-I. No lado móvel, o 3GPP segue a sua própria via paralela, com a arquitetura dos 5G Multicast-Broadcast Services na Release 17, que partilha a mesma herança de protocolos FLUTE e ROUTE.
O que tem faltado é interoperabilidade na prática. Quase todas as implementações comerciais de mABR até hoje correm sobre a mesma pilha proprietária, o nanoCDN da Broadpeak. O MSYNC, um dos protocolos de transporte opcionais incorporados no DVB-MABR em 2023, começou como um protocolo da Broadpeak antes de ser trazido para a especificação. Uma norma implementada na sua maior parte por um só fornecedor é uma norma no papel. O que transforma uma especificação no papel num mercado multifornecedor que funciona é uma implementação neutra sobre a qual qualquer um possa construir e testar.
Onde entram a GPAC e a Motion Spell
Esta é a parte da história do mABR que aponta o caminho para uma normalização genuína.
A GPAC é um framework multimédia de código aberto de longa data, distribuído sob a licença LGPL e desenvolvido com a Motion Spell, o seu parceiro comercial. Tem raízes na investigação académica na Telecom Paris e foi descarregado perto de 100 milhões de vezes. A GPAC implementou o protocolo ROUTE para o ATSC 3.0 há anos, um trabalho que ganhou um prémio de inovação do NAB em 2018, e é o único projeto de código aberto que suporta tanto o ROUTE como o FLUTE, os dois protocolos de transporte obrigatórios do DVB-MABR. Em 2024 acrescentou suporte de FLUTE especificamente para o DVB-MABR. O media server da GPAC já pode funcionar como gateway de multicast para ABR, expondo uma sessão multicast como um serviço de streaming HTTP normal, com reparação unicast e uma janela de desfasamento temporal configurável.
O DVB lançou depois um pedido de propostas para uma ferramenta de código aberto destinada a verificar e validar implementações DVB-MABR. O resultado, as DVB-MABR Reference Tools, assenta na GPAC e na Motion Spell. É de código aberto, escrito em Python sobre a biblioteca GPAC, e funciona em dois modos: um modo servidor que gera um fluxo multicast a partir de uma fonte HTTP, e um modo gateway que recebe multicast e o volta a servir por HTTP, incluindo reparação HTTP. Está publicado na própria organização do GitHub do DVB e destina-se a engenheiros, integradores e equipas de validação que precisam de confirmar que um servidor multicast, uma gateway e leitores DASH padrão interoperam de facto.
É por isso que este trabalho conta mais do que mais um lançamento de produto. Uma implementação de referência isenta de royalties e disponível abertamente dá a cada operadora, fabricante de dispositivos e fornecedor de software uma base comum. É o mecanismo prático pelo qual o DVB-MABR pode passar de um mercado de implementações de fornecedor único para uma verdadeira interoperabilidade multifornecedor, que é a diferença entre uma norma publicada e uma norma que todo o ecossistema pode realmente usar. O envolvimento da GPAC liga também o mABR a investigação mais ampla, incluindo o trabalho do consórcio SMART-CD sobre uma entrega de vídeo mais sustentável, ao lado de parceiros como a Telecom Paris, a Ateme e a Viaccess-Orca.
Uma nota à parte: o peer-to-peer ataca o mesmo problema pelo outro lado
O mABR não é a única forma de evitar que um fluxo ao vivo popular seja enviado uma vez por espetador. A entrega peer-to-peer ataca o mesmo desperdício a partir da direção oposta. Em vez de enviar uma cópia para uma rede gerida e depois abri-la em leque perto do lar, uma camada peer-to-peer deixa que os próprios dispositivos dos espetadores partilhem segmentos entre si. Cada leitor obtém os primeiros bytes do CDN, depois troca fragmentos diretamente com outros leitores que estão a ver a mesma coisa, e só recorre ao CDN quando é mesmo preciso.
A empresa francesa Quanteec é um exemplo. A sua tecnologia, que começou como investigação académica, acrescenta uma camada assistida por pares a um fluxo de trabalho HLS ou DASH existente e é agnóstica em relação ao CDN e ao DRM. A Quanteec relata que uma implementação com a France Télévisions, que servia centenas de milhares de espetadores em simultâneo, descarregou em média cerca de 75 por cento do tráfego do CDN, com mais de 50 por cento de poupança de energia e menos rebuffering do que o unicast simples.
O contraste importante com o mABR é a rede. O mABR precisa de uma rede de acesso gerida e da cooperação da operadora. O peer-to-peer funciona sobre a internet pública, entre dispositivos, sem qualquer envolvimento da operadora, que é exatamente a lacuna que o mABR não consegue alcançar. A contrapartida é que o peer-to-peer depende de haver espetadores em simultâneo suficientes e da capacidade de envio e do comportamento dos dispositivos de consumo. As duas abordagens não se excluem mutuamente. Uma emissora sem controlo sobre o último quilómetro pode usar peer-to-peer já hoje, uma operadora que controla a sua própria rede pode usar mABR, e uma grande plataforma poderia apoiar-se em ambos.
O que isto significa para as operadoras
O mABR não é uma solução milagrosa e não é novo. É uma ferramenta focada para um problema específico e caro: entregar o mesmo fluxo ao vivo a uma audiência muito grande numa rede gerida sem pagar por cada cópia. Para uma operadora que transmite uma grande final desportiva, esse problema é real e agrava-se a cada época. Para um serviço puramente OTT sem controlo sobre o último quilómetro, o mABR é algo que pode pedir aos ISP que suportem, mas que não pode construir sozinho.
O resumo honesto é que a tecnologia funciona, a norma existe, as implementações são reais mas ainda concentradas em pilhas proprietárias de fornecedor único, a latência e o ecossistema de dispositivos continuam a ser limitações reais, e o trabalho de referência de código aberto liderado pela GPAC e pela Motion Spell é o caminho mais credível para mudar essa concentração.
A iReplay.TV é um coletivo de engenheiros de broadcast e streaming, pelo que os compromissos entre o mABR, o peer-to-peer e a entrega CDN unicast simples são o tipo de coisas que os seus membros ponderam com regularidade. O Multicast ABR é uma alavanca entre várias, e só ajuda dentro de uma rede gerida. Se a tua audiência te chega pela internet aberta, a poupança tem de vir de outro lado: entrega assistida por pares, um desenho de origem mais inteligente, melhores escolhas de codec e uma configuração de CDN mais apertada. Há uma ferramenta gratuita de otimização de custos de CDN no site para quem quiser olhar para os seus próprios números.
Referências e leituras complementares
- DVB, «Adaptive media streaming over IP multicast» (página da especificação 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» (atualização de 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» (repositório de código fonte): 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, solução Multicast Adaptive Bitrate (MABR): commscope.com
- IETF: FLUTE (RFC 6726), ROUTE (RFC 9223), NORM (RFC 5740), disponíveis em rfc-editor.org