MLT Framework tools позволяет собирать и запускать многодорожечные аудио- и видеокомпозиции из командной строки: утилита melt открывает файлы и MLT XML, режет фрагменты по точкам in/out, складывает их в дорожки, подключает фильтры и переходы, выводит предпросмотр или передаёт результат consumer-модулям для кодирования, сериализации и автоматического рендеринга. Набор особенно полезен для пакетных задач, серверных сценариев и проектов, где монтаж нужно описывать командами или XML, а не вручную собирать на тайм-линии.

Под названием MLT Framework tools здесь понимаются пользовательские инструменты MLT Multimedia Framework, прежде всего команда melt. На официальном сайте MLT описан как движок для авторинга, управления и запуска многодорожечных аудио- и видеокомпозиций, а melt — как командный проигрыватель и редактор, работающий поверх тех же producer, filter, transition и consumer-сервисов. Поэтому материал относится именно к MLT и его штатным средствам, а не к видеоредакторам, которые лишь используют MLT как внутренний движок.

У MLT нет одной фиксированной панели с одинаковым набором кнопок на всех компьютерах: фактические возможности определяются установленными модулями. Практический центр работы — команды melt, запросы -query, профили вывода, свойства сервисов и MLT XML. Это даёт очень точный контроль над цепочкой обработки, но требует внимательно проверять, какие producers, filters, transitions и consumers доступны именно в конкретной сборке.

Что именно делают MLT Framework tools

Основная задача набора — превратить набор источников в управляемую медиакомпозицию. Источником может быть видеофайл, звуковой файл, изображение, генератор цвета, текстовый producer, устройство или другой MLT-проект. Источник отдаёт кадры и аудиосэмплы, а MLT последовательно пропускает их через операции, которые описаны командной строкой либо XML. На выходе можно получить окно предпросмотра, закодированный файл, сетевой или аппаратный вывод, XML-сериализацию или пустой вывод для проверки производительности. Точный список зависит от модулей, поэтому универсальная команда в MLT почти всегда начинается с проверки окружения.

melt умеет не только воспроизводить один клип. Команда принимает несколько producers, задаёт каждому собственные in и out, строит дорожки, добавляет пустые участки, повторяет и разделяет клипы, смешивает соседние фрагменты, подключает фильтры к клипу, дорожке или итоговому выходу и направляет результат в выбранный consumer. Это ближе к текстовому описанию монтажной схемы, чем к обычному конвертеру: один и тот же проект можно сначала проиграть, затем сериализовать в XML, а после — отрендерить в файл другим consumer.

Сильная сторона подхода — воспроизводимость. Если команда и входные файлы не изменились, её можно запускать из shell-скрипта, планировщика, очереди рендеринга или CI. Вместо последовательности ручных действий остаётся явный набор аргументов: профиль, пути к media, точки монтажа, фильтры, переходы, кодеки и свойства consumer. Для длинных команд обычно удобнее перейти к MLT XML, где те же объекты представлены структурно.

• воспроизведение и проверка отдельных файлов и MLT-композиций;
• сборка последовательности клипов с точками входа и выхода;
• многодорожечная композиция с аудио- и видеодорожками;
• фильтрация и анимация параметров во времени;
• переходы и композитинг между дорожками;
• кодирование через consumer avformat при наличии соответствующего модуля;
• сериализация схемы в MLT XML и повторный запуск проекта;
• пакетный и headless-рендеринг с текстовым прогрессом.

Модель MLT: producer, filter, transition и consumer

Чтобы уверенно пользоваться melt, полезно думать не в терминах файл открылся — эффект применился — файл сохранился, а в терминах графа сервисов. Producer создаёт кадры и аудио; filter модифицирует кадры, проходящие через определённый участок графа; transition получает данные как минимум с двух ветвей и смешивает их; consumer забирает готовые кадры и делает с ними финальное действие. Playlist и multitrack организуют producers во времени и по дорожкам, а tractor объединяет сложную композицию в producer верхнего уровня.

Компонент	Что делает	Где встречается в работе
Producer	Создаёт аудио- и видеокадры	Файл, изображение, цвет, текст, XML, устройство
Playlist	Расставляет producers последовательно	Монтаж одной дорожки с пробелами и обрезкой
Multitrack	Укладывает дорожки параллельно	Видео, фон, титры, отдельный звук
Filter	Изменяет проходящие кадры	Цвет, геометрия, звук, текст, анализ
Transition	Смешивает две или более ветви	Наплыв, лума-переход, композитинг, аудиомикс
Consumer	Получает готовый поток кадров	Окно, файл, XML, устройство, null-вывод

Эта модель объясняет многие особенности синтаксиса. Параметр, записанный сразу после producer, относится к нему; -filter добавляет фильтр в текущий контекст; -transition связывает дорожки; -consumer выбирает конечный приёмник. Когда свойство поставлено не там, где ожидается, MLT может применить его к другому сервису или вообще проигнорировать, если у выбранного сервиса нет такого параметра. Поэтому при сложной команде важно читать её слева направо как описание создаваемого графа.

Producer и ресурс

Для обычного медиаклипа melt часто сам подбирает producer через служебный loader. На практике команда melt clip.mp4 не означает, что MLT содержит собственный MP4-декодер: loader выбирает подходящий сервис из тех, что доступны в сборке, а для распространённых форматов обычно используется модуль avformat, связанный с FFmpeg. Если модуль не собран или его библиотеки недоступны, один и тот же файл на двух системах может давать разный результат. Проверка melt -query producers поэтому важнее предположения о поддержке расширения.

Ресурс можно указывать явно вместе с producer, когда нужно избежать автоматического выбора. Это особенно полезно для изображений, текстовых генераторов, XML или диагностики. Общие свойства in, out и length задают временной диапазон, но конкретный producer может иметь дополнительные параметры: выбор аудиодорожки, режим EOF, аппаратное декодирование, интерпретацию последовательности изображений и другие опции. Их правильнее не запоминать по сторонним примерам, а смотреть через -query producer=идентификатор.

Playlist, дорожки и tractor

Playlist описывает последовательность: клип, следующий клип, пауза, ещё один фрагмент. Multitrack, наоборот, ставит несколько playlists по вертикали и позволяет получать кадры с нескольких дорожек на одной временной позиции. Чтобы эти дорожки стали итоговой картинкой или звуковым миксом, применяются transitions, filters и правила tractor. В MLT XML такая структура видна буквально: отдельные producer, затем playlist, затем tractor с multitrack и связями между дорожками.

Командный синтаксис melt позволяет собрать то же без ручного XML. Опция -track начинает новую дорожку, -audio-track или -hide-video создаёт дорожку, где используется только звук, а -video-track или -hide-audio оставляет видео. -null-track и -hide-track создают скрытую дорожку. Такой подход удобен для коротких схем; когда количество объектов и диапазонов растёт, XML становится читаемее и надёжнее для сопровождения.

Consumer как точка вывода

Если consumer не указан, melt обычно пытается использовать consumer по умолчанию для интерактивного воспроизведения. Для автоматического рендеринга лучше всегда задавать consumer явно. avformat пишет кодированный медиапоток в файл или иной поддерживаемый FFmpeg-вывод, xml сериализует сервисную сеть, null позволяет прогонять кадры без файла, а SDL-потребитель выводит изображение и звук для просмотра. Наличие каждого варианта проверяется командой melt -query consumers.

Consumer получает уже сформированные кадры, поэтому его свойства могут влиять не только на контейнер и кодек, но и на профиль, масштабирование, аудиоформат, режим реального времени и число рабочих потоков. Ошибка новичка — задавать разрешение только параметрами кодера и не учитывать профиль MLT. Профиль участвует в вычислении композиции раньше consumer, поэтому для точного результата размеры, частоту кадров и аспект лучше задавать через -profile либо корректный mlt_profile.

Проверка установленного набора перед работой

Первый диагностический шаг — убедиться, что запускается именно нужный melt. Команда melt -version показывает версию и сообщение об авторских правах, а системные средства which, where или явный полный путь помогают исключить ситуацию, когда в PATH находится другой экземпляр. Это особенно важно на системах, где MLT поставляется как зависимость видеоредактора, установлен пакетным менеджером и одновременно собран вручную.

Следом стоит выполнить melt -query. Эта команда перечисляет зарегистрированные сервисы, то есть фактически показывает, что конкретная сборка умеет использовать. Для целевой проверки есть отдельные запросы -query producers, -query filters, -query transitions, -query consumers, -query links, -query profiles и -query presets. Отдельно можно запросить форматы, аудиокодеки и видеокодеки, если avformat-модуль их предоставляет.

Если список подозрительно короткий или пустой, не имеет смысла сразу менять параметры кодирования. Сначала нужно проверить расположение модулей и данных MLT. Переменная MLT_REPOSITORY может переопределять каталог модулей, MLT_DATA — каталог дополнительных данных, а MLT_PROFILE — профиль по умолчанию. Неправильный префикс установки или перенос одного melt без его библиотек и модулей приводит к характерной ситуации: сам исполняемый файл запускается, но нужных producers и consumers нет.

Команды -query, которые полезно сохранить

melt -query
melt -query producers
melt -query consumers
melt -query filters
melt -query transitions
melt -query profiles
melt -query presets
melt -query formats
melt -query audio_codecs
melt -query video_codecs

