CMAF: Формат Упаковки, Объединивший HLS и DASH

Опубликовано: 2026-05-21 · Время чтения: 27 мин · Автор: Николай Сапунов, CEO Фора Софт

Последняя сверка: 2026-05-21 со стандартом ISO/IEC 23000-19:2024 (Common Media Application Format, третья редакция, февраль 2024) и Поправкой 1:2024 (LCEVC и связанные профили, июль 2024), ISO/IEC 23001-7:2023 (Common Encryption, четвёртая редакция), Apple HLS Authoring Specification revision 2025-09, IETF draft-пантос-hls-8216bis-15, DASH-IF Implementation Guidelines: Content Protection and Multi-DRM v1.5 (2025), исходным кодом Shaka Packager v3, исходным кодом Bento4 v1.6, отчётом Bitmovin Video Developer Report 2025/26.

TL;DR

CMAF – Common Media Application Format, ISO/IEC 23000-19 – это формат файлов, который положил конец восьмилетнему «налогу упаковки» каждого live- и VOD-видео, требовавшему двойной обработки: один раз как MPEG-TS для HLS и один раз как fragmented MP4 для DASH. Теперь один набор файлов fMP4 может обслуживать и HLS-плейлист, и DASH-манифест, используя одни и те же байты на ориджине. Это сокращает объём хранилища и исходящий трафик с ориджина примерно вдвое, удваивает эффективность кэширования в CDN и – благодаря общей схеме шифрования Common Encryption (CENC) с поддержкой cbcs – позволяет использовать один зашифрованный файл для работы с FairPlay (Apple), Widevine (Google) и PlayReady (Microsoft).

На уровне формата CMAF представляет собой строгое подмножество fragmented MP4 с тремя ключевыми нововведениями: CMAF track (трек ISO BMFF с дополнительными ограничениями), CMAF fragment (один или несколько чанков, выровненных по границам сегмента), CMAF chunk (одна пара moof + mdat – минимальная декодируемая единица), а также небольшим набором brands и media profiles, которые информируют декодер о используемом кодеке, битовой глубине и HDR-передаточной функции.

К 2026 году CMAF уже перестал быть переходным решением и стал стандартом по умолчанию: каждый крупный пакеджер по умолчанию выдаёт CMAF, каждый современный плеер его поддерживает, «налог двойной упаковки» исчез, и единственным legacy-форматом, который ещё имеет смысл поддерживать, остаётся MPEG-TS – для старых Smart TV, которые до сих пор не умеют работать с fragmented MP4 в нативном HLS-плеере.

Почему это важно

Если вы доставляете видео на несколько платформ – iOS и Android, Safari и Chrome, Apple TV и Roku, браузер и Smart TV – раньше вы платили «налог». Вы кодировали один раз, упаковывали дважды, шифровали дважды, хранили дважды и наблюдали, как падает эффективность кэша CDN, потому что один и тот же контент существовал в двух бинарно идентичных, но не побайтово идентичных форматах. CMAF – это формат, который положил конец этому налогу, и экономия ощутима: −50% объёма хранилища, ~2× эффективность кэширования на CDN, один multi-DRM-пайплайн вместо трёх, один пайплайн упаковки вместо двух. Механика имеет значение, потому что в продакшене до сих пор ломаются три вещи – выбор схемы шифрования (cenc vs cbcs), декларация brand-кода (какие устройства отвергают cmf2?) и различение segment / fragment / chunk (спецификация HLS от Apple называет «segment» то, что в CMAF называется «fragment») – и ошибка в любой из них тихо возвращает налог двойной упаковки. Эта статья делает каждый слой CMAF понятным: иерархия box’ов, словарь brand-кодов, режимы шифрования, связь с манифестами HLS и DASH, production-стек в его реальном виде на 2026 год.

Что такое CMAF, в одном абзаце

CMAF – это формат упаковки, а не кодек, не протокол и не механизм доставки. Он определяет, как организовать байты видео и аудио на диске так, чтобы один и тот же файл можно было использовать как в HLS-плейлисте, так и в DASH-манифесте, расшифровывать с помощью FairPlay, Widevine и PlayReady по одному ключу, а также декодировать любым плеером, поддерживающим fragmented MP4. Конкретно CMAF представляет собой ограниченный профиль ISO Base Media File Format (ISO BMFF – тот же стандарт, что определяет .mp4), с фиксированным порядком box’ов: сначала идёт initialization-сегмент с боксом moov, затем media-сегменты, каждый из которых содержит одну или несколько пар moof + mdat, – и словарём brands и media profiles, в котором объявлены используемый кодек, режим шифрования и HDR-характеристики. История стандартизации кратка: Apple и Microsoft совместно предложили CMAF в MPEG в начале 2016 года, первая редакция была опубликована как ISO/IEC 23000-19 в 2018 году, вторая – в 2020, третья – в феврале 2024 года. Именно эту третью редакцию следует использовать в production-развёртываниях в 2026 году.

