Streaming Cost Optimizer

Сократите расходы на CDN и избегайте платы за превышение. Потоковая доставка с оплатой по факту.

Попробовать бесплатно

Multicast ABR (mABR) простыми словами: как это работает, что экономит и путь к общему стандарту

Эта статья переведена с английского с помощью ИИ. Читать оригинал

Во время Евро-2024 более 11,5 миллиона британских домохозяйств посмотрели в стриминге хотя бы один матч сборных Великобритании через широкополосную сеть BT. Позже BT сообщила, что трафик от BBC и ITV вырос более чем в 30 раз по сравнению с обычным недельным объёмом, и обе вещательные компании на короткое время обошли Netflix, Facebook и YouTube как крупнейшие источники контента в её сети. Самый высокий отдельный пик трафика турнира пришёлся на момент, когда Коул Палмер сравнял счёт в финале.

Следующее испытание такого масштаба всего в месяце от нас. Чемпионат мира по футболу FIFA 2026 стартует в июне, его принимают США, Канада и Мексика, и его прямая аудитория ляжет на те же фиксированные и мобильные сети, которые никогда не строились для того, чтобы отправлять один и тот же матч в каждое домохозяйство отдельным потоком.

Такой пик сети поглотить трудно, и причина структурная. Все широко используемые сегодня форматы стриминга, включая HLS и DASH, построены на юникасте. Каждый зритель открывает собственную сессию и забирает собственную копию каждого сегмента. Десять зрителей на одном канале означают десять одинаковых потоков, пересекающих сеть. Миллион зрителей означает миллион одинаковых потоков. Содержимое одно и то же для всех, но сеть переносит его так, будто каждая копия — отдельная вещь.

Multicast ABR, который обычно сокращают до mABR, — это главный ответ отрасли стриминга на эту проблему. Он не нов, он уже стандартизирован, и горстка крупных телеком-операторов уже эксплуатирует его в продакшене. У него есть и реальные ограничения, которые стоит понимать, прежде чем считать его решением всего. В этой статье разбирается, что такое mABR, как он работает, что он на самом деле экономит, где он не дотягивает, кто его внедрил и почему работа с открытым исходным кодом под руководством GPAC и Motion Spell важна для будущего этой технологии.

Что такое Multicast ABR?

Multicast ABR доставляет обычный контент с адаптивным битрейтом — те же сегменты HLS или DASH, которые обычный плеер и так ожидает, — по IP-мультикасту вместо юникаста. В управляемой сети оператора канал отправляется по сети один раз как мультикаст-поток, к которому может присоединиться любое число домохозяйств. Обратное преобразование в стандартный юникаст-HTTP происходит внутри дома или рядом с ним, так что устройство и его плеер никогда не узнают, что что-то изменилось. С точки зрения плеера он по-прежнему запрашивает сегменты по HTTP у того, что выглядит как близкий edge CDN.

Основная идея проста. При юникасте один зритель означает один поток. При мультикасте один канал означает один поток, независимо от того, сколько домохозяйств смотрит.

Стоит уточнить два момента. Во-первых, mABR гибридный. Мультикаст берёт на себя основную часть доставки, а юникаст остаётся в контуре как путь восстановления и резервный путь. Во-вторых, mABR рассчитан на прямой и линейный контент. Технический обзор, опубликованный Streaming Video Technology Alliance — отраслевым органом, чей документ по multicast ABR вёл инженер Ericsson при участии операторов, в том числе 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, определяет эталонную архитектуру, построенную из небольшого набора именованных функций:

  • Мультикаст-сервер. Он принимает стандартный ABR-контент от источника или edge CDN, сопоставляет каждый сегмент одному или нескольким мультикаст-транспортным объектам и передаёт их по IP-мультикасту. Оператор через API настройки сообщает ему, какие потоки захватывать и как их отправлять.
  • Мультикаст-шлюз. Он принимает мультикаст-поток и преобразует его обратно в обычный HTTP для локальных плееров. Он ведёт себя как небольшой локальный кэш и HTTP-прокси.
  • Служба рандеву мультикаста. Она направляет первый запрос плеера через HTTP-перенаправление к нужному шлюзу на основе плана обслуживания и бизнес-правил оператора.
  • Юникаст-восстановление. Когда мультикаст-пакеты теряются, шлюз дозабирает недостающие части по юникасту, обычно с помощью HTTP-запросов по диапазону байтов, чтобы воспроизведение не прерывалось.

Где работает шлюз