Запрос одного сервиса обычно информативнее длинного списка. Например, melt -query consumer=avformat показывает метаданные и свойства соответствующего consumer, а melt -query filter=... помогает понять допустимые параметры фильтра. Важно учитывать, что документация описывает возможности MLT в целом, а -query отражает конкретную установленную сборку. При расхождении для практической команды приоритет имеет то, что зарегистрировано локально.

Первый запуск melt и интерактивное воспроизведение

Самая короткая полезная команда выглядит как melt video.mp4. Если подходящий producer найден и доступен consumer предпросмотра, MLT откроет поток, выведет окно и одновременно напечатает в терминале транспортную подсказку. В ней используются клавиши для перемещения по кадрам и клипам, переходов назад и вперёд, возврата к началу, остановки и запуска воспроизведения. Такое окно удобно для проверки композиции, но оно не подходит как неявный вывод в cron, CI или пакетном скрипте.

Причина проста: интерактивный consumer рассчитан на пользователя. Автоматическое задание должно явно писать файл или использовать другой неинтерактивный sink. Если команда в пакетном файле зависает после кадра, не создаёт ожидаемый файл или ждёт клавиатуру, первым делом нужно проверить, задан ли -consumer avformat:имя_файла и включён ли режим прогресса. Для последовательной очереди лучше использовать -progress или -progress2, а не полагаться на строку Current Position, связанную с интерактивным режимом.

Клавиатурное управление и -silent

Транспортная часть melt удобна для ручной проверки: можно двигаться на кадр, на клип или на крупный временной шаг, запускать и останавливать воспроизведение. Но для скрипта лишний интерактивный ввод только мешает. Опция -silent убирает вывод позиции и транспортной подсказки, -quiet снижает уровень логов, а -loglevel позволяет выбрать градацию от тихого режима до подробной отладки и таймингов. Для расследования проблемы обычно полезнее временно повысить подробность, чем полностью скрывать stderr.

Опция -getc отдельно включает получение клавиатурного ввода через getc. Это нишевая возможность, и добавлять её в headless-команды не нужно. Для автоматизации важнее, чтобы consumer не требовал дисплея и ввода, прогресс печатался предсказуемо, а код завершения процесса можно было обработать вызывающим скриптом.

Обрезка клипов: in, out, length и единицы времени

MLT оперирует позициями кадров, но большинство временных свойств умеют принимать не только целые номера кадров. Для producer можно записать in и out, ограничив используемый участок ресурса. При последовательности из нескольких файлов свойства относятся к тому producer, после которого записаны: melt a.mp4 in=100 out=249 b.mp4 in=50 out=149 создаёт два разных отрезка. Значения in и out лучше считать частью монтажа, а не параметрами контейнера или кодека.

Временные строки поддерживают кадровое представление, SMPTE timecode и clock-форму. Если строка содержит двоеточие и дробную часть, она интерпретируется как значение часов/минут/секунд; timecode без дробной части может содержать кадры. Это удобно в XML: запись, рассчитанная в секундах, легче читается и может автоматически пересчитываться при изменении частоты кадров, хотя смена FPS неизбежно может повлиять на точную кадровую границу.

В анимации и некоторых временных свойствах отрицательные позиции имеют особый смысл — отсчёт от конца объекта. Это позволяет задать действие за несколько секунд до конца, не вычисляя абсолютный номер кадра. Но такую запись стоит применять осознанно: если длина producer меняется, положение отрицательной точки тоже смещается.

Форма	Пример	Когда удобна
Кадры	250	Точная работа на фиксированном FPS
Clock	00:00:10.500	Сценарии, где время важнее номера кадра
SMPTE	00:00:10:12	Монтаж и сверка по таймкоду
От конца	-2:00	Ключевые точки относительно финала

Несколько файлов и последовательный монтаж

Несколько ресурсов можно перечислить в одной команде: melt a.mp4 b.mp4 c.png. Они образуют последовательность, а MLT приводит кадры к параметрам композиции, которые задаёт профиль. Для каждого ресурса разрешается указать собственный диапазон и свойства. Это простой способ собрать черновую линейную последовательность без отдельного XML.

Опция -blank вставляет пустой участок на текущей дорожке, -repeat повторяет последний cut, -split делит последний cut по относительной позиции, -swap переставляет два последних элемента, -remove удаляет последний cut, а -join объединяет несколько клипов в один cut. Эти операции полезны именно как средства построения playlist; они не означают безперекодировочное изменение исходных файлов на диске.

-group позволяет применить одинаковые свойства к следующим сервисам. Например, можно задать одинаковые in и out группе клипов. Важно вовремя закрыть область действия пустым -group: последние групповые свойства продолжают распространяться и на следующие filters, transitions или consumer, если их не сбросить. Это одна из причин, по которой очень длинные однострочные команды становятся труднее отлаживать, чем эквивалентный XML.

Многодорожечная композиция

Для параллельного размещения материала используется -track. Всё, что было собрано до этой точки, становится одной дорожкой, после чего можно описать следующую. Простейший пример — фон на нижней дорожке и короткий клип на верхней. Чтобы верхняя дорожка действительно смешалась с нижней, одного факта её существования недостаточно: нужен transition или другой механизм композитинга, который определит, как кадры соединяются.

Аудио и видео можно разделять логически. -audio-track и эквивалентное скрытие видео позволяют оставить только звук; -video-track или скрытие аудио — только изображение. Это удобно для отдельной музыкальной дорожки, закадрового голоса, фонового видео или титрового слоя. Если нужно сохранить место в multitrack, но временно не выводить дорожку, используются скрытые и null-варианты.

При сложном проекте важно считать номера дорожек. Свойства transitions вроде a_track и b_track ссылаются на конкретные входы multitrack. Если после добавления новой дорожки нумерация изменилась, старый transition может начать смешивать не те источники. В XML такие связи легче видеть, поэтому длинные многодорожечные композиции разумно хранить в структурированном виде, а melt использовать для запуска и быстрого прототипа.

Пустые участки и синхронизация

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

Синхронизацию лучше выражать явными длинами и точками, а не рассчитывать только на длительность файлов. У источников могут быть переменная частота кадров, неточные метаданные, задержка аудио или особенности декодера. Для ответственных задач полезно сначала проверить фактическую длительность producer, затем строить монтаж в кадрах или в согласованном timecode выбранного профиля.

Переходы и смешивание дорожек

Опция -transition добавляет сервис, который получает две ветви композиции. Классический пример в документации MLT — luma: transition может выполнять обычный наплыв либо использовать luma-изображение как маску. Важные свойства — диапазон in/out, номера a_track и b_track, а для некоторых сценариев reverse. Само название transition и набор свойств нужно сверять через -query transitions и запрос конкретного сервиса.

Для перехода между соседними cut в одной логической последовательности предусмотрена пара -mix и -mixer. -mix задаёт длительность перекрытия последних двух cut, а -mixer выбирает transition, который будет использоваться внутри этого перекрытия. Такой синтаксис короче ручного построения дополнительных дорожек, но чувствителен к порядку аргументов.

Аудиомикс и видеокомпозитинг — разные задачи. Даже если визуальный transition выглядит корректно, звук может требовать отдельного перехода или регулировки уровней. MLT содержит специализированные сервисы для аудио, а точный набор зависит от сборки. Поэтому полезно проверять метаданные конкретного transition и не предполагать, что видеопереход автоматически реализует нужную кривую громкости.

Когда нужен qtblend, а когда luma

luma уместен для переходов, где важно управлять маской или ходом смешивания между двумя дорожками. qtblend используется для геометрического и альфа-композитинга в Qt-модуле и встречается в проектах, которым нужны положение, масштабирование и смешивание слоя. Эти сервисы решают разные задачи, поэтому подмена одного другим только по слову transition обычно ведёт к запутанным параметрам.

Если конкретная сборка не содержит ожидаемого transition, команда должна считаться непереносимой, пока это не исправлено. Правильный способ диагностики — melt -query transition=имя. Если запрос не возвращает сервис, нужно установить соответствующий модуль или выбрать другой доступный механизм, а не пытаться менять свойства вслепую.

Фильтры и область их действия

-filter добавляет фильтр в текущую точку графа. Свойства in и out могут ограничивать действие во времени, а дополнительные параметры зависят от выбранного filter. В документации melt для простого примера используется greyscale, но реальный набор гораздо шире и может включать собственные фильтры MLT, адаптеры frei0r, FFmpeg avfilter, Qt-эффекты, аудиообработку и другие модули.

Важное свойство MLT — фильтр может быть привязан не только к текущему cut. Опции -attach-clip, -attach-track, -attach-cut и -attach задают разные уровни. Это позволяет, например, применить один эффект к отдельному источнику, другой — ко всей дорожке, а третий — к итоговому выходу. Ошибка уровня привязки часто выглядит как фильтр то работает, то исчезает, хотя на самом деле он применяется только к части графа.

Некоторые filters молча игнорируют свойства, которых у них нет. Поэтому параметр, найденный в примере для одного фильтра, нельзя механически переносить на другой. Если результат не меняется, первым делом запросите метаданные конкретного сервиса и убедитесь, что имя свойства написано правильно и значение имеет ожидаемый тип.

Диапазон фильтра и монтажные точки

Диапазон фильтра вычисляется в контексте того объекта, к которому он привязан. Это принципиально для сложной композиции: кадр 100 у исходного producer, кадр 100 внутри playlist и кадр 100 итогового tractor могут означать разные моменты. Если эффект должен появляться по времени итоговой программы, удобнее привязать его на уровне дорожки или выхода; если он относится к конкретному клипу независимо от места на timeline — на уровне clip.