История в четырёх вехах

CMAF появился из-за проблемы, которую стриминговая индустрия сама создала в 2009 году и с которой жила почти десятилетие.

Первая веха – публикация HLS в 2009 году компанией Apple. HLS был построен на основе MPEG-2 Transport Stream – того же формата сегментов .ts, что используется в спутниковом и кабельном вещании, – потому что в 2009 году каждое устройство Apple декодировало MPEG-TS нативно на аппаратном уровне. Цена этого компромисса заключалась в том, что больше никто не стал использовать MPEG-TS в интернет-стриминге. Браузеры, Android, Smart TV и весь остальной парк устройств перешли на fragmented MP4 (fMP4), и именно его выбрал DASH, когда MPEG опубликовал стандарт ISO/IEC 23009-1 в 2012 году. С 2012 года любой сервис, стремившийся охватить и устройства Apple, и все остальные платформы, вынужден был упаковывать один и тот же контент дважды: один раз в формате MPEG-TS для HLS-плейлиста и один раз в формате fMP4 для DASH-манифеста. Объём хранилища удваивался, эффективность кэширования в CDN падала вдвое, а шифрование также удваивалось – Apple FairPlay шифровал MPEG-TS, а Widevine и PlayReady – fMP4. В результате multi-DRM превратился из одной операции в три параллельных пайплайна.

Вторая веха – июнь 2016 года, когда Apple на WWDC объявила, что HLS впервые будет поддерживать fragmented-MP4-сегменты наряду с MPEG-TS. Это заявление стало структурной предпосылкой для CMAF: оно означало, что один fMP4-файл в принципе может использоваться как в HLS-плейлисте, так и в DASH-манифесте. Четырьмя месяцами ранее – в феврале 2016 года – Apple и Microsoft совместно подали в MPEG предложение по формализации общего формата. Akamai и несколько других вендоров присоединились к инициативе в 2016 году. Рабочая группа MPEG приняла его на путь стандартизации в том же году.

Третья веха – январь 2018 года, когда MPEG опубликовал первую редакцию стандарта ISO/IEC 23000-19 – Common Media Application Format for segmented media. Эта редакция 2018 года определила понятия CMAF-трека, сегмента, фрагмента и чанка; структурные brand-коды cmfc и cmf2; первый набор профилей медиа для H.264/AVC, HEVC и AAC; а также требование передавать CMAF-медиа в формате, совместимом с 'isom' / 'iso6', на основе fragmented MP4. Вторая редакция, вышедшая в 2020 году, добавила профили для HEVC HDR (HDR10, HDR10+, HLG) и Dolby Atmos. Третья редакция 2024 года, опубликованная в феврале 2024, является текущим базовым стандартом; она включает профили для AV1, VVC (Versatile Video Coding, H.266) и ужесточает структурные ограничения на бокс moof. Поправка 1 к редакции 2024 года, вышедшая в июле 2024, добавляет поддержку Low Complexity Enhancement Video Coding (LCEVC) и соответствующие профили.

Четвёртая веха – созревание production-стека с 2019 по 2026. Все крупные пакеджеры (Shaka Packager, Bento4, AWS Elemental MediaPackage, Unified Packager от Unified Streaming, Wowza Streaming Engine, Bitmovin Live, Mux, Norsk) внедрили режимы выдачи CMAF в период с 2019 по 2022 год и сделали CMAF форматом по умолчанию с 2023 по 2025 год. Все основные плееры (нативный HLS-плеер Apple на iOS / tvOS 10+, hls.js, Shaka Player, dash.js, Bitmovin Player, ExoPlayer, Video.js, THEOplayer) поддерживают CMAF нативно. Все ведущие DRM-системы (FairPlay, Widevine, PlayReady) поддерживают cbcs-шифрование, то есть один зашифрованный CMAF-стрим совместим со всеми тремя. По данным Bitmovin Video Developer Report 2025/26, CMAF стал доминирующим форматом упаковки среди более чем 700 опрошенных инженеров стриминговых платформ; необходимость поддерживать двойной стек для новых развёртываний исчезла.

Цена отказа от CMAF – и экономия от его внедрения

Самый наглядный способ понять CMAF – посчитать байты. Возьмём типичную библиотеку VOD: 1000 часов контента, пять рендиций (1080p, 720p, 540p, 360p, 240p), 4-секундные сегменты, средний видео-битрейт 2 Мбит/с по лестнице.

Без CMAF – упаковывая каждую рендицию и как MPEG-TS для HLS, и как fMP4 для DASH – арифметика хранилища:

1 000 часов × 3 600 с/час × 2 Mbit/s / 8 = 900 GB на рендицию
5 рендиций × 900 GB = 4 500 GB на packaging-стек
2 packaging-стека (HLS + DASH) = 9 000 GB всего на ориджине

С CMAF – один набор fMP4-файлов, используемый как HLS-плейлистом, так и DASH-манифестом – арифметика сводится к одному стеку:

