Контейнеры: MP4, fMP4, MKV, WebM, MOV, MPEG-TS

TL;DR

Видеоконтейнер – это файл, который объединяет сжатый видеопоток, одну или несколько аудиодорожек, субтитры, главы и метаданные, необходимые плееру для корректного воспроизведения. Контейнер – не то же самое, что кодек: кодек сжимает пиксели в битовый поток, а контейнер – это своего рода конверт, в котором эти биты хранятся вместе со всем остальным. Шесть контейнеров покрывают почти все задачи современного видео. MP4 и его фрагментированный вариант fMP4 доминируют в открытом интернете, поскольку их поддерживает любое устройство; MKV – выбор, когда нужны все дорожки, все субтитры и максимальная функциональность в одном файле; WebM – веб-ориентированный профиль Matroska от Google, основанный на роялти-свободных кодеках; MOV – профессиональный формат Apple для постпродакшена и прямой предшественник MP4; MPEG-TS – «рабочая лошадка» вещания, лежащая в основе кабельного, спутникового телевидения и ранних версий HLS-стриминга. Выберите не тот контейнер – и либо ограничите совместимость с половиной плееров мира, либо будете годами платить инфраструктурный налог за стриминг. Эта статья объясняет, что собой представляет каждый контейнер, в чём его сильные стороны и какой использовать для каждой задачи в 2026 году.

Зачем это нужно

Если вы создаёте сервис, который передаёт видео зрителю – стриминговый сервис, онлайн-обучение, видеоконференцсвязь, телемедицину или систему видеонаблюдения, – рано или поздно ваши инженеры зададут вопрос: «Какой контейнер использовать?» Ответ на него определит стоимость, совместимость и продуктовый roadmap на годы вперёд.

Платформа, выбравшая обычный MP4 для live-стриминга, через девять месяцев перепишет весь упаковочный слой с нуля – обычный MP4 не подходит для потоковой передачи в реальном времени. Платформа, решившая использовать MKV для скачивания, будет объяснять пользователям, почему файлы не открываются на iPhone. А платформа, выбравшая MPEG-TS для видео по запросу, будет платить 10–15 % надбавки за хранение и трафик на каждый файл всю оставшуюся жизнь – ведь MPEG-TS изначально разрабатывался для кабельных и спутниковых сетей, а не для дисков и CDN.

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

Эта статья предлагает ментальную модель, которая поможет принять решение один раз – спокойно и правильно. Мы начнём с различия между контейнером и кодеком, рассмотрим шесть наиболее распространённых контейнеров, разберём устройство каждого из них и завершим деревом решений, которое можно применить к реальному продукту даже без участия инженера.

Контейнер – это не кодек

С этого начнём. Кодек – сокращение от coder-decoder, то есть кодировщик-декодировщик – это программа, которая сжимает необработанные видеоданные до значительно меньшего потока бит и восстанавливает их при воспроизведении. H.264, H.265 (HEVC), VP9, AV1 и VVC – примеры кодеков. Это чистая математика: на вход подаётся последовательность кадров, на выходе – поток бит, из которого тот же кодек восстанавливает (почти) те же кадры.

Контейнер – это формат файла, который оборачивает эти биты. Это как коробка, в которой хранятся сжатая видеодорожка, сжатая аудиодорожка, дорожки субтитров, главы, обложка, метаданные («видео 1920 на 1080, 24 fps, BT.709, начало в 01:00:00») и индекс, позволяющий плееру мгновенно перейти к 37-й минуте двухчасового фильма, не просматривая весь файл. Всё это – не задача кодека. Кодек не должен знать и не обязан знать, в каком контейнере окажутся биты.

Один и тот же H.264-поток можно упаковать в MP4, MKV, MOV, MPEG-TS или fMP4. Внутри – одни и те же байты. Меняется только обёртка. Полезная аналогия: кодек – это сам напиток, а контейнер – ящик, в котором его перевозят. Pepsi одинаково вкусна и в шестибаночном картоне, и в торговом автомате, и в ресторанном стакане – но упаковка определяет, как её транспортировать, хранить, маркировать и подавать.

Из-за этого разделения вопрос «MP4 или AV1?» теряет смысл. MP4 – это контейнер, AV1 – кодек. Настоящий вопрос звучит иначе: «MP4 с AV1 и Opus или WebM с AV1 и Opus?» – одинаковое содержимое, разные обёртки. Как только это становится понятным, половина путаницы вокруг контейнеров исчезает.

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