При анимируемых свойствах положение ключей тоже интерпретируется относительно длины объекта. Нельзя без проверки переносить строку анимации с filter, привязанного к короткому clip, на глобальный filter, который живёт всю композицию. Отрицательные ключи особенно чувствительны к этому, потому что считаются от конца соответствующего объекта.

Анимация свойств и ключевые кадры

MLT позволяет записывать изменение свойства во времени одной строкой. Позиция находится слева, значение — справа, а ключи разделяются точкой с запятой. Тип интерполяции обозначается оператором: дискретная смена, линейная интерполяция или сглаженная кривая Catmull-Rom. Благодаря этому параметр filter или transition может менять прозрачность, координаты, размер, число или другой поддерживаемый тип без отдельного массива объектов.

Временная позиция ключа может быть номером кадра, clock-строкой или SMPTE timecode. Отрицательная позиция отсчитывается от конца длительности. Это удобно для универсальных анимаций вроде за две секунды до конца начать исчезновение, но только если сервис знает длину объекта. Если длина неизвестна или меняется на лету, отрицательные позиции требуют дополнительной проверки.

MLT поддерживает анимируемые целые, вещественные и прямоугольные значения, а строки в общем случае меняются дискретно. Тип mlt_rect удобен для геометрии: он хранит координаты, размеры и непрозрачность в форме, которую понимают соответствующие сервисы. Конкретное свойство должно быть помечено сервисом как анимируемое; наличие механизма анимации в framework не означает, что любой параметр любого плагина автоматически интерполируется.

0|=0; 50|=100; 100=200; 200~=60; -2:00~=100; -1=220

В такой строке можно сочетать разные типы интерполяции. При отладке полезно сначала сократить выражение до двух ключей, убедиться, что свойство вообще анимируется, и только затем добавлять сложную кривую. Это быстрее, чем одновременно искать ошибку в синтаксисе времени, значениях и типе filter.

Профили: разрешение, FPS и геометрия кадра

Профиль MLT описывает параметры видеокомпозиции, а не только свойства финального кодека. В него входят числитель и знаменатель частоты кадров, ширина, высота, progressive-флаг, sample aspect ratio, display aspect ratio и colorspace. Профили хранятся как простые текстовые документы и могут выбираться по имени или по пути к собственному файлу.

Команда melt -query profiles показывает доступные готовые профили. Для запуска профиль задают через -profile имя. Альтернативно работает переменная MLT_PROFILE, а consumer может получить mlt_profile как свойство. Профиль consumer имеет высокий приоритет, но отдельные свойства consumer, записанные после него, способны переопределить его размеры, FPS, прогрессивность и аспекты.

Практическое правило: сначала определите параметры композиции, затем кодирование. Если проект рассчитан на 1920×1080 при 25 fps, это должно быть отражено профилем. Параметры width, height или частоты, переданные только encoder consumer, не заменяют корректного профиля во всех внутренних операциях. Filters и producers получают часть параметров именно из profile и могут вести себя иначе при несогласованной конфигурации.

Свойство профиля	Смысл	Почему важно
frame_rate_num/den	Точная частота кадров дробью	Таймкод, длительности, синхронизация
width/height	Размер композиции	Масштаб фильтров и итоговая геометрия
progressive	Прогрессивный или чересстрочный режим	Обработка движения и кодирование
sample_aspect_num/den	Форма пикселя	Корректные пропорции изображения
display_aspect_num/den	Соотношение сторон отображения	Интерпретация кадра плеером и фильтрами
colorspace	Цветовое пространство профиля	Корректные преобразования изображения

Собственный профиль

Если готового профиля нет, можно создать текстовый файл с нужными параметрами. Для дробных величин используются пары numerator/denominator, что избавляет от ошибки округления, характерной для записи FPS как обычного decimal. Имя профиля желательно задавать явно, если он передаётся не как файл, а через объект свойств или строковое описание.

Переменная MLT_PROFILES_PATH переопределяет системный каталог профилей. Это полезно для контролируемой среды сборки или сервера, но может быть причиной неожиданностей: если пользователь задаёт свой каталог и забывает добавить стандартные профили, знакомые имена перестанут находиться. Для переносимого скрипта разумно либо использовать собственный профиль по явному пути, либо проверять наличие требуемого имени перед рендерингом.

Предпросмотр в пониженном разрешении

Preview scaling позволяет считать композицию в полном профиле, но просить consumer выводить изображение меньшего размера. Для melt это делается свойством scale consumer. При scale=0.5 ширина и высота уменьшаются вдвое, поэтому общее число пикселей становится примерно четвертью исходного. Это может значительно облегчить интерактивный просмотр тяжёлой композиции.

Масштаб предпросмотра не равнозначен смене профиля проекта. Правильная логика — сохранить исходную геометрию композиции и уменьшить запрос consumer. Некоторые эффекты умеют учитывать такой масштаб, а некоторые могут отключать его, если алгоритм не переносится на уменьшенное разрешение. Внешние плагины тоже могут вести себя иначе, поэтому низкоразрешённый preview нельзя считать безусловным доказательством идентичности финального рендера.

При выборе коэффициента полезно сохранять одинаковый масштаб по ширине и высоте и следить за чётностью размеров. Для YUV с субдискретизацией нечётные размеры могут создать лишние проблемы. Multi-consumer для preview scaling не поддерживается, поэтому сценарии, которые одновременно выводят в несколько consumers, требуют отдельного проектирования.

Экспорт через consumer avformat

Для записи обычного медиофайла чаще всего используется avformat. Базовая форма — -consumer avformat:output.mp4, после которой идут свойства контейнера, видео- и аудиокодека. Набор конкретных кодеков не зашит в документацию MLT раз и навсегда: он зависит от FFmpeg/Libav и того, как собран avformat-модуль. Поэтому перед использованием конкретного vcodec или acodec полезно проверить -query video_codecs и -query audio_codecs.

Типичный набор параметров может включать f для формата контейнера, vcodec, acodec, pix_fmt, частоту дискретизации ar, число каналов channels, настройки качества или битрейта, GOP и приватные параметры выбранного кодера. Но переносить длинную строку из чужого проекта без проверки опасно: свойства FFmpeg меняются между кодерами, часть параметров может быть устаревшей, а аппаратные энкодеры используют собственные наборы опций.

Если задача — обычный H.264/AAC-файл, лучше начать с минимального набора и получить корректный результат, а затем добавлять качество, пресет и дополнительные параметры. Когда команда падает на неизвестном параметре, уберите его и запросите поддерживаемые свойства. Когда файл создаётся, но не воспроизводится, проверьте контейнер, pix_fmt, аудиоформат и сообщения stderr, а не только расширение имени.

Кодек, контейнер и расширение — не одно и то же

Имя output.mp4 сообщает avformat желаемый контейнер лишь косвенно. Явное свойство f=mp4 может убрать неоднозначность, но само по себе не выбирает видеокодек. vcodec=libx264, аппаратный H.264 encoder или другой кодек — отдельное решение. Аналогично AAC, Opus, PCM или другой аудиокодек выбирается независимо от видеопотока, если контейнер это допускает.

Свойство movflags=+faststart часто встречается в MP4-командах, потому что оно просит FFmpeg расположить служебные данные так, чтобы файл было удобнее начинать воспроизводить до полной загрузки. Это не влияет на монтажную схему MLT и не является универсальным параметром для любого контейнера. Такие опции следует считать частью конфигурации avformat, а не framework в целом.

Аудиопараметры consumer

В базовом consumer MLT есть свойства частоты аудио и числа каналов. Типичное значение частоты — 48000 Гц, но конкретный результат зависит от профиля, consumer и кодера. Если входы имеют разные частоты дискретизации, MLT и модули могут выполнять пересэмплирование. Для предсказуемого файла лучше задавать целевую частоту, раскладку каналов и кодек явно, особенно если проект смешивает несколько источников.

Не следует путать громкость, микширование и формат кодирования. ab или другие параметры encoder относятся к выходному аудиопотоку; громкость меняется filter, а баланс нескольких дорожек — структурой композиции и соответствующими аудиосервисами. Если звук клиппует ещё до consumer, снижение битрейта или смена кодека это не исправит.

Пресеты свойств

MLT умеет хранить наборы name=value в preset-файлах и применять их к сервису через свойство properties. Для avformat это позволяет вынести длинную конфигурацию кодирования из командной строки. Установленные пресеты можно перечислить через melt -query presets, а конкретный — исследовать запросом melt -query preset=имя.

Пресеты могут быть общими для сервиса и специализированными под профиль. Профильный вариант имеет больший приоритет. Это полезно, когда один логический preset должен отличаться для PAL, NTSC, HD или другого профиля. Но preset не отменяет необходимость проверять наличие кодеков: если он ссылается на encoder, которого нет в текущей сборке FFmpeg, рендер всё равно не состоится.

Собственный preset — удобный способ стандартизировать серверную очередь. Вместо нескольких десятков аргументов в shell-скрипте остаётся имя файла или установленного preset, а изменение битрейта или профиля кодека вносится централизованно. В production-сценарии preset полезно хранить вместе с конфигурацией окружения, чтобы обновление зависимостей не превращало одну и ту же короткую команду в непредсказуемо другой результат.