1 000 часов × 3 600 с × 2 Mbit/s / 8 = 900 GB на рендицию
5 рендиций × 900 GB = 4 500 GB
1 packaging-стек (CMAF) = 4 500 GB всего на ориджине

Экономия составляет ровно 50% объёма origin-хранилища при неизменном охвате контента. Экономика CDN ещё выгоднее: она тарифицирует cache miss (выход на origin) и кэширует популярные файлы на edge-узлах. Без CMAF сегмент 02.ts (HLS) и сегмент 02.m4s (DASH) – это два разных объекта кэша, хотя содержат одни и те же кадры. Кэш тратит место на дубликаты, а hit ratio падает. С CMAF оба манифеста ссылаются на один и тот же .m4s-объект, кэш хранит его один раз, и hit ratio при том же объёме edge-утилизации примерно удваивается. Совокупный эффект – вдвое меньше хранилища, вдвое выше эффективность кэша, вдвое ниже стоимость пайплайна кодирования и упаковки. Именно это делает CMAF стандартом по умолчанию в 2026 году, а не экзотикой.

Экономия на шифровании – независима. Без CMAF вы шифровали MPEG-TS для FairPlay (тогда использовался AES-128-CBC), fMP4 для Widevine (AES-128-CTR, схема cenc) и fMP4 снова для PlayReady (тоже cenc). Три разных зашифрованных варианта. С CMAF и схемой cbcs Common Encryption – поддерживаемой FairPlay с 2017 года, PlayReady 4.0+ с 2018 года, Widevine L1 с прошивок 2018 года – вы шифруете CMAF-файл один раз с помощью одного content-ключа, и все три DRM его расшифровывают. Один зашифрованный экземпляр, три DRM, полный охват устройств.

Нажмите, чтобы увеличить

Объектная модель CMAF – track, fragment, chunk, segment

Спецификация CMAF определяет небольшую иерархию объектов, и правильное именование этих объектов – едва ли не самое важное, что должен делать production-инженер. Одно и то же слово «segment» означает разное в HLS, DASH и CMAF, и эта путаница – источник половины production-багов в этой области.

CMAF track

CMAF track – один непрерывный медиа-поток: одна видео-камера, один аудио-микс каналов, один subtitle-поток – внутри CMAF-файла. Соответствует один к одному trak-боксу в ISO BMFF. Любая CMAF-презентация – это набор треков: обычно один видео-трек на рендицию (1080p, 720p, …), один аудио-трек на язык и схему каналов (English stereo, Spanish 5.1), ноль или несколько subtitle-треков (English WebVTT, Spanish WebVTT). CMAF-трек кодируется одним кодеком с одной фиксированной конфигурацией; качество переключается переключением треков, а не сменой параметров внутри трека. У каждого CMAF-трека есть track header – moov-бокс с mvhd, trak, mdia и кодек-специфическими боксами конфигурации, – который плеер читает один раз при старте и переиспользует всё воспроизведение.

CMAF chunk

CMAF chunk – наименьшая декодируемая единица. Она состоит ровно из одного moof-бокса (movie fragment, с таймингом и оффсетами сэмплов) и одного mdat-бокса (media data, со сжатыми кадрами). Пара moof + mdat – атомарная единица, которую принимает source buffer плеера. Типичный chunk содержит 200–500 мс медиа: при 30 fps это 6–15 видеокадров на chunk, при 60 fps – 12–30 кадров. Спецификация CMAF 2024 ужесточает требования ISO BMFF, заменяя правило «один или более chunk-ов на fragment» на ровно один chunk на fragment в строгом brand-коде cmf2. Это упрощает парсинг для плеера и становится production-дефолтом в 2026 году.

Фрагмент CMAF

CMAF fragment – один или несколько CMAF-чанков, пересекающих границу fragment в fragmented-MP4 – то есть находящихся между двумя styp-маркерами (segment type) в файле. В обычном VOD fragment совпадает с segment (файлом, который скачивает плеер). В low-latency live segment формируется из нескольких fragment-ов, каждый из которых состоит из одного или нескольких chunk-ов; именно этот механизм позволяет LL-HLS-стримингам (LL-HLS) публиковать частичные сегменты до завершения полного сегмента. Иерархия снизу вверх: трек содержит сегменты; сегмент содержит фрагменты; фрагмент содержит чанки; чанк содержит кадры.

Сегмент CMAF

CMAF segment – файл, который плеер реально скачивает. Он начинается с styp-бокса (тип сегмента, указывающего применимые CMAF-бренд-коды), далее следуют одна или несколько пар moof + mdat (фрагменты и чанки), и завершается в конце файла сегмента. Обычно длительность сегментов составляет 2–6 секунд: 2 секунды – современный стандарт для live-трансляций, 4 или 6 – типичны для VOD. В HLS-манифесте CMAF-сегмент представлен одной записью #EXTINF; в DASH-манифесте – через $Number$ или $Time$ внутри SegmentTemplate. Один файл, две ссылки.

