During Euro 2024, more than 11.5 million UK homes streamed at least one home-nations match over BT’s broadband network. BT later reported that traffic from the BBC and ITV climbed to more than 30 times the normal weekly volume, with both broadcasters briefly overtaking Netflix, Facebook and YouTube as the largest content sources on its network. The single biggest traffic peak of the tournament came at the moment Cole Palmer equalised in the final.
The next test on that scale is only a month away. The 2026 FIFA World Cup kicks off in June, hosted across the United States, Canada and Mexico, and its live audience will land on the same broadband and mobile networks that were never built to send the same match to every household as a separate stream.
That kind of spike is hard for a network to absorb, and the reason is structural. Every streaming format in wide use today, HLS and DASH included, is built on unicast. Each viewer opens their own session and pulls their own copy of every segment. Ten viewers on the same channel means ten identical streams crossing the network. A million viewers means a million identical streams. The content is the same for everyone, but the network carries it as if every copy were a different thing.
Multicast ABR, usually shortened to mABR, is the streaming industry’s main answer to that problem. It is not new, it is already standardised, and a handful of large telcos already run it in production. It also has real limits that are worth understanding before treating it as a fix for everything. This article covers what mABR is, how it works, what it actually saves, where it falls short, who has deployed it, and why the open-source work led by GPAC and Motion Spell matters for the technology’s future.
What is Multicast ABR?
Multicast ABR delivers ordinary adaptive bitrate content, the same HLS or DASH segments a normal player already expects, over IP multicast instead of unicast. On a managed operator network, a channel is sent across the network once as a multicast stream that any number of homes can join. The conversion back to standard unicast HTTP happens inside or close to the home, so the device and its player never know anything changed. From the player’s point of view it is still requesting segments over HTTP from what looks like a nearby CDN edge.
The core idea is simple. With unicast, one viewer means one stream. With multicast, one channel means one stream, regardless of how many homes are tuned in.
Two points are worth being precise about. First, mABR is a hybrid. Multicast carries the bulk delivery, and unicast stays in the loop as a repair and fallback path. Second, mABR is designed for live and linear content. The tech brief published by the Streaming Video Technology Alliance, an industry body whose multicast ABR paper was led by an Ericsson engineer with contributions from operators including Comcast, is explicit that video on demand still comes from a CDN. mABR earns its keep when many people watch the same thing at the same time, which is the live sports and live news case.
Multicast video is not new, especially in France
It is worth being clear that multicast delivery of television is decades old, and France is one of the best examples of it working at scale. In the early 2000s, when Free rolled out the Freebox, it built television delivery over IP multicast directly into its own unbundled DSL network, something the incumbent’s DSLAMs did not offer at the time. By 2008 Free was ranked first among the world’s largest IPTV carriers. Multicast was the reason the economics worked: one copy of each channel travelled the network no matter how many Freebox homes were watching it.
Free also exposed that multicast feed to subscribers directly, through a service called Multiposte. It let you watch the Freebox TV channels on a computer alongside the television, by opening a playlist of channels in VLC. The streams were plain IP multicast carried over the Freebox and joined with IGMP, with no set-top box involved. A generation of French broadband users effectively had a multicast TV receiver running on their PC.
The tooling has never been exotic either. VLC, the same player Multiposte relied on, can take a unicast stream as input and re-emit it to a multicast address over UDP or RTP through a single stream output configuration. Turning one unicast feed into a multicast one is, on its own, an ordinary and long-solved problem.
So if multicast is old and the tools are everywhere, what is actually new about Multicast ABR? Classic multicast IPTV, the Freebox model, carried a fixed continuous transport stream to the operator’s own set-top box. mABR instead carries modern adaptive bitrate content, the HLS and DASH segments that every phone, tablet, smart TV and streaming stick already speaks, and it aims that at the whole fragmented device ecosystem rather than at one proprietary box. The hard part of mABR is not the multicast. It is doing multicast for segmented, adaptive, multi-device streaming, with the gateway, rendezvous and repair machinery that this requires.
How mABR works
The DVB-MABR specification, developed by the DVB Project and published by ETSI as TS 103 769, defines a reference architecture built from a small set of named functions:
- Multicast server. It ingests standard ABR content from a CDN origin or edge, maps each segment to one or more multicast transport objects, and transmits them over IP multicast. An operator tells it what streams to capture and how to send them through a configuration API.
- Multicast gateway. It receives the multicast stream and converts it back into plain HTTP for local players. It behaves like a small local cache and HTTP proxy.
- Multicast rendezvous service. It routes a player’s initial request, by HTTP redirect, to the right gateway based on the operator’s service plan and business rules.
- Unicast repair. When multicast packets are lost, the gateway fetches the missing pieces over unicast, typically using HTTP byte-range requests, so playback does not break.
Where the gateway runs
The specification is deliberately flexible about where the multicast gateway sits. It can run in the operator’s network, in the home gateway or router, in the optical network terminal, or directly inside the set-top box. When the gateway and the player are on the same device, the DVB spec says the interface between them can simply be a local API. The SVTA brief described the same component, which it called the multicast client, as deployable on a set-top box, a residential gateway, an ONT, or inside the operator’s edge cache. That last option is useful on its own: an mABR client embedded in a CDN edge can populate the cache over multicast and cut requests back to the origin.
Transport protocols
Underneath, mABR uses file delivery protocols built for one-way multicast. DVB-MABR makes two of them mandatory. FLUTE (File Delivery over Unidirectional Transport, RFC 6726) comes from the 3GPP world. ROUTE (Real-Time Object Delivery over Unidirectional Transport, RFC 9223) comes from ATSC 3.0. A 2023 revision of the spec added two optional protocols, NORM (NACK-Oriented Reliable Multicast, RFC 5740) and MSYNC. All of them run over UDP and carry the segmented content along with forward error correction.
One useful property: mABR is format, codec and DRM agnostic. It moves HLS or DASH, MPEG-TS or CMAF, encrypted or not, and it does not re-encode anything. It changes how the bytes travel, not what they are.
The benefits of multicast ABR
Scale, which is the whole point
The core argument for mABR is that the network cost of a popular live channel stops growing with the audience. The SVTA tech brief illustrates this with two access network examples. On a DOCSIS cable network, the number of channels needed for unicast ABR grows in a straight line as viewers join, while with mABR it rises briefly and then flattens as viewers share the same multicast streams. On a GPON fibre network, the brief estimates that for an operator carrying 500 linear channels where 80 percent of viewers watch 10 percent of the lineup, core bandwidth savings reach roughly 50 percent at 32 customers per PON, and the per-viewer bandwidth requirement falls to under 3 percent of the unicast figure once the audience reaches into the tens of thousands. The brief’s blunt phrasing is that mABR can reduce edge bandwidth requirements for extremely popular live events from petabytes to megabytes.
There is one figure that comes straight from an operator rather than from a modelled estimate. In March 2025, BT Group reported its first successful trial of MAUD, its name for Multicast-Assisted Unicast Delivery, carrying live BBC Two content to EE set-top boxes on the live network. During peak times, the trial converted more than 60 percent of traffic from unicast to multicast.
Quality of experience
mABR is delivered as a managed service rather than a best-effort one. The SVTA brief notes that this mitigates playback jitter, because the operator controls the path rather than relying on the open internet between origin and viewer. For a live final, consistent delivery to everyone watching matters as much as the raw bandwidth saving.
It reuses what is already there
The SVTA brief makes the point that the infrastructure cost of mABR can be lower than other scaling options, because most of the routers and network elements involved are already deployed in the operator’s network. mABR is also complementary to CDN caching rather than a replacement for it, and can act as the content source that populates edge caches.
The drawbacks of multicast ABR
Added latency
The multicast gateway has to receive and reassemble segments before it can serve them, which adds delay on top of the source ABR stream. One technical analysis, published by Techne Digitale, estimates that mABR adds roughly two segments of delay on top of a typical OTT delivery, pushing an end-to-end figure from around 8 seconds to around 12. The SVTA brief argues that careful design, including shorter segment durations and CMAF chunked transfer, can keep mABR competitive with or even below plain unicast ABR. Either way, latency is a real consideration for live sports, where a viewer who hears a neighbour react before the action reaches their own screen will notice.
The client ecosystem problem
The SVTA brief calls the lack of a deployed client ecosystem the primary barrier to wider mABR adoption. Legacy home gateways and ONTs often do not have the CPU and memory to run a multicast client. Newer hardware can, but device makers have little reason to build, test and support multicast client software when there is no infrastructure to use it, and operators have little reason to deploy infrastructure when the devices cannot use it. At a CSI Magazine event in early 2023, BT’s TV architect Simon Jones noted that BT had operated multicast TV for over a decade but delivered it only to televisions, not connected devices, and that BT could not deliver something like the World Cup on its existing infrastructure. DAZN’s video playback and delivery architect Bob Hannent said in the same discussion that the market was still “really immature”. Both pointed to the lack of support from device makers such as Google and Apple as the main blocker.
It only works on managed networks
There is no multicast on the public internet. mABR works inside a single operator’s managed network, between a multicast server the operator runs and a gateway the operator controls. A pure OTT service such as Netflix cannot deploy mABR end to end on its own. It can ask ISPs to support it, but it depends on each ISP individually.
Fragmentation
Because it is local to each network, mABR is only as effective as the ISP it runs on. If half the ISPs serving an audience support it, the other half’s viewers still get the unicast experience and the same congestion. Unlike a unicast CDN, no single company can deliver an end-to-end mABR experience across the whole audience.
The problem may be shrinking on modern networks
The Techne Digitale analysis argues that on modern GPON fibre, where a 1:64 split still leaves each home with tens of megabits per second, the last-mile bandwidth crunch that mABR was designed for may not exist, and that mABR makes the most sense on older cable networks. The SVTA brief itself raises a similar question, asking whether years of CDN edge buildout, better codecs such as HEVC, AV1 and VVC, and new transports have already let the industry keep ahead of the growth curve. It is worth remembering that Comcast’s own early mABR project, run by its VIPER research group around 2015, never reached deployment.
Multiple renditions eat the savings
Every format, bitrate ladder and DRM variant an operator wants to serve has to be multicast separately. The more device types and content protections in play, the more parallel multicast streams are needed, and the smaller the net efficiency gain becomes.
Who is actually using mABR
mABR is past the lab stage. The clearest public examples come from telcos that run their own managed access networks.
- BT Group in the UK has been the most open about it. BT announced its MAUD initiative in 2024 and reported its first successful live trial in March 2025, carrying BBC Two to EE set-top boxes and converting more than 60 percent of peak traffic to multicast. BT has said the goal is to handle mass-audience live events, and trade coverage has reported that broadcasters are evaluating MAUD for the 2026 FIFA World Cup.
- Orange in Spain has told its own customers that it is the first operator in the country to deliver mABR streaming for its highest-audience live events, citing LaLiga, Formula 1 and MotoGP, and extending it beyond the set-top box to other devices in the home.
- TIM in Italy has written in its own technical journal that since 2021 it has run a multicast content distribution platform compliant with the ETSI M-ABR standard, used to add scalability for massive live events such as sport, integrated with the existing unicast model with automatic fallback.
- Bouygues Telecom in France was reported by trade press to be the first French operator to commercially stream in mABR, starting in 2023.
Not every operator is convinced. Deutsche Telekom has publicly framed mABR as a transition technology, useful where infrastructure cannot yet support pure unicast, rather than a long-term destination.
One pattern stands out across these deployments. They have almost all been built on the same proprietary, single-vendor implementation, Broadpeak’s nanoCDN, rather than on interoperable, standards-based stacks. That is a market fact rather than a technical endorsement. The DVB-MABR specification is public, but for years there was no neutral, openly available implementation of it to build and test against, so an operator that wanted mABR in production had little practical choice of supplier.
The device side
On the hardware side, the set-top box and CPE makers matter as much as the operators. CommScope offers a Multicast ABR solution it describes as based on parts of both the DVB and CableLabs standards, with a client that can run embedded in a set-top box or in the home gateway, and it states that no changes are needed to the streaming devices in the home. Vantiva, formerly Technicolor, has shipped set-top boxes with multicast ABR client software integrated. Set-top box chipsets from suppliers such as Broadcom provide IP multicast support at the network level, but mABR itself is implemented in software running on the device, not as a named chipset feature.
The gap is most visible on the largest device platform. Stock Android TV supports only unicast, so multicast ABR on those devices depends on operator-tier integrations that add a multicast client. Google’s own ExoPlayer and Media3 player libraries do not provide multicast ABR natively, and there is an open feature request asking for it.
The standard exists. Interoperability is the hard part.
It is a common assumption that mABR is held back by a missing standard. That is not the case.
CableLabs did early IP multicast ABR architecture work around 2014. The DVB Project published its multicast ABR reference architecture for industry comment in 2018, its Steering Board approved the full specification in early 2020, and it was published as the ETSI standard TS 103 769 in November 2020. It has been revised several times since, including a 2023 update that added the optional NORM and MSYNC transport protocols along with reporting, authenticity and tamper-protection features. The DVB working group behind it, MCAST, is chaired by Richard Bradbury of BBC R&D. There is a real, published, internationally recognised standard, and it has companion work such as the DVB-MABR implementation guidelines and the DVB-I service discovery specification. On the mobile side, 3GPP has its own parallel track, with the 5G Multicast-Broadcast Services architecture in Release 17, sharing the same FLUTE and ROUTE protocol heritage.
What has been missing is interoperability in practice. Almost every commercial mABR deployment to date runs on the same proprietary stack, Broadpeak’s nanoCDN. MSYNC, one of the optional transport protocols folded into DVB-MABR in 2023, began life as a Broadpeak protocol before it was brought into the spec. A standard that is implemented mostly by one vendor is a standard on paper. The thing that turns a paper spec into a working multi-vendor market is a neutral implementation that everyone can build and test against.
Where GPAC and Motion Spell come in
This is the part of the mABR story that points toward genuine standardisation.
GPAC is a long-running open-source multimedia framework, distributed under the LGPL licence and developed with Motion Spell, its commercial partner. It has roots in academic research at Telecom Paris and has been downloaded close to 100 million times. GPAC implemented the ROUTE protocol for ATSC 3.0 years ago, work that won an NAB innovation award in 2018, and it is the only open-source project that supports both ROUTE and FLUTE, the two mandatory DVB-MABR transport protocols. In 2024 it added FLUTE support specifically for DVB-MABR. GPAC’s media server can already act as a multicast-to-ABR gateway, exposing a multicast session as a normal HTTP streaming service, with unicast repair and a configurable time-shift window.
DVB then issued a request for proposals for an open-source tool to verify and validate DVB-MABR implementations. The result, the DVB-MABR Reference Tools, is built on GPAC and Motion Spell. It is open source, written in Python on top of the GPAC library, and it runs in two modes: a server mode that originates a multicast stream from an HTTP source, and a gateway mode that receives multicast and serves it back over HTTP, including HTTP repair. It is published in DVB’s own GitHub organisation and aimed at engineers, integrators and validation teams who need to confirm that a multicast server, a gateway and standard DASH players actually interoperate.
That is why this work matters more than another product launch. A royalty-free, openly available reference implementation gives every operator, device maker and software vendor a common baseline. It is the practical mechanism by which DVB-MABR can move from a market of single-vendor deployments toward real multi-vendor interoperability, which is the difference between a published standard and a standard that the whole ecosystem can actually use. GPAC’s involvement also ties mABR into wider research, including the SMART-CD consortium’s work on more sustainable video delivery, alongside partners such as Telecom Paris, Ateme and Viaccess-Orca.
A side note: peer-to-peer attacks the same problem from the other end
mABR is not the only way to stop a popular live stream from being sent once per viewer. Peer-to-peer delivery goes after the same waste from the opposite direction. Instead of sending one copy into a managed network and fanning it out close to the home, a peer-to-peer layer lets the viewers’ own devices share segments with each other. Each player fetches the first bytes from the CDN, then exchanges chunks directly with other players watching the same thing, and falls back to the CDN only when it has to.
The French company Quanteec is one example. Its technology, which started as academic research, adds a peer-assisted layer to an existing HLS or DASH workflow and is CDN and DRM agnostic. Quanteec reports that a deployment with France Télévisions serving hundreds of thousands of simultaneous viewers offloaded around 75 percent of traffic from the CDN on average, with more than 50 percent energy savings and lower rebuffering than plain unicast.
The important contrast with mABR is the network. mABR needs a managed access network and cooperation from the operator. Peer-to-peer works over the public internet, between devices, without any operator involvement, which is exactly the gap mABR cannot reach. The trade-off is that peer-to-peer depends on having enough concurrent viewers and on the upload capacity and behaviour of consumer devices. The two approaches are not mutually exclusive. A broadcaster with no control over the last mile can use peer-to-peer today, an operator that controls its own network can use mABR, and a large platform could lean on both.
Where this leaves operators
mABR is not a silver bullet and it is not new. It is a focused tool for one specific and expensive problem: delivering the same live stream to a very large audience on a managed network without paying for every copy. For an operator carrying a major sports final, that problem is real and it gets worse every season. For a pure OTT service with no control over the last mile, mABR is something it can ask ISPs to support but cannot build alone.
The honest summary is that the technology works, the standard exists, the deployments are real but still concentrated on proprietary single-vendor stacks, latency and the device ecosystem remain genuine constraints, and the open-source reference work led by GPAC and Motion Spell is the most credible path to changing that concentration.
iReplay.TV is a collective of broadcast and streaming engineers, so the trade-offs between mABR, peer-to-peer and plain unicast CDN delivery are the kind of thing its members weigh up regularly. Multicast ABR is one lever among several, and it only helps inside a managed network. If your audience reaches you over the open internet, the savings have to come from somewhere else: peer-assisted delivery, smarter origin design, better codec choices, and tighter CDN configuration. There is a free CDN cost optimiser tool on the site for anyone who wants to look at their own numbers.
References and further reading
- DVB, “Adaptive media streaming over IP multicast” (DVB-MABR specification page): dvb.org
- DVB, “DVB-I and DVB-MABR published as ETSI standards”: dvb.org/news
- DVB, “DVB publishes updated Multicast ABR specification and guidelines” (2023 update): dvb.org/news
- DVB, “DVB-MABR Reference Tools”: dvb.org
- GPAC, “MABR: Multicast Adaptive BitRate”: gpac.io
- Motion Spell, “DVB-MABR Open-Source Tool” (source repository): github.com/MotionSpell
- Streaming Video Technology Alliance, “The Viability of Multicast ABR in Future Streaming Architectures”: svta.org
- BT Group, “BT delivers first successful trial of new live streaming technology”: newsroom.bt.com
- CommScope, Multicast Adaptive Bitrate (MABR) Solution: commscope.com
- IETF: FLUTE (RFC 6726), ROUTE (RFC 9223), NORM (RFC 5740), available at rfc-editor.org