MLT XML: проект как сериализованный граф

MLT XML отражает внутреннюю модель framework. Документ может содержать profile, producers, playlists, tractor, multitrack, filters, transitions и consumer. Нормальная форма начинается с уникальных producers, затем собирает из них playlists дорожек, после чего создаёт multitrack и связи. Такой файл можно загрузить как producer и запустить командой melt project.mlt или передать в рендеринг с явным consumer.

XML особенно полезен там, где командная строка становится длинной. Имена объектов и их ID позволяют ясно ссылаться на источники, один media-файл можно использовать в нескольких entry с разными in/out, а фильтры и transitions располагаются рядом со своими связями. При этом XML — не отдельный монтажный движок: его элементы в конечном счёте создают те же MLT services, поэтому отсутствующий module сломает и XML-проект.

Парсер MLT XML не занимается валидацией по DTD в привычном строгом смысле. Ошибка структуры или неизвестное свойство может проявиться уже при создании service. Поэтому для отладки полезно сериализовать рабочую команду в XML и сравнить структуру с вручную написанным проектом, а не только проверять, что XML синтаксически корректен.

Минимальная логика XML

<mlt>
  <producer id="p0">
    <property name="resource">clip.mp4</property>
  </producer>
  <playlist id="track0">
    <entry producer="p0" in="0" out="249"/>
  </playlist>
  <tractor id="main">
    <multitrack>
      <track producer="track0"/>
    </multitrack>
  </tractor>
</mlt>

В реальном проекте profile обычно задаётся явно, а на верхнем уровне появляются дополнительные producers, transitions и filters. Лучше не ограничивать producer собственными in/out, если один и тот же исходник будет использоваться в разных местах: точки монтажа удобнее задавать в entry. Так один producer остаётся полным ресурсом, а playlists берут из него нужные диапазоны.

Вложенные XML и повторное использование

MLT XML сам может выступать resource другого producer. Это позволяет инкапсулировать готовую сцену, заставку или сложный фрагмент и использовать его как один источник в большем проекте. При таком подходе особенно важны пути к файлам и профиль: вложенный документ должен находить свои ресурсы в новом окружении и правильно взаимодействовать с profile внешней композиции.

Если проект переносится между машинами, абсолютные пути быстро становятся проблемой. XML consumer умеет работать с root и связанными свойствами сериализации, а редакторы на базе MLT могут записывать собственную структуру путей. Перед серверным рендерингом чужого проекта нужно проверить, что все ресурсы доступны из каталога, откуда запускается melt, и что не осталось ссылок на локальные пользовательские папки.

Сериализация команд и повторный запуск

melt умеет сохранять построенную командную композицию. Опция -serialise записывает последовательность команд в текстовую форму, которую затем можно использовать как ресурс. Это удобно для быстрого прототипа: сначала схема собирается интерактивно в командной строке, затем фиксируется и запускается повторно без копирования длинного набора аргументов.

Более выразительный вариант — consumer xml. Он не кодирует видео, а обходит связанный граф и создаёт MLT XML. Такой файл легче анализировать, изменять скриптом и использовать в другом приложении на базе MLT. Для чистой сериализации иногда полезно отключать избыточные метаданные, но точные параметры XML consumer лучше проверять через -query consumer=xml, потому что набор свойств может меняться вместе со сборкой.

При сериализации нужно помнить о путях. -serialise сохраняет ресурсы в той форме, в которой они были указаны в команде. Если исходник задан относительным путём, повторный запуск из другой рабочей директории может не найти файл. Для долговременного проекта либо стабилизируйте рабочий каталог, либо используйте структуру root/относительных путей, понятную вашему процессу развертывания.

Пакетный рендеринг и прогресс

Для очередей рендеринга важнее всего предсказуемое поведение процесса. Вместо интерактивного окна задайте consumer, который пишет файл, и включите -progress2. Этот режим печатает каждое обновление прогресса отдельной строкой, поэтому лог удобно читать в терминале, сохранять в файл и разбирать внешним скриптом. -progress тоже показывает позицию и процент, но обновляет строку иначе и менее удобен для обычных CI-логов.

Скрипт должен проверять не только процент, но и код завершения. Ошибки encoder, отсутствие модуля, недоступный входной файл или сбой consumer могут остановить процесс до 100%. Если stdout/stderr перенаправляются, не скрывайте stderr полностью: именно там обычно появляются сообщения MLT и FFmpeg, объясняющие причину остановки. Для сервера удобно писать отдельный лог на каждое задание и сохранять команду или XML рядом с результатом.

В headless-среде нельзя рассчитывать на consumer, который создаёт окно. Явный avformat для файла, null для тестового прохода или XML consumer работают без интерактивного предпросмотра. Если в графе есть Qt-сервисы, на Linux без display может понадобиться offscreen-платформа Qt; на macOS поведение иное, но переносимый скрипт всё равно выигрывает от явной конфигурации.

Несколько заданий подряд

В Windows batch, shell-скрипте или очереди задач каждое выполнение melt лучше делать отдельным процессом и ждать его завершения. После успешного выхода можно переходить к следующему проекту. Не стоит запускать несколько тяжёлых рендеров одновременно только потому, что процессор многоядерный: каждый экземпляр MLT, декодер и encoder могут сами создавать несколько потоков, и суммарная конкуренция часто снижает общую производительность.

Для независимых коротких задач параллелизм возможен, но число одновременно работающих процессов нужно подбирать по реальной нагрузке на CPU, GPU, память и накопитель. Если все задания читают большие исходники с одного диска и пишут туда же, узким местом станет ввод-вывод. Если используется аппаратный encoder, ограничение может задаваться количеством доступных аппаратных сессий, а не числом ядер.

Headless-рендеринг без окна

Базовая идея headless-режима проста: не оставлять выбор consumer по умолчанию. Команда с -consumer avformat:output.mp4 пишет файл и завершает работу без окна предпросмотра. Для server-side сценария полезно также выбрать профиль явно, включить -progress2 и направить stderr в лог. Тогда процесс можно запускать из cron, systemd, launchd, CI или собственного backend-сервиса.

Qt-модули требуют отдельного внимания. Текстовый producer qtext и другие Qt-сервисы могут инициализировать графическую подсистему даже тогда, когда итоговый consumer не показывает окно. На headless Linux помогает QT_QPA_PLATFORM=offscreen, если конкретная сборка Qt это поддерживает. Для текстовых задач без Qt может быть доступен producer на базе Pango; его наличие нужно проверить через -query producers.

Для стабильной серверной установки полезно заранее прогнать диагностический набор: версия, producers, filters, consumers, profiles, codecs и тестовый короткий рендер. Такой smoke test обнаруживает проблемы библиотек сразу после обновления образа или пакетов, а не во время реального задания.

Производительность и свойство real_time

MLT разделяет подготовку кадров и вывод, а consumer имеет свойство real_time, управляющее асинхронным поведением. Значение 1 означает асинхронную работу с возможностью пропуска кадров, -1 — асинхронную работу без пропуска, 0 — синхронный режим. В FAQ MLT также описывает использование модулей real_time с большим абсолютным числом для нескольких потоков подготовки кадров: положительный вариант допускает drop, отрицательный — нет.

Для интерактивного preview пропуск кадров может быть приемлем, потому что важнее сохранять темп воспроизведения. Для финального рендера обычно нельзя терять кадры, поэтому выбирают режим без drop. Но большее число потоков не гарантирует ускорения: некоторые filters не масштабируются, часть decoder/encoder уже использует собственный thread pool, а память и I/O могут стать ограничением раньше CPU.

Свойство threads у producer или consumer относится к тем сервисам, которые его поддерживают. FFmpeg-кодеки часто умеют многопоточность, но конкретная эффективность зависит от codec. Не стоит автоматически ставить число потоков равным всем логическим ядрам в каждой точке графа. Гораздо надёжнее начать с умеренного значения и измерять реальное время одного и того же короткого проекта.

Предварительная буферизация и frame dropping

Consumer может иметь buffer, prefill и drop_max. Буфер определяет объём кадров для асинхронного потока, prefill — сколько кадров подготовить до начала вывода, а drop_max ограничивает серию подряд пропущенных кадров в режиме, где drop разрешён. Эти свойства в первую очередь важны для realtime playback и streaming, а не для обычного офлайн-кодирования.

Если предпросмотр рывками догоняет timeline, увеличение buffer не всегда помогает. Возможно, отдельный filter слишком тяжёлый и система физически не успевает обработать кадры в реальном времени. Тогда полезнее preview scaling, отключение части effects или более лёгкий proxy-источник. Для финального рендера скорость ниже realtime сама по себе не является ошибкой.

Аппаратное декодирование и GPU

MLT может использовать аппаратные возможности через конкретные модули, но это не единая кнопка GPU для всего. Avformat producer способен работать с аппаратным декодированием при наличии нужного FFmpeg backend и драйвера, а отдельные модули обрабатывают OpenGL/Movit-эффекты. Результат зависит от сборки, видеодрайвера и того, какие filters остаются на CPU.

Преимущество аппаратного decoder может исчезнуть, если каждый кадр приходится постоянно копировать из памяти GPU в CPU для фильтрации и обратно. Поэтому MLT имеет параметры и переменные окружения, позволяющие ограничивать аппаратное декодирование по объёму пикселей или выбирать устройство. Такие настройки стоит применять после проверки фактической цепочки, а не включать автоматически для любого проекта.