Терминология сначала только запутывает, прежде чем прояснится. Спецификация Apple HLS использует слово «segment» в значении того, что в CMAF называют «fragment». В формате MPEG-TS HLS расширение .ts применяется к файлу, который технически соответствует одному CMAF-сегменту. Элемент <SegmentBase> в манифесте DASH при определённых конфигурациях ссылается на фрагмент внутри сегмента. Самая полезная модель для понимания: кадры объединяются в чанки, чанки – в фрагменты, фрагменты – в сегменты, а сегменты – это то, что загружает плеер. Всё остальное – вопрос терминологии.

Нажмите, чтобы увеличить

Brand-коды и media-профили CMAF – метки совместимости

Боксы styp (segment type) и ftyp (file type) CMAF-файла содержат один или несколько четырёхсимвольных brand-кодов, которые сообщают парсеру, какое подмножество ISO BMFF и какой кодек используется в файле. Brand-коды – это своего рода контракт: плеер, поддерживающий brand X, примет любой файл, в котором объявлен X; плеер, не поддерживающий X, отвергнет такой файл. Существуют два уровня brand-кодов – структурные, указывающие, какая версия спецификации CMAF применяется, и media-профильные, описывающие используемый кодек и HDR-характеристики.

Структурные бренд-коды: `cmfc` и `cmf2`

Два структурных brand-кода – cmfc (базовый CMAF-бренд) и cmf2 (более жёсткое ограничение). Файл, объявляющий cmfc, удовлетворяет всем базовым CMAF-ограничениям – порядку упаковки, наличию боксов, правилам группировки сэмплов – но допускает несколько чанков на фрагмент, несколько треков в файле и часть устаревших возможностей ISO BMFF. Файл, объявляющий cmf2, дополнительно требует ровно один чанк на фрагмент, ровно один трек на файл и более строгий moof-бокс; именно этот бренд используют большинство современных плееров, поскольку его строгость обеспечивает детерминированный парсинг. Производственный дефолт 2026 года – cmf2 для нового контента; старый контент с брендом cmfc остаётся широко поддерживаемым.

Видео-профили медиа

Brand media-профиль объявляет кодек, профиль, уровень, битовую глубину и HDR-передаточную функцию. Третья редакция CMAF (2024) регистрирует следующие:

Аудио-профили медиа

Профили субтитров и метаданных

CMAF также определяет профили для субтитров IMSC1 (im1t, im1i), WebVTT (wvtt) и треков event-message (emsg) для маркеров вставки рекламы и метаданных. Современная CMAF-презентация обычно включает один видеотрек, один или два аудиотрека и один субтитровый трек, объявленные в боксах styp и ftyp.

Разобранный пример

4K HDR10-фильм, упакованный в формате CMAF для развёртывания в 2026 году, в боксе ftyp может объявить:

ftyp:
  major_brand = 'cmf2'
  minor_version = 0
  compatible_brands = ['cmf2', 'cmfc', 'isom', 'iso6', 'cud1', 'caca']

Это значит: «Я – строгий CMAF (cmf2)-файл, совместимый с базовым CMAF (cmfc), поддерживающий старые ISO BMFF-бренды (isom, iso6), содержащий HEVC Main10 HDR10-видео (cud1) и Dolby Atmos-аудио (caca)». Плеер, поддерживающий cmf2, cud1 и caca, сможет воспроизвести файл; если у него отсутствует хотя бы один из этих компонентов – он откажется его обрабатывать. Декларация brand-кодов – это своего рода контракт, превращающий CMAF из формата «попробуем и помолимся» в формат с гарантированной совместимостью.

Common Encryption – один ключ, три DRM

Уровень шифрования CMAF – Common Encryption (CENC), определённый в ISO/IEC 23001-7. Common Encryption разделяет операцию шифрования и систему управления правами (DRM), хранящую ключи. Контент шифруется один раз на этапе упаковки с использованием AES-128 в одном из двух режимов; каждый DRM (FairPlay, Widevine, PlayReady) обеспечивает логику лицензионного сервера, выдающего плееру один и тот же content-ключ, и плеер расшифровывает данные тем же алгоритмом, независимо от того, какой DRM выдал лицензию. Один зашифрованный файл – три DRM, совместимость со всеми современными устройствами.

В production используются две схемы:

cenc (AES-128-CTR). Режим счётчика. Шифруется каждый байт сэмпла; IV вычисляется на основе счётчика для каждого сэмпла. Значение по умолчанию – 2018. Поддерживается Widevine и PlayReady; FairPlay не поддерживает. Если вы используете шифрование cenc, Apple-устройства не смогут воспроизвести контент. cenc всё ещё встречается в устаревших развертываниях, не связанных с Apple, но больше не рекомендуется в качестве значения по умолчанию для нового контента.