Что вообще должен уметь контейнер

Посмотрите на задачу: видеофайл должен выполнять пять функций одновременно.

Во-первых, хранить несколько потоков сразу. У типичного фильма одна видеодорожка, две-три аудиодорожки (английский оригинал, испанский дубляж, комментарий режиссёра) и несколько дорожек субтитров. Всё это живёт в одном файле так, чтобы плеер мог найти нужное.

Во-вторых, синхронизировать дорожки – чтобы реплики точно совпадали с движениями губ, а субтитры появлялись вовремя. Контейнер обеспечивает это, присваивая каждому фрагменту видео и аудио точный таймкод: «воспроизвести через 17,504 секунды». Плеер использует эти таймкоды, чтобы корректно объединить все потоки.

В-третьих, позволять плееру прыгать по файлу, не перечитывая его с начала. Нажав на 90-ю минуту двухчасового фильма, плеер должен сразу знать, с какого байта начать воспроизведение. Контейнер хранит индекс (sample table, offset table или cues block – в зависимости от формата), который сопоставляет «90 минут» с «байтом 2 041 876 332».

В-четвёртых, нести метаданные – описательные ярлыки и параметры, которые сопровождают файл: название, язык, кодек, разрешение, частота кадров, цветовое пространство, частота дискретизации звука, раскладка каналов, имена глав, а также обложка. Без них плееру приходится угадывать, а угадывание быстро сбоит.

В-пятых, запись по частям – желательно без переписывания всего файла, когда нужно добавить фрагмент в конец. Это важно для камер (которые записывают в реальном времени), для live-кодировщиков (работающих во время эфира) и для стриминговых серверов (которые начинают передачу до завершения записи).

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

ISO BMFF – общее дерево для половины форматов

Три из шести контейнеров – MP4, fMP4 и MOV – имеют общего предка. Все они основаны на ISO Base Media File Format (сокращённо ISO BMFF), стандартизированном как ISO/IEC 14496-12 Международной организацией по стандартизации. 1 Понимая ISO BMFF, вы освоите 90 % контейнеров, с которыми когда-либо столкнётесь.

ISO BMFF представляет файл в виде дерева боксов (boxes), которые Apple исторически называла атомами (atoms). У каждого бокса есть фиксированный заголовок: четыре байта – размер, четыре байта – тип (ftyp, moov, mdat) и тело, которое может содержать либо сырые данные, либо вложенные боксы. Весь файл представляет собой большое вложенное дерево боксов.

В типичном MP4-файле присутствует небольшой набор боксов верхнего уровня. Бокс ftyp в начале файла определяет формат и версию – подобно тому, как «магическое число» идентифицирует JPEG или PNG. Бокс moov (movie box) содержит всю метаданные файла: информацию о дорожках, параметрах кодеков, таймингах и ключевую таблицу сэмплов, которая сопоставляет таймкоды с байтовыми смещениями в медиаданных. Бокс mdat (media data box) хранит сами сжатые байты видео и аудио – без внутренней структуры, за исключением той, что описана в индексах moov. 1

Два факта об этой раскладке определяют всё дальнейшее. Во-первых: плеер должен прочитать moov целиком, прежде чем начать воспроизведение – это оглавление, по которому он находит каждый кадр в mdat. Во-вторых: moov обычно занимает всего несколько килобайт на час видео. Если moov находится в начале файла, плеер начинает играть сразу после получения первых сетевых пакетов; если же он в конце (что является стандартом для некоторых рекордеров), плеер вынужден скачать весь файл целиком, прежде чем начнётся воспроизведение. Размещение moov в начале называют «fast-start», «moov atom first» или «web-optimised» – в зависимости от используемого инструмента. Для веб-раздачи всегда применяйте такой подход.

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

ISO BMFF доминирует уже два десятилетия благодаря своей гибкости: одна и та же структура боксов одинаково хорошо подходит как для минутного клипа с телефона, так и для четырёхчасового 4K HDR-фильма или фрагментированного live-потока. Те же самые парсеры, демультиплексоры и инструменты работают со всем этим без изменений. Далее – о конкретных диалектах ISO BMFF, а также о двух форматах, не относящихся к ISO BMFF (Matroska и MPEG-TS), которые решают другие задачи.