Movit/OpenGL требует корректного OpenGL-контекста и подходящего consumer. В melt для этого предусмотрены сервисы вроде qglsl при наличии соответствующего модуля. Не все MLT-effects имеют GPU-реализацию, а OpenFX-плагины могут иметь собственные ограничения. Если задача — только H.264 encode, аппаратный encoder avformat и GPU-фильтры — независимые механизмы.

Как понять, что GPU действительно используется

Сначала убедитесь, что нужный service присутствует через -query. Затем включите подробный loglevel и проверьте сообщения backend о выбранном decoder/encoder или OpenGL. Наконец, сравните загрузку и время на одном и том же коротком проекте. Наличие слова hwaccel в команде не доказывает, что все стадии выполняются на GPU.

При ошибке аппаратного decoder полезно временно вернуться к software path. Если software работает, можно отдельно разбираться с драйвером, устройством, pixel format и transfer. Это лучше, чем одновременно менять профиль, filter graph и encoder: иначе становится неясно, какая часть исправила или сломала результат.

Изображения и слайд-шоу

MLT умеет использовать неподвижные изображения как producers. В разных сборках для этого могут быть доступны qimage, pixbuf или loader, который выберет подходящий модуль. Поскольку у одиночной картинки нет естественной длительности видеоклипа, её продолжительность задают свойствами вроде length, out или специфическим ttl для последовательностей изображений.

Для слайд-шоу важно заранее решить, будет ли каждый кадр описан отдельным producer или источником станет последовательность файлов. Отдельные producers дают точный контроль над длительностью каждого слайда; pattern/sequence удобнее, когда все изображения показываются одинаково. Если wildcard-синтаксис из старого примера не работает, проверьте документацию конкретного image producer и не предполагайте, что shell и Windows интерпретируют шаблон одинаково.

Масштабирование изображения выполняется относительно профиля. Чтобы избежать неожиданного растяжения, учитывайте sample aspect ratio и параметры filter, отвечающие за fit/fill. Если нужен Ken Burns-подобный ход, геометрический filter или transition должен поддерживать анимируемые координаты и размер; сам producer изображения только отдаёт кадр.

Текст, титры и субтитры

Текст в MLT может создаваться разными services. Qt-модуль предоставляет qtext, Pango-модуль — соответствующий текстовый producer, а kdenlivetitle работает со структурированными титрами, если присутствует модуль Kdenlive. Отдельные filters умеют накладывать text или subtitles поверх уже существующего изображения. Их свойства, шрифты и возможности анимации различаются.

В серверном рендеринге главная проблема титров часто не синтаксис текста, а доступность шрифтов и графической платформы. Если в production-контейнере нет нужного font family, результат будет отличаться даже при том же XML. Поэтому шрифты нужно считать частью окружения и заранее проверять на тестовом кадре.

Для субтитров важно различать burn-in и отдельный subtitle stream. Фильтр, который рисует текст на кадре, делает необратимую часть изображения. Создание отдельной subtitle-дорожки контейнера относится к возможностям muxer/avformat и требует другой конфигурации. MLT-фильтр субтитров не стоит автоматически считать эквивалентом muxing.

Работа со звуком

Аудио в MLT проходит по тем же временным объектам, что и видео. Producer отдаёт samples, playlist определяет их место, multitrack объединяет дорожки, filters меняют сигнал, а consumer преобразует его в целевой формат. Это позволяет синхронно монтировать звук вместе с изображением, но для сложного аудиомикса необходимо понимать, на каком уровне применяется каждый filter.

Частота дискретизации и число каналов задаются consumer и могут переопределяться кодером. MLT способен пересэмплировать аудио, если источник отличается от целевого формата, но не стоит полагаться на неявные значения в проекте с несколькими дорожками. Явные frequency, channels и channel layout уменьшают вероятность того, что стерео, mono и многоканальные источники будут сведены неожиданным образом.

Для изменения уровня, нормализации, pitch или других эффектов используются filters. Их наличие зависит от сборки: часть находится в core, часть приходит через SoX, Rubber Band, LADSPA или другие modules. Для переносимого проекта лучше сначала определить минимальный набор обязательных аудиосервисов и проверять их наличие при старте.

Отдельная звуковая дорожка

Чтобы добавить музыку под видео, удобно собрать нижнюю или верхнюю audio-only track и затем убедиться, что итоговый tractor микширует её с остальным звуком. Если нужно начать музыку позже, перед ней ставят blank. Если дорожка короче программы, нужно решить, должна ли она закончиться, повториться или удерживать последний кадр/состояние — это зависит от producer и логики playlist.

Фейд громкости удобно выражать через анимируемое свойство подходящего volume filter. Но имя свойства и диапазон значений нужно брать из metadata конкретного filter. Универсального volume=50% для всех аудиоплагинов нет: разные modules могут ожидать линейный коэффициент, dB или другой тип.

Форматы, кодеки и обнаружение возможностей

Список поддерживаемых контейнеров и codec нельзя корректно описать одной статической таблицей для всех установок MLT. Avformat опирается на FFmpeg, а FFmpeg может быть собран с разными внешними библиотеками и лицензиями. Поэтому melt -query formats, -query audio_codecs и -query video_codecs — практический источник истины для конкретной машины.

Это касается и аппаратных codec. На одном компьютере может быть доступен encoder NVIDIA, на другом — VA-API, VideoToolbox, D3D11/Vulkan или только software. Название codec в FFmpeg-списке ещё не гарантирует, что устройство и драйвер позволят запустить его с нужным профилем. Тестовый encode нескольких секунд должен входить в подготовку окружения.

Если требуется необычный контейнер или сетевой протокол, сначала убедитесь, что avformat его перечисляет, затем сделайте минимальный consumer без filters. После успешного вывода добавляйте композицию. Такой порядок отделяет ошибки muxer от ошибок MLT graph.

Вывод на устройства и потоковые сценарии

MLT создавался с учётом broadcast-задач, поэтому consumer не обязательно пишет файл. В зависимости от модулей могут существовать outputs для SDL, JACK, DeckLink, NDI, transport stream, сети и других систем. Однако список очень зависит от того, как собран package. Скрипт, рассчитанный на DeckLink, должен явно проверять этот consumer и доступность устройства до запуска основной программы.

Для сетевого потока особенно важно разделять уровни: MLT формирует кадры, avformat кодирует и muxes, а transport/network option определяет доставку. Ошибка подключения к адресу не означает ошибку filter graph, а плохой GOP или bitrate не означает проблему сети. Логи нужно анализировать по слою, который выдаёт сообщение.

Consumer multi позволяет направлять один граф в несколько outputs, но это усложняет синхронизацию и нагрузку. Preview scaling с multi consumer не поддерживается, поэтому одновременный низкоразрешённый preview и полноразмерный output лучше проектировать как отдельные процессы или иной граф, если конкретная задача требует надёжного поведения.

Null consumer и тестирование производительности

null consumer полезен, когда нужно проверить чтение, фильтры и общую скорость композиции без записи файла. Такой тест помогает понять, где находится bottleneck. Если null-рендер уже медленный, проблема, вероятно, в декодировании или обработке. Если null быстрый, а encode медленный, внимание стоит перенести на encoder, bitrate, disk I/O или аппаратный backend.

Для корректного сравнения используйте один профиль, один диапазон и один real_time. Изменение сразу нескольких параметров делает результаты бесполезными. Полезно также запускать достаточно длинный фрагмент, чтобы стартовые накладные расходы не доминировали над временем обработки.

Производительность preview нельзя напрямую переносить на финальный export. Preview consumer может пропускать кадры и масштабировать изображение, тогда как офлайн-рендер обрабатывает каждый кадр и кодирует полное разрешение. Поэтому скорость почти realtime в окне не обещает такой же export.

Ошибки, предупреждения и диагностика

MLT пишет большую часть диагностических сообщений в stderr. Условно их можно разделить на три группы: framework не нашёл сервис или ресурс; plugin/backend открылся, но не принимает параметры; consumer начал работу, но decoder/encoder выдаёт warnings или errors. Правильная стратегия — найти первое сообщение, после которого состояние становится неправильным, а не реагировать на последнюю строку.

Если melt -query producers возвращает почти пустой список и появляется сообщение о том, что repository не содержит plugins, проблема обычно связана с путём установки модулей. Копирование одного melt.exe в отдельную папку редко работает: ему нужны MLT libraries, modules и их внешние зависимости. Исправляйте установку или repository path, а не добавляйте случайные DLL по одной.

Если producer invalid, проверьте, есть ли сервис, который должен открыть этот ресурс. Для обычного MP4 это часто avformat. Если avformat producer отсутствует, смена расширения файла не поможет. Если producer есть, запросите его metadata и проверьте, может ли underlying FFmpeg открыть этот codec.

Сообщения FFmpeg о PTS и DTS

Во время кодирования avformat может сообщать о timestamps, deprecated options, pixel format, non-monotonous DTS или других деталях. Не каждое warning фатально: процесс иногда продолжает рендер и создаёт корректный файл. Но игнорировать повторяющиеся сообщения нельзя, особенно если результат рассинхронизирован или muxer вынужден переписывать timestamps.

