Упаковка видео: от выхода энкодера к манифесту – подробный разбор

TL;DR

Видеопакетайзер – это софт, который берёт готовый энкод (одну mezzanine-дорожку или целую лесенку bitrate-вариантов) и превращает его в то, что стриминговый плеер реально может скачать: короткие медиа-сегменты, обёрнутые в контейнер (в 2026 году это почти всегда fragmented MP4), текстовый манифест со списком этих сегментов (плейлист HLS .m3u8, файл DASH .mpd или оба сразу) и – для платного контента – ключи шифрования по стандарту Common Encryption (ISO/IEC 23001-7), чтобы те же сегменты могли расшифровать три разные DRM-системы. Рынок 2026 года делится на open-source инструменты – Shaka Packager от команды Google Widevine (стабильный v3.7.2, апрель 2026) и Bento4 от Axiomatic Systems – и коммерческие пакетайзеры, в основном серверные: Unified Origin (CodeShop), AWS Elemental MediaPackage, Wowza, Norsk (id3as), а также open-source GPAC. Доминируют две архитектуры: статическая упаковка, которая один раз на ингесте пишет каждый сегмент на диск, и just-in-time упаковка (JIT), генерирующая сегменты и манифесты на каждый запрос плеера из меньшего набора исходных MP4-файлов. Дефолт 2026 года для любой платформы старше пары сотен тайтлов – CMAF-сегменты, зашифрованные AES-CBC pattern-схемой cbcs, индексируемые манифестами и HLS, и DASH, ссылающимися на одни и те же байты на диске: «закодировал один раз, упаковал один раз, расшифровал везде».

Кому и зачем это нужно

Упаковка – самый недооценённый слой стримингового стека и тот самый слой, который тихо решает, сколько вы платите за хранилище, как быстро сможете запустить новую платформу-устройство и нужно ли через два года при ротации DRM перепаковать весь каталог или просто перевыпустить ключи. Продакт-менеджер, который относится к упаковке как «к тому, что бывает после энкода», теряет рычаг для торга между storage- и compute-затратами, определяющими месячный счёт за origin; основатель, который выбирает пакетайзер без понимания деления «static vs JIT», впихивает себя в workflow, где storage-затраты вчетверо вырастают в день, когда каталог переваливает за тысячу тайтлов. Стриминговым инженерам нужна та же картина с другой стороны: какой пакетайзер поддерживает последний драфт LL-HLS, у какого честно реализована CMAF-запись, в чём именно командно-строчная разница между Shaka и Bento4 для multi-DRM CMAF VOD. Эта статья даёт обеим аудиториям одну и ту же карту – с номерами стандартов, реальными командами и арифметикой стоимости, по которой можно принять решение.

Что на самом деле делает пакетайзер

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

Удобно представить пакетайзер как продавца в гастрономе. Энкодер – это разделочный цех в подсобке; он производит длинные, полностью кодированные «бока туши», называемые mezzanine-файлами – по одному на каждое качество в bitrate-лесенке. Пакетайзер – это продавец у прилавка, который режет бок на одинаковые 4-секундные порции, оборачивает каждую в фирменную бумагу (контейнер fragmented MP4), наклеивает этикетки и вешает прайс-лист на стену (манифест), чтобы покупатели могли попросить нужные ломтики в нужном качестве. Если в гастрономе есть «премиальные» отрубы по подписке, тот же продавец накладывает на каждый ломтик защитную пломбу, которую могут сорвать только покупатели с правильным ключом (Common Encryption). Покупатели – плееры на телефонах, в браузерах, на смарт-ТВ – никогда не видят целого бока; они получают только подписанные ломтики.

Три работы идут вместе: fragment, manifest, encrypt. Пакетайзер существует, потому что плеер не может потреблять многогигабайтный единый файл-энкод. Плееры потребляют HTTP-запросы к коротким файлам, индексируемые манифестом, опционально защищённые DRM-ключом. Всё ниже – это детали этих трёх работ.

Где упаковка стоит в пайплайне

Стриминговый пайплайн до пакетайзера выглядит так. Камера или мастер-файл кормят энкодер (FFmpeg, AWS Elemental Live, Bitmovin, NETINT, x264/x265/SVT-AV1, libvpx и т. д.). Энкодер выдаёт по одному mezzanine-файлу на каждую ступень лесенки – полный энкод 240p/360p/480p/720p/1080p/4K в H.264, HEVC, AV1 или VVC, каждый со своим целевым битрейтом. Эти mezzanine – вход пакетайзера.