MP4 – формат по умолчанию, поддерживаемый всеми

MP4, определённый стандартом ISO/IEC 14496-14 и утверждённый в 2003 году, – самый распространённый видеоконтейнер из существующих. 2 Если вам нужен файл, который будет воспроизводиться на любом смартфоне, ноутбуке, в любом браузере, на любом смарт-телевизоре и игровой консоли без дополнительных настроек – сохраняйте его в формате MP4. Почти все камеры, программы для записи экрана и видеоредакторы экспортируют видео в MP4 по умолчанию; почти все социальные платформы – YouTube, TikTok, Instagram, LinkedIn – принимают MP4 как предпочтительный формат загрузки.

Внутри MP4 – прямая реализация ISO BMFF с небольшим набором боксов, специфичных для MP4. Бренд в ftyp – isom или mp42, а moov индексирует потоки. Внутри обычно находятся: H.264 для видео (универсальный стандарт по умолчанию), H.265 для нового 4K и HDR-контента, AAC для звука, AC-3 и E-AC-3 для surround-звука, Opus для низколатентного аудио и всё чаще AV1 – как формат следующего поколения по эффективности. 2

Главная слабость MP4 – следствие его дизайна: формат изначально задумывался как файл, который записывается один раз и затем читается с диска. Единственный moov-индекс, обеспечивающий эффективность воспроизведения, делает формат неудобным для live-стриминга: moov нельзя завершить, пока автор не знает точного положения каждого кадра в файле, а эта информация становится доступна только после окончания записи. Готовый MP4 можно передавать по HTTP, но файл, который ещё записывается, – нет. Именно эту проблему и призван был решить fMP4.

Маленькая проверка чисел помогает оценить эффективность MP4. Двухчасовой 1080p-фильм с видеобитрейтом 5 Мбит/с и аудиобитрейтом 192 кбит/с весит:

всего бит = (5 000 000 + 192 000) × 7 200 секунд
всего бит = 5 192 000 × 7 200
всего бит ≈ 37,4 миллиарда бит
всего байт ≈ 4,67 гигабайта

Накладные расходы контейнера MP4 составляют около 0,5–1 % – несколько десятков мегабайт на боксы moov, ftyp и таблицы выборок. То есть 4,67 ГБ исходных данных превращаются в 4,69 ГБ в формате MP4. Это минимальный «упаковочный налог» среди всех контейнеров – и одна из причин, по которой MP4 остаётся форматом по умолчанию.

fMP4 – MP4, разбитый на стриминговые фрагменты

Фрагментированный MP4 (fMP4) – это тот же ISO BMFF, но с одной структурной особенностью: вместо одного большого moov, ссылающегося на единый mdat, файл делится на множество небольших фрагментов, каждый из которых представляет собой самодостаточную пару moof (box фрагмента фильма) + свой mdat. В moof хранится небольшой индекс только для своего фрагмента, а в mdat – только байты этого фрагмента. 3

Звучит как мелочь. Но это не мелочь. Это самое важное изменение в истории интернет-доставки видео.

Причина в том, что каждый фрагмент воспроизводится независимо. Плеер может скачать фрагмент №47 из live-эфира, декодировать его и отобразить изображение, не видя при этом фрагменты с 1 по 46. Каждый moof содержит полное оглавление байтов в соответствующем mdat. Поэтому фрагмент можно закодировать и записать сразу после захвата, отправить на CDN, и плеер начнёт его воспроизводить уже через несколько секунд после съёмки. Файл можно распределить по edge-нодам CDN, а плеер будет собирать фрагменты из разных источников. Между фрагментами можно менять качество – и плеер этого не заметит. Именно на этом принципе построены все современные протоколы адаптивного битрейта в интернете.

У этого последнего пункта есть название: Adaptive Bitrate streaming, или ABR. Кодировщик создаёт несколько копий одного видео с разными битрейтами – например, 5 Мбит/с, 3 Мбит/с, 1,5 Мбит/с, 600 кбит/с – и разбивает каждую на fMP4-фрагменты длительностью 2–6 секунд. Плеер отслеживает скорость интернета и загрузку процессора зрителя, выбирая нужный битрейт для каждого фрагмента в реальном времени. Когда вы смотрите Netflix, и через пару секунд картинка становится чётче – это ABR заменил фрагмент с низким битрейтом на фрагмент с высоким. fMP4 – это основа, на которой всё это работает.