Чтобы локализовать проблему, сначала попробуйте тот же вход без дополнительных filters и transitions. Затем упростите параметры encoder. Если warning исчез, возвращайте опции по одной. Для проблем PTS/DTS полезно проверить временную базу, profile FPS, variable-frame-rate source и фильтры, меняющие темп. Если сообщение появляется только на одном повреждённом файле, перекодирование или remux исходника может быть более разумным, чем усложнение MLT-графа.

Неизвестный filter или transition

Ошибка service not found обычно означает отсутствие module, а не опечатку в media path. Проверьте точное имя через -query filters или -query transitions. Некоторые plugins добавляют namespace, например сервисы frei0r, avfilter или movit. Имя из GUI видеоредактора не всегда совпадает с MLT service ID, поэтому копирование названия эффекта из меню редактора ненадёжно.

Если сервис есть, но параметр не действует, запросите metadata конкретного service. Проверьте регистр, единицы измерения, mutable/animatable status и допустимый диапазон. Не все параметры можно менять во времени, даже если MLT в целом поддерживает keyframes.

Файл не создаётся

Самая частая причина — consumer не задан и melt просто проигрывает композицию. Вторая — output path недоступен для записи. Третья — encoder или muxer не запускается из-за неподдерживаемой комбинации codec/container. Сначала используйте простой локальный путь и минимальный -consumer avformat:test.mp4 vcodec=... acodec=..., затем возвращайте остальные опции.

Если процесс создаёт нулевой или очень маленький файл и завершается с ошибкой, смотрите stderr до первой encoder error. Если файл растёт, но команда не завершается, проверьте длину producer и playlist: live source или неверный EOF может не иметь ожидаемого конца.

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

Пути сначала разбирает shell, а затем MLT. На Windows и Unix правила quoting различаются, поэтому путь с пробелами нужно защищать на уровне shell. В batch и PowerShell синтаксис разный. Если команда работает с простым файлом в текущей папке, но ломается с полным путём, проблема почти наверняка в quoting или интерпретации специальных символов.

В XML shell уже не участвует, но действуют правила XML-экранирования. Амперсанд, кавычки в атрибутах и специальные символы должны быть корректно encoded. Для resource в property обычно удобнее текстовый узел, чем длинный атрибут.

Локаль и числовые значения

MLT хранит многие свойства как строки и преобразует их в числа с учётом locale. Это особенно заметно в XML и анимации, где десятичный разделитель может быть точкой или запятой. Непредсказуемая LC_NUMERIC способна превратить корректную на одной машине строку в ошибочное значение на другой. Для автоматизированного рендера разумно фиксировать locale окружения, если проект содержит дробные параметры.

В командной строке есть -setlocale, позволяющий сделать числовые строки чувствительными к locale. Использовать его нужно осознанно: переносимые скрипты обычно проще, когда числовой формат стандартизирован, а не зависит от пользовательских региональных настроек. В XML consumer locale может попадать в атрибуты сериализации, поэтому при сравнении файлов это тоже следует учитывать.

Если коэффициент масштаба, opacity или параметр анимации внезапно читается неправильно, проверьте не только синтаксис, но и decimal separator. Эта проблема особенно неприятна тем, что значения могут оставаться валидными числами, но иметь другой смысл, не вызывая явной ошибки.

Безопасность MLT XML и чужих проектов

MLT XML способен ссылаться на локальные файлы, плагины, устройства и consumer properties, поэтому чужой проект следует рассматривать как активную конфигурацию обработки, а не как безобидный текстовый документ. Перед серверным рендером полезно разбирать список ресурсов, разрешать только ожидаемые каталоги и запускать процесс с минимальными правами.

Устаревшие свойства consumer ante и post, способные запускать shell-команды, по умолчанию отключены. Переменная MLT_CONSUMER_ANTE_POST_ALLOWED может разрешить их, но включать её для непроверенных XML опасно. Если ваш собственный legacy-процесс действительно зависит от этих свойств, отделите доверенные проекты от пользовательских и не используйте общий worker без sandbox.

Дополнительный риск создают плагины. OpenFX, frei0r, LADSPA и другие внешние modules выполняют нативный код. MLT только загружает их как services, поэтому безопасность такого расширения определяется самим плагином и способом его установки. Production-среду лучше собирать с фиксированным набором необходимых modules, а не сканировать произвольные пользовательские каталоги.

Переменные окружения, которые реально помогают

Для диагностики MLT важнее всего знать несколько переменных. MLT_REPOSITORY переопределяет каталог plugin modules, MLT_DATA — путь к данным framework и модулей, MLT_PROFILE — profile по умолчанию, MLT_PROFILES_PATH — каталог profiles, MLT_CONSUMER и MLT_PRODUCER могут влиять на сервисы по умолчанию. Наличие переменной не означает, что её нужно задавать всегда: нормальная пакетная установка должна работать без ручных путей.

Переменные полезны, когда MLT запускается из нестандартного префикса, portable-дерева или build directory. В такой среде лучше собрать небольшой wrapper-скрипт, который задаёт все пути последовательно, чем экспортировать их в глобальный профиль пользователя. Иначе одна тестовая сборка способна неожиданно изменить поведение системной.

Для временной диагностики выводите значения окружения в лог рядом с melt -version и результатом -query. Это позволяет понять, почему два worker с одинаковым бинарником видят разные плагины или профили.

Запуск из каталога сборки

Разработчики и интеграторы нередко проверяют MLT до установки. В исходном проекте для этого предусмотрено окружение, которое добавляет пути к собранным библиотекам и modules. Запуск одного бинарника из build directory без правильного environment может дать ложное впечатление, что build пустая: executable стартует, но repository не находится.

Такой режим удобен для тестирования patch или собственного module, однако для готового production worker лучше устанавливать файлы в согласованный prefix. Смешивание build-tree libraries и системных plugin binaries может привести к ABI-конфликтам, которые сложнее диагностировать, чем обычное отсутствие сервиса.

Связка с проектами других видеоредакторов

Некоторые видеоредакторы используют MLT как движок и хранят проект в MLT XML либо создают MLT-compatible job для рендера. Такой файл иногда можно передать напрямую melt. Но совместимость зависит от services: frontend мог использовать собственные filters, титры, proxy-пути или modules, которых нет в отдельной установке MLT.

Поэтому правильная последовательность — открыть XML, определить profile и список mlt_service, затем проверить их через -query. Если проект содержит kdenlivetitle, специфические frei0r effects или другие дополнительные modules, чистый framework без них не воспроизведёт результат идентично. Нельзя считать любой файл с расширением .mlt полностью самодостаточным.

Для рендера job, экспортированного редактором, consumer может уже находиться внутри XML. Если его нет, запуск melt project.mlt обычно воспроизводит проект, а не сохраняет файл. В таком случае добавьте явный -consumer или используйте XML, подготовленный именно как render job.

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

MLT не обязан использоваться как обычный транскодер, но он удобен, если перед encode нужно одинаково обрабатывать много файлов: масштабировать, накладывать filter, добавлять заставку или нормализовать структуру timeline. Сценарий начинается с проверки avformat producer/consumer и выбора profile. Затем на одном коротком входе настраивается минимальная команда, после чего пути подставляются циклом.

Условия, относящиеся к media, лучше оставлять у producer, а encode settings выносить в preset. Тогда shell-цикл отвечает только за input/output names и обработку exit code. Логи сохраняются отдельно, а при ошибке файл не отправляется на следующий этап. Такой процесс намного надёжнее гигантской строки, которая строится из десятка условных переменных.

Практический сценарий: заставка, основной ролик и финальный кадр

Линейную композицию можно описать тремя producers. Для заставки задаётся нужная длительность, основной клип берётся целиком или по in/out, финальное изображение получает собственный out. Если нужен наплыв между заставкой и роликом, применяются -mix/-mixer или отдельная многодорожечная схема с transition. Для финального изображения можно анимировать geometry или opacity подходящего filter.

В таком проекте удобно сразу использовать MLT XML. Заставка и финальный блок становятся переиспользуемыми producers, а основное видео подменяется параметром или генератором XML. Это хороший пример того, почему framework удобен для массовой генерации: монтажная логика остаётся постоянной, меняется только ресурс.

Практический сценарий: серверный рендер MLT XML

Worker получает XML и каталог media, выполняет предварительную проверку сервисов, затем запускает melt -progress2 с явным output consumer. Перед стартом полезно убедиться, что XML не выходит за разрешённый root, а все media доступны на чтение. Worker фиксирует profile, environment, версию melt и список обязательных modules.

Если задача превышает лимит времени, process можно завершить снаружи. Временный output лучше писать в отдельное имя и переименовывать только после успешного exit code, чтобы недорендеренный файл не выглядел готовым. Для больших очередей полезно ограничить concurrency и учитывать encoder/GPU sessions.

Практический сценарий: генерация чернового preview

Для быстрого preview нет необходимости менять весь проект. Сохраняется основной profile, а consumer получает уменьшенный scale. Можно также выбрать более быстрый encoder или вовсе использовать realtime playback. Важно понимать, что preview scaling влияет на запрос размеров к effects; некоторые plugins могут давать отличия, поэтому финальный quality control выполняется на полном разрешении.

Если slow effect не поддерживает preview scaling, его можно временно отключать в черновом варианте проекта, но такой preview уже не является точной копией. Лучше явно маркировать его как draft, чем выдавать ускоренный граф за окончательный render.

Практический сценарий: извлечение XML из команды

