Bento4 позволяет разбирать структуру MP4, получать сведения о дорожках и кодеках, извлекать и заменять атомы, мультиплексировать элементарные потоки, создавать fragmented MP4, готовить сегменты и манифесты MPEG-DASH, HLS и CMAF, а также шифровать и расшифровывать совместимый медиаконтент с помощью набора консольных утилит.
Основной способ работы с Bento4 — последовательность небольших команд, каждая из которых решает отдельную задачу. Для диагностики используются mp4info и mp4dump, для точечного изменения контейнера — mp4edit и mp4extract, для подготовки потоковой раздачи — mp4fragment, mp4split, mp4dash и HLS-инструменты. Такой подход удобен, когда нужно не перекодировать изображение или звук, а работать с контейнером, таймингами, дорожками, сегментами и служебными данными ISO Base Media File Format.
Программа особенно полезна в цепочках подготовки видео для веб-плееров, CDN и DRM: можно проверить, фрагментирован ли исходный MP4, получить точную строку codecs, разбить fMP4 на init- и media-сегменты, собрать адаптивную презентацию из нескольких вариантов качества и добавить сигнальные данные Common Encryption. При этом Bento4 не заменяет видеокодер или монтажный редактор: разрешение, частоту кадров, битрейт и сам видеопоток обычно подготавливают заранее, а Bento4 выполняет упаковку, анализ и преобразования без перекодирования там, где это допускает конкретная утилита.
Скачать Bento4
- Конвертация видео
- Сжатие файлов
- Просто для новичков
- Только командная строка
- Нет видеотранскодинга
- Высокий порог входа
Что входит в Bento4 и как разделены задачи
Bento4 состоит из C++-библиотеки и набора инструментов командной строки. Для практической работы чаще всего достаточно каталога bin: там находятся исполняемые файлы и скрипты, которые можно вызывать напрямую или добавить в переменную PATH. Разделение по утилитам принципиально: вместо единого окна с десятками панелей используется набор специализированных команд. Это уменьшает число скрытых действий — по имени утилиты и параметрам обычно понятно, что именно будет сделано с файлом.
Наиболее востребованные инструменты можно условно разбить на несколько групп. Первая группа анализирует содержимое: mp4info показывает сведения о файле, фильме, дорожках, длительности, sample descriptions и строках кодеков, а mp4dump выводит полное дерево box/atom. Вторая группа редактирует структуру: mp4extract извлекает выбранный атом, mp4edit вставляет, удаляет или заменяет атомы, mp4tag работает с тегами, а mp4compact преобразует таблицы размеров sample из stsz в более компактные stz2, когда это возможно.
Третья группа занимается медиапотоками. mp4mux собирает MP4 из H.264/AVC, H.265/HEVC, AAC, AC-3, EC-3, AC-4 или дорожек других MP4. Обратные по направлению утилиты mp42aac, mp42avc и mp42hevc извлекают элементарные потоки из контейнера. mp42ts переводит содержимое MP4 в MPEG-2 Transport Stream.
Четвёртая группа предназначена для адаптивного стриминга. mp4fragment превращает обычный MP4 в fragmented MP4, mp4split раскладывает fMP4 на отдельный initialization segment и медиасегменты, mp4dash формирует MPEG-DASH и при необходимости параллельно HLS на fMP4-сегментах. Для традиционного HLS с MPEG-2 TS предназначены высокоуровневый mp4hls и низкоуровневый mp42hls. Для сценариев защиты есть mp4encrypt, mp4decrypt и параметры шифрования в mp4dash.
| Задача | Основной инструмент | Что получается |
|---|---|---|
| Сводная информация о MP4 | mp4info | Дорожки, длительность, кодеки, sample descriptions |
| Дерево ISO BMFF | mp4dump | Иерархия ftyp, moov, trak, moof, mdat и вложенных box |
| Извлечение или замена box | mp4extract, mp4edit | Отдельный атом либо изменённый MP4 |
| Fragmented MP4 | mp4fragment | MP4 с фрагментами moof/mdat |
| DASH и fMP4-HLS | mp4dash | MPD, HLS-плейлисты и общие сегменты |
| Традиционный HLS | mp4hls, mp42hls | Master/media playlists и TS/packed-audio сегменты |
| CENC-шифрование | mp4encrypt, mp4dash | Защищённый MP4 или защищённая streaming-презентация |
Подготовка командной строки и организация проекта
Для разовой операции можно перейти в каталог с исполняемыми файлами Bento4 и вызвать команду оттуда. Для постоянной работы удобнее добавить каталог bin в PATH, чтобы команды находились из любого рабочего каталога. Это особенно полезно в пакетных сценариях: имена входных и выходных файлов можно собирать в shell-, PowerShell- или Python-скрипте, а Bento4 использовать как набор предсказуемых стадий конвейера.
У высокоуровневых скриптов вроде mp4dash есть дополнительная зависимость от Python. В официальной документации для текущего способа запуска указан Python 3.7 или новее. В готовых SDK команда mp4dash служит оболочкой над скриптом mp4-dash.py; на Windows запускатель ожидает команду python, на других системах — python3. Если низкоуровневые бинарные утилиты работают, а mp4dash завершается ещё до анализа файлов, первым делом стоит проверить именно доступность Python и путь к служебным executable.
Практичная структура каталогов отделяет исходники от результатов. Например, в source можно хранить мастер-файлы, в fragmented — fMP4 после mp4fragment, а в package — MPD, плейлисты и сегменты. Это важно потому, что опция --force у mp4dash разрешает запись в уже существующую выходную папку. При автоматизации безопаснее создавать новый каталог на каждую сборку, чем без необходимости использовать принудительную запись поверх старого набора сегментов.
mp4info source.mp4
mp4fragment source.mp4 fragmented.mp4
mp4dash --output-dir=package fragmented.mp4
Эта трёхкомандная цепочка хорошо показывает границы ответственности. Первая команда ничего не меняет и только диагностирует файл. Вторая перестраивает MP4 в фрагментированную форму. Третья создаёт streaming-структуру. Если нужен только анализ атомов, второй и третий шаги не требуются; если уже имеется корректный fragmented MP4, стадия фрагментации тоже лишняя.
mp4info: проверка файла, дорожек и строк кодеков

mp4info — первый инструмент, с которого разумно начинать неизвестный MP4. В стандартном текстовом выводе есть блок File с major brand, minor version, compatible brands и признаком fast start, блок Movie с длительностью, timescale и состоянием fragments, затем сведения по каждой дорожке. Для видео выводятся, среди прочего, display width, display height, вычисленная частота кадров и параметры sample description. Для аудио видны тип кодирования, sample rate, число каналов и связанные сведения конкретного кодека.
Особенно полезны строки Codecs String. Для H.264 можно получить значение вида avc1.640028, для AAC — mp4a.40.2. Такие идентификаторы применяются в MIME-описаниях Media Source Extensions, в манифестах и при диагностике несовместимости плеера. Здесь важно не подменять вывод предположением по расширению файла: два MP4 могут содержать совершенно разные кодеки, профили и уровни.
Базовый вызов минимален:
mp4info input.mp4
Опция --verbose раскрывает дополнительную информацию, когда она доступна. --format json переключает вывод на JSON и заметно упрощает машинный разбор. --show-layout показывает раскладку sample, --show-samples добавляет детали отдельных sample, а --show-sample-data позволяет увидеть данные sample. Последняя опция резко увеличивает объём вывода и нужна скорее при низкоуровневой диагностике, чем при обычной проверке ролика. --fast, напротив, пропускает часть медленно вычисляемых подробностей.
На стадии подготовки DASH полезно смотреть на строку fragments. Значение no означает, что перед стандартным сценарием с mp4dash файл следует пропустить через mp4fragment. Значение yes подтверждает фрагментированную структуру, но не гарантирует, что все представления идеально выровнены по точкам переключения: для ABR всё равно нужно учитывать структуру GOP и синхронность вариантов качества.
При проверке защищённого файла mp4info --verbose помогает увидеть protected sample description, тип схемы и KID, если соответствующие данные присутствуют. Это диагностический источник для сверки идентификатора ключа, но сам по себе вывод KID не предоставляет ключ дешифрования. Bento4 работает с теми ключами, которые пользователь передаёт утилите, и не получает их из лицензирующего сервиса автоматически.
Когда использовать JSON
JSON-вывод удобен в CI и массовой обработке. Например, можно прогнать сотни файлов, извлечь список дорожек, codec string и признак fragmentation, а затем отправлять только неподходящие файлы на дополнительную обработку. Это надёжнее, чем анализировать человекочитаемый текст регулярными выражениями, особенно когда интересуют вложенные характеристики sample description.
Как читать расхождение длительностей
Movie duration и duration отдельных дорожек не обязаны совпадать до последней единицы. Аудио и видео могут иметь разные timescale, разный шаг sample и небольшую разницу на границе. Наличие отличий само по себе не означает повреждение файла. Проблемой становится ситуация, когда одна дорожка значительно длиннее другой, обрывается или имеет некорректные timestamps; тогда перед упаковкой нужно разобраться, является ли это особенностью исходника или ошибкой предыдущего muxing.
mp4dump: дерево атомов и служебные данные
Если mp4info отвечает на вопрос что за медиадорожки находятся в файле, то mp4dump показывает, как устроен сам контейнер. Команда рекурсивно выводит ISO BMFF box/atom: верхнеуровневые ftyp, moov, mdat, а для fragmented MP4 также повторяющиеся moof и mdat. Внутри moov можно проследить trak, mdia, minf, stbl и таблицы sample; в защищённых потоках встречаются sinf, schm, schi, tenc и pssh.
mp4dump input.mp4
Уровень подробности задаётся --verbosity от 0 до 3. Низкие значения подходят для быстрой проверки дерева, высокие — когда нужно увидеть значения полей конкретного box. Формат --format json полезен для программного анализа структуры. В отличие от простого hex-viewer, mp4dump понимает семантику известных атомов и подписывает поля, поэтому поиск неправильного размера, не того типа sample description или отсутствующего box значительно упрощается.