fMP4 стал стандартным форматом упаковки для двух основных HTTP-протоколов стриминга. HLS (HTTP Live Streaming) – протокол Apple, появившийся в 2009 году, – изначально использовал сегменты в формате MPEG-TS и получил поддержку fMP4 на конференции WWDC 2016. 4 MPEG-DASH (Dynamic Adaptive Streaming over HTTP), международный аналог HLS, с самого начала работает с fMP4. Ещё одна аббревиатура, с которой вы столкнётесь, – CMAF, Common Media Application Format. Это, по сути, более строгий профиль fMP4, разработанный так, чтобы один и тот же набор фрагментов мог использоваться одновременно и для HLS, и для DASH. О CMAF поговорим подробнее ниже.

Для всего, что идёт в эфире – концерты, спорт, новости, лекции, хирургические трансляции – в 2026 году fMP4 станет выбором по умолчанию на уровне контейнера. Для статичного VOD с одним битрейтом обычный MP4 нередко проще и чуть эффективнее. Во всех промежуточных случаях fMP4 выигрывает, поскольку бесплатно обеспечивает ABR.

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

MOV – профессиональный предок и формат монтажа

MOV, формально QuickTime File Format, создан Apple в 1991 году для платформы QuickTime. 5 Это прямой предшественник MP4 – спецификация MP4 появилась, когда формат QuickTime был обобщён и стандартизирован в ISO в 1998 году. Внутренне MOV и MP4 настолько схожи, что многие инструменты могут открывать один формат как другой; различия заключаются лишь в значении поля ftyp и нескольких атомах, специфичных для MOV, которые хранят профессиональные метаданные, не поддерживаемые формально в MP4.

В повседневной работе MOV – это формат для постпродакшена. Final Cut Pro, Avid Media Composer и DaVinci Resolve по умолчанию сохраняют MOV-файлы для промежуточных и мастер-версий. Внутри почти всегда используется кодек ProRes – «промежуточный» кодек Apple, предназначенный для монтажа. У него гораздо более высокий битрейт и значительно меньшая компрессия по сравнению с H.264 или H.265, что позволяет редактору свободно прокручивать, резать и пересохранять материал без потери качества от поколения к поколению. Час 1080p-видео в ProRes 422 занимает около 66 ГБ против примерно 2,3 ГБ в H.264 – но ProRes декодируется быстрее, монтируется чище и сохраняет столько деталей, сколько нужно, чтобы выдержать десять циклов правок без заметных потерь.

Когда использовать MOV? Внутри продакшен-пайплайна – почти всегда. Метаданные о цвете в MOV богаче, чем в обычном MP4: теги gamma, matrix и primary-colour сохраняются при передаче между редакторами без искажений, которые годами портят цветовые метаданные в MP4. Вне продакшена – никогда; весь мир работает с MP4. Переход из MOV в MP4 происходит в конце постпродакшена, когда мастер пересчитывают для доставки. Многие монтажные инструменты называют этот шаг «Export H.264 / MP4 for delivery» – и это правильная модель: MOV – мастер, MP4 – оттиск.

MKV / Matroska – «всё в одном» среди контейнеров

Matroska, расширение .mkv, – открытый мультимедийный контейнер, созданный в 2002 году для решения задач, на которые изначально не рассчитывали при разработке ISO BMFF: объединить в одном файле все возможности, которые может пожелать зритель, без необходимости платить лицензионные отчисления. 6 Он основан на параллельном бинарном формате EBML (Extensible Binary Meta Language), а не на иерархической структуре боксов ISO BMFF. Функционально EBML и ISO BMFF выполняют схожие задачи – оба представляют собой дерево помеченных элементов, – но Matroska выбрал собственный путь.

Сила MKV – в этой универсальности. MKV-файл может содержать неограниченное количество видео-, аудио- и субтитровых дорожек. Поддержка субтитров особенно богата: Matroska нативно поддерживает SubStation Alpha (SSA / ASS), SubRip (SRT), VobSub и графические PGS с правильной стилизацией и позиционированием. 6 Он также поддерживает главы, встроенные шрифты, встроенные изображения, edit-decision-листы и произвольные метаданные – всё то, что другие контейнеры хранить внутри файла не позволяют.