Выход пакетайзера уходит в origin – небольшой сервер (или S3-бакет за CloudFront), который хранит сегменты и отдаёт их по HTTP. За origin'ом стоит content delivery network (CDN) – глобальный кеширующий слой, который тянет сегмент с origin один раз и раздаёт его зрителям с краевых узлов рядом с их физическим расположением. Плеер у зрителя сначала тянет манифест, парсит список ступеней, выбирает одну, потом тянет сегменты один за другим с ближайшего edge.

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

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

Фрагменты, сегменты, чанки: три слова

Самая частая путаница в терминологии упаковки – это разница между фрагментом, сегментом и чанком. Спецификация ISO/IEC 23000-19 CMAF (2018, второе издание 2020) даёт каждому термину точное значение, и серьёзные пакетайзеры этот разделитель уважают.

CMAF chunk – это один box moof, за которым следует один box mdat внутри fragmented-MP4. moof – это movie fragment box; он содержит timing- и sample-table-метаданные для байтов, идущих за ним. mdat – это media data box; он содержит сами кодированные сэмплы видео или аудио. Чанк – минимальная независимо декодируемая единица в CMAF, обычно один кусок выровненного по GOP видео длиной около 200 мс.

CMAF fragment – это один или несколько подряд идущих чанков, имеющих общий адрес относительно сегмента. Большинство production-пакетайзеров в 2026 году используют отображение один-к-одному – один фрагмент равен одному чанку – а сам термин «фрагмент» в основном выживает потому, что лежащий в основе ISO base media file format (ISO/IEC 14496-12) пользуется им.

CMAF segment – это один или несколько фрагментов, которые вместе образуют адресуемую единицу, скачиваемую плеером одним HTTP-запросом – обычно 2, 4 или 6 секунд видео. Сегмент – это единица, которая появляется в HLS-плейлисте или в DASH MPD-таймлайне. Сегмент начинается с keyframe, чтобы его можно было декодировать без отсылок к предыдущему сегменту.

Отношение такое: chunk ≤ fragment ≤ segment. Для low-latency-стриминга (LL-HLS, LL-DASH) значимая транспортная единица – это чанк: плеер запрашивает partial-сегменты, собранные из чанков по мере их появления в живом потоке, вместо ожидания полного сегмента. Для всего остального значимая единица – это сегмент.

Два следствия для инженера, который собирает шаг упаковки. Во-первых, пакетайзер обязан выровнять границы сегментов с keyframe-интервалом энкодера – иначе плеер скачает «сегмент», у которого первый кадр это P-кадр, зависящий от данных, которых у плеера нет. Большинство production-энкодеров имеют ручку --gop-size, которую читает пакетайзер; промах в этом выравнивании – самый частый баг упаковки. Во-вторых, длительность сегмента – это нижняя граница задержки переключения. Если сегменты по 6 секунд, плеер может менять качество не чаще раза в 6 секунд; если по 2 секунды – в четыре раза чаще. Trade-off ниже.

Длительность сегмента: компромисс 2 / 4 / 6

Какой длины должен быть сегмент? Индустрия спорила об этом десять лет. Консенсус 2026 года узкий: 4 секунды для VOD, 2 секунды для live, с длинными (6 секунд) для VOD-only каталогов, ценящих CDN-кеш-эффективность выше быстрого переключения качества, и с короткими (1 секунда или меньше через partial-сегменты LL-HLS) для live, гонящегося за низкой задержкой. Apple HLS Authoring Specification (ревизия 2025-09, §4.3.2.2) рекомендует 6-секундные сегменты для стандартного HLS и partial-сегменты по 0,33 с для LL-HLS.

Арифметика trade-off коротка.

HTTP-запросов в час на рендицию = 3600 / segment_duration
При 2 с: 1 800 запросов/час/рендиция
При 4 с:   900 запросов/час/рендиция
При 6 с:   600 запросов/час/рендиция

Короткие сегменты утраивают нагрузку запросами на origin и CDN. CDN биллит и запросами, и байтами, поэтому количество запросов прямо мапится в месячный счёт. Каждый запрос несёт ещё ~500–800 байт HTTP-заголовков, что раздувает суммарный трафик при коротких сегментах.

Обратная сторона.

Задержка переключения качества ≥ segment_duration
При 2 с: минимум 2 с на ответ на изменение пропускной способности
При 4 с: минимум 4 с
При 6 с: минимум 6 с

Задержка старта ≥ segment_duration × buffer_segments
При 2 с × 3 сегмента до старта: 6 с старт
При 4 с × 3 сегмента до старта: 12 с старт
При 6 с × 3 сегмента до старта: 18 с старт

Плеер должен забуферизовать достаточно сегментов, чтобы пережить короткий провал сети, прежде чем начнёт воспроизведение. Три сегмента – типичный минимум. Значит, 6-секундный сегмент с 3 сегментами на старт даёт 18 секунд time-to-first-frame в худшем случае – поэтому VOD-платформы для мобильных пользователей на нестабильных сетях обычно сводятся к 4 секундам, а live-платформы под спорт – к 2 секундам.