Опция --track ID имеет отдельное назначение: она записывает данные выбранной дорожки в файл, причём каждый sample предваряется размером в 32-битном big-endian формате. К идентификатору дорожки можно добавить 128-битный ключ в hex и попросить инструмент попытаться расшифровать данные. Это низкоуровневый режим и не заменяет обычный mp4decrypt, когда требуется получить полноценный MP4.
При диагностике DRM mp4dump часто применяют для поиска pssh и default_KID. Здесь важно различать назначение полей. pssh содержит данные, предназначенные системе защиты, а KID является идентификатором ключа. Ни один из них не является самим контентным ключом. Если задача легитимно связана с тестовой или собственной DRM-инфраструктурой, эти значения помогают сверить упаковку с конфигурацией сервера лицензий.
Проверка fast start и расположения moov
Для progressive download критично расположение метаданных: moov обычно нужен до большого mdat, чтобы плеер мог начать разбор раньше полной загрузки. mp4info даёт удобный признак fast start, а mp4dump позволяет увидеть реальный порядок верхнеуровневых box. Bento4 не является универсальным ремонтом fast start одной кнопкой; при сложных случаях стоит работать с инструментом, специально перестраивающим interleaving/offsets, либо пересобрать контейнер корректным muxer.
Почему отдельный сегмент .m4s может не открываться в mp4info
Одиночный media segment обычно не содержит полного moov, потому что метаданные находятся в initialization segment. Поэтому команда, рассчитанная на самостоятельный MP4 movie, может сообщить, что movie не найден. Для анализа сегмента полезнее mp4dump: он покажет styp, moof, traf, trun и mdat без требования иметь полный movie header. Если нужно воспроизведение или высокоуровневый анализ, init segment и media segments должны рассматриваться как части одной презентации.
mp4extract и mp4edit: точечная работа с атомами
mp4extract извлекает выбранный box по пути. Синтаксис строится вокруг atom_path, входного и выходного файла. Например, если требуется сохранить пользовательские данные из moov/udta, путь задаётся явно. По умолчанию в выход попадает атом вместе с заголовком; параметр --payload-only оставляет только payload.
mp4extract moov/udta source.mp4 udta.atom
mp4extract --payload-only moov/udta source.mp4 udta.bin
Это полезно при сравнении двух файлов, переносе известного служебного блока, исследовании метаданных или подготовке собственного преобразования. Но извлечение атома и его механическая вставка в другой файл не гарантируют семантическую совместимость. Некоторые box содержат offsets, длительности, ссылки на дорожки или данные, связанные с конкретной структурой исходника. Для безопасной операции нужно понимать, независим ли переносимый атом от остального контейнера.
mp4edit принимает одну или несколько команд: --insert, --remove и --replace. Источником атома может быть файл, содержащий полный header и payload. Для UUID-box поддерживается форма с 32-символьным UUID и отдельным файлом payload. Позиция при вставке указывается дополнительным компонентом, когда важно место среди соседних атомов.
mp4edit --remove moov/udta input.mp4 without-udta.mp4
mp4edit --replace moov/udta:udta.atom input.mp4 replaced.mp4
Лучший способ избежать случайной порчи — работать с новым выходным файлом и затем сравнить его mp4dump/mp4info с исходником. Если после операции плеер перестал видеть дорожку или метаданные, нужно проверять не только наличие вставленного box, но и его размер, версию, flags, связь с родительским atom и корректность внутренних ссылок.
Перенос пользовательских данных и телеметрии
Некоторые камеры и устройства хранят телеметрию в специализированных дорожках или nested box, а не просто в moov/udta. Поэтому попытка перенести GPS копированием одного udta может дать файл, где формально atom присутствует, но прикладная программа не распознаёт данные. Перед переносом полезно сравнить деревья исходника и результата, определить, где именно находятся связанные sample tables и references, и только после этого выбирать mp4extract/mp4edit.
mp4tag: чтение и изменение метаданных
mp4tag предназначен для тегов, а не для произвольного дерева atom. Команда --show-tags выводит найденные теги, --list-symbols и --list-keys показывают встроенные символы и символические ключи. Для записи предусмотрены --set и --add, для удаления — --remove, для выгрузки значения — --extract.
Тип значения задаётся явно. S означает UTF-8 строку, LS — строку с трёхбуквенным кодом языка, I8, I16 и I32 — целые числа соответствующей разрядности, JPEG и GIF принимают имя файла изображения, B задаёт binary string, Z ссылается на встроенный символ. Такая типизация важна: metadata atom ожидает конкретное представление, и текст нельзя бездумно подставлять туда, где требуется integer или binary data.
Ключ может записываться как имя или как namespace/name. Если namespace опущен, используется meta. В документации отдельно указаны meta для iTunes-style metadata и dcf для OMA-DCF; также допустим пользовательский long-form namespace. При нескольких одноимённых ключах индекс указывается через #n, где нумерация начинается с нуля. Это полезно, например, при нескольких изображениях cover art.
Для медиаконвейера mp4tag хорош тем, что отделяет осмысленную правку тегов от низкоуровневого редактирования atom. Если задача сводится к названию, артисту, cover art или другому поддерживаемому метаданному, лучше использовать семантическую команду, а не собирать бинарный atom вручную.
mp4mux: сборка MP4 из элементарных потоков и дорожек
mp4mux мультиплексирует один или несколько потоков в MP4. Поддерживаются типы h264, h265, aac, ac3, ec3, ac4 и mp4. Для AAC ожидается ADTS, для H.264 и H.265 — соответствующие elementary streams. Если тип не указан, инструмент пытается определить его по расширению, но в автоматизированной схеме лучше задавать тип явно там, где возможна неоднозначность.
mp4mux --track h264:video.h264 --track aac:audio.aac output.mp4
Для HEVC доступны параметры frame_rate и format; формат может быть hev1 или hvc1. Также предусмотрены параметры Dolby Vision: dv_profile со значениями профиля 5, 8 или 9 и dv_bc для backward-compatibility ID, когда он обязателен. Подобные параметры стоит задавать только при наличии корректного исходного потока и понимании его профиля: простая запись метки не превращает обычный HEVC в Dolby Vision.
Общий параметр language позволяет назначить трёхбуквенный код ISO 639-2 конкретной дорожке. Когда источником служит другой MP4, тип mp4 поддерживает выбор track=audio, track=video или числового track ID. Это удобно при пересборке контейнера из выбранных дорожек без перекодирования.
Главное ограничение mp4mux — он не является кодером. Если подать неподдерживаемый или некорректный elementary stream, утилита не перекодирует его в подходящий H.264/HEVC/AAC. Сначала нужно получить валидный поток кодером или транскодером, затем использовать Bento4 для упаковки.
Частота кадров H.264 и H.265
При muxing raw elementary stream часть информации, привычно хранящейся в контейнере, приходится задавать или выводить из bitstream. Для H.265 mp4mux документирует параметр frame_rate с типичным значением по умолчанию 24.0. Если реальная частота отличается и тайминги не выводятся так, как ожидается, этот параметр нужно задать явно. Ошибка здесь проявится не обязательно как отказ команды: файл может создаться, но длительность и временная шкала окажутся неправильными.
mp42aac, mp42avc и mp42hevc: извлечение elementary stream
Три небольшие утилиты выполняют обратную по отношению к muxing операцию. mp42aac извлекает AAC, mp42avc — AVC/H.264, mp42hevc — HEVC/H.265. Базовый синтаксис одинаков: входной MP4 и выходной файл. Для простых однотипных файлов этого достаточно, когда требуется передать elementary stream в анализатор, декодер или другой muxer.
mp42aac input.mp4 audio.aac
mp42avc input.mp4 video.h264
mp42hevc input.mp4 video.h265
У каждой из этих команд предусмотрен параметр --key с 128-битным ключом в hex для совместимых защищённых входов. Это не универсальный механизм работы с любой DRM: успешность зависит от схемы и структуры конкретного файла. Для полноценного CENC-сценария обычно удобнее сначала применить mp4decrypt с KID/track ID и ключом, а затем извлекать поток из уже расшифрованного контейнера.
После извлечения исчезает контейнерная информация: отдельный H.264/H.265 bitstream не содержит MP4-тегов, chapter metadata и track-level language; AAC в ADTS также представляет только аудиопоток. Поэтому такой шаг подходит для низкоуровневой обработки, но не для архивирования всех свойств исходного файла.
mp4fragment: подготовка fragmented MP4