Для практического пользователя – и особенно для конечного потребителя, скачивающего или собирающего свою коллекцию, – MKV непобедим. Один MKV-фильма может нести 4K HDR Dolby Vision-картинку, английский Atmos-трек, дублированный французский трек, английские субтитры, испанские субтитры, субтитры для слабослышащих, главы и постер – всё в одном файле, который чисто играется в VLC, Kodi, mpv и современных смарт-ТВ.

Но у MKV есть серьёзная слабость: веб его нативно не поддерживает. Ни один основной браузер не воспроизводит MKV через стандартный HTML5 <video>. Экосистема Apple – iOS, iPadOS, tvOS, Safari на macOS – вообще не поддерживает MKV. Упаковщики HLS и DASH не умеют фрагментировать MKV для адаптивного стриминга так, как фрагментируют ISO BMFF. Если цель – выложить видео в веб, MKV – не лучший выбор. 7

Ментальная модель: MKV – формат для архивов, личных коллекций и ситуаций, когда вы контролируете и источник, и плеер. MP4 (или fMP4) – формат для случаев, когда плеер находится вне вашего контроля.

WebM – веб-ориентированный профиль Matroska от Google

WebM – это формат Matroska, из которого убрали всё, что не является роялти-фри, и ограничили список поддерживаемых кодеков узким белым списком, совместимым с вебом. Google представил его в мае 2010 года одновременно с выпуском открытого кодека VP8. Цель была ясной: создать видеоформат, который открытый веб может использовать без уплаты патентных отчислений третьим сторонам. 8

WebM-файл по структуре – это Matroska. Синтаксис контейнера – то же EBML-дерево, и большинство инструментов для работы с Matroska обрабатывают WebM как частный случай. Ограничения касаются содержимого: в WebM разрешены только кодеки VP8, VP9 и AV1 для видео, а также Vorbis и Opus для аудио. 8 Кодеки H.264, H.265, AAC и AC-3 использовать нельзя. Цель – сохранить весь стек (контейнер, видеокодек, аудиокодек) свободным от обязательств по патентным пулам MPEG.

WebM даёт две практические выгоды. Во-первых, его нативно поддерживают все современные браузеры – Chrome, Firefox, Edge и, начиная с Safari 14.1 в 2021 году, также Safari. Во-вторых, используемые в нём кодеки – VP9 и особенно AV1 – значительно эффективнее H.264 по использованию битрейта. На типичных веб-настройках AV1 на 30–50 % экономичнее H.264 при одинаковом воспринимаемом качестве. Это напрямую снижает расходы на CDN и ускоряет загрузку видео на медленных соединениях.

Слабостей тоже две. Первая: аппаратное декодирование AV1, хотя и стало распространённым на устройствах после 2022 года, всё ещё не универсально – старые телефоны, телевизоры и многие корпоративные ноутбуки вынуждены использовать программное декодирование, что быстро расходует батарею и может вызывать подтормаживания на слабом железе. Вторая: мир iOS продолжает отдавать предпочтение HEVC в MP4 для аппаратно-ускоренного воспроизведения, поэтому даже если Safari поддерживает WebM, AV1 и VP9, наиболее плавное воспроизведение на iPhone обеспечивается HLS-потоком в формате fMP4 с кодеками H.265 или H.264.

Практическая рекомендация на 2026 год: если ваша аудитория использует Chrome, Firefox или Android – отдавайте приоритет WebM как основному формату доставки. Если аудитория охватывает разнообразные устройства – телефоны, планшеты, смарт-ТВ, приставки – используйте fMP4 / MP4 с кодеками H.264 или H.265, а WebM применяйте как эффективный дополнительный формат для поддерживающих его браузеров.

MPEG-TS – рабочая лошадка вещания

MPEG Transport Stream, обычно сокращаемый до MPEG-TS или просто TS, – старейший контейнер в этом списке и обладатель самых неинтуитивных решений. Он был определён в стандарте MPEG-2 Systems (ISO/IEC 13818-1) в 1995 году для одной задачи: передачи сжатого видео по ненадёжным сетям, где данные могут теряться, повреждаться или приходить не в том порядке. 9 То есть – спутниковая, кабельная, наземная цифровая трансляция и IPTV-сети. Каждый цифровой телеканал, который вы смотрите сегодня, доходит до приставки в виде MPEG-TS-потока.