cbcs (AES-128-CBC + субсэмпловый паттерн). Шифрование по схеме Cipher Block Chaining с паттерном, при котором шифруются только отдельные байты – обычно один из каждых десяти блоков в видео (паттерн 1:9), – а остальное остаётся открытым. Это позволяет железным декодерам обрабатывать поток без расшифровки ненужных кадров. Такой подход значительно снижает нагрузку на дешифровку в мобильных чипах. Поддерживается FairPlay (с 2017), PlayReady 4.0+ (с 2018), Widevine L1 (с 2018). Стандарт по умолчанию с 2026 года; если вы шифруете cbcs, один CMAF-файл подходит для iOS, Android, Smart TV и открытого веба.

Старый контент иногда использовал третью схему – cbc1 (AES-128-CBC без субсэмплового паттерна), – но cbc1 так и не получил широкого распространения и фактически был выведен из эксплуатации к 2026 году.

Метаданные шифрования хранятся в moov-боксе (декларации key-system’ов) и внутри каждого moof (уникальный вектор инициализации для фрагмента). Ключ шифрования контента (Content Encryption Key, CEK) идентифицируется по идентификатору ключа (Key ID, KID – 16-байтовый UUID). При запросе лицензии плеер отправляет KID на каждый сервер лицензирования DRM, после чего сервер возвращает лицензию, содержащую CEK, защищённый корневым доверенным окружением (root of trust) своей системы DRM: FairPlay привязывает ключ к Secure Enclave устройства Apple, Widevine – к Trusty TEE или Strongbox, PlayReady – к ключу, привязанному к аппаратному DRM от Microsoft. Медиа-стек плеера расшифровывает каждый фрагмент по мере поступления в буфер источника. Все DRM-системы работают с одним и тем же CMAF-файлом; различия заключаются только в протоколе взаимодействия с сервером лицензирования.

Эффект на проводе – драматичный. До внедрения CMAF + CENC + cbcs требовалось три кодированных потока (или, чаще, три зашифрованных варианта одного потока), три интеграции с серверами лицензирования, три CDN-пути, три пайплайна упаковки и три тестовых плана. После перехода на CMAF + cbcs та же библиотека использует один поток, три сервера лицензирования (обойти их всё ещё нельзя – ключи общие, но протоколы лицензирования различаются), один CDN-путь, один пайплайн упаковки и один тестовый план. Операция шифрования перешла с per-DRM на per-content; лицензирование осталось per-DRM.

Частая ошибка в продакшене – считать, что «поддержка cbcs» автоматически означает поддержку устройством. Устройства с версией ниже iOS 11 (выпущена в сентябре 2017 года) не воспроизводят cbcs-зашифрованный CMAF; устройства с PlayReady до 2018 года – тоже; часть Smart TV вышла с прошивкой Widevine L3, которая декодирует только cenc. Правило 2026: если ваша аудитория использует устройства, выпущенные в 2019 году или позже, cbcs покрывает всех; если нужно охватить устаревшие устройства до 2018 года, может потребоваться и cenc-вариант, и cbcs-вариант одного и того же контента. Алгоритм решения прост: проведите аудит целевого списка устройств, определите самое старое поддерживаемое, проверьте, поддерживает ли оно cbcs, и выберите cbcs, если оно поддерживается.

Паттерн "один набор файлов, два манифеста"

Архитектурное преимущество CMAF заключается в том, что один и тот же набор .m4s-сегментов на диске используется как для HLS-плейлиста (.m3u8), так и для DASH-манифеста (.mpd). Пакер создаёт файлы один раз. Манифесты – это небольшие текстовые файлы, генерируемые параллельно; их единственная задача – указывать на сегменты и сообщать плееру, какие сегменты идут вместе.

Скелет HLS-плейлиста, ссылающегося на CMAF-сегменты:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-MAP:URI="init.mp4"
#EXTINF:4.0,
segment-1.m4s
#EXTINF:4.0,
segment-2.m4s
#EXTINF:4.0,
segment-3.m4s
#EXT-X-ENDLIST

Соответствующий DASH-манифест ссылается на тот же init.mp4 и те же segment-N.m4s-файлы:

<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
     profiles="urn:mpeg:dash:profile:isoff-on-demand:2011,urn:mpeg:dash:profile:cmaf:2019"
     type="static" mediaPresentationDuration="PT12S">
  <Period>
    <AdaptationSet mimeType="video/mp4" segmentAlignment="true" startWithSAP="1">
      <Representation id="720p" bandwidth="2500000" codecs="avc1.4d401f">
        <SegmentTemplate
            initialization="init.mp4"
            media="segment-$Number$.m4s"
            startNumber="1"
            duration="4"
            timescale="1"/>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

HLS-плеер видит три сегмента в плейлисте, тянет init.mp4 плюс каждый .m4s по порядку, расшифровывает под FairPlay по схеме cbcs, объявленной в moov-боксе файла, и рендерит. DASH-плеер видит те же три сегмента через SegmentTemplate, тянет тот же init.mp4 и те же .m4s-файлы по порядку, расшифровывает под Widevine или PlayReady по той же схеме cbcs и тому же content-ключу, и рендерит. Байты на диске идентичны. Кэш CDN хранит каждый .m4s ровно один раз. Origin egress примерно вдвое меньше, чем при двухстековой модели.