Для low-latency-live сегмент режут на partial-сегменты (LL-HLS) или чанки (LL-DASH / CMAF), каждый длиной 200–333 мс. Полный сегмент по-прежнему присутствует в манифесте для клиентов, не понимающих LL-HLS, но LL-aware клиент подписывается на добавления partial-сегментов по мере их появления. См. LL-HLS подробный разбор и LL-DASH и CMAF-chunked на практике для механики протоколов.

Контейнеры: ISO BMFF, fMP4 и почему MPEG-TS угасает

Контейнер – это файловый формат, оборачивающий кодированные сэмплы плюс метаданные, нужные плееру для декодирования и тайминга. В 2026 для упаковки в стриминге имеют значение два семейства.

Fragmented MP4 (fMP4), он же ISO Base Media File Format (ISO/IEC 14496-12) или ISO BMFF, – это дефолтный контейнер почти для всего нового. Fragmented-MP4-файл начинается с initialization-сегмента – ftyp (file-type box) и moov (movie box, держит codec config) – за которым идёт сколько угодно пар moof/mdat (фрагменты). Сегментные файлы, которые пишут Shaka Packager, Bento4 или любой CMAF-aware пакетайзер, – это fMP4-файлы. CMAF – это подмножество fMP4 плюс дополнительные ограничения, обеспечивающие совместимость между платформами.

MPEG-2 Transport Stream (MPEG-TS или .ts) – более старый контейнер, изначально проектировавшийся для спутникового и кабельного вещания. До 2016 года HLS был только MPEG-TS – спецификация HLS требовала .ts сегментов. Apple добавил fMP4 в HLS с iOS 10 (июнь 2016), а HEVC поверх HLS требует fMP4 (MPEG-TS не может нести HEVC по спецификации HLS). DASH в основных профилях никогда MPEG-TS не поддерживал; DASH всегда был fMP4.

Почему это важно для пакетайзера? Потому что некоторые legacy-парки устройств всё ещё не умеют декодировать fMP4 HLS – старые смарт-ТВ, Apple TV на tvOS 9, отдельные приставки. Пакетайзер, обслуживающий эти парки, должен выдавать и MPEG-TS-, и fMP4-варианты, удваивая хранилище. Реальность 2026 – этот набор устройств достаточно мал, чтобы большинство платформ совсем выкинули MPEG-TS и пользовались только CMAF-fMP4, оставив MPEG-TS контрибьюшен-стороне пайплайна (RIST, SRT), где его mux-структура действительно полезна.

Вторая причина победы fMP4: один и тот же fMP4-сегмент может быть прописан в HLS-манифесте и в DASH-манифесте. С MPEG-TS HLS-поток и DASH-поток одного контента приходилось упаковывать отдельно. С fMP4 – и особенно с CMAF, который ограничивает fMP4 достаточно, чтобы и Apple, и DASH-IF согласились с общим подмножеством – один набор байт обслуживает оба. Хранилище уполовинивается; CDN-cache-hit примерно удваивается.

CMAF: контейнер, объединивший HLS и DASH

Common Media Application Format (CMAF), стандартизированный как ISO/IEC 23000-19 в 2018 году с вторым изданием 2020 года, – это формат, закончивший десятилетие дублирующихся упаковочных пайплайнов. CMAF определяет две вещи: строгое подмножество fMP4, которому обязаны следовать все CMAF-совместимые инструменты и плееры, и каталог медиа-профилей (CMAF-AVC, CMAF-HEVC, CMAF-AV1), фиксирующий выбор кодека и битстрим-формата.

Самое важное следствие CMAF для инженера упаковки: один CMAF-сегмент может быть адресован и HLS-плейлистом, и DASH MPD. Тот же файл .m4s на диске виден как #EXT-X-MAP + #EXTINF-строки в HLS-плейлисте и как ссылка в <SegmentTemplate> DASH MPD. Два манифеста, один набор байт.

Для OTT-платформы с тысячей тайтлов это сразу уполовинивает хранилище. Для CDN – удваивает фактическую кеш-эффективность: зритель на iOS (HLS) и зритель на смарт-ТВ (DASH) греют один и тот же кеш-объект на edge, а не два разных.

CMAF также ограничивает историю шифрования (см. Common Encryption ниже). Все CMAF-conformant пакетайзеры и плееры поддерживают AES-CBC pattern схему cbcs – единственный режим Common Encryption, который все три крупные DRM (Widevine, PlayReady, FairPlay) обрабатывают в текущих релизах. С CMAF + cbcs один зашифрованный сегмент расшифровывается любой из трёх DRM при наличии правильной лицензии – впервые настоящий «encrypt once, deliver to all».