Когда экспериментальная команда наконец даёт нужный результат, её можно направить в XML consumer и получить структурированный проект. Это полезно для обучения: в XML видно, какие playlists, producers и transitions создал melt из компактного синтаксиса. Затем файл можно отформатировать, присвоить понятные ID и вынести повторяющиеся properties.

Обратный процесс тоже работает: XML загружается как producer, а melt обеспечивает preview или render. Таким образом, команда и XML — два представления одной service network, а не две разные системы.

Когда MLT Framework tools неудобен

Если задача требует визуально двигать клипы по timeline, быстро смотреть waveform, мышью расставлять keyframes и менять десятки effects в процессе творческого монтажа, чистый melt будет медленнее GUI-редактора. Framework даёт механизм, но не заменяет полноценную монтажную оболочку.

Для простого remux или stream copy без декодирования MLT тоже часто избыточен. Его модель ориентирована на получение и обработку кадров, а не на максимально прямое копирование packet streams. В таких задачах FFmpeg CLI обычно короче и ближе к низкоуровневой операции.

Ещё одно ограничение — зависимость services от сборки. Команда с avfilter, Qt, frei0r, Movit, OpenFX или специализированным hardware consumer может работать только там, где соответствующий module и его внешние libraries установлены. Для переносимости нужно контролировать runtime, а не хранить одну команду и надеяться на одинаковое окружение.

Сравнение MLT Framework tools с аналогами

Программа	Лучше подходит для	Главное ограничение
MLT Framework tools	Скриптовых многодорожечных композиций, MLT XML, автоматического рендера и встраивания монтажного движка	Нет полноценной графической тайм-линии; набор сервисов зависит от сборки
FFmpeg	Транскодирования, remux, filter_complex, потоковой обработки и точного управления codec/muxer	Большие монтажные проекты и переиспользуемая timeline-структура быстро становятся громоздкими
GStreamer	Realtime media pipelines, capture, playback, streaming и построения приложений из элементов	Редакторская timeline-модель и готовая сериализация монтажа требуют дополнительной инфраструктуры
VapourSynth	Скриптовой покадровой видеофильтрации, восстановительных цепочек и frame serving	Не ориентирован на полноценный аудио-видеомонтаж и конечный mux/encode как единый workflow
MoviePy	Высокоуровневой генерации и монтажа видео из Python-скриптов	Меньше низкоуровневого контроля над медиаграфом и производительностью, чем у специализированных frameworks

MLT стоит выбирать, когда нужен именно монтажный граф с дорожками, transitions, filters и сериализуемым проектом, который можно запускать как команду или использовать из собственного приложения. FFmpeg лучше для прямой работы с codecs, containers и потоками; GStreamer — для realtime pipeline; VapourSynth — для кадроориентированной фильтрации; MoviePy — для простых Python-сценариев с высоким уровнем абстракции. Если основная работа выполняется вручную на визуальной тайм-линии, удобнее взять редактор с интерфейсом, использующий один из этих движков внутри.

Краткий справочник команд по задачам

Задача	Команда или опция	Что проверить
Проверить версию	melt -version	Запускается ли нужный бинарник
Показать services	melt -query	Нет ли пустого repository
Показать producers	-query producers	Наличие avformat, image/text producers
Показать consumers	-query consumers	avformat, xml, null, preview outputs
Показать profiles	-query profiles	Нужное разрешение и FPS
Выбрать profile	-profile имя	Размер, FPS, aspect
Обрезать source	in=... out=...	Контекст producer/cut
Начать новую дорожку	-track	Нумерация a_track/b_track
Добавить filter	-filter service	Metadata и диапазон действия
Добавить transition	-transition service	Дорожки, in/out, свойства
Записать файл	-consumer avformat:file	Codec, container, writable path
Печатать прогресс	-progress2	Логи и exit code
Сериализовать XML	-consumer xml:file.mlt	Пути и профиль
Тест без output	-consumer null	Производительность graph

Частые вопросы

MLT Framework tools открывает MP4, MOV, MKV и другие форматы?

Да, если установлен avformat producer и underlying FFmpeg build умеет читать соответствующий container и codec. Расширение само по себе не является гарантией. Для диагностики проверьте producers и попробуйте минимальную команду с одним файлом.

Можно ли монтировать без перекодирования?

MLT ориентирован на декодирование кадров, их обработку и выдачу consumer. Общего smart-rendering или stream-copy режима для произвольной многодорожечной композиции ждать не стоит. Если нужно только соединить совместимые streams или сменить container без обработки, лучше использовать инструмент, предназначенный для remux.

Как отрендерить только часть проекта?

Ограничьте in/out у нужного producer, playlist entry или верхнего объекта в XML. В командной строке важно понимать, к какому cut относится свойство. Для точного диапазона итоговой программы структурированный XML обычно проще, чем длинная цепочка относительных операций.

Почему melt project.mlt показывает видео, но не сохраняет MP4?

Потому что без output consumer melt использует consumer воспроизведения. Добавьте -consumer avformat:output.mp4 с подходящими codec settings либо используйте XML, где consumer уже описан.

Как вывести прогресс в скрипт?

Используйте -progress2. Он печатает отдельные строки с текущим состоянием и подходит для логов. Не забывайте обрабатывать exit code и stderr: достижение последнего процента не заменяет проверку успешного завершения.

Почему filter из документации отсутствует?

Потому что modules опциональны. Проверьте -query filters и пакет, который поставляет нужный module. Имя effect в GUI другого редактора может не совпадать с MLT service ID.

Можно ли запускать MLT без графического окружения?

Да, если используется неинтерактивный consumer. Для avformat, null или XML окно не нужно. Однако Qt-based producers/filters могут требовать offscreen-конфигурацию Qt, поэтому headless worker нужно тестировать с теми же титрами и effects, которые будут в реальных проектах.

Как узнать, какие кодеки доступны?

Выполните melt -query video_codecs и melt -query audio_codecs. Для контейнеров используйте -query formats. Это надёжнее любой общей таблицы, потому что показывает возможности конкретной FFmpeg-сборки.

Почему рендер медленнее воспроизведения?

Preview может уменьшать разрешение, пропускать кадры или использовать другой consumer, тогда как финальный export обрабатывает каждый кадр и кодирует полный output. Сравнивать их скорость напрямую нельзя. Для поиска bottleneck используйте null consumer и одинаковый профиль.

Можно ли ускорить рендер всеми ядрами?

Часть codec уже многопоточна, а consumer может параллельно готовить кадры. Увеличение threads и real_time parallelism помогает не всегда. Измеряйте на одном проекте и следите за I/O и памятью, иначе oversubscription снизит скорость.

Что делать, если melt -query не видит plugins?

Проверьте, что executable запускается вместе с правильными libraries и module directory. Сверьте MLT_REPOSITORY и prefix установки. Не переносите один бинарник в отдельную папку без runtime.

Как перенести XML-проект на другой компьютер?

Используйте контролируемые относительные пути, одинаковый profile и список required services. Перенос одного XML недостаточен, если проект использует внешние media, fonts или plugins. Хорошая практика — пакетировать project, media и presets в предсказуемой directory tree.

Как проверить свойства конкретного filter?

Запросите его через melt -query filter=service. Аналогично работают запросы producer, consumer, transition и preset. Metadata сообщает типы, допустимые значения и описание параметров, если module их публикует.

Можно ли сделать анимацию параметра?

Да, если service поддерживает анимацию данного property. Используются keyframe-строки с позициями и типами интерполяции. Сначала проверьте простой переход между двумя ключами, затем добавляйте smooth-кривые и отрицательные позиции.

Чем -serialise отличается от XML consumer?

-serialise сохраняет командное представление, а XML consumer создаёт структурированную сериализацию service graph. Для чтения человеком, автоматического редактирования и сложных проектов XML обычно удобнее.

Почему один и тот же XML даёт другой результат на двух системах?

Причиной могут быть разные modules, FFmpeg codecs, versions plugins, fonts, color management, drivers или profile defaults. Для воспроизводимости фиксируйте runtime и проверяйте -query, а не только project file.

Проверочный чек-лист перед длинным рендером

1. Убедиться, что запускается нужный melt и сохранить вывод -version.
2. Проверить обязательные producers, filters, transitions и consumers через -query.
3. Выбрать profile и подтвердить разрешение, FPS, progressive mode и aspect.
4. Открыть каждый input минимальной командой, особенно если codecs или paths необычные.
5. Сделать короткий тестовый диапазон с теми же filters и transitions.
6. Проверить output container, video codec, audio codec и pixel format.
7. Включить -progress2 и сохранить stderr в log.
8. Для headless среды отдельно проверить Qt/text services и fonts.
9. Для GPU path убедиться по логам, что выбран нужный backend, и иметь software fallback.
10. После успешного exit code открыть output и проверить длительность, звук и несколько контрольных кадров.

Такой порядок снижает стоимость ошибок: проблема обнаруживается на коротком отрезке, прежде чем часы рендера будут потрачены на неверный profile или недоступный encoder. Для постоянной инфраструктуры этот checklist лучше превратить в автоматический preflight, который запускается при развертывании worker и перед обработкой неизвестного XML.

Итоговая схема работы

MLT Framework tools эффективен, когда медиапроект нужно описывать как воспроизводимую структуру. Сначала проверяются services и profile, затем строятся producers и playlists, при необходимости добавляются tracks, filters и transitions, после чего выбирается consumer. Короткую композицию удобно собрать прямо в melt, длинную — сохранить в MLT XML, а encode settings вынести в presets.