Спецификация намеренно гибка в вопросе того, где находится мультикаст-шлюз. Он может работать в сети оператора, в домашнем шлюзе или маршрутизаторе, в оптическом сетевом терминале или прямо внутри телеприставки. Когда шлюз и плеер находятся на одном устройстве, спецификация DVB говорит, что интерфейс между ними может быть просто локальным API. Обзор SVTA описывал тот же компонент, который он называл мультикаст-клиентом, как разворачиваемый на телеприставке, домашнем шлюзе, ONT или внутри edge-кэша оператора. Последний вариант полезен сам по себе: mABR-клиент, встроенный в edge CDN, может наполнять кэш по мультикасту и сокращать число запросов обратно к источнику.

Транспортные протоколы

Внизу 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 процентов сетки, экономия полосы пропускания в ядре сети достигает примерно 50 процентов при 32 абонентах на PON, а потребность в полосе на одного зрителя падает ниже 3 процентов от показателя юникаста, как только аудитория доходит до десятков тысяч. Обзор формулирует это без обиняков: mABR может снизить потребности в полосе пропускания на краю сети для чрезвычайно популярных прямых событий с порядка петабайтов до порядка мегабайтов.

Есть одна цифра, которая исходит напрямую от оператора, а не из смоделированной оценки. В марте 2025 года BT Group сообщила о своём первом успешном испытании MAUD — так компания называет Multicast-Assisted Unicast Delivery, — которое доставляло прямой контент BBC Two на телеприставки EE в боевой сети. В часы пик испытание перевело более 60 процентов трафика из юникаста в мультикаст.

Качество восприятия

mABR поставляется как управляемая услуга, а не как услуга по принципу наилучших усилий. Обзор SVTA отмечает, что это смягчает джиттер воспроизведения, потому что оператор управляет маршрутом, а не полагается на открытый интернет между источником и зрителем. Для прямого финала ровная доставка всем, кто смотрит, значит столько же, сколько и сама экономия полосы пропускания.

Он переиспользует то, что уже есть

Обзор SVTA подчёркивает, что инфраструктурные издержки mABR могут быть ниже, чем у других вариантов масштабирования, потому что большинство задействованных маршрутизаторов и сетевых элементов уже развёрнуто в сети оператора. mABR также дополняет кэширование CDN, а не заменяет его, и может выступать источником контента, наполняющим edge-кэши.

Недостатки Multicast ABR

Дополнительная задержка

Мультикаст-шлюз должен принять и заново собрать сегменты, прежде чем сможет их отдать, что добавляет задержку поверх исходного ABR-потока. Технический анализ, опубликованный Techne Digitale, оценивает, что mABR добавляет около двух сегментов задержки к типичной OTT-доставке, поднимая показатель от конца до конца примерно с 8 секунд до примерно 12. Обзор SVTA утверждает, что аккуратная разработка, в том числе более короткие длительности сегментов и чанковая передача CMAF, может удерживать mABR на уровне обычного юникаст-ABR или даже ниже. Так или иначе задержка — реальное соображение для прямого спорта, где зритель, услышавший реакцию соседа раньше, чем действие дойдёт до его собственного экрана, это заметит.

Проблема экосистемы клиентов

Обзор SVTA называет отсутствие развёрнутой экосистемы клиентов главным препятствием для более широкого внедрения mABR. У старых домашних шлюзов и ONT часто нет процессорных мощностей и памяти, чтобы запустить мультикаст-клиент. У более нового оборудования они есть, но у производителей устройств мало причин создавать, тестировать и поддерживать программное обеспечение мультикаст-клиента, пока нет инфраструктуры, чтобы его использовать, а у операторов мало причин разворачивать инфраструктуру, пока устройства не умеют ею пользоваться. На мероприятии CSI Magazine в начале 2023 года ТВ-архитектор BT Саймон Джонс отметил, что BT эксплуатировала мультикаст-телевидение более десяти лет, но доставляла его только на телевизоры, а не на подключённые устройства, и что BT не смогла бы доставить что-то вроде чемпионата мира на своей существующей инфраструктуре. Боб Ханнент, архитектор воспроизведения и доставки видео в DAZN, в той же дискуссии сказал, что рынок по-прежнему «по-настоящему незрелый». Оба указали на нехватку поддержки со стороны производителей устройств, таких как Google и Apple, как на главное препятствие.

Он работает только в управляемых сетях

В публичном интернете мультикаста нет. mABR работает внутри управляемой сети одного оператора, между мультикаст-сервером, который эксплуатирует оператор, и шлюзом, который оператор контролирует. Чисто OTT-сервис вроде Netflix не может развернуть mABR от конца до конца самостоятельно. Он может просить интернет-провайдеров поддержать его, но зависит от каждого провайдера по отдельности.

Фрагментация