CMAF разобран отдельно: CMAF – формат упаковки, объединивший HLS и DASH. Для этой статьи итог: дефолт упаковки 2026 – это CMAF, точка, если только у вас нет явной причины поддерживать legacy MPEG-TS или non-CMAF DASH-вариант для конкретного класса устройств.

Манифесты: HLS-плейлисты и DASH MPD

Манифест – это текстовый файл, который плеер тянет первым. Он сообщает плееру две вещи: какие рендиции существуют (multivariant playlist в HLS, MPD в DASH), и какие URL сегментов составляют каждую рендицию (media playlists в HLS, <SegmentTemplate> или <SegmentTimeline> в DASH).

HLS multivariant playlist – небольшой текстовый файл, начинающийся с #EXTM3U. Каждая рендиция – одна строка #EXT-X-STREAM-INF (bandwidth, resolution, codec), за которой следует URL её media-плейлиста. Минимальный multivariant-плейлист для трёхступенчатой 1080p/720p/480p лесенки – 12 строк текста. Apple HLS Authoring Specification (ревизия 2025-09) задаёт рекомендуемые формы и теги. Сам протокол перевыпускается как RFC 8216bis (последний драфт draft-pantos-hls-rfc8216bis-22, 2026), который заменит RFC 8216 после финализации.

HLS media playlist описывает сегменты одной рендиции. Открывается #EXTM3U, #EXT-X-VERSION:7, #EXT-X-TARGETDURATION:4, затем для fMP4-рендиции #EXT-X-MAP:URI="init.mp4" (initialization-сегмент), и список пар #EXTINF:4.0 + URL-сегмента. Двухчасовой фильм при 4-секундных сегментах – это 1 800 строк сегментов.

DASH MPD (Media Presentation Description) – XML-файл. Корень – <MPD>, внутри один или несколько блоков <Period> (Period – связный отрезок времени, обычно весь VOD или live-окно). Внутри Period – по одному <AdaptationSet> на тип медиа (один на видео, один на аудио, по одному на язык субтитров). Внутри AdaptationSet – по одному <Representation> на ступень качества. Внутри Representation ровно один из <BaseURL>, <SegmentBase>, <SegmentList> или <SegmentTemplate> описывает, как адресовать сегменты. Стандарт ISO/IEC 23009-1:2022 (пятое издание) определяет схему; DASH Industry Forum (DASH-IF) публикует implementation guidelines, ограничивающие комбинации на практике.

Три способа адресации сегментов в DASH имеют значение для упаковки.

• <SegmentBase> – для single-segment representations: вся рендиция – один большой fMP4, адресация фрагментов внутри идёт через byte-range-запросы. Полезно для VOD, когда нужно минимизировать число HTTP-запросов; используется редко.
• <SegmentList> – явный список URL сегментов. Пакетайзер пишет каждый URL в манифест. Многословно, но однозначно; предпочитается при нерегулярной длительности сегментов.
• <SegmentTemplate> с плейсхолдером $Number$ или $Time$ – дефолт 2026. Пакетайзер пишет одну template-строку, например media="segment-$Number$.m4s", и либо <SegmentTimeline> (явные start-time и duration на сегмент), либо атрибут duration (для регулярных сегментов). Плеер вычисляет URL-ы на лету. Самый кеш-дружелюбный подход.

Для live пакетайзер комбинирует <SegmentTemplate> с <SegmentTimeline> – таймлайн растёт по мере появления новых сегментов, плеер периодически опрашивает MPD, чтобы узнать о них.

<!-- Минимальный DASH MPD для одной live-видео-рендиции через SegmentTemplate -->
<MPD type="dynamic" availabilityStartTime="2026-05-23T12:00:00Z" minBufferTime="PT4S">
  <Period>
    <AdaptationSet contentType="video" mimeType="video/mp4" codecs="avc1.640028">
      <Representation id="v1" bandwidth="3000000" width="1280" height="720">
        <SegmentTemplate timescale="1000" initialization="init-$RepresentationID$.m4s"
                         media="seg-$RepresentationID$-$Number$.m4s" startNumber="1">
          <SegmentTimeline>
            <S t="0" d="4000" r="20"/>  <!-- 20 сегментов по 4000 мс, начиная с t=0 -->
          </SegmentTimeline>
        </SegmentTemplate>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Два манифеста ссылаются на одни и те же fMP4-сегменты, когда workflow – CMAF. В этом и весь смысл CMAF.

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

Common Encryption: зашифруй один раз, расшифровывай везде

