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-pantos-hls-rfc8216bis-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-манифест из одних и тех же байт на ориджине, сокращает хранилище и origin egress примерно вдвое, удваивает эффективность 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 cache hit ratio, потому что один и тот же контент существовал в двух бинарно-идентичных-но-не-побайтово-идентичных форматах. CMAF – это формат, прекративший этот налог, и экономия немаленькая: −50% хранилища, ~2× CDN edge cache efficiency, один multi-DRM-пайплайн вместо трёх, один packaging-пайплайн вместо двух. Механика имеет значение, потому что в проде до сих пор ломаются три вещи – выбор схемы шифрования (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 существует из-за проблемы, которую streaming-индустрия сама себе создала в 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 cache efficiency падала вдвое. Шифрование удваивалось – 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 track, segment, fragment и chunk; структурные brand-коды cmfc и cmf2; первый набор media-профилей для H.264/AVC, HEVC и AAC; требование переносить CMAF-медиа в 'isom' / 'iso6'-совместимом fragmented MP4. Вторая редакция 2020 добавила профили для HEVC HDR (HDR10, HDR10+, HLG) и Dolby Atmos. Третья редакция 2024 – опубликованная в феврале 2024 – это текущий baseline; она добавляет профили для 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+ опрошенных streaming-инженеров; для новых развёртываний налог двойного стека исчез.

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

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

Без 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 storage при том же охвате контента. CDN-экономика ещё лучше. CDN тарифицирует cache miss (origin egress) и кэширует популярные файлы на edge. Без CMAF сегмент 02.ts (HLS) и сегмент 02.m4s (DASH) – два разных cache-объекта, хотя несут одни и те же кадры – кэш тратит полки на дубликаты, hit ratio падает. С CMAF оба манифеста адресуют один и тот же .m4s-объект, кэш хранит его один раз, hit ratio для того же edge-футпринта примерно удваивается. Совокупный эффект – половина хранилища, двойная эффективность кэша, половина стоимости encoding-and-packaging-пайплайна – это то, что делает 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 fragment

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

CMAF segment

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

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

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

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

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

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

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

Видео media-профили

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

Аудио media-профили

Subtitle- и metadata-профили

CMAF также определяет профили для IMSC1 text-subtitles (im1t, im1i), WebVTT (wvtt) и event-message-треков (emsg) для маркеров вставки рекламы и метаданных. Современная CMAF-презентация обычно объявляет один видео-brand, один-два аудио-brand-а и один subtitle-brand в боксах 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-brand-ами (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) предоставляет логику license-сервера, выдающую плееру тот же content-ключ, и плеер расшифровывает тем же алгоритмом независимо от того, какой DRM выпустил лицензию. Один зашифрованный файл, три DRM, каждое современное устройство.

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

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

cbcs (AES-128-CBC + субсэмпловый паттерн). Cipher Block Chaining с паттерном, шифрующим только часть байт – обычно 1 из каждых 10 блоков для видео (паттерн 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 (per-fragment IV). Content Encryption Key (CEK) идентифицируется Key ID (KID, 16-байтовый UUID). При запросе лицензии плеер шлёт KID каждому license-серверу DRM; license-сервер возвращает лицензию с CEK, защищённым root-of-trust своего DRM (FairPlay привязывает к Secure Enclave Apple-устройства; Widevine – к Trusty TEE или Strongbox; PlayReady – к Microsoft Hardware DRM bound key). Media-стек плеера расшифровывает каждый сэмпл при его поступлении в source buffer. Каждый DRM видит один и тот же CMAF-файл; различается только протокол license-сервера.

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

Частая production-ошибка – считать, что "поддержка cbcs" автоматически означает поддержку устройством. Устройства ниже iOS 11 (вышел в сентябре 2017) не воспроизводят cbcs-зашифрованный CMAF; pre-2018 PlayReady-устройства – тоже; часть Smart TV вышла с прошивкой Widevine L3, декодирующей только cenc. Правило 2026: если ваша аудитория на устройствах, выпущенных в 2019 или позднее, cbcs покрывает всех; если приходится дотягиваться до long tail pre-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-profile URN, объявляющий, что контент в CMAF, и сообщающий плееру применять CMAF-aware-парсинг (в частности, схему cbcs, а не cenc). Соответствующая HLS-конвенция – строка EXT-X-VERSION:6 (минимальная версия HLS, поддерживающая fMP4) и ссылка #EXT-X-MAP на init-сегмент. Оба манифеста маленькие (килобайты), легко перегенерируются и лежат рядом с файлами сегментов; стоимость – в сегментах, которые теперь упакованы один раз.

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

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

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

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

Связь с MPEG-TS – legacy-форматом HLS-сегментов – это аккуратный вывод из эксплуатации. MPEG-TS HLS ещё требуется для небольшой популяции устройств: старые модели Roku, часть Smart TV до 2018 года выпуска (ранние Vizio, некоторые LG webOS 3.x, некоторые Samsung Tizen 3.x), несколько embedded set-top-box-ов. Развёртывание 2026, таргетирующее эти устройства, поставляет небольшую MPEG-TS HLS-fallback-рендицию рядом с основным 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 из одного входа, плюс богатую библиотеку для инспекции fragmented MP4-файлов. Bento4 – выбор инженеров, которым нужен CLI-toolkit и тонкий контроль над brand-декларациями.

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

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

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

Shaka Packager и Bento4 покрывают open-source-bench; три managed-сервиса – SaaS-bench. Выбор между ними – это build-vs-buy-вопрос поверх того, что в 2026 CMAF-выдача – table stakes.

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

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

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

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

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

Грабли 2 – объявленный не тот codec-brand. Пакеджер выдаёт 4K HEVC HDR10, но пишет cmfc вместо cmf2 в ftyp и забывает 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 – забытое segment-alignment между рендициями. 1080p-segment 42 начинается в 02:48.000 по wall-clock, а 720p-segment 42 – в 02:48.040, потому что cadence энкодера дрейфовал. ABR-переключение плеера производит видимый 40-мс глитч. Лечение – выставить segmentAlignment="true" в DASH-манифесте и убедиться, что upstream-энкодер выдаёт выровненные GOP-ы по всем рендициям: каждая рендиция начинает новый IDR-кадр в один и тот же wall-clock-момент.

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

Production-реальность – внедрение, throughput и следующие два года

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

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

На перспективу – два изменения, за которыми стоит следить: codec layer и transport layer. Codec layer сдвигается к AV1 (сейчас дефолт YouTube и Netflix для нового контента) и VVC/H.266 (давно обещанный преемник HEVC, теперь поставляется в отдельных азиатских рынках); у обоих CMAF-brand-коды определены и готовы, и packaging-история не меняется при смене кодека. Transport layer интереснее: Media over QUIC – это попытка рабочей группы положить CMAF-chunk-и на настоящий streaming-транспорт, а не HTTP, и MoQ-relay-сеть Cloudflare на 330 городов плюс интеграция Bitmovin + Cloudflare MoQ – ранние production-намёки на то, куда идёт следующий крупный сдвиг. На протяжении этого сдвига CMAF остаётся. Packaging-формат – это субстрат, позволяющий каждому протоколу сверху – HLS, DASH, LL-HLS, LL-DASH, MoQ, HESP – делить одни и те же файлы.

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

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

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

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