Тонкая деталь DASH-манифеста – атрибут profiles, несущий urn:mpeg:dash:profile:cmaf:2019: это DASH-URN профиля, указывающий, что контент представлен в формате CMAF, и сообщающий плееру использовать парсинг, совместимый с CMAF (в частности, схему cbcs, а не cenc). Соответствующая конвенция для HLS – строка EXT-X-VERSION:6 (минимальная версия HLS, поддерживающая fMP4) и ссылка #EXT-X-MAP на init-сегмент. Оба манифеста небольшие – всего килобайты, легко перегенерируются и размещаются рядом с сегментами; основная стоимость – в самих сегментах, которые теперь упакованы единожды.

Место CMAF в общем streaming-стеке

CMAF – один из трёх слоёв современного стримингового пайплайна: слой кодеков (H.264, HEVC, AV1, VVC) сжимает видеофреймы; слой упаковки (CMAF) помещает сжатые данные в адресуемые файлы; слой доставки (HLS, DASH, LL-HLS, LL-DASH) передаёт эти файлы плеерам по HTTP. CMAF находится посередине. Ему безразличен кодек, сгенерировавший байты (внутри CMAF-чанка можно использовать любой зарегистрированный кодек), и ему безразличен протокол доставки (одни и те же CMAF-файлы можно использовать с HLS, DASH, LL-HLS или LL-DASH). CMAF заботится только о порядке боксов внутри файла, brand-декларациях и схеме шифрования, оборачивающей сэмплы.

Связь с LL-HLS и LL-DASH – прямая. Оба low-latency-протокола зависят от того, что CMAF-chunk можно декодировать независимо от остальной части родительского сегмента. То есть, как только энкодер создаёт 333-миллисекундный слайс видео, пакеджер сразу сохраняет на диск полную пару moof + mdat; ориджин немедленно её читает; chunked-transfer или HTTP/2-стриминг передают байты плееру; source buffer плеера принимает chunk, и декодер выдаёт кадры примерно с задержкой в 333 мс относительно камеры. Без CMAF-чанков low-latency HTTP-стриминг невозможен – пришлось бы ждать окончания сегмента длиной 2–6 секунд. CMAF – это упаковочный субстрат, на котором реализуются механизмы #EXT-X-PART (LL-HLS) и @availabilityTimeOffset (LL-DASH). См. LL-HLS подробно и LL-DASH подробно – как протоколы сверху интерпретируют сигналы манифеста; эта статья – о субстрате внизу.

Связь с Media over QUIC (MoQ) – перспектива на будущее. MoQ – это новый транспортный протокол поверх QUIC, предназначенный для следующего поколения потоковой передачи с низкой задержкой. Рабочая группа явно ориентируется на передачу CMAF-чанков в качестве полезной нагрузки. IETF-черновики draft-wilaw-moq-cmafpackaging-01 и предложение LOCMAF ("Low Overhead CMAF for MoQ") описывают, как CMAF-чанк отображается на объект MoQ. Суть в том, что формат упаковки не меняется – изменяется только транспортный уровень сверху. CMAF выступает в роли lingua franca, обеспечивая преемственность инвестиций в MoQ с инвестициями в LL-HLS: остаются энкодеры, пакеджер и хранилище; меняется только протокол доставки, когда требуется меньшая задержка.

Связь с MPEG-TS – legacy-форматом HLS-сегментов – это аккуратный вывод из эксплуатации. MPEG-TS HLS всё ещё требуется для небольшой группы устройств: старые модели Roku, часть Smart TV до 2018 года выпуска (ранние Vizio, некоторые LG webOS 3.0, некоторые Samsung Tizen 3.0), несколько встроенных set-top box’ов. Развёртывание в 2026 году, ориентированное на эти устройства, будет включать небольшую MPEG-TS HLS-резервную версию рядом с основным CMAF-стеком. Для всех устройств, выпущенных с 2019 года, CMAF – единственный формат упаковки, который вы предоставляете.

Пакеджеры – что реально даёт CMAF в 2026

Пять реализаций упаковки доминируют в production:

Shaka Packager (Google, open source) – самый широко используемый CMAF-пакеджер. По умолчанию генерирует cmf2-строгий CMAF, поддерживает шифрование cenc и cbcs, интегрируется со всеми крупными системами управления ключами DRM (Widevine, FairPlay, PlayReady через EZDRM, Axinom, BuyDRM, PallyCon и др.), работает как CLI-утилита в CI и в режиме долгоживущего live-стриминга. Является эталонной реализацией, задействованной в сотнях production-развёртываний у Google, YouTube и крупных телеком-операторов.

Bento4 (Axiomatic Systems, open source) – второй по распространённости инструмент. Bento4 поставляет инструменты mp4dash и mp4hls, преобразующие один входной поток в DASH+CMAF и HLS+CMAF, а также предлагает богатую библиотеку для анализа фрагментированных MP4-файлов. Bento4 – выбор инженеров, которым нужен CLI-инструментарий и точный контроль над декларациями brand.