Если контент платный – серия Netflix, оплаченный курс, live pay-per-view – пакетайзер шифрует каждый сегмент content-ключом, а сервер лицензий DRM выдаёт соответствующий decryption-ключ авторизованным плеерам. Технический контракт между пакетайзером и плеером – это Common Encryption (CENC), стандартизированный как ISO/IEC 23001-7 (третье издание 2016, четвёртое 2023).

CENC определяет четыре схемы; в production 2026 имеют значение только две.

• Схема cenc – AES-128 в режиме CTR (counter), применяется к полным sample-данным. Изначально единственный режим, поддерживавшийся Widevine и PlayReady.
• Схема cbcs – AES-128 в режиме CBC (cipher block chaining), применяется по паттерну 1:9 (зашифровать один 16-байтовый блок, пропустить девять). Разработана как эффективная для аппаратных декодеров. Единственный режим, поддерживавшийся Apple FairPlay.

Бо́льшую часть 2010-х cbcs был «только Apple», а cenc – «только Widevine/PlayReady». Платформам приходилось шифровать дважды – раз cenc для DASH/Widevine/PlayReady, раз cbcs для HLS/FairPlay – и хранить обе копии. Конвергенция случилась в два шага. Google добавил cbcs в Widevine в 2017. Microsoft добавил cbcs в PlayReady 4.0 в 2018. К 2020 все три крупные DRM расшифровывали cbcs чисто, и индустрия повернулась к single-encryption workflow.

Дефолт 2026 года – cbcs-шифрование CMAF-сегментов, индексируемых и HLS-, и DASH-манифестами. Один зашифрованный файл .m4s расшифруется на iOS (FairPlay), на Android и в Chrome (Widevine), на Edge и Xbox (PlayReady), при наличии правильного ключа. Сам ключ приходит с multi-DRM лицензионного сервера (BuyDRM, EZDRM, castLabs, Axinom, AWS Elemental MediaTailor, Mux Video DRM, Bitmovin), выдающего FairPlay-, Widevine- и PlayReady-лицензии под одним content-ключом.

Одна оговорка. Если целевая аудитория включает Android-устройства старше Android 7.0 (август 2016), нужен cenc, а не cbcs – Android добавил поддержку cbcs в media-фреймворк в 7.0. В 2026 году доля pre-Android-7.0 устройств в мире ниже 0,5%; trade-off почти всегда – выкинуть эти устройства и выпускать только cbcs.

Шаг пакетайзера короток. Shaka Packager, Bento4, AWS MediaPackage, Unified Origin, Wowza и GPAC поддерживают обе схемы через один флаг командной строки. Конфигурация лицензионного сервера – отдельная длинная история, см. DRM 101: почему три системы и зачем выпускать все три и отдельную статью Common Encryption (CENC) подробно.

Рынок пакетайзеров: open source

Два open-source пакетайзера доминируют. Оба – командно-строчные утилиты, оба встраиваются как библиотеки.

Shaka Packager (разработан командой Google Widevine, MIT-лицензия, github.com/shaka-project/shaka-packager) – де-факто референс. Последний стабильный релиз v3.7.2 (апрель 2026). Написан на C++. Поддерживает HLS, DASH, шифрование cenc и cbcs, интеграцию с лицензионными серверами Widevine, PlayReady и FairPlay, CMAF-выход, live и VOD. CLI у Shaka Packager строгий и консистентный – один stream-аргумент на рендицию, один флаг на упаковочный концепт.

Минимальный вызов Shaka Packager, который превращает видео- и аудио-mezzanine в CMAF HLS+DASH презентацию с cbcs-шифрованием:

packager \
  'in=video_720p.mp4,stream=video,init_segment=v720/init.mp4,segment_template=v720/$Number$.m4s,playlist_name=v720.m3u8' \
  'in=audio.m4a,stream=audio,init_segment=a/init.mp4,segment_template=a/$Number$.m4s,playlist_name=a.m3u8' \
  --hls_master_playlist_output master.m3u8 \
  --mpd_output stream.mpd \
  --protection_scheme cbcs \
  --enable_raw_key_encryption \
  --keys label=video:key_id=<32-hex>:key=<32-hex>,label=audio:key_id=<32-hex>:key=<32-hex>

На выходе – дерево директорий с fMP4 init-сегментами и $Number$.m4s media-сегментами, плюс HLS multivariant playlist (master.m3u8), per-rendition media-плейлисты HLS и DASH MPD (stream.mpd). Каждый сегмент зашифрован под per-track ключ. Multi-DRM лицензионный сервер выдаёт FairPlay-, Widevine- и PlayReady-лицензии под переданные key ID.

Bento4 (Axiomatic Systems, GPL-лицензия для open-source ядра, отдельная коммерческая лицензия SDK, bento4.com) – старше из двух и до сих пор массово используется в production. Высокоуровневые упаковочные инструменты – mp4dash для DASH и mp4hls для HLS – это Python-обёртки над низкоуровневыми C++ бинарниками (mp4fragment, mp4encrypt, mp42hls).