Внутренняя структура MPEG-TS экзотична по сравнению с боксовыми форматами. Это непрерывная последовательность фиксированных 188-байтных пакетов. Каждый пакет начинается с байта синхронизации (шестнадцатеричное значение 0x47), за которым следует небольшой заголовок, содержащий 13-битный Packet Identifier (PID), указывающий приёмнику, к какому потоку относится пакет, и полезную нагрузку длиной до 184 байт. 9 Размер 188 байт выбран так, чтобы ровно четыре пакета помещались в ячейку AAL-1 сети ATM (Asynchronous Transfer Mode) – телекоммуникационного бэкбона 1990-х годов. Сегодня эта деталь – окаменелость, но размер так и не менялся.

PID позволяет одному потоку мультиплексировать несколько программ. Один MPEG-TS-поток со спутника может содержать 20 каналов – у каждого свой видео-PID, свои аудио-PID и субтитровые PID – а приёмник подключается, отфильтровывая нужные PID. Вся архитектура построена с учётом того, что часть пакетов может потеряться в пути, поэтому каждый пакет самодостаточен: повреждённый пакет можно отбросить, не затрагивая остальные.

В интернет-стриминг MPEG-TS попал с «заднего входа». Когда Apple представила HLS в 2009 году, она выбрала MPEG-TS в качестве формата сегментов, потому что им уже пользовались все вещательные кодировщики, а каждый аппаратный декодер его понимал. 4 Ранний HLS-поток представлял собой последовательность .ts-файлов продолжительностью 6–10 секунд, перечисленных в .m3u8-плейлисте. Это работало, но MPEG-TS несёт около 10–15 % накладных расходов на пакет по сравнению с эквивалентным fMP4 – четырёхбайтные заголовки накапливаются на миллионах пакетов – и это реальная плата, когда вы оплачиваете CDN за гигабайты трафика. 10

История MPEG-TS в интернет-видео за последнее десятилетие – это постепенное отступление. В 2016 году HLS получил поддержку fMP4-сегментов как альтернативного формата. К 2018 году CMAF объединил упаковку HLS и DASH на основе fMP4. Новые развёртывания HLS по умолчанию используют fMP4. MPEG-TS всё ещё повсеместно применяется – в каждой приставке, в каждом вещательном ингесте, в каждом SRT (Secure Reliable Transport)-фиде, поступающем в стриминговый origin, – но для новых интернет-проектов MPEG-TS остаётся оправданным выбором только в том случае, если требуется взаимодействие с вещательным оборудованием или системой, явно поддерживающей этот формат. Во всех остальных случаях fMP4 просто вытеснил его.

CMAF – слой объединения для HLS и DASH

Заметка о CMAF, Common Media Application Format, потому что вы обязательно столкнётесь с ним в любом современном разговоре об упаковке медиаконтента. CMAF – это не контейнер в привычном смысле, как MP4 или MKV. Это ограниченный профиль fMP4, стандартизированный в 2018 году как ISO/IEC 23000-19. Он фиксирует структуру боксов, поддерживаемые кодеки, методы шифрования и временные метки так, чтобы один и тот же набор фрагментов мог воспроизводиться как в HLS-, так и в DASH-плеерах. 11

До появления CMAF стриминговая платформа, чтобы поддерживать устройства Apple (HLS) и все остальные (DASH), вынуждена была упаковывать каждый контент дважды – .ts-сегменты для HLS и fMP4 для DASH. Это означало двойное хранение, использование двух CDN и двойную работу по кодированию. CMAF устраняет эту необходимость, заменяя оба формата единым fMP4-пейлоадом, на который ссылаются оба манифеста. Байты на диске остаются одинаковыми; различаются лишь плейлисты .m3u8 и .mpd.

CMAF также поддерживает низколатентный стриминг. Разделяя каждый сегмент на небольшие чанки длительностью 0,5–2 секунды и применяя HTTP/1.1 chunked transfer encoding, CMAF-поток достигает зрителя уже через 2–4 секунды после съёмки – вместо 20–30 секунд задержки, характерных для HLS до появления CMAF. 12 Такая скорость делает возможным трансляцию спортивных событий в реальном времени, интерактивные стримы, прямые аукционы и любые продукты, где аудитория должна ощущать себя «в одной комнате» с происходящим.

