Durante la Eurocopa 2024, más de 11,5 millones de hogares británicos vieron en streaming al menos un partido de las selecciones del Reino Unido a través de la red de banda ancha de BT. BT informó después de que el tráfico procedente de la BBC e ITV trepó a más de 30 veces el volumen semanal habitual, y ambas cadenas superaron brevemente a Netflix, Facebook y YouTube como las mayores fuentes de contenido de su red. El mayor pico de tráfico del torneo llegó en el momento en que Cole Palmer empató en la final.
La próxima prueba de esa escala está a solo un mes. La Copa del Mundo de la FIFA 2026 arranca en junio, organizada en Estados Unidos, Canadá y México, y su audiencia en directo recaerá sobre las mismas redes fijas y móviles, que nunca se construyeron para enviar el mismo partido a cada hogar como un flujo independiente.
Un pico así es difícil de absorber para una red, y la razón es estructural. Todos los formatos de streaming de uso amplio hoy, HLS y DASH incluidos, se basan en unicast. Cada espectador abre su propia sesión y obtiene su propia copia de cada segmento. Diez espectadores en el mismo canal significan diez flujos idénticos atravesando la red. Un millón de espectadores significa un millón de flujos idénticos. El contenido es el mismo para todos, pero la red lo transporta como si cada copia fuera algo distinto.
El Multicast ABR, habitualmente abreviado como mABR, es la principal respuesta del sector del streaming a ese problema. No es nuevo, ya está estandarizado, y un puñado de grandes operadores de telecomunicaciones ya lo explota en producción. También tiene límites reales que conviene entender antes de tratarlo como una solución para todo. Este artículo cubre qué es el mABR, cómo funciona, qué ahorra realmente, dónde se queda corto, quién lo ha desplegado y por qué el trabajo de código abierto liderado por GPAC y Motion Spell importa para el futuro de la tecnología.
¿Qué es el Multicast ABR?
El Multicast ABR entrega contenido en tasa de bits adaptativa corriente, los mismos segmentos HLS o DASH que un reproductor normal ya espera, sobre IP multicast en lugar de unicast. En la red gestionada de un operador, un canal se envía una sola vez a través de la red como un flujo multicast al que puede unirse cualquier número de hogares. La reconversión a HTTP unicast estándar ocurre dentro del hogar o cerca de él, de modo que el dispositivo y su reproductor nunca saben que algo ha cambiado. Desde el punto de vista del reproductor, sigue pidiendo segmentos por HTTP a lo que parece un edge de CDN cercano.
La idea de fondo es sencilla. En unicast, un espectador equivale a un flujo. En multicast, un canal equivale a un flujo, sin importar cuántos hogares estén sintonizados.
Conviene precisar dos puntos. Primero, el mABR es híbrido. El multicast se encarga del grueso de la entrega, y el unicast permanece en el circuito como vía de reparación y de respaldo. Segundo, el mABR está diseñado para contenido en directo y lineal. La nota técnica publicada por la Streaming Video Technology Alliance, un organismo del sector cuyo documento sobre multicast ABR fue dirigido por un ingeniero de Ericsson con contribuciones de operadores como Comcast, es explícita: el vídeo bajo demanda sigue viniendo de un CDN. El mABR justifica su valor cuando mucha gente ve lo mismo al mismo tiempo, es decir, el deporte en directo y las noticias en directo.
El vídeo en multicast no es nuevo, sobre todo en Francia
Conviene tener claro que la entrega de televisión en multicast tiene décadas, y Francia es uno de los mejores ejemplos de su funcionamiento a gran escala. A principios de los años 2000, cuando Free lanzó la Freebox, el operador integró la entrega de televisión sobre IP multicast directamente en su propia red DSL desagregada, algo que los DSLAM del operador histórico no ofrecían entonces. En 2008, Free figuraba como el mayor proveedor de IPTV del mundo. El multicast era la razón por la que la economía funcionaba: una sola copia de cada canal circulaba por la red sin importar cuántos hogares Freebox la estuvieran viendo.
Free también expuso ese flujo multicast directamente a los abonados, mediante un servicio llamado Multiposte. Permitía ver los canales de la Freebox TV en un ordenador junto al televisor, abriendo una lista de reproducción de canales en VLC. Los flujos eran simple IP multicast transportado por la Freebox y unido mediante IGMP, sin ningún descodificador de por medio. Toda una generación de usuarios de banda ancha franceses tuvo, de hecho, un receptor de televisión multicast funcionando en su PC.
Las herramientas tampoco han tenido nunca nada de exótico. VLC, el mismo reproductor en el que se apoyaba Multiposte, puede tomar un flujo unicast como entrada y reemitirlo a una dirección multicast por UDP o RTP con una sola configuración de salida de flujo. Convertir un flujo unicast en uno multicast es, por sí mismo, un problema corriente y resuelto desde hace mucho.
Entonces, si el multicast es antiguo y las herramientas están por todas partes, ¿qué hay realmente de nuevo en el Multicast ABR? La IPTV multicast clásica, el modelo Freebox, transportaba un flujo de transporte fijo y continuo hacia el descodificador propio del operador. El mABR, en cambio, transporta contenido moderno en tasa de bits adaptativa, los segmentos HLS y DASH que ya hablan todos los teléfonos, tabletas, smart TV y memorias de streaming, y apunta a todo el ecosistema fragmentado de dispositivos en lugar de a una única caja propietaria. La parte difícil del mABR no es el multicast. Es hacer multicast para streaming segmentado, adaptativo y multidispositivo, con la maquinaria de pasarela, rendezvous y reparación que eso exige.
Cómo funciona el mABR
La especificación DVB-MABR, desarrollada por el DVB Project y publicada por ETSI como TS 103 769, define una arquitectura de referencia construida a partir de un pequeño conjunto de funciones con nombre:
- Servidor multicast. Ingiere contenido ABR estándar desde un origen o un edge de CDN, asigna cada segmento a uno o varios objetos de transporte multicast y los transmite por IP multicast. Un operador le indica qué flujos capturar y cómo enviarlos a través de una API de configuración.
- Pasarela multicast. Recibe el flujo multicast y lo reconvierte en HTTP simple para los reproductores locales. Se comporta como una pequeña caché local y un proxy HTTP.
- Servicio de rendezvous multicast. Encamina la petición inicial de un reproductor, mediante redirección HTTP, hacia la pasarela correcta según el plan de servicio y las reglas de negocio del operador.
- Reparación unicast. Cuando se pierden paquetes multicast, la pasarela recupera las piezas que faltan por unicast, normalmente mediante peticiones HTTP por rango de bytes, para que la reproducción no se rompa.
Dónde se ejecuta la pasarela
La especificación es deliberadamente flexible respecto a dónde se sitúa la pasarela multicast. Puede ejecutarse en la red del operador, en la pasarela doméstica o el router, en el terminal de red óptica, o directamente dentro del descodificador. Cuando la pasarela y el reproductor están en el mismo dispositivo, la especificación del DVB indica que la interfaz entre ambos puede reducirse a una simple API local. La nota de la SVTA describía el mismo componente, al que llamaba cliente multicast, como desplegable en un descodificador, una pasarela residencial, un ONT, o dentro de la caché edge del operador. Esta última opción es útil por sí sola: un cliente mABR integrado en un edge de CDN puede llenar la caché por multicast y reducir las peticiones de vuelta al origen.
Protocolos de transporte
Por debajo, el mABR utiliza protocolos de entrega de archivos pensados para multicast unidireccional. El DVB-MABR hace obligatorios dos de ellos. FLUTE (File Delivery over Unidirectional Transport, RFC 6726) viene del mundo de la 3GPP. ROUTE (Real-Time Object Delivery over Unidirectional Transport, RFC 9223) viene de ATSC 3.0. Una revisión de 2023 de la especificación añadió dos protocolos opcionales, NORM (NACK-Oriented Reliable Multicast, RFC 5740) y MSYNC. Todos funcionan sobre UDP y transportan el contenido segmentado junto con corrección de errores hacia adelante.
Una propiedad útil: el mABR es agnóstico respecto al formato, el códec y el DRM. Mueve HLS o DASH, MPEG-TS o CMAF, cifrado o no, y no recodifica nada. Cambia cómo viajan los bytes, no lo que son.
Las ventajas del Multicast ABR
La escalabilidad, que es de lo que se trata
El argumento central a favor del mABR es que el coste de red de un canal en directo popular deja de crecer con la audiencia. La nota técnica de la SVTA lo ilustra con dos ejemplos de redes de acceso. En una red de cable DOCSIS, el número de canales necesarios para el ABR unicast crece de forma lineal a medida que se suman espectadores, mientras que con el mABR sube brevemente y luego se aplana, ya que los espectadores comparten los mismos flujos multicast. En una red de fibra GPON, la nota estima que para un operador con 500 canales lineales en el que el 80 por ciento de los espectadores ve el 10 por ciento de la oferta, el ahorro de ancho de banda en el núcleo de red alcanza alrededor del 50 por ciento con 32 clientes por PON, y la necesidad de ancho de banda por espectador cae por debajo del 3 por ciento de la cifra unicast una vez que la audiencia llega a las decenas de miles. La nota lo resume sin rodeos: el mABR puede reducir las necesidades de ancho de banda en el borde de la red, para eventos en directo extremadamente populares, del orden del petabyte al del megabyte.
Hay una cifra que viene directamente de un operador y no de una estimación modelada. En marzo de 2025, BT Group informó de su primer ensayo exitoso de MAUD, el nombre que da a la Multicast-Assisted Unicast Delivery, que llevaba contenido en directo de BBC Two a descodificadores EE en la red de producción. En horas punta, el ensayo convirtió más del 60 por ciento del tráfico de unicast a multicast.
La calidad de experiencia
El mABR se entrega como un servicio gestionado en lugar de uno de mejor esfuerzo. La nota de la SVTA señala que esto mitiga la inestabilidad de la reproducción, porque el operador controla la ruta en lugar de depender de la internet abierta entre el origen y el espectador. Para una final en directo, una entrega constante a todos los que están viendo importa tanto como el ahorro bruto de ancho de banda.
Reutiliza lo que ya existe
La nota de la SVTA destaca que el coste de infraestructura del mABR puede ser menor que el de otras opciones de escalado, porque la mayoría de los routers y elementos de red implicados ya están desplegados en la red del operador. El mABR también es complementario al almacenamiento en caché de CDN en lugar de un sustituto, y puede actuar como la fuente de contenido que llena las cachés de borde.
Los inconvenientes del Multicast ABR
Latencia añadida
La pasarela multicast tiene que recibir y reensamblar los segmentos antes de poder servirlos, lo que añade retardo sobre el flujo ABR de origen. Un análisis técnico, publicado por Techne Digitale, estima que el mABR añade en torno a dos segmentos de retardo a una entrega OTT típica, llevando la cifra de extremo a extremo de unos 8 segundos a unos 12. La nota de la SVTA sostiene que un diseño cuidadoso, con duraciones de segmento más cortas y transferencia por fragmentos de CMAF, puede mantener el mABR competitivo con el ABR unicast simple, o incluso por debajo. En cualquier caso, la latencia es una consideración real para el deporte en directo, donde un espectador que oye reaccionar a un vecino antes de que la acción llegue a su propia pantalla lo notará.
El problema del ecosistema de clientes
La nota de la SVTA califica la falta de un ecosistema de clientes desplegado como la principal barrera para una adopción más amplia del mABR. Las pasarelas domésticas y los ONT antiguos a menudo no tienen la CPU ni la memoria para ejecutar un cliente multicast. El hardware más reciente sí puede, pero los fabricantes de dispositivos tienen pocos motivos para construir, probar y mantener software de cliente multicast mientras no haya infraestructura que lo use, y los operadores tienen pocos motivos para desplegar infraestructura mientras los dispositivos no puedan aprovecharla. En un evento de CSI Magazine a principios de 2023, el arquitecto de TV de BT, Simon Jones, señaló que BT había operado televisión en multicast durante más de una década, pero que solo la entregaba a televisores y no a dispositivos conectados, y que BT no podría entregar algo como la Copa del Mundo con su infraestructura existente. Bob Hannent, arquitecto de reproducción y entrega de vídeo en DAZN, dijo en la misma conversación que el mercado seguía siendo «realmente inmaduro». Ambos señalaron la falta de soporte por parte de fabricantes de dispositivos como Google y Apple como el principal obstáculo.
Solo funciona en redes gestionadas
No hay multicast en la internet pública. El mABR funciona dentro de la red gestionada de un único operador, entre un servidor multicast que el operador explota y una pasarela que el operador controla. Un servicio puramente OTT como Netflix no puede desplegar el mABR de extremo a extremo por sí solo. Puede pedir a los ISP que lo admitan, pero depende de cada ISP individualmente.
Fragmentación
Como es local a cada red, el mABR solo es tan eficaz como el ISP en el que se ejecuta. Si la mitad de los ISP que sirven a una audiencia lo admiten, los espectadores de la otra mitad siguen teniendo la experiencia unicast y la misma congestión. A diferencia de un CDN unicast, ninguna empresa por sí sola puede ofrecer una experiencia mABR de extremo a extremo a toda la audiencia.
El problema quizá se esté reduciendo en las redes modernas
El análisis de Techne Digitale sostiene que en la fibra GPON moderna, donde un reparto 1:64 aún deja a cada hogar decenas de megabits por segundo, la estrechez de ancho de banda en la última milla para la que se diseñó el mABR quizá no exista, y que el mABR tiene más sentido en redes de cable más antiguas. La propia nota de la SVTA plantea una pregunta similar, al preguntarse si años de construcción de edges de CDN, mejores códecs como HEVC, AV1 y VVC, y nuevos protocolos de transporte no han permitido ya al sector mantenerse por delante de la curva de crecimiento. Vale la pena recordar que el propio proyecto temprano de mABR de Comcast, llevado por su grupo de investigación VIPER hacia 2015, nunca llegó a desplegarse.
Las múltiples variantes se comen el ahorro
Cada formato, cada escalera de tasas de bits y cada variante de DRM que un operador quiera servir tiene que enviarse por multicast por separado. Cuantos más tipos de dispositivo y protecciones de contenido haya en juego, más flujos multicast en paralelo se necesitan, y menor se vuelve la ganancia neta de eficiencia.
Quién usa realmente el mABR
El mABR ha superado la fase de laboratorio. Los ejemplos públicos más claros vienen de operadores de telecomunicaciones que explotan sus propias redes de acceso gestionadas.
- BT Group, en el Reino Unido, ha sido el más transparente al respecto. BT anunció su iniciativa MAUD en 2024 e informó de su primer ensayo en directo exitoso en marzo de 2025, que llevaba BBC Two a descodificadores EE y convertía más del 60 por ciento del tráfico de pico a multicast. BT ha dicho que el objetivo es gestionar eventos en directo de audiencia masiva, y la prensa especializada ha informado de que hay cadenas evaluando MAUD para la Copa del Mundo de la FIFA 2026.
- Orange, en España, ha comunicado a sus propios clientes que es el primer operador del país en ofrecer streaming mABR para sus eventos en directo de mayor audiencia, citando LaLiga, la Fórmula 1 y MotoGP, y en extenderlo más allá del descodificador a otros dispositivos del hogar.
- TIM, en Italia, ha escrito en su propia revista técnica que desde 2021 explota una plataforma de distribución de contenido en multicast conforme al estándar M-ABR de ETSI, usada para añadir escalabilidad a eventos en directo masivos como el deporte, integrada con el modelo unicast existente con repliegue automático.
- Bouygues Telecom, en Francia, fue presentado por la prensa especializada como el primer operador francés en emitir comercialmente en mABR, a partir de 2023.
No todos los operadores están convencidos. Deutsche Telekom ha presentado públicamente el mABR como una tecnología de transición, útil allí donde la infraestructura todavía no puede soportar el unicast puro, más que como un destino a largo plazo.
Un patrón destaca a lo largo de estos despliegues. Casi todos se han construido sobre la misma implementación propietaria de un único proveedor, el nanoCDN de Broadpeak, en lugar de sobre pilas interoperables basadas en estándares. Es un hecho de mercado, no un aval técnico. La especificación DVB-MABR es pública, pero durante años no existió ninguna implementación neutral y disponible abiertamente sobre la que construir y probar, de modo que un operador que quería mABR en producción apenas tenía elección práctica de proveedor.
El lado de los dispositivos
En el lado del hardware, los fabricantes de descodificadores y de equipos de cliente cuentan tanto como los operadores. CommScope ofrece una solución Multicast ABR que describe como basada en partes tanto del estándar DVB como del de CableLabs, con un cliente que puede ejecutarse embebido en un descodificador o en la pasarela doméstica, y la empresa afirma que no hace falta ningún cambio en los dispositivos de streaming del hogar. Vantiva, antes Technicolor, ha entregado descodificadores con software de cliente multicast ABR integrado. Los chips de descodificador de proveedores como Broadcom proporcionan soporte de IP multicast a nivel de red, pero el mABR en sí está implementado en software que se ejecuta en el dispositivo, y no como una función con nombre del chip.
La brecha es más visible en la mayor plataforma de dispositivos. Android TV en su versión estándar solo admite unicast, de modo que el multicast ABR en esos dispositivos depende de integraciones a nivel de operador que añaden un cliente multicast. Las propias bibliotecas de reproducción de Google, ExoPlayer y Media3, no proporcionan multicast ABR de forma nativa, y hay una solicitud de funcionalidad abierta que lo reclama.
El estándar existe. La interoperabilidad es la parte difícil.
Es una suposición común que el mABR está frenado por la ausencia de un estándar. No es el caso.
CableLabs hizo trabajo temprano de arquitectura de IP multicast ABR hacia 2014. El DVB Project publicó su arquitectura de referencia para multicast ABR para comentarios del sector en 2018, su Steering Board aprobó la especificación completa a principios de 2020, y se publicó como el estándar ETSI TS 103 769 en noviembre de 2020. Se ha revisado varias veces desde entonces, incluida una actualización de 2023 que añadió los protocolos de transporte opcionales NORM y MSYNC junto con funciones de informe, autenticidad y protección contra manipulación. El grupo de trabajo del DVB que está detrás, MCAST, está presidido por Richard Bradbury, de BBC R&D. Existe un estándar real, publicado y reconocido internacionalmente, acompañado de trabajos complementarios como las directrices de implementación del DVB-MABR y la especificación de descubrimiento de servicios DVB-I. En el lado móvil, la 3GPP sigue su propia vía paralela, con la arquitectura de los 5G Multicast-Broadcast Services en la Release 17, que comparte la misma herencia de protocolos FLUTE y ROUTE.
Lo que ha faltado es interoperabilidad en la práctica. Casi todos los despliegues comerciales de mABR hasta la fecha funcionan sobre la misma pila propietaria, el nanoCDN de Broadpeak. MSYNC, uno de los protocolos de transporte opcionales incorporados al DVB-MABR en 2023, empezó siendo un protocolo de Broadpeak antes de pasar a la especificación. Un estándar implementado en su mayor parte por un solo proveedor es un estándar sobre el papel. Lo que convierte una especificación sobre el papel en un mercado multiproveedor que funciona es una implementación neutral sobre la que cualquiera pueda construir y probar.
Dónde entran GPAC y Motion Spell
Esta es la parte de la historia del mABR que apunta hacia una normalización genuina.
GPAC es un framework multimedia de código abierto de largo recorrido, distribuido bajo la licencia LGPL y desarrollado con Motion Spell, su socio comercial. Tiene raíces en la investigación académica en Telecom Paris y se ha descargado cerca de 100 millones de veces. GPAC implementó el protocolo ROUTE para ATSC 3.0 hace años, un trabajo que ganó un premio a la innovación del NAB en 2018, y es el único proyecto de código abierto que admite tanto ROUTE como FLUTE, los dos protocolos de transporte obligatorios del DVB-MABR. En 2024 añadió soporte de FLUTE específicamente para DVB-MABR. El media server de GPAC ya puede actuar como pasarela multicast-a-ABR, exponiendo una sesión multicast como un servicio de streaming HTTP normal, con reparación unicast y una ventana de desfase temporal configurable.
El DVB lanzó después una petición de propuestas para una herramienta de código abierto destinada a verificar y validar implementaciones DVB-MABR. El resultado, las DVB-MABR Reference Tools, se apoya en GPAC y Motion Spell. Es de código abierto, escrito en Python sobre la biblioteca GPAC, y funciona en dos modos: un modo servidor que genera un flujo multicast a partir de una fuente HTTP, y un modo pasarela que recibe multicast y lo vuelve a servir por HTTP, incluida la reparación HTTP. Está publicado en la propia organización de GitHub del DVB y está dirigido a ingenieros, integradores y equipos de validación que necesitan confirmar que un servidor multicast, una pasarela y reproductores DASH estándar interoperan realmente.
Por eso este trabajo importa más que un lanzamiento de producto más. Una implementación de referencia libre de regalías y disponible abiertamente da a cada operador, fabricante de dispositivos y proveedor de software una base común. Es el mecanismo práctico mediante el cual el DVB-MABR puede pasar de un mercado de despliegues de proveedor único hacia una verdadera interoperabilidad multiproveedor, que es la diferencia entre un estándar publicado y un estándar que todo el ecosistema puede usar de verdad. La implicación de GPAC también vincula el mABR con una investigación más amplia, incluido el trabajo del consorcio SMART-CD sobre una entrega de vídeo más sostenible, junto a socios como Telecom Paris, Ateme y Viaccess-Orca.
Un apunte al margen: el peer-to-peer ataca el mismo problema por el otro extremo
El mABR no es la única forma de evitar que un flujo en directo popular se envíe una vez por espectador. La entrega peer-to-peer va a por el mismo despilfarro desde la dirección opuesta. En lugar de enviar una copia a una red gestionada y abrirla en abanico cerca del hogar, una capa peer-to-peer deja que los propios dispositivos de los espectadores compartan segmentos entre sí. Cada reproductor obtiene los primeros bytes del CDN, luego intercambia fragmentos directamente con otros reproductores que están viendo lo mismo, y solo recurre al CDN cuando no le queda más remedio.
La empresa francesa Quanteec es un ejemplo. Su tecnología, que empezó como investigación académica, añade una capa asistida por pares a un flujo de trabajo HLS o DASH existente y es agnóstica respecto al CDN y al DRM. Quanteec informa de que un despliegue con France Télévisions, que atendía a cientos de miles de espectadores simultáneos, descargó de media en torno al 75 por ciento del tráfico del CDN, con más del 50 por ciento de ahorro de energía y menos rebuffering que el unicast simple.
El contraste importante con el mABR es la red. El mABR necesita una red de acceso gestionada y la cooperación del operador. El peer-to-peer funciona sobre la internet pública, entre dispositivos, sin ninguna implicación del operador, que es exactamente el hueco que el mABR no puede alcanzar. La contrapartida es que el peer-to-peer depende de contar con suficientes espectadores simultáneos y de la capacidad de subida y el comportamiento de los dispositivos de consumo. Los dos enfoques no se excluyen entre sí. Una cadena sin control sobre la última milla puede usar peer-to-peer hoy mismo, un operador que controla su propia red puede usar mABR, y una gran plataforma podría apoyarse en ambos.
Qué implica esto para los operadores
El mABR no es una solución milagrosa y no es nuevo. Es una herramienta enfocada para un problema concreto y caro: entregar el mismo flujo en directo a una audiencia muy grande en una red gestionada sin pagar por cada copia. Para un operador que transmite una gran final deportiva, ese problema es real y empeora cada temporada. Para un servicio puramente OTT sin control sobre la última milla, el mABR es algo que puede pedir a los ISP que admitan, pero que no puede construir solo.
El resumen honesto es que la tecnología funciona, el estándar existe, los despliegues son reales pero todavía están concentrados en pilas propietarias de proveedor único, la latencia y el ecosistema de dispositivos siguen siendo limitaciones reales, y el trabajo de referencia de código abierto liderado por GPAC y Motion Spell es la vía más creíble para cambiar esa concentración.
iReplay.TV es un colectivo de ingenieros de broadcast y streaming, así que los compromisos entre el mABR, el peer-to-peer y la entrega CDN unicast simple son de las cosas que sus miembros sopesan con regularidad. El Multicast ABR es una palanca entre varias, y solo ayuda dentro de una red gestionada. Si tu audiencia te llega por la internet abierta, el ahorro tiene que venir de otro sitio: entrega asistida por pares, un diseño de origen más inteligente, mejores elecciones de códec y una configuración de CDN más ajustada. Hay una herramienta gratuita de optimización de costes de CDN en el sitio para quien quiera mirar sus propias cifras.
Referencias y lecturas complementarias
- DVB, «Adaptive media streaming over IP multicast» (página de la especificación 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» (actualización 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» (repositorio de código fuente): 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, solución Multicast Adaptive Bitrate (MABR): commscope.com
- IETF: FLUTE (RFC 6726), ROUTE (RFC 9223), NORM (RFC 5740), disponibles en rfc-editor.org