Типичный запуск Bento4 для DASH с одним видео-mezzanine на ступень:

mp4dash --output-dir=dash/ \
        --hls \
        --encryption-cenc-scheme=cbcs \
        --encryption-key=<key_id_hex>:<key_hex> \
        video_360p.mp4 video_720p.mp4 video_1080p.mp4 audio.m4a

Флаг --hls говорит mp4dash также выдать HLS multivariant playlist, ссылающийся на те же fMP4-сегменты, что и DASH MPD, – это CMAF-стиль двойного выхода у Bento4. Сегменты лежат в пронумерованных поддиректориях под dash/; stream.mpd и master.m3u8 – на верхнем уровне.

Анализ Motion Spell (компания за GPAC) от 2024 года сравнил три open-source пакетайзера (Shaka, Bento4, GPAC) на CMAF VOD-нагрузке. Главный вывод: GPAC упаковал 90-минутный фильм примерно в 3 раза быстрее Shaka Packager и в 5 раз быстрее Bento4 на одном железе, и GPAC оказался единственным, кто выдал spec-conformant CMAF без ручных правок для двух тестовых входов. Shaka остаётся выбором по умолчанию для команд, ценящих размер сообщества и поддержку Google; Bento4 – для команд, уже использующих mp4-инструменты в пайплайнах; GPAC – для команд, которым нужна сырая производительность или контроль CMAF-чанков.

Encore Packager от Eyevinn (github.com/Eyevinn/encore-packager) – высокоуровневый сервис-обёртка вокруг Shaka Packager, обновлена в январе 2026. Это не отдельный упаковочный движок – под капотом вызывает Shaka – но даёт managed pipeline-style API, удобный для CI/CD-driven медиа-workflow.

Рынок пакетайзеров: коммерческие

Четыре коммерческих пакетайзера / managed-сервиса упаковки покрывают большую часть non-open-source production.

Unified Origin (CodeShop, unified-streaming.com) – software-only origin, выполняющий just-in-time упаковку из небольшого набора исходных fMP4-файлов («Unified» source-файлы – сами fragmented MP4 с внутренним индексом). Unified Origin держит лесенку как N fMP4-файлов на диске и синтезирует HLS, DASH, MSS или HDS манифесты и сегменты на каждый запрос плеера, в любой комбинации схем шифрования. Коммерческое преимущество – операционное: один формат на диске, любой формат в эфире, с полным multi-DRM на момент запроса.

AWS Elemental MediaPackage – managed-сервис упаковки AWS. Принимает один или несколько fMP4-, HLS- или DASH-входов из MediaLive (live-энкодер AWS), упаковывает в HLS, DASH, CMAF или Microsoft Smooth Streaming, накладывает CENC-шифрование через AWS SPEKE для любой из трёх крупных DRM, и отдаёт через CloudFront. Just-in-time на egress; сегменты не пишутся на S3 в финальной форме. Биллинг – за GB egress плюс per-second выполнения, и это большая часть причины, почему компании, переваливающие за пару сотен конкурентных live-каналов, в итоге уходят на self-managed origin.

Wowza Streaming Engine – давно работающий Java-стриминговый сервер, делающий упаковку плюс ingest плюс origin плюс live-транскод в одном процессе. Wowza поставляет свой JIT-упаковочный пайплайн для HLS и DASH, интегрированный с multi-DRM партнёрами. Роль Wowza в 2026 – в основном enterprise on-premise и edge-деплои, где AWS не вариант (регулируемые среды, broadcast plant, спутниковые уплинк-сайты).

Norsk (id3as, norsk.video) – TypeScript SDK и runtime для сборки live стриминговых пайплайнов, включая упаковку. Это не одноразовый CLI вроде Shaka – это программируемый runtime, где разработчик связывает узлы: ingest, transcode, package, encrypt, output. USP Norsk – поддержка LL-HLS / LL-DASH и возможность выразить сложные live workflow (мультиязычное аудио, real-time графика, динамическая вставка рекламы) кодом, а не конфигом.

Паттерн в коммерческом рынке – value-added-services поверх, а не принципиально другая упаковка. Под капотом большинство коммерческих пакетайзеров либо встраивают Shaka, либо реализуют те же ISO-стандарты напрямую; дифференциатор – managed-сервис-поверхность.

Static vs Just-in-Time: две формы развёртывания

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