mp4fragment — ключевой этап перед современным DASH/fMP4-HLS, если на входе обычный MP4 без movie fragments. Утилита перестраивает файл так, чтобы медиаданные были разбиты на фрагменты с moof/mdat. Такой контейнер можно далее делить на initialization/media segments или передавать в mp4dash.
mp4fragment input.mp4 fragmented.mp4
По умолчанию длительность фрагментов выбирается автоматически. Опция --fragment-duration принимает миллисекунды и задаёт целевую длительность. Следует понимать слово целевая: видеофрагменты должны начинаться в допустимых sync points, поэтому фактическая граница зависит от структуры GOP. Если кодер расставил ключевые кадры редко или варианты ABR имеют несовпадающие GOP, одна только одинаковая цифра --fragment-duration не исправит выравнивание.
--track ограничивает обработку дорожкой по ID либо типом audio, video или subtitles. --trim подрезает избыток данных в более длинных дорожках. --index пересоздаёт segment index. --timescale меняет timescale; документация отдельно приводит 10000000 для совместимости со Smooth Streaming. Эти параметры нужны в специальных конвейерах и не должны назначаться механически для каждого файла.
Опция --tfdt-start задаёт первое значение timestamp в tfdt в секундах, --sequence-number-start — начальный номер последовательности сегмента. --no-tfdt отключает tfdt для старых клиентов Smooth Streaming, а --trun-version-zero заставляет писать trun версии 0 вместо версии 1. Эти флаги относятся к совместимости и структуре box; применять их без требования целевого проигрывателя не стоит.
Для open-GOP есть --force-i-frame-sync auto|all. Режим auto помечает все I-frame как sync samples только при обнаружении open-GOP, а all делает это безусловно. Такой параметр способен изменить трактовку точек случайного доступа, поэтому полезен при конкретной проблеме open-GOP, а не как общий ускоритель.
--copy-udta переносит moov/udta во фрагментированный результат. Если метаданные из этого контейнера важны downstream-системе, этот флаг стоит учитывать: стандартная фрагментация сосредоточена на медиаструктуре, и не вся пользовательская информация обязательно переносится так, как ожидает стороннее ПО.
Проверка результата
После фрагментации полезно снова выполнить mp4info и убедиться, что fragments: yes, а дорожки и их codec string остались ожидаемыми. Затем mp4dump должен показать последовательности moof/mdat. Если длительность заметно изменилась, пропала дорожка или язык, лучше остановить pipeline на этом этапе, а не продолжать упаковку в сотни сегментов.
mp4split: init segment и отдельные .m4s
mp4split принимает fragmented MP4 и раскладывает его на отдельные файлы. По умолчанию initialization segment называется init.mp4, а media segment формируется по шаблону, использующему 64-битные целые значения. Это низкоуровневый инструмент, когда манифест не нужен либо сегменты будут использоваться в собственном протоколе доставки.
--init-only выводит только init segment. --init-segment меняет его имя. --media-segment задаёт шаблон имени медиасегментов. --start-number определяет начальную нумерацию. Через --pattern-parameters выбираются параметры шаблона: I для track ID и N для номера сегмента.
Фильтрация выполняется --track-id, причём можно перечислить несколько ID через запятую, либо использовать сокращения --audio и --video. Это удобно, если один fragmented MP4 содержит несколько дорожек, а на выходе нужны раздельные последовательности.
В типичном DASH/HLS-пакете вручную вызывать mp4split не обязательно: высокоуровневый mp4dash сам организует структуру выходных файлов. mp4split полезнее при отладке, при разработке собственного packager/origin или когда требуется строго контролировать шаблон сегментов без генерации MPD.
mp4dash: создание MPEG-DASH из одного или нескольких представлений
mp4dash принимает один или несколько fragmented MP4 и строит полноценную MPEG-DASH presentation. Для каждого входа можно использовать stream selector в квадратных скобках, чтобы выбрать дорожку или переопределить её свойства. Один и тот же MP4 разрешается перечислять несколько раз, если селекторы выбирают разные потоки.
mp4dash --output-dir=package video-1080-frag.mp4 video-720-frag.mp4 audio-frag.mp4
--output-dir задаёт каталог результата, --mpd-name — имя MPD. --profiles выбирает один или несколько DASH-профилей: в качестве сокращений документированы live, on-demand и hbbtv-1.5. Выбор профиля должен соответствовать требованиям клиентской среды; нельзя считать, что слово live автоматически превращает статический VOD в прямую трансляцию.
--no-media позволяет сформировать только манифесты без копирования медиаданных. --rename-media включает шаблонные имена вместо базовых имён входов, --media-prefix задаёт префикс, --init-segment — имя initialization segment. --no-split не разделяет файл на отдельные segment files.
Для описания сегментов доступны разные схемы. --use-segment-list заставляет применять SegmentList вместо шаблонов. --use-segment-template-number-padding добавляет padding к номерам в URL/filename template. --use-segment-timeline формирует SegmentTimeline и требуется, когда длительности сегментов меняются. Для постоянного каденса шаблон проще, а при VFR, неравномерных границах или иных причинах неодинаковой длительности timeline точнее описывает фактические интервалы.
--min-buffer-time задаёт minimum buffer time в секундах. Параметр не является магической настройкой задержки: реальное поведение плеера зависит от MPD, размера сегментов, сети, ABR-логики и буферной политики клиента. Менять его разумно в контексте всего профиля доставки.
Stream selectors и выбор дорожек
Селекторы позволяют брать, например, французскую аудиодорожку из одного файла и видеодорожку из другого. Поддерживается выбор по type, language, track и другим свойствам. Язык можно переопределить, а --language-map переназначает код вроде und в конкретный язык, если исходник был размечен недостаточно точно.
mp4dash [type=audio,language=fra]audio-multi-frag.mp4 [type=video]video-frag.mp4
Для HLS-вывода у входов есть дополнительные свойства группирования: group, default/autoselect и characteristic. Они полезны при нескольких языках, альтернативном аудио и accessibility-вариантах. Нельзя полагаться только на порядок файлов: лучше задавать свойства явно, чтобы мастер-плейлист был устойчив к изменению списка входов.
Субтитры
mp4dash умеет включать один или несколько subtitle tracks. Поддерживаются субтитры в MP4 и отдельные файлы соответствующих семейств, включая IMSC1/TTML и WebVTT. Опция --subtitles включает обработку субтитров в пакете. 3GPP Timed Text в документации обозначен как неподдерживаемый для данного DASH-сценария, поэтому наличие текстовой дорожки в MP4 ещё не гарантирует её пригодность.
При нескольких языках важно корректно разметить language и, если нужно, label. Иначе плеер может показать дорожки как und или не дать пользователю понятный выбор. Исправлять разметку лучше до публикации, а не на стороне интерфейса плеера.
HLS на fMP4 и совместный DASH/HLS-вывод
Современный сценарий HLS в Bento4 строится вокруг mp4dash --hls. Команда создаёт MPEG-DASH MPD и одновременно HLS-плейлисты, причём оба формата могут ссылаться на общий набор fragmented MP4 media segments. Именно этот подход используется для CMAF-подобной доставки, где одна медиабаза обслуживает разные манифесты и нет необходимости хранить отдельную копию сегментов только из-за протокола верхнего уровня.
mp4dash --hls --output-dir=package video-1080-frag.mp4 video-720-frag.mp4 audio-frag.mp4
Имена HLS-файлов управляются параметрами --hls-master-playlist-name, --hls-media-playlist-name и --hls-iframes-playlist-name. --hls-key-url задаёт адрес ключа для соответствующего HLS-режима. При использовании FairPlay можно передать key URI через --fairplay-key-uri; он имеет смысл только вместе с HLS-выводом и корректной DRM-конфигурацией.
Преимущество общего набора сегментов — меньше дублирования storage и более единообразная проверка. Если один media segment повреждён, проблема затрагивает обе манифестные формы, поэтому QA легче сосредоточить на единой последовательности. С другой стороны, ограничения целевых устройств всё равно нужно учитывать: старые HLS-клиенты могут ожидать MPEG-2 TS, и тогда fMP4-only доставка им не подходит.
CMAF в контексте Bento4
CMAF определяет общую модель сегментированных медиаресурсов для адаптивного стриминга и позволяет DASH и HLS ссылаться на одни и те же сегменты. В Bento4 такой сценарий реализуется через mp4dash с --hls. Важно понимать, что CMAF — не отдельное расширение файла, которое автоматически делает контент совместимым со всеми клиентами. Кодеки, profiles/levels, encryption scheme, segment alignment и capabilities плеера остаются частью совместимости.
mp4hls и mp42hls: традиционный HLS с MPEG-2 TS
mp4hls — высокоуровневый HLS packager, который вызывает mp42hls для каждого входа и собирает multibitrate master playlist. Он предназначен для традиционного HLS с MPEG-2 TS media segments; официальный материал Bento4 прямо рекомендует для современных сред предпочитать fMP4-HLS через mp4dash, если целевые проигрыватели его поддерживают.
У mp4hls есть --hls-version, настройки имён master/media/I-frame playlists, --output-single-file, выбор формата аудио packed или ts и --segment-duration. Для защиты поддерживаются AES-128 и SAMPLE-AES, а также IV modes sequence, random и fps для FairPlay Streaming. Параметр --signal-session-key добавляет session key tag в master playlist, когда это требуется схемой доставки.
mp42hls работает с одним MP4 и даёт более низкоуровневый контроль: PMT/audio/video PID, track IDs, длительность сегмента, threshold, PCR offset, шаблоны файлов и URL, I-frame playlist, single-file режим и параметры шифрования. Высокоуровневый mp4hls передаёт ему соответствующие настройки, поэтому большинство специальных возможностей низкого уровня остаются доступны и в многовариантном процессе.
| Инструмент | Тип сегментов | Типичный случай |
|---|---|---|
mp4dash --hls | fragmented MP4 | Общий набор сегментов для DASH и HLS, CMAF-сценарии |
mp4hls | MPEG-2 TS, packed audio | Multibitrate legacy HLS |
mp42hls | MPEG-2 TS, packed audio | Низкоуровневая упаковка одного MP4 |
Выбор не стоит сводить к новое против старого. Если парк устройств включает клиентов, не умеющих fMP4-HLS, TS остаётся практическим вариантом. Если целевые платформы понимают fMP4, общий DASH/HLS-набор упрощает хранение и упаковку.
mp42ts: преобразование MP4 в MPEG-2 Transport Stream
mp42ts конвертирует MP4 в MPEG-2 TS. Можно назначать PID для PMT, аудио и видео, задавать PCR offset и включать подробный вывод. Опция --segment делит результат по целевой длительности, причём имя выхода в этом режиме должно быть printf-шаблоном вроде seg-%d.ts. --playlist создаёт playlist, а --playlist-hls-version задаёт его HLS version.
Этот инструмент полезен не только для финального HLS. Иногда TS требуется тестовому оборудованию, вещательному pipeline или анализатору, который ожидает транспортный поток. Но конвертация контейнера не меняет фундаментальную совместимость кодека: если downstream не умеет исходный видеокодек, упаковка в TS сама по себе проблему не решит.
mp4encrypt: схемы шифрования и структура ключей