AWS Elemental MediaPackage v2 – ведущий управляемый CMAF-пакеджер в облачных решениях. Принимает один потоковый вход (обычно RTMP, SRT или RIST) и формирует CMAF-сегменты, которые одновременно доступны как LL-HLS и LL-DASH через единый chunked-оригин, раздаваемый через CloudFront. Релиз v2 (2023) сделал CMAF форматом по умолчанию и убрал устаревший режим dual-stack.

Unified Packager / Unified Origin от Unified Streaming работает как долгоживущий демон, который в реальном времени ремультиплексирует входящий fMP4 (или MPEG-TS) в CMAF и динамически генерирует HLS- и DASH-манифесты по запросу. Модель «just-in-time packaging» означает: храните один CMAF-совместимый исходник на диске – и ориджин будет выдавать любой вариант манифеста – HLS, DASH, с поддержкой низкой задержки или без, с любым DRM, с любой комбинацией языковых дорожек – прямо в момент запроса. Эту технологию используют многие крупные европейские операторы.

Bitmovin Live, Mux Live, Norsk (id3as) – крупные сервисы «кодер и пакетировщик в облаке» (managed live encoder and packager as a service). Каждый из них принимает ингест (RTMP, SRT, WHIP), кодирует видео по настраиваемой битрейт-лестнице, упаковывает в CMAF с низколатентными чанками и выдаёт LL-HLS и LL-DASH через управляемый ориджинал. Отличия заключаются в стратегии битрейт-лестницы, удобстве API и объёме встроенной аналитики; при этом выдача в формате CMAF функционально эквивалентна.

Shaka Packager и Bento4 покрывают open-source-решения; три managed-сервиса – SaaS-решения. Выбор между ними – это вопрос «собрать самому или купить» на фоне того, что к 2026 году CMAF-выдача станет стандартом.

Где здесь Фора Софт

Мы разрабатываем программное обеспечение для видеостриминга, WebRTC, OTT, телемедицины, e-learning, видеонаблюдения и AR/VR с 2005 года. Переход на CMAF – это путь, который мы прошли вместе с клиентами от начала до конца: от архитектуры до 2019 года «упаковывай дважды, шифруй дважды» к базовой модели 2026 года – «упаковывай один раз, шифруй один раз, раздавай везде». Там, где мы создаём ценность, – это миграция: аудит существующей dual-stack-оригинальной инфраструктуры, определение, какой контент может работать только в MPEG-TS или только в cenc, планирование перехода на multi-DRM-совместимую архитектуру с поддержкой только cbcs, правильная настройка cache-key на CDN, чтобы новые CMAF-объекты действительно получали cache hit ratio, за который вы заплатили. Мы не продаём энкодеры или пакеджеры – мы поставляем приложение вокруг них: плееры, оркестрацию back-end-ориджинала, интеграции с DRM, дашборды качества пользовательского опыта – и разрабатываем CMAF-совместимые стриминговые сервисы с момента выхода формата в GA.

Типичные ошибки – режимы отказа, которые всё ещё встречаются в 2026

Формат зрелый, но его реализация – не всегда. В production-аудитах регулярно выявляются пять режимов отказа.

Грабли 1 – шифрование cenc, когда в аудитории есть Apple. Самая распространённая ошибка. Инженер читает спецификацию Common Encryption, видит старую схему cenc первой в списке и выбирает её по умолчанию. Устройства Apple отказываются воспроизводить контент. Решение – использовать cbcs для всего нового контента; шаг проверки – убедиться, что в файле moov установлены флаги в боксе pssh (Protection System Specific Header) и боксе tenc (track encryption), и что выбрано значение cbcs.

Грабли 2 – объявлен не тот codec-brand. Пакеджер выдаёт 4K HEVC HDR10, но в поле ftyp указывает cmfc вместо cmf2 и забывает указать brand cud1. Некоторые плееры принимают файл (считывая кодек из moov), другие – отклоняют (полагаясь только на декларацию brand). Решение – указывать в compatible_brands все применимые brand-коды: базовый CMAF (cmfc или cmf2), профиль кодека (cfhd / chd1 / cud1 / cav1 / …) и профиль аудио (caac / cec3 / caca).

Грабли 3 – разные длительности chunk-ов по рендициям. 1080p-рендиция использует chunk-ы по 333 мс, 720p – по 500 мс, 540p – по 200 мс. ABR-алгоритм плеера ломается, потому что chunk-ы больше не выровнены по wall-clock. Лечение – зафиксировать одну длительность chunk-а на всю лестницу; production-дефолт 2026 – 333 мс, потому что хорошо ложится на 30 fps (10 кадров на chunk) и 60 fps (20 кадров на chunk).