Статическая упаковка один раз пишет каждый сегмент на диск на ингесте. 90-минутный фильм, упакованный в шестиступенчатую лесенку, 4-секундные сегменты, аудио на трёх языках, в HLS-MPEG-TS, HLS-fMP4 и DASH-fMP4 – это примерно 24 000 сегментных файлов на диске на тайтл. На тысяче тайтлов – 24 миллиона файлов. Пакетайзер запускается один раз на тайтл (или один раз на добавление языка), потом сегменты живут на origin вечно. CDN-cache-hit rate отличный, потому что URL каждого файла стабилен между зрителями; ограничение – стоимость хранилища.

Just-in-time упаковка (JIT) хранит по одному fMP4-исходнику на рендицию – шесть файлов на шестиступенчатую лесенку – и синтезирует сегментные файлы и записи манифеста на каждый запрос плеера. Пакетайзер запускается на каждый запрос. Каталог в тысячу тайтлов хранит 6 000 source-файлов (по шесть на тайтл) вместо 24 миллионов сегментных файлов; это примерно ×4 000 экономии на хранилище.

Trade-off – origin-compute. JIT-origin крутит упаковочную логику на горячем пути каждого запроса плеера, каждого fetch'а сегмента. Современные JIT-origin'ы (Unified Origin, AWS MediaPackage, MediaPackage-on-Lambda варианты) делают это эффективно – суб-миллисекунды на сегмент – но compute-счёт замещает часть того, что больше не платит storage-счёт.

История с кешем тоже другая. При статической упаковке URL сегментов стабильны навсегда; CDN кеширует каждый сегмент один раз и отдаёт миллиарды раз из кеша. При JIT URL сегментов тоже стабильны (JIT-origin генерирует детерминированные URL из source-файлов и параметров манифеста), так что CDN-cache-hit rate схожий – но origin вынужден защищаться агрессивным front-cache, потому что cache miss теперь триггерит упаковочную работу, а не просто чтение с диска. JIT-origin'ы почти всегда деплоятся за origin shield.

Точка перелома 2026, где JIT окупается, примерно такова:

• Под 100 тайтлов: статика обычно выигрывает по простоте. Стоимость хранилища нерелевантна; вы экономите на JIT-origin лицензировании/операциях.
• 100–1000 тайтлов: зависит от churn каталога. Если тайтлы часто добавляются/удаляются – JIT выигрывает, потому что статика требует перепаковки на каждое новое устройство/ротацию шифрования. Если каталог стабильный – статика выигрывает на простоте кеша.
• Больше 1000 тайтлов: JIT почти всегда выигрывает на хранилище. Редкие исключения – платформы с экстремальной оптимизацией cache-hit-rate (Netflix, YouTube), строящие собственный origin-tier и амортизирующие хранилище по флоту.

Это каноническая разбивка; более глубокое сравнение – в следующей статье, JIT-упаковка vs пре-пакетированный origin.

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

Рабочий пример: стоимость статической упаковки для каталога в 1 000 тайтлов

Чтобы trade-off хранилища стал конкретным, вот арифметика для среднего OTT, упаковывающего 1 000 фильмов по 90 минут с шестиступенчатой лесенкой 1080p/720p/540p/360p/240p/144p, 4-секундными CMAF-сегментами, аудио на трёх языках, шифрованного cbcs.

Сегментов на рендицию на тайтл:

90 минут × 60 секунд / 4 с на сегмент = 1 350 видео-сегментов на рендицию на тайтл

Всего видео-сегментных файлов на тайтл:

1 350 × 6 видео-рендиций = 8 100 видео-сегментов на тайтл

Аудио-сегментов на тайтл:

1 350 × 3 аудио-рендиции = 4 050 аудио-сегментов на тайтл

Init-сегментов на тайтл:

6 видео + 3 аудио = 9 init-сегментов на тайтл

Всего сегментных файлов на тайтл:

8 100 + 4 050 + 9 = 12 159 сегментных файлов на тайтл

По каталогу из 1000 тайтлов:

12 159 × 1 000 = 12,159 миллиона сегментных файлов

Средний размер сегмента, при H.264 c битрейтами 5/3/1,5/0,8/0,4/0,2 Mbps для видео (с весом ниже для нижних ступеней по среднему паттерну просмотра) и 128 kbps аудио:

Видео-байты на сегмент (среднее 720p при 3 Mbps): 3 Mbps × 4 с / 8 = 1,5 MB на сегмент
Аудио-байты на сегмент: 128 kbps × 4 с / 8 = 64 KB на сегмент

Всего хранилища:

Видео: 8 100 сегментов × 1 000 тайтлов × ~1 MB ср. = ~8 TB
Аудио: 4 050 сегментов × 1 000 тайтлов × 64 KB = ~260 GB
Итого: ~8,3 TB на диске

По прайсу S3 Standard (май 2026, US-East-1): около $0,023/GB-месяц = $190/месяц за статически упакованный каталог. Это стоимость статического workflow.