Поскольку mABR локален для каждой сети, он эффективен ровно настолько, насколько эффективен провайдер, на котором он работает. Если половина провайдеров, обслуживающих аудиторию, его поддерживает, зрители другой половины по-прежнему получают юникаст-опыт и ту же перегрузку. В отличие от юникаст-CDN, ни одна отдельная компания не может доставить mABR-опыт от конца до конца всей аудитории.

На современных сетях проблема, возможно, уменьшается

Анализ Techne Digitale утверждает, что на современном оптоволокне GPON, где разветвление 1:64 всё равно оставляет каждому домохозяйству десятки мегабит в секунду, узкого места по полосе пропускания на последней миле, для которого создавался mABR, может и не быть, и что mABR имеет наибольший смысл в более старых кабельных сетях. Сам обзор SVTA поднимает похожий вопрос, спрашивая, не позволили ли годы наращивания edge-инфраструктуры CDN, лучшие кодеки вроде HEVC, AV1 и VVC и новые транспортные протоколы отрасли уже держаться впереди кривой роста. Стоит напомнить, что собственный ранний проект mABR компании Comcast, который вела её исследовательская группа VIPER около 2015 года, так и не дошёл до развёртывания.

Множество вариантов съедает экономию

Каждый формат, каждую лестницу битрейтов и каждый вариант DRM, который оператор хочет обслуживать, нужно передавать по мультикасту отдельно. Чем больше типов устройств и средств защиты контента в игре, тем больше нужно параллельных мультикаст-потоков и тем меньше становится чистый выигрыш в эффективности.

Кто на самом деле использует mABR

mABR прошёл стадию лаборатории. Самые ясные публичные примеры исходят от телеком-операторов, которые эксплуатируют собственные управляемые сети доступа.

  • BT Group в Великобритании была наиболее открытой об этом. BT объявила о своей инициативе MAUD в 2024 году и сообщила о своём первом успешном живом испытании в марте 2025 года, которое доставляло BBC Two на телеприставки EE и переводило более 60 процентов пикового трафика в мультикаст. BT заявила, что цель — справляться с прямыми событиями для массовой аудитории, а отраслевая пресса сообщала, что вещатели оценивают MAUD для чемпионата мира по футболу FIFA 2026.
  • Orange в Испании сообщила собственным клиентам, что является первым оператором страны, предлагающим mABR-стриминг для своих прямых событий с наибольшей аудиторией, ссылаясь на LaLiga, «Формулу-1» и MotoGP, и расширяет его за пределы телеприставки на другие устройства в доме.
  • TIM в Италии написала в собственном техническом журнале, что с 2021 года эксплуатирует платформу распространения контента по мультикасту, соответствующую стандарту M-ABR ETSI, используемую для добавления масштабируемости массовым прямым событиям вроде спорта, интегрированную с существующей юникаст-моделью с автоматическим откатом.
  • Bouygues Telecom во Франции была представлена отраслевой прессой как первый французский оператор, ведущий коммерческий стриминг в mABR, начиная с 2023 года.

Не все операторы убеждены. Deutsche Telekom публично представила mABR как переходную технологию, полезную там, где инфраструктура пока не тянет чистый юникаст, а не как долгосрочную цель.

Один паттерн выделяется по всем этим внедрениям. Почти все они построены на одной и той же проприетарной реализации единственного вендора — nanoCDN от Broadpeak, — а не на совместимых, основанных на стандартах стеках. Это факт рынка, а не техническая рекомендация. Спецификация 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 вела раннюю архитектурную работу по IP-мультикаст-ABR около 2014 года. DVB Project опубликовал свою эталонную архитектуру для multicast ABR на отзыв отрасли в 2018 году, его Steering Board одобрил полную спецификацию в начале 2020 года, и она была опубликована как стандарт ETSI TS 103 769 в ноябре 2020 года. С тех пор она пересматривалась несколько раз, в том числе обновление 2023 года, добавившее опциональные транспортные протоколы NORM и MSYNC, а также функции отчётности, подтверждения подлинности и защиты от подделки. Рабочую группу DVB, стоящую за ней, MCAST, возглавляет Ричард Брэдбери из BBC R&D. Существует настоящий, опубликованный, международно признанный стандарт, сопровождаемый смежной работой вроде руководящих указаний по реализации DVB-MABR и спецификации обнаружения сервисов DVB-I. На мобильной стороне у 3GPP собственная параллельная дорожка — архитектура 5G Multicast-Broadcast Services в Release 17, разделяющая то же протокольное наследие FLUTE и ROUTE.

