Pendant l'Euro 2024, plus de 11,5 millions de foyers britanniques ont regardé en streaming au moins un match des nations du Royaume-Uni sur le réseau haut débit de BT. BT a ensuite indiqué que le trafic en provenance de la BBC et d'ITV avait grimpé à plus de 30 fois le volume hebdomadaire habituel, les deux diffuseurs dépassant brièvement Netflix, Facebook et YouTube parmi les plus grandes sources de contenu de son réseau. Le plus gros pic de trafic du tournoi est survenu au moment où Cole Palmer a égalisé en finale.
Le prochain test de cette ampleur n'est plus qu'à un mois. La Coupe du Monde de la FIFA 2026 débute en juin, organisée aux États-Unis, au Canada et au Mexique, et son audience en direct va se reporter sur les mêmes réseaux fixes et mobiles, qui n'ont jamais été conçus pour envoyer le même match à chaque foyer sous la forme d'un flux distinct.
Un tel pic est difficile à absorber pour un réseau, et la raison est structurelle. Tous les formats de streaming largement utilisés aujourd'hui, HLS et DASH compris, reposent sur l'unicast. Chaque spectateur ouvre sa propre session et récupère sa propre copie de chaque segment. Dix spectateurs sur la même chaîne, cela fait dix flux identiques qui traversent le réseau. Un million de spectateurs, cela fait un million de flux identiques. Le contenu est le même pour tout le monde, mais le réseau le transporte comme si chaque copie était une chose différente.
Le Multicast ABR, le plus souvent abrégé en mABR, est la principale réponse du secteur du streaming à ce problème. Ce n'est pas une nouveauté, c'est déjà normalisé, et une poignée de grands opérateurs télécoms l'exploitent déjà en production. La technologie a aussi de vraies limites, qu'il vaut mieux comprendre avant d'y voir une solution à tout. Cet article explique ce qu'est le mABR, comment il fonctionne, ce qu'il économise réellement, là où il pèche, qui l'a déployé, et pourquoi le travail open source mené par GPAC et Motion Spell compte pour l'avenir de cette technologie.
Qu'est-ce que le Multicast ABR ?
Le Multicast ABR diffuse du contenu en débit adaptatif ordinaire, les mêmes segments HLS ou DASH qu'un lecteur classique attend déjà, sur de l'IP multicast plutôt qu'en unicast. Sur le réseau managé d'un opérateur, une chaîne est envoyée une seule fois à travers le réseau sous la forme d'un flux multicast auquel n'importe quel nombre de foyers peut se joindre. La reconversion vers du HTTP unicast standard se produit à l'intérieur du foyer ou à proximité, si bien que l'appareil et son lecteur ne savent jamais que quoi que ce soit a changé. Du point de vue du lecteur, il demande toujours des segments en HTTP à ce qui ressemble à un edge de CDN proche.
L'idée de fond est simple. En unicast, un spectateur égale un flux. En multicast, une chaîne égale un flux, quel que soit le nombre de foyers à l'écoute.
Deux points méritent d'être précisés. D'abord, le mABR est hybride. Le multicast assure l'essentiel de la diffusion, et l'unicast reste dans la boucle comme voie de réparation et de repli. Ensuite, le mABR est conçu pour le contenu en direct et linéaire. La note technique publiée par la Streaming Video Technology Alliance, un organisme du secteur dont le document sur le multicast ABR a été dirigé par un ingénieur d'Ericsson avec des contributions d'opérateurs dont Comcast, est explicite : la vidéo à la demande continue de venir d'un CDN. Le mABR justifie son intérêt quand beaucoup de gens regardent la même chose en même temps, c'est-à-dire le sport en direct et l'information en direct.
Le multicast vidéo n'a rien de nouveau, surtout en France
Il faut être clair : la diffusion de la télévision en multicast a des décennies d'existence, et la France est l'un des meilleurs exemples de son fonctionnement à grande échelle. Au début des années 2000, lorsque Free a lancé la Freebox, l'opérateur a intégré la diffusion de la télévision en IP multicast directement dans son propre réseau DSL dégroupé, ce que les DSLAM de l'opérateur historique ne proposaient pas à l'époque. En 2008, Free était classé premier des plus grands diffuseurs d'IPTV au monde. Le multicast était la raison pour laquelle l'équation économique tenait : une seule copie de chaque chaîne circulait sur le réseau, quel que soit le nombre de foyers Freebox en train de la regarder.
Free a aussi exposé ce flux multicast directement aux abonnés, via un service appelé Multiposte. Il permettait de regarder les chaînes de la Freebox TV sur un ordinateur en parallèle du téléviseur, en ouvrant une playlist de chaînes dans VLC. Les flux étaient du simple IP multicast acheminé par la Freebox et rejoint via IGMP, sans aucun décodeur impliqué. Toute une génération d'utilisateurs du haut débit français a eu, de fait, un récepteur de télévision multicast qui tournait sur son PC.
Les outils n'ont jamais rien eu d'exotique non plus. VLC, le lecteur sur lequel reposait Multiposte, peut prendre un flux unicast en entrée et le réémettre vers une adresse multicast en UDP ou RTP avec une simple configuration de sortie de flux. Transformer un flux unicast en flux multicast est, en soi, un problème ordinaire et résolu depuis longtemps.
Alors, si le multicast est ancien et que les outils sont partout, qu'y a-t-il réellement de nouveau dans le Multicast ABR ? L'IPTV multicast classique, le modèle Freebox, transportait un flux de transport continu et figé vers le décodeur propre à l'opérateur. Le mABR transporte au contraire du contenu en débit adaptatif moderne, les segments HLS et DASH que tout téléphone, tablette, smart TV et clé de streaming parle déjà, et il vise tout l'écosystème fragmenté des appareils plutôt qu'un seul boîtier propriétaire. La partie difficile du mABR, ce n'est pas le multicast. C'est de faire du multicast pour du streaming segmenté, adaptatif et multi-appareils, avec la mécanique de passerelle, de rendez-vous et de réparation que cela exige.
Comment fonctionne le mABR
La spécification DVB-MABR, développée par le DVB Project et publiée par l'ETSI sous la référence TS 103 769, définit une architecture de référence construite à partir d'un petit ensemble de fonctions nommées :
- Le serveur multicast. Il ingère du contenu ABR standard depuis une origine ou un edge de CDN, associe chaque segment à un ou plusieurs objets de transport multicast, et les transmet en IP multicast. Un opérateur lui indique quels flux capturer et comment les envoyer via une API de configuration.
- La passerelle multicast. Elle reçoit le flux multicast et le reconvertit en simple HTTP pour les lecteurs locaux. Elle se comporte comme un petit cache local et un proxy HTTP.
- Le service de rendez-vous multicast. Il aiguille la requête initiale d'un lecteur, par redirection HTTP, vers la bonne passerelle en fonction de l'offre de service et des règles métier de l'opérateur.
- La réparation unicast. Lorsque des paquets multicast sont perdus, la passerelle récupère les morceaux manquants en unicast, généralement au moyen de requêtes HTTP par plage d'octets, pour que la lecture ne se rompe pas.
Où s'exécute la passerelle
La spécification est délibérément souple quant à l'emplacement de la passerelle multicast. Elle peut s'exécuter dans le réseau de l'opérateur, dans la passerelle domestique ou le routeur, dans le terminal de réseau optique, ou directement à l'intérieur du décodeur. Lorsque la passerelle et le lecteur sont sur le même appareil, la spécification du DVB indique que l'interface entre les deux peut se réduire à une simple API locale. La note de la SVTA décrivait le même composant, qu'elle appelait le client multicast, comme déployable sur un décodeur, une passerelle résidentielle, un ONT, ou à l'intérieur du cache edge de l'opérateur. Cette dernière option est utile en soi : un client mABR intégré à un edge de CDN peut alimenter le cache en multicast et réduire les requêtes renvoyées vers l'origine.
Les protocoles de transport
En dessous, le mABR utilise des protocoles de livraison de fichiers conçus pour le multicast unidirectionnel. Le DVB-MABR en rend deux obligatoires. FLUTE (File Delivery over Unidirectional Transport, RFC 6726) vient du monde de la 3GPP. ROUTE (Real-Time Object Delivery over Unidirectional Transport, RFC 9223) vient de l'ATSC 3.0. Une révision de 2023 de la spécification a ajouté deux protocoles optionnels, NORM (NACK-Oriented Reliable Multicast, RFC 5740) et MSYNC. Tous fonctionnent sur UDP et transportent le contenu segmenté accompagné d'un mécanisme de correction d'erreur (FEC).
Une propriété utile : le mABR est agnostique vis-à-vis du format, du codec et du DRM. Il achemine du HLS ou du DASH, du MPEG-TS ou du CMAF, chiffré ou non, et il ne réencode rien. Il change la façon dont les octets circulent, pas ce qu'ils sont.
Les avantages du Multicast ABR
Le passage à l'échelle, qui est tout l'enjeu
L'argument central en faveur du mABR, c'est que le coût réseau d'une chaîne en direct populaire cesse de croître avec l'audience. La note technique de la SVTA l'illustre avec deux exemples de réseaux d'accès. Sur un réseau câblé DOCSIS, le nombre de canaux nécessaires à l'ABR unicast croît de façon linéaire à mesure que les spectateurs arrivent, tandis qu'avec le mABR il monte brièvement puis se stabilise, les spectateurs partageant les mêmes flux multicast. Sur un réseau fibre GPON, la note estime que pour un opérateur diffusant 500 chaînes linéaires où 80 pour cent des spectateurs regardent 10 pour cent de la grille, les économies de bande passante sur le cœur de réseau atteignent environ 50 pour cent avec 32 clients par PON, et le besoin de bande passante par spectateur tombe sous les 3 pour cent du chiffre unicast une fois que l'audience se compte en dizaines de milliers. La note résume crûment : le mABR peut faire passer les besoins de bande passante en bordure de réseau, pour des événements en direct extrêmement populaires, de l'ordre du pétaoctet à celui du mégaoctet.
Il existe un chiffre qui vient directement d'un opérateur, et non d'une estimation modélisée. En mars 2025, BT Group a annoncé le premier essai réussi de MAUD, le nom qu'il donne à la Multicast-Assisted Unicast Delivery, qui acheminait le contenu en direct de BBC Two vers des décodeurs EE sur le réseau de production. Aux heures de pointe, l'essai a converti plus de 60 pour cent du trafic d'unicast en multicast.
La qualité d'expérience
Le mABR est fourni comme un service managé plutôt qu'en best-effort. La note de la SVTA relève que cela atténue la gigue de lecture, parce que l'opérateur maîtrise le chemin au lieu de dépendre de l'internet ouvert entre l'origine et le spectateur. Pour une finale en direct, une diffusion régulière vers tous ceux qui regardent compte autant que l'économie brute de bande passante.
Il réutilise ce qui existe déjà
La note de la SVTA souligne que le coût d'infrastructure du mABR peut être inférieur à celui d'autres options de passage à l'échelle, parce que la plupart des routeurs et des éléments de réseau concernés sont déjà déployés dans le réseau de l'opérateur. Le mABR est aussi complémentaire de la mise en cache CDN plutôt qu'un remplacement, et peut servir de source de contenu pour alimenter les caches de bordure.
Les inconvénients du Multicast ABR
Une latence supplémentaire
La passerelle multicast doit recevoir et réassembler les segments avant de pouvoir les servir, ce qui ajoute du délai au flux ABR source. Une analyse technique, publiée par Techne Digitale, estime que le mABR ajoute environ deux segments de délai à une diffusion OTT typique, faisant passer le chiffre de bout en bout d'environ 8 secondes à environ 12. La note de la SVTA soutient qu'une conception soignée, avec notamment des durées de segment plus courtes et le transfert par fragments du CMAF, peut maintenir le mABR au niveau de l'ABR unicast simple, voire en dessous. Dans tous les cas, la latence est un vrai sujet pour le sport en direct, où un spectateur qui entend son voisin réagir avant que l'action n'arrive sur son propre écran le remarquera.
Le problème de l'écosystème client
La note de la SVTA qualifie l'absence d'un écosystème client déployé de principal frein à une adoption plus large du mABR. Les passerelles domestiques et les ONT anciens n'ont souvent pas le processeur ni la mémoire nécessaires pour faire tourner un client multicast. Le matériel plus récent le peut, mais les fabricants d'appareils ont peu de raisons de développer, tester et maintenir un logiciel client multicast tant qu'il n'y a pas d'infrastructure pour s'en servir, et les opérateurs ont peu de raisons de déployer une infrastructure tant que les appareils ne savent pas l'utiliser. Lors d'un événement de CSI Magazine début 2023, l'architecte TV de BT Simon Jones a fait remarquer que BT exploitait la télévision en multicast depuis plus de dix ans, mais qu'il ne la diffusait que vers des téléviseurs, pas vers des appareils connectés, et que BT ne pourrait pas diffuser un événement comme la Coupe du Monde avec son infrastructure existante. Bob Hannent, architecte lecture et diffusion vidéo chez DAZN, a déclaré lors de la même discussion que le marché était encore « vraiment immature ». Tous deux ont désigné le manque de prise en charge par les fabricants d'appareils, comme Google et Apple, comme le principal obstacle.
Cela ne fonctionne que sur les réseaux managés
Il n'y a pas de multicast sur l'internet public. Le mABR fonctionne à l'intérieur du réseau managé d'un seul opérateur, entre un serveur multicast que l'opérateur exploite et une passerelle que l'opérateur contrôle. Un service purement OTT comme Netflix ne peut pas déployer le mABR de bout en bout par lui-même. Il peut demander aux FAI de le prendre en charge, mais il dépend de chaque FAI individuellement.
La fragmentation
Parce qu'il est local à chaque réseau, le mABR n'est efficace que dans la mesure où le FAI sur lequel il tourne l'est. Si la moitié des FAI desservant une audience le prennent en charge, les spectateurs de l'autre moitié ont toujours l'expérience unicast et la même congestion. Contrairement à un CDN unicast, aucune entreprise seule ne peut offrir une expérience mABR de bout en bout à l'ensemble de l'audience.
Le problème se réduit peut-être sur les réseaux modernes
L'analyse de Techne Digitale soutient que sur la fibre GPON moderne, où un partage 1:64 laisse encore à chaque foyer des dizaines de mégabits par seconde, la pénurie de bande passante sur le dernier kilomètre pour laquelle le mABR a été conçu n'existe peut-être pas, et que le mABR a surtout du sens sur les réseaux câblés plus anciens. La note de la SVTA pose elle-même une question similaire, en se demandant si des années de construction d'edges de CDN, de meilleurs codecs comme le HEVC, l'AV1 et le VVC, et de nouveaux protocoles de transport n'ont pas déjà permis au secteur de garder une longueur d'avance sur la courbe de croissance. Il vaut la peine de rappeler que le propre projet mABR précoce de Comcast, mené par son groupe de recherche VIPER vers 2015, n'a jamais abouti à un déploiement.
Les multiples déclinaisons grignotent les économies
Chaque format, chaque échelle de débits et chaque variante de DRM qu'un opérateur veut servir doit être multicasté séparément. Plus il y a de types d'appareils et de protections de contenu en jeu, plus il faut de flux multicast en parallèle, et plus le gain net d'efficacité se réduit.
Qui utilise réellement le mABR
Le mABR a dépassé le stade du laboratoire. Les exemples publics les plus nets viennent d'opérateurs télécoms qui exploitent leurs propres réseaux d'accès managés.
- BT Group, au Royaume-Uni, a été le plus transparent à ce sujet. BT a annoncé son initiative MAUD en 2024 et a fait état de son premier essai en direct réussi en mars 2025, qui acheminait BBC Two vers des décodeurs EE et convertissait plus de 60 pour cent du trafic de pointe en multicast. BT a indiqué que l'objectif est de gérer les événements en direct à très large audience, et la presse spécialisée a rapporté que des diffuseurs évaluent MAUD pour la Coupe du Monde de la FIFA 2026.
- Orange, en Espagne, a annoncé à ses propres clients qu'il est le premier opérateur du pays à proposer le streaming mABR pour ses événements en direct à plus forte audience, en citant LaLiga, la Formule 1 et le MotoGP, et à l'étendre au-delà du décodeur vers d'autres appareils du foyer.
- TIM, en Italie, a écrit dans sa propre revue technique qu'il exploite depuis 2021 une plateforme de distribution de contenu en multicast conforme au standard M-ABR de l'ETSI, utilisée pour ajouter du passage à l'échelle aux événements en direct massifs comme le sport, intégrée au modèle unicast existant avec repli automatique.
- Bouygues Telecom, en France, a été présenté par la presse spécialisée comme le premier opérateur français à diffuser commercialement en mABR, à partir de 2023.
Tous les opérateurs ne sont pas convaincus. Deutsche Telekom a présenté publiquement le mABR comme une technologie de transition, utile là où l'infrastructure ne peut pas encore supporter le tout-unicast, plutôt que comme une destination de long terme.
Une constante ressort de ces déploiements. Ils ont presque tous été construits sur la même implémentation propriétaire d'un fournisseur unique, le nanoCDN de Broadpeak, plutôt que sur des piles interopérables fondées sur des standards. C'est un constat de marché, pas une caution technique. La spécification DVB-MABR est publique, mais pendant des années il n'a existé aucune implémentation neutre et librement disponible sur laquelle s'appuyer pour développer et tester, si bien qu'un opérateur qui voulait du mABR en production n'avait guère le choix de son fournisseur.
Côté appareils
Côté matériel, les fabricants de décodeurs et d'équipements clients comptent autant que les opérateurs. CommScope propose une solution Multicast ABR qu'il décrit comme fondée sur des parties à la fois du standard DVB et du standard CableLabs, avec un client qui peut s'exécuter embarqué dans un décodeur ou dans la passerelle domestique, et l'entreprise indique qu'aucune modification n'est nécessaire sur les appareils de streaming du foyer. Vantiva, anciennement Technicolor, a livré des décodeurs intégrant un logiciel client multicast ABR. Les puces de décodeur de fournisseurs comme Broadcom assurent la prise en charge de l'IP multicast au niveau réseau, mais le mABR lui-même est implémenté en logiciel qui tourne sur l'appareil, et non comme une fonction nommée de la puce.
L'écart est le plus visible sur la plus grande plateforme d'appareils. Android TV en version standard ne prend en charge que l'unicast, si bien que le multicast ABR sur ces appareils dépend d'intégrations de niveau opérateur qui ajoutent un client multicast. Les propres bibliothèques de lecture de Google, ExoPlayer et Media3, ne fournissent pas le multicast ABR nativement, et une demande de fonctionnalité ouverte le réclame.
Le standard existe. L'interopérabilité, voilà la partie difficile.
On suppose souvent que le mABR est freiné par l'absence de standard. Ce n'est pas le cas.
CableLabs a mené des travaux pionniers sur l'architecture de l'IP multicast ABR vers 2014. Le DVB Project a publié son architecture de référence pour le multicast ABR, soumise aux commentaires du secteur, en 2018, son Steering Board a approuvé la spécification complète début 2020, et elle a été publiée comme standard ETSI TS 103 769 en novembre 2020. Elle a été révisée plusieurs fois depuis, dont une mise à jour de 2023 qui a ajouté les protocoles de transport optionnels NORM et MSYNC ainsi que des fonctions de reporting, d'authenticité et de protection contre l'altération. Le groupe de travail du DVB qui en est à l'origine, MCAST, est présidé par Richard Bradbury, de BBC R&D. Il existe bel et bien un standard réel, publié et reconnu internationalement, accompagné de travaux connexes comme les lignes directrices d'implémentation du DVB-MABR et la spécification de découverte de services DVB-I. Côté mobile, la 3GPP suit sa propre voie parallèle, avec l'architecture des 5G Multicast-Broadcast Services dans la Release 17, qui partage le même héritage de protocoles FLUTE et ROUTE.
Ce qui a manqué, c'est l'interopérabilité dans la pratique. Presque tous les déploiements commerciaux de mABR à ce jour reposent sur la même pile propriétaire, le nanoCDN de Broadpeak. MSYNC, l'un des protocoles de transport optionnels intégrés au DVB-MABR en 2023, a d'abord été un protocole de Broadpeak avant d'être repris dans la spécification. Un standard qui n'est implémenté pour l'essentiel que par un seul fournisseur est un standard sur le papier. Ce qui transforme une spécification sur le papier en un marché multi-fournisseurs qui fonctionne, c'est une implémentation neutre sur laquelle chacun peut développer et tester.
Là où GPAC et Motion Spell entrent en jeu
C'est la partie de l'histoire du mABR qui montre la voie vers une véritable normalisation.
GPAC est un framework multimédia open source de longue date, distribué sous licence LGPL et développé avec Motion Spell, son partenaire commercial. Il prend racine dans la recherche académique à Telecom Paris et a été téléchargé près de 100 millions de fois. GPAC a implémenté le protocole ROUTE pour l'ATSC 3.0 il y a des années, un travail qui a remporté un prix de l'innovation du NAB en 2018, et c'est le seul projet open source à prendre en charge à la fois ROUTE et FLUTE, les deux protocoles de transport obligatoires du DVB-MABR. En 2024, il a ajouté la prise en charge de FLUTE spécifiquement pour le DVB-MABR. Le media server de GPAC peut déjà jouer le rôle de passerelle multicast-vers-ABR, en exposant une session multicast comme un service de streaming HTTP normal, avec réparation unicast et une fenêtre de différé configurable.
Le DVB a ensuite lancé un appel d'offres pour un outil open source destiné à vérifier et valider les implémentations DVB-MABR. Le résultat, les DVB-MABR Reference Tools, s'appuie sur GPAC et Motion Spell. C'est de l'open source, écrit en Python par-dessus la bibliothèque GPAC, et il fonctionne en deux modes : un mode serveur qui génère un flux multicast à partir d'une source HTTP, et un mode passerelle qui reçoit le multicast et le ressert en HTTP, réparation HTTP comprise. Il est publié dans l'organisation GitHub du DVB lui-même et s'adresse aux ingénieurs, intégrateurs et équipes de validation qui doivent confirmer qu'un serveur multicast, une passerelle et des lecteurs DASH standard interopèrent réellement.
C'est pourquoi ce travail compte plus qu'un énième lancement de produit. Une implémentation de référence libre de droits et ouvertement disponible donne à chaque opérateur, fabricant d'appareils et éditeur de logiciels une base commune. C'est le mécanisme concret par lequel le DVB-MABR peut passer d'un marché de déploiements à fournisseur unique vers une véritable interopérabilité multi-fournisseurs, ce qui fait toute la différence entre un standard publié et un standard que l'ensemble de l'écosystème peut réellement utiliser. L'implication de GPAC rattache aussi le mABR à des travaux de recherche plus larges, dont ceux du consortium SMART-CD sur une diffusion vidéo plus durable, aux côtés de partenaires comme Telecom Paris, Ateme et Viaccess-Orca.
En aparté : le pair-à-pair s'attaque au même problème par l'autre bout
Le mABR n'est pas le seul moyen d'éviter qu'un flux en direct populaire soit envoyé une fois par spectateur. La diffusion en pair-à-pair s'attaque au même gaspillage par le bout opposé. Au lieu d'envoyer une copie dans un réseau managé puis de la diffuser près du foyer, une couche pair-à-pair laisse les appareils des spectateurs eux-mêmes se partager les segments. Chaque lecteur récupère les premiers octets auprès du CDN, puis échange des fragments directement avec d'autres lecteurs qui regardent la même chose, et ne revient au CDN que lorsqu'il le faut.
L'entreprise française Quanteec en est un exemple. Sa technologie, née de la recherche académique, ajoute une couche assistée par les pairs à un workflow HLS ou DASH existant et reste agnostique vis-à-vis du CDN et du DRM. Quanteec indique qu'un déploiement avec France Télévisions, desservant des centaines de milliers de spectateurs simultanés, a déchargé en moyenne environ 75 pour cent du trafic du CDN, avec plus de 50 pour cent d'économies d'énergie et moins de remise en mémoire tampon qu'en unicast simple.
Le contraste important avec le mABR, c'est le réseau. Le mABR a besoin d'un réseau d'accès managé et de la coopération de l'opérateur. Le pair-à-pair fonctionne sur l'internet public, entre les appareils, sans aucune implication de l'opérateur, ce qui correspond exactement à la zone que le mABR ne peut pas atteindre. La contrepartie, c'est que le pair-à-pair dépend de la présence d'assez de spectateurs simultanés ainsi que de la capacité d'envoi et du comportement des appareils grand public. Les deux approches ne s'excluent pas. Un diffuseur qui n'a aucune maîtrise du dernier kilomètre peut utiliser le pair-à-pair dès aujourd'hui, un opérateur qui contrôle son propre réseau peut utiliser le mABR, et une grande plateforme pourrait s'appuyer sur les deux.
Ce que cela implique pour les opérateurs
Le mABR n'est pas une solution miracle et il n'a rien de nouveau. C'est un outil ciblé pour un problème précis et coûteux : diffuser le même flux en direct à une très large audience sur un réseau managé sans payer pour chaque copie. Pour un opérateur qui diffuse une grande finale sportive, ce problème est réel et il s'aggrave à chaque saison. Pour un service purement OTT sans maîtrise du dernier kilomètre, le mABR est quelque chose qu'il peut demander aux FAI de prendre en charge, mais qu'il ne peut pas bâtir seul.
Le résumé honnête, c'est que la technologie fonctionne, que le standard existe, que les déploiements sont réels mais encore concentrés sur des piles propriétaires à fournisseur unique, que la latence et l'écosystème d'appareils restent de vraies contraintes, et que le travail de référence open source mené par GPAC et Motion Spell est la voie la plus crédible pour faire évoluer cette concentration.
iReplay.TV est un collectif d'ingénieurs broadcast et streaming, et les arbitrages entre le mABR, le pair-à-pair et la diffusion CDN unicast classique font partie de ce que ses membres soupèsent régulièrement. Le Multicast ABR est un levier parmi d'autres, et il n'aide qu'à l'intérieur d'un réseau managé. Si votre audience vous atteint par l'internet ouvert, les économies doivent venir d'ailleurs : diffusion assistée par les pairs, conception d'origine plus intelligente, meilleurs choix de codecs, et configuration CDN plus serrée. Il y a un outil gratuit d'optimisation des coûts CDN sur le site pour qui veut regarder ses propres chiffres.
Références et lectures complémentaires
- DVB, « Adaptive media streaming over IP multicast » (page de la spécification 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 » (mise à jour 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 » (dépôt du code source) : 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, solution Multicast Adaptive Bitrate (MABR) : commscope.com
- IETF : FLUTE (RFC 6726), ROUTE (RFC 9223), NORM (RFC 5740), disponibles sur rfc-editor.org