JIT-workflow хранит только 6 видео + 3 аудио = 9 source fMP4-файлов на тайтл, каждый держит полный 90-минутный энкод одного битрейта. Размер source-файлов:

720p 3 Mbps × 90 минут = ~2 GB на файл
Всего на тайтл: ~6 GB по шести видео-ступеням + ~80 MB аудио = ~6,1 GB
1 000 тайтлов × 6,1 GB = ~6 TB

Хранилище JIT в этом примере фактически сопоставимо, потому что source-файлы хранят те же суммарные байты. Выигрыш JIT проявляется, когда платформе нужен другой упаковочный выход – новый device-профиль (Android TV с другим поддерживаемым набором кодеков), новая ротация схемы шифрования, новая аудио-дорожка. Статический workflow перепакует 12 миллионов файлов; JIT-workflow повторно запустит упаковочную логику на момент запроса и не сохранит ничего нового.

Вот рычаг JIT в одном предложении: JIT отвязывает стоимость добавления упаковочного выхода от размера каталога.

Частая ошибка: рассинхрон keyframe и границы сегмента

Самый частый баг упаковки – мы видели его в примерно половине стриминговых кодовых баз, которые аудировали – это энкод с keyframe-интервалом, не делящимся на длительность сегмента. Пакетайзер, настроенный на 4-секундные сегменты, накормленный энкодом с 2,5-секундным keyframe-интервалом, выдаёт часть сегментов, начинающихся с keyframe, и часть – нет. Сегменты-без-keyframe технически валидны как fMP4, но плеер может декодировать их, только переиграв предыдущие сегменты – что аннулирует смысл адресуемых сегментов.

Хуже того, когда плеер меняет рендицию (скажем, с 1080p на 720p посреди потока), переключение может приземлиться только на границе сегмента, которая одновременно – граница keyframe в новой рендиции. Рассинхрон keyframe-интервалов между ступенями лесенки даёт невидимые задержки переключения – плеер ждёт ещё один лишний сегмент, прежде чем новая рендиция станет декодируемой.

Исправление – выставить во всех энкодерах лесенки один и тот же closed GOP, с длиной GOP, равной длительности сегмента. Для 4-секундных сегментов при 30 fps: GOP-size = 120 кадров. При 25 fps: GOP-size = 100. При 60 fps: GOP-size = 240. Все энкодеры, все рендиции, идентично. Shaka Packager предупредит, если детектирует рассинхрон; Bento4 – нет, и баг всплывёт только когда в логе плеера у зрителя появится stall при переключении.

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

Мы выпустили упаковочные пайплайны для OTT-платформ, live e-learning систем, телемедицинских платформ с paid-content уровнями и архивов видеонаблюдения, раздающих записи следователям между отделами полиции. Через все эти проекты проходит один и тот же паттерн: упаковочный слой впитывает большую часть операционных решений, идущих после запуска продукта – каждое новое устройство, каждая новая DRM-ротация, каждое новое требование низкой задержки приземляется сначала на пакетайзер. Мы по умолчанию ставим CMAF + cbcs + JIT-origin для каталогов крупнее пары сотен тайтлов и static Shaka-packaged CMAF для маленьких live-event платформ, где простота побеждает гибкость. Полная картина кода и инфраструктуры таких стеков – в соответствующих кейсах на нашем сайте.

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

• Пакетайзер фрагментирует кодированные mezzanine, пишет манифесты HLS или DASH (или оба) и опционально шифрует сегменты Common Encryption.
• Дефолтный контейнер 2026 – CMAF (ограниченный fMP4), на который ссылаются и HLS, и DASH манифесты по одним и тем же байтам на диске.
• Дефолтное шифрование 2026 – cbcs; все три крупные DRM (Widevine, PlayReady, FairPlay) расшифровывают его при наличии правильной лицензии.
• Shaka Packager и Bento4 – доминирующие open-source выборы; Unified Origin, AWS MediaPackage, Wowza и Norsk возглавляют коммерческий рынок.
• Статика пишет каждый сегмент на диск; JIT синтезирует на запрос. JIT выигрывает после ~1 000 тайтлов или при частых сменах устройств/DRM.
• Самый частый баг упаковки – границы сегментов не совпадают с keyframe-интервалом энкодера. Чинить нужно энкодер, не пакетайзер.

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

• CMAF – формат упаковки, объединивший HLS и DASH – глубокая картина контейнера, делающего возможным «один сегмент – два манифеста».
• JIT-упаковка vs пре-пакетированный origin – когда JIT окупается, а когда статика – правильный выбор.
• DRM 101: почему три системы и зачем выпускать все три – сторона лицензионного сервера в истории шифрования.