在2024年欧洲杯期间，超过1150万英国家庭通过BT的宽带网络观看了至少一场本土球队的比赛。BT后来报告说，来自BBC和ITV的流量飙升至正常每周流量的30多倍，两家广播公司一度超过Netflix、Facebook和YouTube，成为其网络上最大的内容来源。本届赛事单一最高的流量峰值，出现在科尔·帕尔默在决赛中扳平比分的那一刻。
下一场这种规模的考验只有一个月之遥。2026年国际足联世界杯将于6月开幕，由美国、加拿大和墨西哥共同举办，其直播观众将落在同样的固定网络和移动网络上，而这些网络从未被设计成把同一场比赛作为各自独立的流发送给每个家庭。
这样的峰值对网络来说很难吸收，原因是结构性的。今天广泛使用的所有流媒体格式，包括HLS和DASH，都建立在单播之上。每个观众打开自己的会话，拉取每个分段的自己那份副本。同一频道上有十名观众，就意味着十条相同的流穿过网络。一百万名观众，就意味着一百万条相同的流。内容对所有人都一样，但网络运送它的方式，却仿佛每一份副本都是不同的东西。
Multicast ABR，通常缩写为mABR，是流媒体行业对这个问题的主要回答。它并不新，已经标准化，并且已有少数几家大型电信运营商在生产环境中运行它。它也有真实的局限，在把它当作万灵药之前值得理解。本文讲述mABR是什么、它如何运作、它实际节省了什么、它在哪里力有不逮、谁已经部署了它，以及由GPAC和Motion Spell牵头的开源工作为何对这项技术的未来很重要。
什么是Multicast ABR？
Multicast ABR传送的是普通的自适应码率内容，也就是普通播放器本就期待的那些HLS或DASH分段，只不过走的是IP多播而非单播。在运营商的受管网络中，一个频道只经网络发送一次，作为一条任意数量家庭都可以加入的多播流。转换回标准单播HTTP的过程发生在家庭内部或其附近，因此设备及其播放器永远不会知道有任何变化。从播放器的视角看，它仍然是通过HTTP，向看起来像是附近CDN边缘节点的东西请求分段。
核心思想很简单。在单播中，一名观众意味着一条流。在多播中，无论有多少家庭在收看，一个频道都只意味着一条流。
有两点值得说清楚。第一，mABR是混合式的。多播承担传送的主体，而单播作为修复路径和回退路径留在回路中。第二，mABR是为直播和线性内容设计的。由Streaming Video Technology Alliance发布的技术简报——这份关于multicast ABR的文件由一名爱立信工程师牵头，并有包括Comcast在内的运营商参与撰写，这家机构是行业组织——明确指出：点播视频仍然来自CDN。当许多人在同一时间观看同一内容时，mABR才物有所值，也就是直播体育和直播新闻。
多播视频并不新鲜，在法国尤其如此
值得说清楚的是，电视的多播传送已有数十年历史，而法国是它大规模运转的最佳范例之一。在2000年代初，当Free推出Freebox时，这家运营商把通过IP多播传送电视直接构建进了自己解绑的DSL网络，而当时在位运营商的DSLAM并不提供这一点。到2008年，Free在全球最大的IPTV运营商中排名第一。多播正是经济账算得过来的原因：每个频道的一份副本在网络上流动，无论有多少Freebox家庭在收看它。
Free还通过一项名为Multiposte的服务，把那条多播流直接向订户开放。它让你可以在电视之外，在电脑上观看Freebox TV的频道，方法是在VLC中打开一个频道播放列表。这些流就是普通的IP多播，经由Freebox运送，用IGMP加入，完全不涉及机顶盒。一整代法国宽带用户实际上在自己的个人电脑上运行着一台多播电视接收机。
工具也从来都不稀奇。VLC，正是Multiposte所依赖的那个播放器，可以把一条单播流作为输入，并通过一项流输出配置，把它经UDP或RTP重新发往一个多播地址。把一条单播流变成一条多播流，本身就是一个普通的、早已解决的问题。
那么，如果多播已经古老、工具又随处可见，Multicast ABR究竟有什么真正新的东西？经典的多播IPTV，也就是Freebox模式，把一条固定的、连续的传输流运送到运营商自己的机顶盒。mABR运送的则是现代的自适应码率内容，也就是每一部手机、平板、智能电视和流媒体棒早已会说的那些HLS和DASH分段，并把它瞄准整个碎片化的设备生态系统，而不是一只专有的盒子。mABR难的部分不是多播本身。难的是为分段式的、自适应的、跨多设备的流媒体做多播，连同它所需要的网关、汇合与修复这一整套机制。
mABR如何运作
DVB-MABR规范由DVB Project制定，并由ETSI以TS 103 769发布，它定义了一套由一小组有名称的功能构成的参考架构：
- 多播服务器。 它从CDN源站或边缘节点摄取标准的ABR内容，把每个分段映射到一个或多个多播传输对象，并通过IP多播发送出去。运营商通过一个配置API告诉它该捕获哪些流、如何发送。
- 多播网关。 它接收多播流，并为本地播放器把它转换回普通的HTTP。它的行为像一个小型的本地缓存兼HTTP代理。
- 多播汇合服务。 它通过HTTP重定向，把播放器的初次请求，按照运营商的服务计划和业务规则，路由到正确的网关。
- 单播修复。 当多播数据包丢失时，网关通过单播——通常使用HTTP字节范围请求——把缺失的部分取回来，使播放不致中断。
网关在哪里运行
规范在多播网关位于何处这一点上刻意保持灵活。它可以运行在运营商的网络中，运行在家庭网关或路由器中，运行在光网络终端中，或直接运行在机顶盒内部。当网关和播放器在同一台设备上时，DVB规范说，两者之间的接口可以简单地是一个本地API。SVTA简报描述了同一个组件，称之为多播客户端，认为它可以部署在机顶盒、家庭网关、ONT，或运营商的边缘缓存内部。最后一种选择本身就有用：嵌入在CDN边缘的mABR客户端，可以通过多播填充缓存，并减少回到源站的请求。
传输协议
在底层，mABR使用为单向多播而构建的文件传送协议。DVB-MABR把其中两个定为必选。FLUTE（File Delivery over Unidirectional Transport，RFC 6726）来自3GPP的世界。ROUTE（Real-Time Object Delivery over Unidirectional Transport，RFC 9223）来自ATSC 3.0。规范2023年的一次修订增加了两个可选协议：NORM（NACK-Oriented Reliable Multicast，RFC 5740）和MSYNC。它们都运行在UDP之上，并连同前向纠错一起运送分段内容。
有一个有用的特性：mABR与格式、编解码器和DRM无关。它搬运HLS或DASH、MPEG-TS或CMAF，加密与否都行，并且什么都不重新编码。它改变的是字节如何旅行，而不是它们是什么。
Multicast ABR的优点
规模扩展，这正是关键所在
支持mABR的核心论点是：一个热门直播频道的网络成本，不再随观众增长而增长。SVTA技术简报用两个接入网的例子来说明这一点。在DOCSIS电缆网络上，单播ABR所需的频道数随着观众加入而线性增长，而采用mABR时则短暂上升、随后趋于平缓，因为观众共享同样的多播流。对于GPON光纤网络，简报估计：对于一家拥有500个线性频道、其中80%的观众观看10%节目单的运营商，核心网带宽的节省在每个PON承载32个用户时达到约50%，而一旦观众规模达到数万，每名观众的带宽需求便降到单播数字的3%以下。简报直言不讳地总结道：对于极受欢迎的直播活动，mABR可以把网络边缘的带宽需求从PB量级降到MB量级。
有一个数字直接来自运营商，而不是来自建模估算。2025年3月，BT Group报告了其对MAUD——这是该公司对Multicast-Assisted Unicast Delivery的称呼——的首次成功试验，该试验把BBC Two的直播内容传送到生产网络上的EE机顶盒。在高峰时段，这次试验把超过60%的流量从单播转换为多播。
体验质量
mABR是作为受管服务交付的，而不是尽力而为的服务。SVTA简报指出，这缓解了播放抖动，因为运营商控制着路径，而不是依赖源站与观众之间开放的互联网。对于一场直播决赛而言，向所有正在观看的人均匀交付，其重要性不亚于纯粹的带宽节省。
它复用已有的东西
SVTA简报强调，mABR的基础设施成本可能低于其他扩展选项，因为其中涉及的大多数路由器和网络元件已经部署在运营商的网络里。mABR还是对CDN缓存的补充而非替代，并且可以充当填充边缘缓存的内容来源。
Multicast ABR的缺点
额外的延迟
多播网关必须先接收并重新组装分段，然后才能提供它们，这在源ABR流之上增加了延迟。Techne Digitale发布的一项技术分析估计，mABR会在典型的OTT交付之上增加大约两个分段的延迟，把端到端的数字从大约8秒推高到大约12秒。SVTA简报则主张，精心的设计——包括更短的分段时长和CMAF分块传输——可以让mABR与普通的单播ABR相当，甚至更低。无论如何，延迟对直播体育来说都是一个真实的考量，因为当动作还没传到自己的屏幕，就先听到邻居反应的观众，是会察觉到的。
客户端生态系统的问题
SVTA简报把缺乏一个已部署的客户端生态系统，称为mABR更广泛采用的首要障碍。老旧的家庭网关和ONT往往没有运行多播客户端所需的CPU和内存。较新的硬件可以，但只要还没有可供使用的基础设施，设备制造商就几乎没有理由去构建、测试和维护多播客户端软件；而只要设备还用不了它，运营商也几乎没有理由去部署基础设施。在2023年初CSI Magazine的一场活动上，BT的电视架构师西蒙·琼斯指出，BT运营多播电视已超过十年，但只把它交付到电视机，而不交付到联网设备，并且BT用其现有的基础设施无法交付像世界杯这样的活动。DAZN的视频播放与交付架构师鲍勃·汉嫩特在同一场讨论中说，市场仍然"真的不成熟"。两人都把来自Google和Apple这类设备制造商的支持不足，指为最大的阻碍。
它只在受管网络上有效
公共互联网上没有多播。mABR在单个运营商的受管网络内部运作，处在运营商所运营的多播服务器与运营商所控制的网关之间。像Netflix这样的纯OTT服务，无法靠自己端到端地部署mABR。它可以请求ISP去支持，但它要逐个依赖每一家ISP。
碎片化
由于mABR对每个网络都是本地化的，它的有效程度只取决于它所运行其上的那家ISP。如果服务于某一受众的ISP有一半支持它，另一半的观众依然得到单播的体验和同样的拥塞。与单播CDN不同，没有任何一家公司能向全体受众端到端地交付mABR体验。
在现代网络上这个问题或许正在缩小
Techne Digitale的分析主张，在现代GPON光纤上，1:64的分光仍能给每个家庭留下每秒数十兆比特，因此mABR当初为之设计的最后一公里带宽瓶颈也许根本不存在，mABR最有意义的地方是较老的电缆网络。SVTA简报本身也提出了类似的问题，发问多年来CDN边缘的扩建、HEVC、AV1和VVC等更好的编解码器，以及新的传输协议，是否已经让行业领先于增长曲线。值得记住的是，Comcast自己早期的mABR项目，由其VIPER研究小组在2015年前后推进，最终从未进入部署。
多种版本会吃掉节省
运营商想要提供的每一种格式、每一条码率阶梯、每一个DRM变体，都必须分别进行多播。在场的设备类型和内容保护越多，所需的并行多播流就越多，效率上的净收益也就越小。
究竟谁在使用mABR
mABR已经走过了实验室阶段。最清晰的公开案例来自那些运营着自己受管接入网的电信运营商。
- 英国的BT Group在这方面最为坦诚。BT在2024年宣布了它的MAUD计划，并在2025年3月报告了首次成功的直播试验，该试验把BBC Two传送到EE机顶盒，并把超过60%的高峰流量转换为多播。BT表示，目标是应对面向大规模受众的直播活动，行业报道称，已有广播公司正在为2026年国际足联世界杯评估MAUD。
- 西班牙的Orange已告知其自有客户，它是该国第一家为其收视率最高的直播活动提供mABR流媒体的运营商，并提到了LaLiga、一级方程式和MotoGP，还把它从机顶盒扩展到家中的其他设备。
- 意大利的TIM在其自己的技术期刊上写道，自2021年起它运营着一个符合ETSI的M-ABR标准的多播内容分发平台，用于为体育之类的大规模直播活动增加可扩展性，并与既有的单播模式以及自动回退相集成。
- 法国的Bouygues Telecom被行业媒体介绍为第一家自2023年起以mABR进行商业流媒体传送的法国运营商。
并非每家运营商都信服。德国电信公开把mABR定位为一种过渡技术，在基础设施还撑不住纯单播的地方有用，而不是一个长期的归宿。
在这些部署中有一个模式格外突出。它们几乎全都建立在同一个单一供应商的专有实现之上，也就是Broadpeak的nanoCDN，而不是建立在可互操作的、基于标准的技术栈之上。这是一个市场事实，而非技术上的背书。DVB-MABR规范是公开的，但多年来并不存在一个中立的、公开可得的实现，可供在其之上构建并对其进行测试，因此一家想要在生产中使用mABR的运营商，几乎没有切实可行的供应商选择。
设备这一侧
在硬件这一侧，机顶盒和用户驻地设备的制造商与运营商同等重要。CommScope提供一种Multicast ABR解决方案，它将其描述为基于DVB和CableLabs两套标准的一部分，其客户端可以内嵌运行在机顶盒或家庭网关中，并且该公司表示，家中的流媒体设备无需任何改动。Vantiva，即从前的Technicolor，已出货集成了多播ABR客户端软件的机顶盒。来自Broadcom等供应商的机顶盒芯片组在网络层面提供IP多播支持，但mABR本身是作为运行在设备上的软件来实现的，而不是一项有名称的芯片组功能。
这一差距在最大的设备平台上最为明显。原生的Android TV只支持单播，因此那些设备上的multicast ABR要依赖运营商级别的集成来加入一个多播客户端。Google自己的播放器库ExoPlayer和Media3并不原生提供multicast ABR，并且有一个尚未解决的功能请求在要求它。
标准是存在的。难的部分是互操作性。
有一种常见的假设，认为mABR是被一个缺失的标准拖了后腿。事实并非如此。
CableLabs在2014年前后做过IP多播ABR的早期架构工作。DVB Project在2018年把它的multicast ABR参考架构公开征求行业意见，其Steering Board在2020年初批准了完整规范，该规范于2020年11月作为ETSI标准TS 103 769发布。此后它经过多次修订，其中包括2023年的一次更新，增加了可选的传输协议NORM和MSYNC，以及报告、真实性和防篡改方面的功能。其背后的DVB工作组MCAST，由BBC R&D的理查德·布拉德伯里担任主席。确实存在一个真实的、已发布的、获得国际承认的标准，并伴有诸如DVB-MABR实施指南和DVB-I服务发现规范这样的配套工作。在移动这一侧，3GPP走着自己的平行路线，Release 17中的5G Multicast-Broadcast Services架构，共享着同样来自FLUTE和ROUTE的协议血统。
一直缺失的是实践中的互操作性。迄今几乎每一个商业mABR部署，都运行在同一个专有技术栈上，也就是Broadpeak的nanoCDN。MSYNC是2023年被纳入DVB-MABR的可选传输协议之一，但在被带入规范之前，它一开始是Broadpeak的协议。一个大多由一家供应商实现的标准，是纸面上的标准。把一份纸面规范变成一个能运转的、多供应商的市场的，是一个人人都能在其上构建、并对其进行测试的中立实现。
GPAC与Motion Spell登场之处
这正是mABR故事中指向真正标准化的那一部分。
GPAC是一个由来已久的开源多媒体框架，以LGPL许可证分发，并与其商业伙伴Motion Spell共同开发。它的根扎在Telecom Paris的学术研究中，下载量已接近1亿次。GPAC多年前为ATSC 3.0实现了ROUTE协议，这项工作在2018年赢得了一项NAB创新奖，而且GPAC是唯一同时支持ROUTE和FLUTE这两个DVB-MABR必选传输协议的开源项目。2024年，它专门为DVB-MABR增加了FLUTE支持。GPAC的媒体服务器已经能够充当从多播到ABR的网关，把一个多播会话作为普通的HTTP流媒体服务对外提供，并带有单播修复和一个可配置的时移窗口。
随后DVB发出了一份招标书，征集一个用于验证和确认DVB-MABR实现的开源工具。其成果，即DVB-MABR Reference Tools，构建在GPAC和Motion Spell之上。它是开源的，用Python写在GPAC库之上，并以两种模式运行：一种服务器模式，从一个HTTP源生成多播流；一种网关模式，接收多播并通过HTTP重新提供它，包括HTTP修复。它发布在DVB自己的GitHub组织里，面向那些需要确认多播服务器、网关和标准DASH播放器确实可以互操作的工程师、集成商和验证团队。
这正是为什么这项工作比又一次产品发布更有分量。一个免版税、公开可得的参考实现，给每一家运营商、设备制造商和软件供应商一个共同的基准。它是一个切实的机制，使DVB-MABR能够从一个由单一供应商部署构成的市场，走向真正的、跨多个供应商的互操作性，而这正是一个已发布的标准与一个整个生态系统真正能用的标准之间的区别。GPAC的参与也把mABR与更广泛的研究联系起来，包括SMART-CD联盟在更可持续的视频交付方面的工作，与之并肩的还有Telecom Paris、Ateme和Viaccess-Orca这样的伙伴。
题外话：点对点从另一端攻入同一个问题
mABR并不是阻止一条热门直播流按每名观众发送一次的唯一办法。点对点交付从相反的方向去对付同样的浪费。它不是把一份副本送进受管网络、再在家庭附近呈扇形展开，而是让点对点这一层，使观众自己的设备彼此分享分段。每个播放器从CDN取得最初的字节，然后直接与正在观看同一内容的其他播放器交换分块，只有在不得不时才回退到CDN。
法国公司Quanteec就是一个例子。它的技术起初是学术研究，它在既有的HLS或DASH工作流之上增加一个由对等节点辅助的层，并且与CDN和DRM无关。Quanteec报告称，一个服务于数十万并发观众的、与France Télévisions合作的部署，平均把约75%的流量从CDN卸下，并实现了超过50%的能耗节省，以及比纯单播更少的重新缓冲。
与mABR的重要对比在于网络。mABR需要一个受管的接入网，以及运营商的配合。点对点在公共互联网上、在设备之间运作，不需要运营商的任何参与，而那恰恰是mABR够不到的缺口。其代价是，点对点取决于是否有足够多的并发观众，也取决于消费设备的上行能力和行为。这两种方法并不互相排斥。一家无法控制最后一公里的广播公司今天就可以使用点对点，一家控制着自己网络的运营商可以使用mABR，而一个大型平台则可以同时倚靠两者。
这对运营商意味着什么
mABR不是灵丹妙药，也不新鲜。它是针对一个具体而昂贵的问题的、目标明确的工具：在受管网络上把同一条直播流交付给非常庞大的受众，而不必为每一份副本付费。对于一家承载大型体育决赛的运营商来说，这个问题是真实的，而且每个赛季都在加重。对于一个无法控制最后一公里的纯OTT服务来说，mABR是它可以请求ISP去支持、却无法独自构建的东西。
诚实的总结是：这项技术是有效的，标准是存在的，部署是真实的、但仍集中在单一供应商的专有技术栈上，延迟和设备生态系统仍是真实的约束，而由GPAC和Motion Spell牵头的开源参考工作，是改变这种集中状况最可信的路径。
iReplay.TV是一个由广播与流媒体工程师组成的集体，因此在mABR、点对点和普通的单播CDN交付之间的取舍，正是其成员经常掂量的那类事情。Multicast ABR是众多杠杆中的一个，而且只在受管网络内部才有帮助。如果你的受众是通过开放的互联网到达你的，节省就必须来自别处：由对等节点辅助的交付、更聪明的源站设计、更好的编解码器选择，以及更紧凑的CDN配置。站点上有一个免费的CDN成本优化工具，供任何想看看自己数字的人使用。
参考资料与延伸阅读
- DVB，"Adaptive media streaming over IP multicast"（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"（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"（源代码仓库）：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)，可在rfc-editor.org获取