mp4encrypt шифрует MP4 и поддерживает несколько семейств схем. В документации перечислены OMA-PDCF-CBC/CTR, Marlin IPMP, ISMA, PIFF CBC/CTR, а также Common Encryption варианты MPEG-CENC, MPEG-CBC1, MPEG-CENS и MPEG-CBCS. Для современных DASH/HLS DRM-сценариев особенно важны CENC-схемы cenc/cbcs и родственные варианты.
Ключ задаётся параметром --key n:k:iv, где n — track ID или group key selector, k — 128-битный ключ в hex, iv — IV либо salting key нужной длины для выбранного cipher mode. Для key и IV разрешено слово random, чтобы сгенерировать значение. Несколько --key назначают разные ключи разным дорожкам.
--strict превращает предупреждения, например о незашифрованной дорожке, в ошибку. Для production-пайплайна это полезная защита от ситуации, когда команда завершается, но часть контента случайно остаётся clear. --show-progress показывает ход обработки.
Через --property задаются named properties для дорожек, --global-option — глобальные опции конкретной схемы. --pssh system-id:file добавляет PSSH box для указанной системы; payload берётся из файла, а пустое имя после двоеточия создаёт PSSH без payload, если такой вариант нужен.
Самый важный практический момент: шифрование файла и DRM-лицензирование — разные уровни. Bento4 может зашифровать samples и записать signaling, но политика выдачи лицензий, аутентификация пользователя, хранение content keys и работа license server находятся за пределами этой утилиты. Ключи нельзя встраивать в публичный скрипт упаковки или лог CI в открытом виде.
mp4decrypt: расшифровка по track ID или KID
mp4decrypt принимает входной и выходной MP4 и один или несколько ключей. Параметр записывается как --key id:key; id может быть десятичным track ID или 128-битным KID в hex, а key — 128-битным ключом в hex. KID применим к схемам, где он предусмотрен, например MPEG-CENC. Для нескольких дорожек или KID параметр повторяется.
mp4decrypt --key 1:00112233445566778899aabbccddeeff encrypted.mp4 clear.mp4
В реальном CENC-пайплайне предпочтительно сопоставлять ключ с KID, когда файл содержит корректный default_KID: это уменьшает риск применить значение не к той дорожке. Track ID тоже допустим и иногда используется для диагностики. После расшифровки стоит запустить mp4info --verbose и проверить, что protected sample description больше не помечается как ожидающее дешифрования, а затем воспроизвести файл в обычном валидаторе/плеере.
Если команда создаёт выход, но он не декодируется, это ещё не доказательство успешной дешифровки. Нужно сверить KID, key, scheme, наличие init information и соответствие media fragments. Отдельный media segment без его initialization metadata может не дать инструменту достаточно контекста; для некоторых случаев предусмотрен --fragments-info, когда информация о дорожках читается из другого файла.
Параметр --show-progress полезен на больших файлах, но не добавляет проверку правильности ключа. Неверный ключ может проявиться только на стадии декодирования или в структуре результата, поэтому криптографическую корректность следует проверять не по факту завершения процесса, а по содержимому и воспроизведению тестового материала.
Шифрование непосредственно в mp4dash и DRM signaling
mp4dash умеет шифровать во время упаковки. --encryption-key принимает key specification с KID и key, при необходимости IV. Для нескольких дорожек можно использовать несколько entries и фильтры. --encryption-cenc-scheme выбирает cenc, cbc1, cens или cbcs; default — cenc. Дополнительные аргументы для низкоуровневого mp4encrypt передаются через --encryption-args.
Для EME предусмотрено --eme-signaling с PSSH v0 или v1. Отдельные флаги добавляют signaling для Marlin, PlayReady, Widevine, Primetime и Clear Key. PlayReady header может быть подан как файл, Base64-объект или набор полей; Widevine header — как Base64 либо поля provider/content_id/policy. --fairplay-key-uri указывает key URI для FairPlay в HLS-режиме.
Эти параметры не означают, что Bento4 реализует серверную часть каждой DRM. Их роль — сформировать ожидаемую структуру init segment и манифеста: ContentProtection, PSSH, scheme information и связанные поля. Лицензионный endpoint, бизнес-правила и выдача ключей должны быть согласованы с тем, что packager записал в контент.
Схему cenc и cbcs нельзя выбирать только по вкусу. Совместимость зависит от платформы, DRM и профиля доставки. Например, один и тот же набор DRM-систем может требовать определённой схемы для конкретных устройств. Перед массовой упаковкой разумно иметь небольшую матрицу тестовых клиентов и валидировать один короткий asset на каждом.
Clear Key для тестовой среды
Флаг --clearkey добавляет Clear Key signaling в MPD при наличии encrypted input или --encryption-key. Дополнительно можно задать license/key URI. Такой режим удобен для лабораторной проверки EME/CENC без полноценной коммерческой DRM, но ключ всё равно должен обращаться безопасно в рамках выбранного тестового контура.
Почему нельзя путать KID и KEY
KID — идентификатор, который можно хранить в контенте открыто. KEY — секретный AES-ключ. Длина обоих в CENC-сценариях часто представляется 16 байтами, из-за чего их визуально легко перепутать. Если поставить KID в поле key, структура упаковки может выглядеть правдоподобно, но медиа не расшифруется ожидаемым ключом. В автоматизации имена переменных должны отражать назначение, а секретное значение лучше поступать из защищённого хранилища.
mp4dcfpackager и OMA DCF
mp4dcfpackager относится к OMA DCF-сценариям. Он принимает метод NULL, CBC или CTR, content MIME type, content ID, rights issuer, 128-битный key и IV, а также произвольные textual headers. Для большинства современных веб-проектов этот инструмент не является центральным, но он важен как отдельная часть Bento4, когда приходится поддерживать OMA DRM/DCF workflow.
Не стоит заменять им mp4encrypt для CENC только потому, что оба инструмента говорят о CBC/CTR. Контейнер, signaling и модель прав у DCF отличаются. Выбор утилиты определяется целевой спецификацией, а не названием cipher mode.
mp4compact: уменьшение таблицы размеров sample
mp4compact выполняет узкую структурную оптимизацию: преобразует таблицу размеров sample stsz в компактную форму stz2, когда значения позволяют такое представление. Команда принимает вход и выход и имеет только --verbose среди основных опций.
Это не видеокомпрессор и не уменьшает битрейт H.264/HEVC. Экономия относится к metadata table контейнера, поэтому на крупном видео эффект может быть мал по сравнению с объёмом mdat. Инструмент имеет смысл в системах, где обрабатывается огромное число sample и важна каждая часть overhead, но его не нужно включать в pipeline для сжатия MP4 без измеримой причины.
Кодеки, HDR и Dolby Vision в потоке Bento4
Bento4 ориентирован на контейнер, однако качество упаковки зависит от понимания кодеков. Для DASH наиболее распространены H.264/AVC и H.265/HEVC, а документация также рассматривает AV1 и дополнительные HDR-сигналы. Контейнер хранит codec configuration, profile/level, размеры, цветовую информацию и другие данные, которые затем отражаются в MPD или HLS attributes.
mp4info позволяет проверить, как закодирован каждый track, а mp4dash переносит информацию в manifest. Если encoder создал HEVC с неправильной sample entry hev1/hvc1 для целевой платформы, packager не всегда способен исправить совместимость без знания битстрима. Аналогично HDR10 или Dolby Vision требуют корректных метаданных и профиля на стадии кодирования/muxing.
mp4mux отдельно умеет указывать Dolby Vision profile 5, 8 или 9 и backward compatibility ID для профилей, где это нужно, а также выбирать hev1/hvc1 либо dvhe/dvh1. Эти поля следует брать из спецификации конкретного asset. Если добавить Dolby Vision параметры к обычному HEVC без соответствующего RPU/слоёв и требуемой структуры, совместимый проигрыватель не получит настоящего Dolby Vision.
При ABR все video representations должны быть согласованы не только по общей длительности. Для бесшовного переключения важны ключевые кадры и segment boundaries. Поэтому кодирование ladder обычно выполняют с одинаковой GOP cadence, а Bento4 уже фрагментирует и упаковывает подготовленные варианты.
Практический сценарий: подготовка DASH ladder
Предположим, заранее подготовлены три MP4: 1080p, 720p и 480p, все с H.264 и одинаковой GOP-структурой, плюс отдельная AAC-дорожка. Сначала стоит проверить каждый файл через mp4info: codec string, длительность, язык, число дорожек и состояние fragmentation. Если видеофайлы содержат лишний audio track, его лучше не тащить во все representations без необходимости.
Далее каждый вариант фрагментируется. Если нужен целевой segment duration около четырёх секунд, можно указать --fragment-duration 4000, но результат всё равно привязан к sync samples. После фрагментации полезно проверить, что временная сетка вариантов действительно сопоставима.
mp4fragment --fragment-duration 4000 v1080.mp4 v1080-frag.mp4
mp4fragment --fragment-duration 4000 v720.mp4 v720-frag.mp4
mp4fragment --fragment-duration 4000 v480.mp4 v480-frag.mp4
mp4fragment --fragment-duration 4000 audio.mp4 audio-frag.mp4
Затем все representations передаются mp4dash. Если нужен одновременно HLS на тех же fMP4-сегментах, добавляется --hls. В output появится MPD, master/media playlists и каталоги/файлы сегментов согласно выбранному шаблону. После этого нужно проверить не только наличие файлов, но и содержимое MPD: codecs, bandwidth, resolution, audio language, initialization и media templates.
При публикации на HTTP-origin важно правильно отдавать MIME types и разрешить CORS, если плеер работает с другого origin. Это уже настройка веб-сервера, а не Bento4. Ошибка CORS в браузере не исправляется повторным запуском mp4dash, если сами файлы корректны.
Что делать с разными аудиоязыками
Каждый язык удобно держать отдельным audio representation и явно задавать language. Селекторы позволяют выбрать конкретную дорожку из multi-audio MP4. Для HLS нужно правильно сформировать audio groups и признаки default/autoselect, иначе клиент может выбирать неожиданную дорожку. Если исходники помечены und, можно использовать language map или override property, но только если язык действительно известен.
Практический сценарий: единый CMAF-набор для DASH и HLS
Цель такого workflow — хранить один набор fMP4-сегментов и два описания: MPD для DASH и playlists для HLS. В Bento4 это делается mp4dash --hls. До упаковки требуется fragmented MP4, а варианты качества должны быть сегментно согласованы. Аудио и субтитры также подготавливаются как отдельные потоки или совместимые tracks.
Для статического VOD полезно выбрать понятные имена output directory и manifest. Если публикационная система кеширует файлы по имени, стоит избегать перезаписи того же пути для новой версии asset: клиент или CDN может получить смесь старых playlists и новых сегментов. Это организационная проблема, которая проявляется как случайные 404 или decode errors и ошибочно воспринимается как баг packager.
После генерации сравнивают duration, number of segments и последнюю границу каждого representation. Затем тестируют DASH и HLS независимо. Если DASH работает, а HLS нет, это не обязательно проблема media segment: причиной может быть master playlist, codec compatibility целевого HLS-клиента, encryption mode или FairPlay signaling. Общие сегменты упрощают локализацию: если одинаковый .m4s корректно декодируется в одном протоколе, можно сосредоточиться на manifest/signaling другого.
Практический сценарий: анализ неизвестного или повреждённого MP4
Диагностика начинается с mp4info. Если команда видит movie и tracks, фиксируются brands, duration, codec string, sample count и fragmentation. Если mp4info сообщает об отсутствии movie, нужно выяснить, не является ли файл media segment вместо самостоятельного MP4. В таком случае mp4dump даст больше информации.
Далее mp4dump используется для дерева атомов. У обычного MP4 ожидаются ftyp, moov и mdat; у fragmented — init metadata плюс moof/mdat. Необычно маленький mdat, оборванный moov, некорректный размер box или отсутствующий trak часто сразу указывают направление поиска.
Если подозрение падает на один atom, mp4extract позволяет вынести его в отдельный файл и сравнить с рабочим образцом. mp4edit пригоден только после того, как ясно, что именно нужно удалить или заменить. Попытка лечить случайный файл заменой moov из другого MP4 почти всегда неверна: sample tables и offsets описывают конкретное содержимое mdat.
При проблеме с временными метками полезно посмотреть sample layout и samples через mp4info, а затем tfdt/trun через mp4dump. Такой подход даёт точнее результат, чем ориентироваться на сообщение одного плеера, который может скрыть первичную ошибку за общим media decode error.
Автоматизация и использование JSON
Консольная архитектура делает Bento4 удобным для автоматизированных медиапайплайнов. mp4info --format json и mp4dump --format json позволяют получать структурированные данные, не зависящие от оформления терминала. Скрипт может проверять codec, resolution, track languages, наличие fragments и CENC signaling до того, как передаст asset в packager.
Хорошая автоматизация разделяет валидацию и действие. Например, сначала JSON-проверка убеждается, что исходник содержит ровно одну видеодорожку нужного класса и допустимые аудиодорожки; затем mp4fragment создаёт fMP4 в отдельном каталоге; ещё одна проверка подтверждает fragments; только потом mp4dash формирует publication package. Если любая стадия не проходит, последующие не запускаются.
Коды возврата команд следует проверять обязательно. Не нужно определять успех по наличию строки output или по тому, что файл появился. Частично записанный файл после ошибки может существовать. В CI разумно писать stderr/stdout в артефакты задания, но секретные DRM keys перед этим маскировать.
Для параллельной обработки сотен asset лучше ограничивать число одновременно работающих процессов. Хотя многие операции не перекодируют видео, они активно читают и записывают большие файлы, поэтому bottleneck быстро перемещается на storage. Одновременный запуск десятков mp4fragment на одном HDD может быть медленнее последовательной или умеренно параллельной схемы.
Типичные ошибки и способы их локализовать
mp4dash не принимает входной файл
Сначала выполните mp4info и посмотрите fragments. Стандартный вход mp4dash — fragmented MP4. Если fragments = no, подготовьте файл mp4fragment. Затем проверьте, что Python доступен скрипту и что служебные Bento4 executable находятся там, где их ожидает mp4dash. Для нестандартного расположения есть --exec-dir.
Output directory уже существует
mp4dash по умолчанию защищает от неявной записи в существующий каталог. --force снимает ограничение, но в production безопаснее удалить старую staging-папку или создать новую. Смешанный набор старых и новых сегментов сложнее диагностировать, чем явная ошибка записи.
Сегменты имеют разную длительность
Небольшое различие может быть нормальным из-за ключевых кадров и timescale. Если вариация существенна, проверьте GOP и используйте --use-segment-timeline в mp4dash, когда durations действительно неодинаковы. Для ABR важнее выравнивание точек переключения между representations, чем абсолютная идентичность каждого числа.
Один вариант качества переключается с рывком
Сравните keyframe cadence всех encode. Packager не может создать чистую точку random access там, где кодер её не дал. Если GOP open, изучите --force-i-frame-sync, но лучше корректно настроить encoder и одинаковые closed-GOP boundaries для ladder.
Нет языка или язык undefined
Проверьте mp4info. Если track language равен und, используйте selector property или --language-map только после достоверного определения языка. Не подставляйте язык по имени файла без контроля: ошибка попадёт в manifest и интерфейс плеера.
mp4info не открывает .m4s
Это ожидаемо для media segment без moov. Анализируйте его mp4dump или рассматривайте вместе с init segment. Сообщение No movie found в таком контексте не означает автоматически битый media segment.
После mp4decrypt файл есть, но не воспроизводится
Сверьте KID, key и encryption scheme. Проверьте protected sample description до и после операции. Если использовали track ID вместо KID, убедитесь, что выбрана нужная дорожка. Для фрагментов может потребоваться информация из init. Не принимайте нулевой exit code за доказательство правильного секретного ключа.
Windows сообщает об отсутствующей runtime DLL
Предварительно собранные бинарные файлы зависят от соответствующего Microsoft Visual C++ runtime. Если конкретный executable не стартует и система сообщает о runtime DLL, установите поддерживаемый пакет Microsoft Visual C++ Redistributable подходящей архитектуры, а не скачивайте отдельную DLL с неизвестного сайта. После этого снова запустите самую простую команду без входного файла, чтобы увидеть usage banner.
Команда создаёт файл с неожиданной длительностью
Для raw H.264/H.265 при muxing проверьте frame rate и timestamps, которые доступны из bitstream. Для готового MP4 сравните timescale и duration дорожек в mp4info. Если одна дорожка длиннее, mp4fragment --trim может быть уместен в конкретном процессе, но сначала надо понять, допустима ли потеря лишнего хвоста.
Ограничения Bento4, о которых важно знать
Bento4 сосредоточен на ISO-MP4 и связанных streaming-форматах. Он не заменяет универсальный транскодер: нет задачи открыть произвольный MOV/MKV/AVI, применить фильтры, изменить картинку и закодировать её в нужный профиль одной командой. Для этого обычно используют FFmpeg, специализированный encoder или медиасервис, а Bento4 подключают после кодирования.
Набор команд требует понимания терминов container, track, sample, atom/box, timescale, fragment, segment и DRM signaling. Для редкой операции это выше порога входа, чем GUI-программа. Ошибка в пути atom или параметрах ключа может дать технически созданный, но логически неверный файл. Поэтому здесь особенно важны промежуточные проверки.
Другая граница — отсутствие DRM license server. Bento4 шифрует и записывает PSSH/manifest signaling, но не решает аутентификацию пользователя, entitlement и выдачу лицензии. Точно так же HLS/DASH packager не заменяет CDN или origin server: после генерации файлы нужно корректно разместить и отдавать по HTTP.
Некоторые утилиты относятся к legacy workflow: например, mp4hls создаёт MPEG-2 TS HLS, тогда как современные HLS-проекты часто используют fMP4 через mp4dash --hls. Наличие старого инструмента полезно для совместимости, но не означает, что его нужно выбирать по умолчанию для каждого нового проекта.
Наконец, документация отдельных низкоуровневых команд лаконична. Для сложных случаев приходится сочетать usage, исходный код и спецификации ISO BMFF/CENC. Это нормально для инструментария разработчика, но не подходит пользователю, который ожидает мастер с пошаговыми подсказками и автоматическим исправлением ошибок.
Интеграция C++-библиотеки
Помимо CLI, Bento4 предоставляет C++ API для чтения и записи ISO-MP4. В SDK присутствуют headers и static libraries, а исходный код доступен отдельно. Это позволяет встроить разбор atom, создание tracks или другие операции в собственное приложение вместо запуска внешних процессов.
Решение между CLI и API зависит от архитектуры. Для batch transcoding farm проще и надёжнее вызывать готовые команды, фиксируя версии и параметры. Для программы, которая в реальном времени манипулирует box, нужна тесная интеграция, обработка ошибок на уровне объектов и отсутствие временных процессов — здесь библиотека уместнее.
Лицензирование библиотеки нужно учитывать отдельно от технической интеграции. Официально Bento4 предлагается под GPL для приложений, полностью совместимых с условиями GPL, и с коммерческой non-GPL лицензией для случаев, где такое распространение невозможно. Перед включением библиотеки в закрытый продукт следует оценить лицензионную модель проекта, а не исходить только из того, что код доступен публично.
Сравнение Bento4 с аналогами
Прямые альтернативы Bento4 различаются по акценту. Одни сильнее ориентированы на streaming packaging и DRM, другие совмещают упаковку с широким набором мультимедийных преобразований, третьи дают развитые инструменты ISO BMFF. Поэтому сравнивать их корректнее по типу рабочего процесса, а не по одному количеству команд.
| Программа | Лучше подходит для | Главное ограничение |
|---|---|---|
| Bento4 | Разбора и редактирования MP4, fMP4, DASH/HLS/CMAF-упаковки, CENC-сигналинга | Нет видеотранскодинга и GUI |
| GPAC / MP4Box | ISO BMFF-мультиплексирования, DASH, треков, scene/media packaging и широких MP4-операций | Большое число опций требует изучения синтаксиса |
| Shaka Packager | DASH/HLS packaging и Common Encryption в streaming-конвейерах | Меньше инструментов для произвольного редактирования atom |
| FFmpeg | Транскодинга, фильтрации, remuxing и подготовки медиапотоков множества форматов | Не так специализирован на низкоуровневом ISO BMFF/DRM packaging |
| Unified Packager | Профессиональной упаковки VOD/live в DASH/HLS с DRM-интеграцией | Коммерческая экосистема и иной процесс лицензирования |
Практический выбор зависит от того, где находится задача. Если уже есть готовые H.264/HEVC/AAC representations и требуется исследовать MP4, сформировать fMP4, DASH/HLS и CENC signaling, набор Bento4 закрывает этот слой без привлечения видеокодера. Если требуется одновременно менять разрешение, фильтровать видео, перекодировать звук и работать с десятками контейнеров, FFmpeg логично ставить перед packager. Для инфраструктуры, стандартизированной на Shaka Packager или коммерческом Unified Streaming, миграция ради одной функции может не дать выгоды.
GPAC/MP4Box пересекается с Bento4 наиболее широко на уровне MP4 и DASH. Выбор между ними часто определяется уже существующими скриптами, конкретными edge cases и тем, чей синтаксис/валидаторы лучше вписываются в pipeline. Универсального победителя здесь нет: оба проекта покрывают глубокие операции с ISO BMFF, но набор конкретных команд и поведение на редких структурах различается.
Часто задаваемые вопросы
Можно ли Bento4 использовать как видеоконвертер?
В смысле перекодирования изображения — нет. Bento4 может remux, фрагментировать, извлекать elementary streams, превращать MP4 в TS и готовить streaming package, но не выполняет полноценное изменение кодека, разрешения или визуальные фильтры. Для этого нужен encoder/transcoder, после которого Bento4 получает готовые потоки.
Как узнать точный codec string для браузера?
Запустите mp4info и найдите Codecs String в sample description нужной дорожки. Не вычисляйте профиль вручную по расширению. Для файла с несколькими дорожками выпишите видео- и аудио-строки отдельно.
Чем mp4info отличается от mp4dump?
mp4info даёт медиасводку: tracks, duration, dimensions, bitrate, codec configuration. mp4dump показывает дерево box и поля контейнера. Для какой кодек? нужен первый, для где лежит tenc/pssh/trun? — второй.
Нужно ли всегда выполнять mp4fragment перед mp4dash?
Вход mp4dash по официальному usage — fragmented MP4. Если mp4info показывает fragments = yes и структура уже корректна, повторная фрагментация не нужна. Если fragments = no, стандартный путь — mp4fragment.
Можно ли одним запуском получить и DASH, и HLS?
Да. mp4dash --hls создаёт HLS playlists дополнительно к DASH, используя общие MP4 fragments. Это базовый сценарий Bento4 для общего DASH/HLS media set и CMAF.
Когда нужен mp4hls?
Когда требуется традиционный HLS с MPEG-2 TS или целевые клиенты не поддерживают fMP4-HLS. Для нового окружения с fMP4 чаще используют mp4dash --hls.
Может ли Bento4 сделать ABR из одного 4K-файла?
Он может упаковать несколько готовых representations, но не создать 1080p/720p/480p кодированием из 4K. Лестницу качества нужно заранее получить транскодером. Затем Bento4 фрагментирует и собирает манифест.
Почему одинаковая fragment duration не гарантирует одинаковые сегменты?
Границы видео зависят от random access points и GOP. Если ключевые кадры в двух representations находятся в разное время, packager не может сделать идеальное переключение одной настройкой длительности. Согласование начинается на encoder.
Можно ли добавить субтитры?
Да, mp4dash поддерживает subtitle inputs, включая IMSC1/TTML и WebVTT в предусмотренных сценариях, а также субтитры, инкапсулированные в совместимый MP4 track. Формат нужно проверить заранее.
Что означает fragments: yes?
Файл использует movie fragments и содержит фрагментированную структуру. Это необходимый признак для многих streaming workflows, но он ничего не говорит о том, насколько хорошо выровнены representations или корректен DRM signaling.
Можно ли извлечь один atom без всего MP4?
Да, mp4extract получает atom по пути. Флаг --payload-only исключает его header. Обратную вставку или замену выполняет mp4edit.
Что делает mp4compact?
Меняет таблицу sample sizes из stsz в stz2, когда это позволяет представить её компактнее. Видео и аудио не перекодируются, поэтому ожидать заметного уменьшения медиабитрейта нельзя.
Можно ли расшифровать DRM-файл, имея только KID?
Нет. KID идентифицирует ключ, но не является секретным key. mp4decrypt требует 128-битный ключ, полученный законным способом из вашей тестовой/лицензионной инфраструктуры.
Почему mp4decrypt принимает и track ID, и KID?
Это два способа указать, к какой защищённой сущности применить ключ. В CENC KID обычно точнее связывает key с encrypted sample description; track ID удобен в некоторых legacy или диагностических случаях.
Где проверять PSSH?
mp4dump показывает PSSH boxes и их system IDs. Для содержимого конкретной DRM могут потребоваться специализированные декодеры структуры payload. Наличие PSSH ещё не подтверждает, что license server выдаёт подходящую лицензию.
Как сохранить moov/udta при фрагментации?
У mp4fragment есть --copy-udta. Но если важная телеметрия расположена не только в udta, этого может быть недостаточно; сравните полное дерево исходника и результата.
Подходит ли Bento4 для массовой обработки?
Да, CLI и JSON-вывод хорошо автоматизируются. Нужно контролировать exit codes, staging directories, секреты DRM и I/O concurrency. Для тысяч файлов особенно полезна отдельная стадия валидации перед изменением контента.
Что выбрать: JSON или text output?
Для человека удобнее text, для скрипта — JSON. Машинный parser не должен зависеть от пробелов и формата красивого терминального вывода.
Можно ли редактировать произвольный atom через mp4tag?
mp4tag предназначен для тегов. Произвольные atom лучше извлекать и менять через mp4extract/mp4edit, понимая их структуру.
Что делать, если плеер не принимает готовый MPD?
Сначала отделите ошибки доставки от packaging: проверьте network requests, MIME/CORS и доступность сегментов. Затем сопоставьте codecs и encryption capabilities клиента. После этого анализируйте MPD и init segment. Такая последовательность быстрее, чем многократно менять параметры packager наугад.
Рекомендованный порядок проверки перед публикацией
- Проверить исходные MP4 через
mp4info: дорожки, codec string, длительность, язык, dimensions и fragmentation. - Сопоставить representations ABR: одинаковая content duration, совместимые GOP boundaries, ожидаемые профили кодеков.
- При необходимости выполнить
mp4fragmentи повторно проверить результат. - Сформировать пакет
mp4dash, добавив--hls, если нужен общий fMP4-набор. - Проверить MPD и playlists: имена, codecs, bandwidth, languages, segment templates/timeline.
- Для DRM сверить KID, scheme, PSSH/ContentProtection и тестовую выдачу лицензии, не раскрывая key.
- Открыть несколько сегментов через
mp4dumpи убедиться, что init/media структура ожидаема. - Протестировать каждый целевой тип клиента через HTTP-origin с реальными headers и CORS.
Такой порядок важнее набора универсальных параметров. Bento4 даёт много низкоуровневого контроля, но качество результата определяется согласованностью кодирования, контейнера, манифеста, шифрования и инфраструктуры доставки. Если проверять каждую границу отдельно, большинство проблем удаётся локализовать до публикации большого массива контента.
Выбор дорожек в mp4dash и точная разметка representations
При простом вызове mp4dash анализирует каждый вход и сам решает, какие tracks включить. Для небольшого проекта это удобно, но в production лучше использовать input specifiers и явно контролировать выбор. Синтаксис квалификатора помещается перед именем файла в квадратных скобках. Селектор type=audio или type=video ограничивает тип, track=N выбирает конкретный track ID, language=xx — аудио указанного языка. Несколько условий разделяются запятыми.
После селекторов можно добавлять свойства с префиксом +. К документированным относятся language, language_name, representation_id, scan_type, label, key, а в HLS-режиме — hls_group, hls_group_match, hls_default, hls_autoselect и hls_characteristic. Это позволяет разметить presentation непосредственно на входе, не редактируя итоговый manifest вручную.
mp4dash [type=video,+representation_id=v1080]v1080-frag.mp4 [type=audio,+language=rus,+label=Russian]audio-rus-frag.mp4 [type=audio,+language=eng,+label=English]audio-eng-frag.mp4
Квалификатор полезен и тогда, когда один MP4 содержит несколько дорожек. Например, можно один раз указать файл для video track и ещё раз тот же файл для нужного audio track. Такой способ лучше, чем сначала создавать временные MP4 только ради разделения дорожек. Главное — не забывать, что одинаковый физический файл может появляться во входном списке несколько раз только при разных selectors.
Если исходный язык имеет код und, --language-map=und:rus позволяет переопределить его. Но это глобальное сопоставление и оно безопасно только тогда, когда все tracks с исходным кодом действительно относятся к одному языку. В сложном multi-audio файле точнее назначить property конкретному выбранному track.
Почему representation_id лучше задавать осмысленно
Автоматически сгенерированные identifiers допустимы, но осмысленные ID упрощают поддержку, логи CDN, проверку MPD и анализ ошибок плеера. Если storage naming и monitoring строятся вокруг representation IDs, лучше стабилизировать их на этапе упаковки. При этом ID не должен кодировать свойства, которые могут меняться независимо: например, использовать только 1080 рискованно, если в будущем появятся два видеокодека того же разрешения.
Разметка default и autoselect для HLS
При нескольких аудиоязыках master playlist должен сообщать плееру, какая группа является default и может ли track автоматически выбираться. Свойства hls_default и hls_autoselect задают это поведение на входе. Неверная комбинация может привести к тому, что плеер стартует не на том языке или показывает лишние варианты как равнозначные. Такие ошибки не видны в самом media segment, поэтому проверять нужно итоговый master playlist.
Многобитрейтное аудио и особенности AAC
Видео в ABR почти всегда представлено несколькими битрейтами, а аудио традиционно чаще оставляют в одном варианте на язык/кодек. Причина не только в том, что аудиобитрейт намного меньше видеобитрейта. Для обычного AAC и ряда Dolby-форматов seamless switching между независимо закодированными потоками разных битрейтов может быть проблематичным. Поэтому добавление четырёх AAC-битрейтов по аналогии с видео не обязательно даёт корректную адаптацию.
Bento4 отдельно документирует многобитрейтное аудио для xHE-AAC. В этом случае несколько audio inputs можно передать mp4dash вместе, и packager сформирует необходимые representations. Специального флага для самого xHE-AAC не требуется: codec определяется по MP4. Но все потоки всё равно должны быть корректно закодированы и подходить для seamless switching.
При традиционном multi-bitrate packaging, когда каждый video MP4 содержит одинаковое аудио, mp4dash не должен размножать идентичные audio tracks в каждом representation. Официальная логика сохраняет одну аудиодорожку, если входные дорожки не отличаются по битрейту более чем примерно на десять процентов. Это удобно для encode outputs, где контейнер каждого разрешения включает копию одного AAC.
Если нужны одновременно stereo AAC и multichannel E-AC-3, это уже не битрейтные варианты одного и того же аудио, а разные adaptation choices. Их следует явно разметить как отдельные tracks/группы и проверить поддержку каждого кодека на целевых клиентах. Практичный streaming-пакет часто содержит AAC как наиболее широко совместимый fallback и отдельную multichannel-дорожку для устройств, которые её понимают.
Комбинаторика HLS master playlist
В HLS каждая допустимая комбинация video и audio обычно должна быть отражена в master playlist. Если имеется N audio variants и M video variants, автоматический результат может содержать N×M записей EXT-X-STREAM-INF. При четырёх audio bitrates и трёх videos это уже двенадцать комбинаций. Для управляемого master playlist используются hls_group и hls_group_match: аудио присваивается группе, а video указывает, с какими группами его можно сочетать.
Это особенно полезно, если низкий video bitrate должен работать со всеми audio variants, а высокие видео — только с одним высококачественным аудио. Без явных group matches packager сформирует все сочетания, и плеер получит варианты, которые бизнес-логика проекта не планировала.
ISMV, ISMA и наличие tfdt
Legacy Smooth Streaming файлы ISMV/ISMA технически близки к fragmented MP4 и могут выглядеть подходящими для mp4dash. Проблема в том, что некоторые старые packagers создавали fragments без tfdt — Track Fragment Decode Time box. Для современных DASH/HTML5 clients отсутствие tfdt может сделать такой контент непригодным, даже если mp4info показывает fragments = yes.
Проверка выполняется mp4dump: внутри каждого traf ожидается tfdt с base media decode time. Если его нет, официальный рекомендуемый путь — re-fragment через mp4fragment. Утилита сообщит, что вход уже fragmented, и перестроит структуру с актуальными boxes.
mp4fragment legacy.ismv refragmented.mp4
mp4dump refragmented.mp4
Этот пример показывает важное правило: признак fragmented недостаточен для оценки пригодности к конкретной спецификации. Нужно проверять обязательные box и временные данные. Аналогичный принцип работает и с DRM: наличие sinf не доказывает, что PSSH, KID и manifest signaling согласованы.
Re-fragmentation стоит выполнять в отдельный файл. Если старый asset используется ещё одной системой, нельзя заменять его автоматически: новый tfdt-совместимый MP4 может быть правильнее для DASH, но другой legacy player мог зависеть от исходной структуры.
Раздача DASH через HTTP и режим без физического split
Стандартный результат mp4dash рассчитан на обычный HTTP-сервер: init и media segments лежат отдельными файлами, а MPD содержит относительные пути. Для MPD рекомендуется MIME type application/dash+xml, для MP4 init/media — video/mp4. Если сервер отдаёт всё как application/octet-stream, часть плееров всё равно может работать, но рассчитывать на это нельзя.
При cross-origin playback веб-сервер должен корректно настроить CORS. Bento4 не создаёт HTTP headers и не может исправить запрет браузера. Если network panel показывает, что MPD скачивается, а запросы сегментов блокируются CORS, перепаковка media files не изменит ситуацию.
Опция --no-split оставляет медиа в одном файле вместо физических сегментов. Для on-demand profile плеер может использовать индекс и HTTP Range requests. Это снижает количество файлов на storage, но предъявляет требования к клиенту и серверу. Для live-profile обычного встроенного индекса недостаточно; URL виртуализация требует специальной серверной поддержки.
Выбор split/no-split зависит от инфраструктуры. Отдельные сегменты проще кешировать и отдавать через обычный object storage/CDN. Один большой файл уменьшает file-count, но делает критичными Range requests и корректную cache policy на диапазоны. Если CDN плохо работает с ranges, экономия числа файлов может обернуться проблемами доставки.
Проверка Content-Length и Range
При on-demand delivery полезно проверить, что сервер отвечает на Range запросы статусом partial content и возвращает корректные byte ranges. Если вместо диапазона всегда передаётся весь MP4, плеер теряет преимущество индексированного доступа. Это не ошибка MPD или Bento4; она находится между origin и CDN.
Субтитры: TTML, IMSC1 и WebVTT
Поддержка subtitles в mp4dash включает два базовых способа: текстовые данные могут быть инкапсулированы в MP4 track или храниться отдельным файлом. Среди документированных семейств — IMSC1/TTML, включая профили W3C TTML, SMPTE-TT и EBU-TT, а также WebVTT. 3GPP Timed Text для данного DASH workflow отмечен как неподдерживаемый.
Перед упаковкой нужно проверить не только расширение, но и фактический формат. Файл с расширением .xml может не соответствовать ожидаемому TTML profile; WebVTT может содержать некорректные timestamps или style blocks, которые конкретный player интерпретирует иначе. Bento4 отвечает за включение дорожки в presentation, а не за исправление авторских ошибок subtitle content.
Если субтитры embedded в MP4, mp4info поможет определить track и language. При внешнем файле язык/label следует задать через входные свойства. Для нескольких языков каждую дорожку надо маркировать отдельно, иначе пользователь увидит одинаковые или неопределённые названия.
На этапе QA проверяют три вещи: присутствует ли subtitle adaptation set в MPD; правильно ли задан MIME/codec/profile; отображается ли текст в целевом player. Если manifest выглядит корректно, а текст не показывается, нужно отдельно проверить timing и поддержку формата клиентом. Не каждый DASH player реализует весь набор TTML/IMSC1 возможностей.
Синхронизация субтитров после изменения начала
Если видеоряд был подрезан до упаковки, subtitle timestamps должны относиться к той же временной базе. Bento4 не выполняет произвольный retiming внешнего текста как редактор субтитров. Смещение лучше исправить до mp4dash, иначе manifest будет технически валиден, но captions появятся раньше или позже изображения.
mp4dashclone: локальная копия DASH presentation
mp4dashclone создаёт локальную копию существующей MPEG-DASH presentation. Источником может быть локальный MPD или удалённый manifest; на выход передаётся каталог. Инструмент последовательно получает необходимые segments и сохраняет структуру так, чтобы с ней можно было работать локально. Это полезно для тестовой миграции, воспроизводимого bug report или создания лабораторного образца из собственной DASH-раздачи.
mp4dashclone stream.mpd cloned-package
Опция --encrypt=KID:KEY позволяет зашифровать media во время клонирования. --exec-dir указывает, где находятся Bento4 executables. Утилита не предназначена для обхода доступа к чужому защищённому контенту: она работает с ресурсами, которые доступны процессу, а DRM-лицензирование остаётся отдельной системой.
Клон удобно использовать в регрессионных тестах. Например, если ошибка проявляется только на production CDN, можно клонировать собственную presentation, убедиться, что локальный комплект воспроизводится, и тем самым отделить проблему упаковки от edge cache или headers. При изменяемом live manifest клон фиксирует только тот набор, который доступен в момент процесса, поэтому его нельзя считать полной архивной записью бесконечного live stream без отдельной логики.
Контроль качества после упаковки
Успешный exit code mp4dash означает, что packager выполнил свою работу, но не заменяет проверку конечного продукта. Минимальный QC состоит из структурной, медиатехнической и клиентской частей. Структурная проверка смотрит MPD/playlists, наличие init/media files, количество representations и segment numbering. Медиатехническая — codec strings, durations, keyframes, декодирование нескольких сегментов. Клиентская — реальное воспроизведение на целевых player/устройствах.
Для структурной проверки удобно выбрать первый, средний и последний segment каждого типа. Первый выявляет проблемы init/start timestamps, средний — типичную структуру, последний — расхождение длительности и завершения. У защищённого контента дополнительно сверяют tenc, KID и PSSH на initialization level и наличие expected ContentProtection в MPD.
Для ABR следует не просто включить auto-quality и посмотреть несколько секунд. Нужно инициировать переключения между соседними и далёкими bitrates. Если GOP boundaries не совпадают, glitch часто проявляется только при switch. Отдельно тестируют seek в начало, середину и почти конец asset — проблемы segment timeline могут оставаться незаметными при линейном просмотре.
Аудио проверяют по всем языкам и codec alternatives. Наличие дорожки в manifest не гарантирует, что она имеет правильный language, channel layout или синхронность. Для HLS с audio groups надо проверить default choice на чистом профиле плеера без сохранённых пользовательских настроек.
Субтитры проверяют минимум на двух фрагментах, включая сегмент вокруг границы. Если cue пересекает boundary, player должен корректно удерживать его. Для TTML/IMSC1 дополнительно важно, поддерживает ли target rendering features, которые использует авторский файл.
QC для DRM
В тестовой среде один и тот же asset желательно проиграть с валидной лицензией, с намеренно отсутствующей лицензией и, если система позволяет, с истёкшим entitlement. Так проверяется не только шифрование работает, но и ожидаемая обработка отказов. Bento4 формирует media/signaling; корректность пользовательского сообщения при license error относится к player/application.
Как выбирать утилиту по симптомам
| Симптом или цель | Что запускать первым | Следующий шаг |
|---|---|---|
| Неизвестно, что внутри MP4 | mp4info | mp4dump для деталей box |
| Нужно найти KID/PSSH | mp4dump | Сверить DRM-конфигурацию и init segment |
| Нужно получить fMP4 | mp4info | mp4fragment, если fragments = no |
| Нужно получить отдельные .m4s | mp4fragment | mp4split |
| Нужен DASH package | mp4info всех входов | mp4dash |
| Нужны DASH и HLS на общих сегментах | Проверить fMP4/ABR alignment | mp4dash --hls |
| Нужен legacy TS-HLS | Проверить MP4 tracks | mp4hls или mp42hls |
| Нужно вынести atom | mp4dump | mp4extract |
| Нужно заменить atom | mp4extract для резервной копии | mp4edit |
| Нужно изменить теги | mp4tag --show-tags | mp4tag --set/--add |
| Нужен raw AVC/HEVC/AAC | mp4info | mp42avc/mp42hevc/mp42aac |
| Нужно собрать MP4 из raw streams | Проверить elementary streams | mp4mux |
| Нужна CENC-защита | Определить KID/key/scheme | mp4encrypt или encryption в mp4dash |
Такая схема сокращает число лишних преобразований. Например, для поиска KID не нужно сначала делать DASH package, а для смены title tag не нужно выгружать и перестраивать moov вручную. Чем уже задача, тем полезнее выбрать самую специализированную команду Bento4.
Рабочие привычки, которые уменьшают риск повреждения файлов
Первое правило — никогда не использовать единственную копию исходника как output для эксперимента с mp4edit, mp4fragment или encryption. Большинство команд и так требуют отдельный output, и это следует сохранять как дисциплину даже в скриптах. Имена вроде source.mp4, fragmented.mp4, encrypted.mp4 и clear-check.mp4 делают pipeline читаемым.
Второе — фиксировать командную строку рядом с результатом. Для воспроизводимости достаточно текстового log без секретов: tool name, параметры, исходные asset IDs, exit code и хэш master-файла, если такая инфраструктура уже есть. Секретные keys должны подставляться из защищённой переменной и маскироваться в логах.
Третье — проверять промежуточный файл тем инструментом, который не участвовал в его создании. После mp4fragment использовать mp4info/mp4dump; после mp4edit — снова dump и внешний player; после mp4dash — manifest validator и реальный player. Самопроверка тем же кодовым путём может не заметить систематическую ошибку.
Четвёртое — сохранять короткие эталонные assets. Один короткий H.264/AAC, один HEVC, один multi-audio, один subtitle и один DRM sample позволяют быстро понять, сломалась ли среда Bento4 или конкретный новый master. Полноценный двухчасовой фильм не нужен для каждой регрессии и только замедляет поиск причины.
Пятое — не смешивать изменения контейнера и перекодирование в одном диагностическом шаге. Если одновременно изменить codec, GOP и packager settings, при ошибке будет неясно, какой слой виноват. Гораздо эффективнее сначала получить воспроизводимый encoded MP4, затем отдельно фрагментировать, затем отдельно упаковать.
Как читать основные box в MP4 и fMP4
Для эффективной работы с mp4dump полезно знать назначение нескольких базовых box. ftyp сообщает major/compatible brands и помогает определить семейство формата. moov содержит movie metadata, а каждый trak описывает отдельную дорожку. Внутри trak находятся media header, handler, timing и sample tables. Большой mdat хранит медиаданные; его наличие само по себе мало что говорит о структуре воспроизведения без таблиц из moov.
В fragmented MP4 медиавременная структура переносится в повторяющиеся moof. mfhd содержит sequence number фрагмента. Для каждой дорожки внутри traf находятся tfhd, tfdt и один или несколько trun. tfdt задаёт base media decode time, а trun описывает samples текущего fragment: количество, durations, sizes, flags и composition offsets в зависимости от flags box.
| Box | Назначение при диагностике |
|---|---|
ftyp | Brands и общая совместимость контейнера |
moov | Movie metadata и корень описания дорожек |
trak | Одна audio/video/subtitle дорожка |
stsd | Sample descriptions, codec configuration и protected entries |
mdat | Закодированные media samples |
moof | Metadata одного movie fragment |
tfdt | Base decode time fragment |
trun | Список samples и их параметры во fragment |
sidx | Segment index для адресации диапазонов |
pssh | DRM system-specific signaling |
При ошибке декодирования полезно сравнить один рабочий и один проблемный файл на одинаковом уровне verbosity. Если у проблемного representation отсутствует tfdt, отличается sample entry или trun имеет неожиданную схему offsets, это гораздо информативнее сообщения плеера. Но вручную менять низкоуровневые box следует только после понимания зависимости полей: одно исправленное число может потребовать пересчёта offsets в другом месте.
Protected sample entries добавляют ещё один слой. Тип исходного codec хранится через protection scheme information, а tenc сообщает параметры default encryption, включая KID. PSSH находится на уровне, доступном DRM-клиенту. При проверке важно видеть всю цепочку: codec entry остаётся распознаваемой, encryption scheme соответствует manifest, KID совпадает с системой управления ключами.
AES-128, SAMPLE-AES и HLS-шифрование
В legacy HLS-инструментах Bento4 доступны два основных режима: AES-128 и SAMPLE-AES. AES-128 обычно шифрует медиасегмент как объект, тогда как SAMPLE-AES применяется к media samples по правилам HLS и используется, в частности, в FairPlay-сценариях. Нельзя менять один режим на другой только в playlist: способ шифрования байтов должен соответствовать объявленному METHOD.
mp42hls и mp4hls принимают --encryption-key в hexadecimal form и --encryption-mode. IV mode может быть sequence, random или fps. Для fps ожидается объединённое значение key+IV соответствующей длины. --encryption-key-uri определяет URI, записываемый в playlist; отдельные параметры key format и versions нужны для систем, где HLS key tag содержит нестандартный формат доставки ключа.
Параметр --encryption-key-line позволяет передать заранее подготовленную часть строки EXT-X-KEY. При этом METHOD и IV добавляются инструментом автоматически, поэтому дублировать их в preformatted части нельзя. Эта опция взаимоисключается с отдельными key URI/format/version настройками: нужно выбрать один способ формирования key tag.
В modern fMP4-HLS через mp4dash --hls чаще применяется Common Encryption, особенно в связке с DRM. Здесь encryption scheme и signaling должны быть согласованы и с DASH, и с HLS. Например, общий media set может иметь cbcs и разные manifest-level DRM descriptors для FairPlay и другой системы. Именно поэтому в таком pipeline полезно отделять как зашифрованы samples от как клиент узнаёт, где получить лицензию.
Хранение ключа
Даже тестовый ключ не следует записывать в article, batch-файл, публичный репозиторий или имя output. В автоматизации key передают через secret store/переменную окружения либо временный защищённый файл, а лог фильтруют. Bento4 не скрывает переданный секрет автоматически: если команда выводится системой CI целиком, key окажется в журнале. Поэтому маскирование нужно на уровне orchestration.
Ротация ключей
Если проект использует key rotation, нужно проверять не только cryptographic result, но и границы смены ключа, manifest signaling и возможности целевых плееров. Возможности конкретного workflow зависят от используемой схемы упаковки и внешней DRM-инфраструктуры. Не следует имитировать ротацию простым чередованием случайных KID между независимо созданными файлами без согласования с manifest/license policy.
Fast start, fragmentation и segmenting — не одно и то же
Три понятия часто смешивают. Fast start относится к обычному progressive MP4: metadata moov располагается так, чтобы плеер получил её до загрузки большого mdat. Fragmentation меняет модель файла: media разбивается на movie fragments с moof/mdat. Segmenting для DASH/HLS идёт ещё дальше и выделяет отдельные адресуемые media units и manifests.
Файл может иметь fast start и при этом быть non-fragmented. Он хорошо начинает проигрываться по progressive HTTP, но не становится автоматически входом для стандартного DASH packaging. И наоборот, fragmented MP4 может использоваться для streaming даже без понятия fast start в привычном смысле, потому что initialization metadata и fragments организованы иначе.
mp4info помогает разделить эти состояния: в File виден fast start, в Movie — fragments. Если задача — ускорить старт обычного downloadable MP4, mp4fragment может быть избыточен и изменить модель доставки. Если задача — сделать DASH, наличие fast start не избавляет от проверки fragmentation.
После mp4split media segment вообще перестаёт быть самостоятельным movie: ему нужен init segment. Поэтому попытка оценивать такой .m4s по критериям обычного MP4 приводит к ложным выводам. Для каждого слоя следует использовать свой критерий: progressive file, fragmented file или streaming presentation.