Грабли 4 – забытое выравнивание сегментов между рендициями. 1080p-сегмент 42 начинается в 02:48.000 по часовому времени, а 720p-сегмент 42 – в 02:48.040, поскольку частота кадров энкодера дрейфовала. Переключение ABR в плеере вызывает заметный глитч длительностью 40 мс. Решение – указать segmentAlignment="true" в манифесте DASH и убедиться, что исходный энкодер выдаёт выровненные GOP по всем рендициям: каждая рендиция должна начинать новый IDR-кадр в один и тот же момент по часовому времени.

Грабли 5 – кэширование .m4s-сегментов без нормализации cache-ключа. URL HLS-плейлиста содержит session-токен (?session=abc123), и CDN воспринимает segment-42.m4s?session=abc123 и segment-42.m4s?session=xyz789 как два разных кэшируемых объекта. Один и тот же сегмент хранится отдельно для каждого зрителя, и коэффициент попаданий падает до нуля. Решение – либо (1) исключить session-токен из cache-ключа на edge CDN, оставив только путь, либо (2) применять аутентификацию только к URL плейлиста, оставляя URL сегментов без подписи. Экономия CMAF становится реальной только тогда, когда CDN действительно кэширует каждый уникальный объект ровно один раз.

Реальность production – внедрение, пропускная способность и следующие два года

Bitmovin Video Developer Report 2025/26 – самый свежий отраслевой опрос на момент написания – сообщает, что CMAF стал самым распространённым форматом упаковки среди опрошенных инженеров стриминговых систем. Доля внедрения выросла с ~32% в 2020 году (когда cbcs получил production-стабильную поддержку во всех трёх DRM) до ~78% по данным отчёта 2024/25; в отчёте 2025/26 эта цифра приближается к 90% среди новых развёртываний. Оставшиеся 10% – это смесь устаревших решений: long-tail-развёртываний HLS на основе MPEG-TS, внутренних вещательных сред, использующих MPEG-TS из-за особенностей инструментов, а также небольшое количество пакетизаторов, выпущенных до 2018 года, которые ещё не перешли на новые стандарты.

Характеристики пропускной способности важны для планирования ёмкости. CMAF-упакованный 1080p-поток со скоростью 4 Мбит/с в режиме live с чанками по 333 мс проходит через пакер и ориджин со скоростью 12 чанков в секунду; 5-рендиционная лестница генерирует 60 чанков в секунду. Событие с 10 тысячами зрителей при использовании smart-edge CDN обеспечивает отдачу этих 60 чанков в секунду с примерно 99%-ным попаданием в кэш на edge, то есть ориджин обслуживает только свежие чанки и редкие промахи. Нагрузка на канал связи остаётся такой же, как у pre-CMAF dual-стекового ориджина для одного стека. Разница – отсутствие второго стека и, соответственно, дублирующей нагрузки на кэш.

На перспективу – два изменения, за которыми стоит следить: codec layer и transport layer. Codec layer смещается в сторону AV1 (сейчас – стандарт по умолчанию для нового контента на YouTube и Netflix) и VVC/H.266 (давний преемник HEVC, который теперь доступен на отдельных азиатских рынках). У обоих кодеков уже определены CMAF-бренд-коды, и они готовы к использованию; при смене кодека packaging-логика не меняется.

Transport layer выглядит интереснее: Media over QUIC – это попытка рабочей группы использовать CMAF-чанки в настоящем стриминговом транспорте, а не через HTTP. Ранние признаки перехода к следующему крупному сдвигу – это MoQ-ретрансляционная сеть Cloudflare, охватывающая 330 городов, а также интеграция Bitmovin и Cloudflare MoQ.

На протяжении всего этого перехода CMAF остаётся неизменным. Packaging-формат выступает в роли субстрата, позволяющего различным протоколам – HLS, DASH, LL-HLS, LL-DASH, MoQ, HESP – использовать одни и те же файлы.

Ключевые выводы

• CMAF – ограниченный формат фрагментированного MP4, позволяющий одному набору файлов обслуживать как HLS-, так и DASH-плееры с одного источника.
• Третья редакция 2024 (ISO/IEC 23000-19:2024) – текущий базовый стандарт; cmf2 – строгий структурный бренд, на который ориентируются большинство современных плееров.
• Схема cbcs Common Encryption станет дефолтной в 2026 году; её поддерживают FairPlay, Widevine и PlayReady, используя один и тот же ключ контента для расшифровки.
• Экономия при использовании CMAF реальна: на 50% меньше места на origin-хранилище, примерно вдвое выше эффективность кэширования в CDN, одна операция шифрования вместо трёх.
• Иерархия чанков – frame → chunk → fragment → segment – является основой, обеспечивающей работу LL-HLS-стриминга, включая LL-HLS, LL-DASH и MoQ.

Что читать дальше

• HLS подробно: m3u8, сегменты, мультивариантные плейлисты
• MPEG-DASH подробно: MPD, периоды, AdaptationSet, Representation
• LL-DASH и low-latency CMAF: chunked encoding на практике