Чего не хватало, так это совместимости на практике. Почти каждое коммерческое внедрение mABR на сегодня работает на одном и том же проприетарном стеке — nanoCDN от Broadpeak. MSYNC, один из опциональных транспортных протоколов, включённых в DVB-MABR в 2023 году, начинался как протокол Broadpeak, прежде чем был внесён в спецификацию. Стандарт, реализованный по большей части одним вендором, — это стандарт на бумаге. То, что превращает бумажную спецификацию в работающий рынок с несколькими вендорами, — это нейтральная реализация, на которой каждый может строить и против которой тестировать.

Где в дело вступают GPAC и Motion Spell

Это та часть истории mABR, которая указывает путь к подлинной стандартизации.

GPAC — это давно существующий мультимедийный фреймворк с открытым исходным кодом, распространяемый под лицензией LGPL и разрабатываемый вместе с Motion Spell, его коммерческим партнёром. У него корни в академических исследованиях в Telecom Paris, и его скачали почти 100 миллионов раз. GPAC реализовал протокол ROUTE для ATSC 3.0 много лет назад — эта работа получила премию за инновации NAB в 2018 году, — и это единственный проект с открытым исходным кодом, поддерживающий и ROUTE, и FLUTE, два обязательных транспортных протокола DVB-MABR. В 2024 году он добавил поддержку FLUTE специально для DVB-MABR. Медиасервер 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.

Заметка на полях: peer-to-peer атакует ту же проблему с другого конца

mABR — не единственный способ не дать популярному прямому потоку отправляться по разу на зрителя. Доставка peer-to-peer берётся за то же расточительство с противоположной стороны. Вместо того чтобы отправить одну копию в управляемую сеть и затем веером раздать её рядом с домом, слой peer-to-peer позволяет самим устройствам зрителей делиться сегментами друг с другом. Каждый плеер забирает первые байты из CDN, затем обменивается фрагментами напрямую с другими плеерами, которые смотрят то же самое, и обращается обратно к CDN только тогда, когда вынужден.

Французская компания Quanteec — один пример. Её технология, начавшаяся как академическое исследование, добавляет слой с поддержкой пиров к существующему HLS- или DASH-конвейеру и не зависит от CDN и DRM. Quanteec сообщает, что внедрение с France Télévisions, обслуживавшее сотни тысяч одновременных зрителей, в среднем разгрузило около 75 процентов трафика с CDN, при экономии энергии более 50 процентов и меньшем числе перебуферизаций, чем у обычного юникаста.

Важное различие с mABR — это сеть. mABR нужна управляемая сеть доступа и сотрудничество оператора. Peer-to-peer работает поверх публичного интернета, между устройствами, без какого-либо участия оператора, а это как раз тот пробел, до которого mABR не может дотянуться. Компромисс в том, что peer-to-peer зависит от наличия достаточного числа одновременных зрителей, а также от полосы отдачи и поведения потребительских устройств. Два подхода не исключают друг друга. Вещатель без контроля над последней милей может использовать peer-to-peer уже сегодня, оператор, контролирующий собственную сеть, может использовать mABR, а крупная платформа могла бы опираться на оба.

Что это означает для операторов

mABR не панацея и не новость. Это узконаправленный инструмент для одной конкретной и дорогой задачи: доставить один и тот же прямой поток очень большой аудитории в управляемой сети, не платя за каждую копию. Для оператора, транслирующего крупный спортивный финал, эта задача реальна, и с каждым сезоном она становится острее. Для чисто OTT-сервиса без контроля над последней милей mABR — это то, о поддержке чего он может попросить интернет-провайдеров, но не может построить в одиночку.

Честное резюме таково: технология работает, стандарт существует, внедрения реальны, но всё ещё сосредоточены на проприетарных стеках одного вендора, задержка и экосистема устройств остаются настоящими ограничениями, а эталонная работа с открытым исходным кодом под руководством GPAC и Motion Spell — самый правдоподобный путь изменить эту концентрацию.

iReplay.TV — это коллектив инженеров вещания и стриминга, так что компромиссы между mABR, peer-to-peer и обычной юникаст-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): commscope.com
  • IETF: FLUTE (RFC 6726), ROUTE (RFC 9223), NORM (RFC 5740), доступны на rfc-editor.org

Need Help With Your Streaming Project?

This article was written by experienced professionals available through iReplay.tv. Whether you need expertise in ABR streaming, nanoCDN, peer-to-peer streaming—our network of specialists can bring your project to life.

Hire a Professional →

Сократите расходы на стриминг

Streaming Cost Optimizer

Перестаньте переплачивать за пропускную способность CDN. Наша доставка с оплатой по факту устраняет неожиданные расходы и снижает затраты на стриминг.

Рассчитать экономию