Надёжность достигается не количеством параметров, а контролем окружения. Один и тот же service graph должен видеть одинаковые modules, codecs, fonts, profiles и paths. Headless-рендер требует явного consumer, пакетная очередь — progress и exit-code handling, переносимый XML — аккуратных ресурсов и зависимостей. При таком подходе MLT превращается из необычной консольной команды в предсказуемый движок для автоматизированного монтажа и рендера.

Chain и link: обработка producer до монтажа

Помимо обычного producer в melt есть понятия -chain и -link. Chain создаёт producer, к которому можно последовательно присоединять link-services. Такая модель полезна для операций, меняющих временную интерпретацию или подготавливающих источник до того, как он попадёт в playlist. В отличие от filter, link находится в цепочке producer и участвует в запросе кадров как часть источника.

Практическая причина пользоваться chain — отделить обработку исходника от эффектов, которые относятся к монтажному месту. Например, time-related преобразование source логичнее держать в chain, а цветовой filter, который должен действовать только на один cut, — привязать к clip. Точный список links всегда проверяется через melt -query links, потому что эта категория заметно зависит от modules.

Если проект уже выражен XML, chain и link тоже имеют структурное представление. При генерации XML сторонним скриптом полезно не сваливать все операции в один длинный filter-stack: разделение source transformation, timeline composition и output processing упрощает повторное использование и диагностику.

Групповые свойства и порядок аргументов

Командная строка melt чувствительна к последовательности. Это не набор независимых flags, которые parser может переставить произвольно: аргументы постепенно создают сервисы и меняют текущий контекст. Поэтому одинаковые слова, расположенные до и после -track, -filter или -consumer, могут относиться к разным объектам.

-group помогает сократить повторение properties, но одновременно делает область действия менее очевидной. Если group открыта перед несколькими producers, её свойства могут распространиться дальше, чем планировалось. Для поддерживаемого скрипта лучше использовать group только для короткого, визуально очевидного блока и сразу завершать её пустой group. В XML аналогичная логика обычно читается проще, потому что свойства вложены в конкретный element.

При отладке длинной команды полезно временно разнести аргументы по строкам shell с продолжением строки. Тогда каждый producer, filter, transition и consumer виден отдельным блоком. Это не меняет MLT-граф, но резко снижает число ошибок, вызванных тем, что property оказался после не того service.

Consumer multi и несколько выходов

MLT содержит consumer multi, который может передавать один поток нескольким дочерним consumers. Теоретически это позволяет одновременно показывать preview и писать файл или формировать несколько выходов. На практике такой graph требует внимания к производительности и возможностям дочерних services: самый медленный output способен повлиять на всю цепочку.

Если outputs имеют разные profiles или размеры, нужно особенно аккуратно проектировать преобразование. Preview scaling не поддерживается для multi consumer как обычное свойство масштаба, поэтому один полный render плюс маленькое окно не сводится к добавлению scale=0.5 на верхний multi. Часто проще разделить preview и финальный export на отдельные процессы, использующие один XML.

Multi consumer полезен там, где outputs тесно связаны и должны получать одни и те же кадры, но он не является заменой job queue. Два независимых deliverable с разными codecs, filters или durations обычно удобнее рендерить отдельными заданиями из общей сериализованной композиции.

Логи и уровни подробности

-loglevel позволяет выбирать уровень сообщений MLT: от quiet и критических уровней до warning, info, verbose, debug и timings. Для обычного batch job достаточно warning/info, а debug включают на коротком воспроизводимом участке. Постоянный debug для длинного проекта способен создать огромный log и сам ухудшить I/O.

Удобно разделять progress и diagnostic output. -progress2 нужен для состояния задания, а stderr — для причин ошибок. Wrapper может парсить строки прогресса, но исходный stderr лучше сохранять без агрессивной фильтрации: сообщения external libraries нередко содержат единственную подсказку о codec или device error.

При сравнении двух машин сохраняйте не только log рендера, но и outputs -version, -query producers, -query filters, -query consumers и codecs. Это превращает на сервере не работает в сравнимый набор фактов.

Профиль и исходный FPS: что происходит при несовпадении

Producer может читать источник с частотой кадров, отличной от profile композиции. MLT должен выдавать кадры в темпе profile, поэтому временная выборка источника адаптируется к timeline. Для обычного монтажа это ожидаемое поведение, но при точном анализе движения или интерлейсе несогласованность profile способна изменить результат.

Не стоит автоматически выбирать profile по первому входному файлу, если итоговый deliverable заранее определён. Проект с несколькими sources 24, 25 и 30 fps всё равно должен иметь одну временную базу композиции. Выберите целевой profile сознательно, затем проверяйте наиболее чувствительные места — быстрые движения, переходы, титры и звук.

Если требуется сохранить переменную частоту кадров конкретного source как есть, MLT может быть не лучшим уровнем для такой задачи. Timeline framework естественно работает с профилем и кадрами. Для packet-level операций без приведения к timeline чаще подходит FFmpeg remux/transcode workflow.

Цвет, pixel format и 10-bit цепочки

MLT profile содержит colorspace, а конкретные modules могут поддерживать дополнительные transfer characteristics, primaries и высокую разрядность. Однако нельзя считать всю цепочку автоматически 10-bit только потому, что source и encoder это умеют. Каждый filter и transition между ними должен поддерживать соответствующий image format, иначе произойдёт преобразование или service окажется несовместим.

При HDR или 10-bit задаче сначала строят минимальный path producer → consumer без effects и проверяют pixel format и metadata output. Затем filters возвращают по одному. Если после конкретного effect появляется 8-bit output или неправильная transfer function, проблема локализована. Для color-critical workflow MLT требует такого же контроля, как любой другой modular framework.

Свойство pix_fmt у avformat consumer относится к encoder output, но не описывает все промежуточные форматы MLT. Поэтому установка yuv420p10le не гарантирует, что все filters считались в 10-bit. Документация module и тестовые кадры важнее одного параметра consumer.

Работа с live-источниками

Некоторые producers представляют устройства или network streams и не имеют заранее известной конечной длины. Это меняет логику playlist: length может быть неизвестна, отрицательные позиции относительно конца неприменимы, а batch job не завершится сам, пока source остаётся live. Для записи такого потока нужно задавать собственное условие остановки или ограничивать duration внешним process manager.

Live-сценарий сильнее зависит от real_time, buffer и стабильности consumer. В офлайн-render кадр можно считать столько, сколько потребуется; в capture/streaming опоздавший frame уже нельзя догнать без решения о drop или задержке. Поэтому settings, оптимальные для файла, не нужно бездумно переносить на эфирный pipeline.

Перед реальным эфиром или долгой записью test должен включать потерю network, временное исчезновение устройства и заполнение диска. MLT предоставляет graph, но recovery policy обычно реализует окружающее приложение или script.

Интеграция через API и языковые bindings

Когда генерация XML и вызов melt перестают быть удобными, тот же framework можно использовать через C API, C++ wrapper MLT++ и scripting bindings, доступные в конкретной сборке. Преимущество — приложение создаёт producers, filters, transitions и consumers напрямую, не парсит progress text и может слушать события consumer.

Но API не даёт больше эффектов сам по себе: он обращается к тому же repository services. Если на машине отсутствует avformat или frei0r module, Python/C++-программа столкнётся с той же проблемой, что и melt. API нужен для управления жизненным циклом, UI и динамическими graph changes, а не для обхода runtime-зависимостей.

Для небольшого backend обычно разумно начать с XML + subprocess: это проще развернуть и отлаживать. Переход к API оправдан, когда нужны интерактивные изменения, длительно живущий graph, callback на каждый frame, тесная интеграция с собственным UI или более сложное управление ресурсами.

Как выбрать между командой и MLT XML

Ситуация	Командная строка	MLT XML
Один клип + filter	Проще и короче	Избыточен
Два-три клипа и переход	Удобна для эксперимента	Полезен после стабилизации
Много дорожек	Быстро теряется читаемость	Явные ID и связи
Генерация сервером	Хороша для простых параметров	Удобен как структурированный job
Повторное редактирование	Сложно менять середину graph	Можно редактировать отдельные elements
Передача между MLT-приложениями	Ограниченно	Естественный формат сериализации

Практический компромисс — прототипировать короткую схему в melt, сериализовать её через XML consumer, а затем поддерживать XML как основной project template. Output settings можно держать отдельно в preset, чтобы монтажная структура не зависела от конкретного deliverable.

Что проверять после рендера

Успешный exit code означает, что процесс завершился без зафиксированной фатальной ошибки, но editorial quality control всё равно нужен. Минимум стоит проверить длительность файла, наличие video/audio streams, ожидаемые resolution/FPS, несколько кадров на границах cuts и transitions, начало и конец звука. Если проект содержит subtitles или titles, проверьте fonts и non-ASCII characters.

Для автоматической системы полезен ffprobe или другой независимый media inspector после MLT. Он не заменяет визуальный просмотр, но быстро обнаруживает нулевую длительность, другой codec, неожиданное число каналов или неправильный frame size. Такой postflight особенно важен после обновления FFmpeg или package dependencies.

Контрольные кадры можно извлекать в заранее известных временных точках и сравнивать с эталонными только для стабильных deterministic проектов. Effects с аппаратным backend или разными library versions могут давать небольшие отличия, поэтому побитовое сравнение подходит не всегда.