В 2026 году CMAF станет форматом упаковки по умолчанию для новой стриминговой инфраструктуры. AWS Elemental MediaPackage, Bitmovin, Mux, Wowza, Shaka Packager и Unified Streaming уже по умолчанию используют CMAF. Когда инженеры говорят: «мы упаковываем в CMAF», – они имеют в виду fMP4-сегменты, настроенные одновременно под HLS и DASH и готовые к доставке с низкой задержкой. Это правильная архитектура для любого нового продукта, запускаемого сегодня.

Сравнение в одном месте

Таблица ниже кратко отвечает на вопрос «какой контейнер выбрать?». Это быстрая шпаргалка; подробный разбор выше – её обоснование.

Закономерность: MP4 выигрывает по совместимости, fMP4 / CMAF – по стримингу, MOV – по продакшен-метаданным, MKV – по функциональности, WebM – по роялти-фри доставке в вебе, MPEG-TS – по наследию вещания. Ни один формат не идеален во всём – поэтому ваш видеопайплайн рано или поздно будет использовать несколько.

Частая ошибка: один контейнер на все случаи

Самая частая архитектурная ошибка ранних видеоплатформ – выбрать один контейнер и использовать его везде. Соблазн понятен: меньше форматов – меньше багов, но платить за это приходится одним из двух способов.

Если выбрать обычный MP4 для всего, вы заплатите в день, когда захотите добавить трансляцию в реальном времени или адаптивный битрейт: обычный MP4 не поддерживает стриминг в реальном времени и не адаптируется под условия просмотра. Вам придётся внедрить второй слой упаковки (fMP4 / CMAF) поверх существующего пайплайна. Это обойдётся в несколько недель инженерной работы, а также потребует дублирования хранилища и CDN на время перехода.

Если выбрать MKV везде из-за гибкости, вы заплатите в день, когда первый нетехнический пользователь пожалуется, что iPhone или iPad не открывает присланный файл. Вы всё равно дойдёте до транскода в MP4, но позже – и пользователю уже неприятно.

Правильная архитектура разбивает пайплайн на стадии, каждая из которых работает в своём контейнере. Стадия захвата записывает данные в MOV (камеры, редакторы) или MKV (архив). Стадия транскодирования создаёт MP4 (для скачивания) и fMP4 / CMAF (для стриминга) на основе мастер-файла. Стадия доставки отдаёт плееру именно то, что он запросил. Каждый контейнер выполняет свою задачу – и вы больше не боретесь с форматом.

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

Мы интегрировали контейнеры более чем в 239 видеопродуктов с 2005 года – в стриминговое видео, видеоконференции, OTT и интернет-ТВ, системы видеонаблюдения, e-learning, телемедицину и AR/VR. Выбор формата контейнера редко становится приоритетом для клиента – но почти всегда незаметно определяет стоимость и масштабируемость решения. В OTT- и интернет-ТВ-платформах мы используем CMAF в качестве единого стримингового слоя, поверх которого работают манифесты HLS и DASH. В телемедицине и видеоконференциях применяем fMP4 для записи сессий, MP4 – для скачивания доказательной документации, а MPEG-TS – только там, где это требует устаревшая инфраструктура больниц. В e-learning MOV остаётся в производственном пайплайне, а конечному пользователю доставляется адаптивный fMP4. Общий принцип один: использовать подходящий контейнер на каждой стадии, но никогда – один и тот же формат для всех задач одновременно.

Ключевое

• Контейнер объединяет дорожки и метаданные, а кодек сжимает пиксели. Они независимы и могут свободно сочетаться.
• MP4 – универсальный стандарт по умолчанию для скачивания и загрузки.
• fMP4 / CMAF – стандарт упаковки для любой новой стриминговой инфраструктуры в 2026 году.
• MOV – подходящий контейнер внутри производственного пайплайна, но не для внешнего использования.
• MKV непобедим в архивах и личных коллекциях, но не подходит для открытого веба.
• WebM обеспечивает роялти-свободную доставку в вебе с кодеками VP9 или AV1; MPEG-TS используется в вещании и устаревших реализациях HLS.

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

• Стриминг-протоколы: 8 главных в 2026
• Краткая история видеокодеков: от H.120 (1984) до AV2 (2025)
• Что такое цифровое видео: от аналогового сигнала к битам