FFmpeg

FFmpeg — это набор свободных мультимедийных инструментов и библиотек, рассчитанный прежде всего на работу из командной строки и на встраивание в другие приложения. Он умеет читать, декодировать, кодировать, перекодировать, объединять и разбирать контейнеры, фильтровать аудио и видео, анализировать потоки, захватывать данные с устройств и работать с сетевыми протоколами. Для разовой конвертации одного ролика FFmpeg требует больше подготовки, чем обычный графический конвертер, зато в повторяемых задачах даёт точный контроль над кодеками, потоками, фильтрами и автоматизацией.

Короткий ответ: кому нужен FFmpeg и какую задачу он решает

FFmpeg подходит тем, кому недостаточно кнопки «конвертировать». Его выбирают для воспроизводимых медиапроцессов: массового перекодирования, подготовки прокси, извлечения дорожек, ремультиплексирования без перекодирования, нормализации звука, генерации превью, сборки HLS-пакетов, трансляции, контроля нескольких аудио- и субтитровых потоков, а также для серверной обработки. Команда фиксирует все параметры явно, поэтому одинаковую операцию можно повторить на сотнях файлов или перенести в сценарий автоматизации.

Новичку важно сразу принять особенность продукта: у FFmpeg нет привычного окна проекта, таймлайна, панели эффектов и кнопки Undo. Основной пользовательский интерфейс — терминал, где вводится команда вида «входы → параметры → выходы». Результат обычно записывается в новый файл. Роль «проекта» выполняют исходники, текст команды, сценарий оболочки, списки файлов и вспомогательные ресурсы вроде субтитров или шрифтов. Если задача требует визуального монтажа с предварительным просмотром и перетаскиванием клипов, удобнее использовать редактор или графический конвертер, а FFmpeg оставить для технической обработки и автоматизации.

Состояние продукта, разработка и актуальная версия

FFmpeg остаётся активно развиваемым проектом. На дату проверки актуальная стабильная версия — FFmpeg 9.0.1 «Lei», выпущенная 12 августа 2026 года; ветка 9.0 была отделена от основной ветки 26 июня 2026 года. При этом официальный проект подчёркивает различие между release-ветками и development branch: стабильные ветки получают выбранные исправления, а основная ветка развивается быстрее и получает новые изменения раньше. Для обычной рабочей станции разумнее выбирать готовую стабильную сборку от поставщика, на которого ведёт официальная страница загрузки, если нет конкретной причины собирать development branch.

Разработчик в практическом смысле — FFmpeg Project, то есть сообщество проекта, поддерживающее исходный код, библиотеки, инструменты и документацию. Набор переносим между Linux, macOS, Windows, BSD-системами и Solaris. Однако «поддержка платформы» не означает одинаковый двоичный пакет и одинаковый набор кодеков: официальный сайт FFmpeg распространяет исходный код, а готовые исполняемые файлы для Windows, macOS и отдельных Linux-сценариев публикуют сторонние поставщики, на которых официальный раздел Download даёт ссылки.

Лицензия и почему состав конкретной сборки имеет значение

Базовая лицензия FFmpeg — LGPL версии 2.1 или более поздней. Часть компонентов распространяется на условиях GPL; если при сборке включить такие компоненты, требования GPL распространяются на получившуюся конфигурацию. Для домашней конвертации это обычно не создаёт практических сложностей, но для разработчика, который встраивает библиотеки FFmpeg в распространяемый продукт, важны флаги сборки, способ линковки и лицензии дополнительных библиотек. Поэтому юридически значим не только номер FFmpeg, но и конкретная конфигурация, которую показывает ffmpeg -buildconf.

Отдельной коммерческой проприетарной лицензии у проекта нет. Это не означает, что любой сторонний кодек или библиотека автоматически получает те же условия: сборка может включать внешние зависимости с собственными лицензиями и патентными ограничениями. Если FFmpeg используется внутри коммерческого продукта, корректная проверка начинается с -version, -buildconf и перечня задействованных библиотек, а не с общего утверждения «FFmpeg бесплатный, значит ограничений нет».

Безопасный путь получения и различия между платформами

Официальный маршрут начинается на странице Download FFmpeg. Там прямо сказано, что FFmpeg предоставляет исходный код, а готовые пакеты и исполняемые файлы перечислены отдельно. Для Linux страница ведёт к пакетам Debian, Ubuntu и другим источникам; для Windows — к поставщикам готовых Windows builds; для macOS — к готовым статическим сборкам. Это важная граница: случайный архив с неизвестного сайта нельзя считать «официальным FFmpeg» только из-за названия файла.

Если нужен именно исходный код, официальный раздел даёт подписанные архивы и ключ для проверки PGP-подписи. Для готовой сторонней сборки такой же механизм может не применяться: тогда нужно проверять происхождение конкретного поставщика, контрольные суммы, подпись исполняемого файла, если она публикуется, и обязательно фиксировать вывод ffmpeg -version после установки. Сохранённый вывод версии позволяет позже понять, почему одна и та же команда ведёт себя по-разному на двух машинах.

Для Windows типовая готовая сборка представляет собой каталог с ffmpeg.exe, ffprobe.exe и, в зависимости от поставщика, ffplay.exe. Можно вызывать исполняемый файл полным путём или добавить каталог в переменную PATH. На macOS и Linux часто удобнее пакетный менеджер, но версия и набор опций зависят от репозитория. Универсального «минимального объёма ОЗУ» или единого системного требования для всех сборок проект не задаёт: нагрузка определяется кодеком, разрешением, фильтрами, числом потоков, аппаратным ускорением и тем, как конкретный бинарник был собран.

Карта интерфейса: что заменяет окна, панели и проект

Вместо графического интерфейса у FFmpeg есть несколько уровней управления. Первый — командная оболочка: PowerShell или Windows Terminal в Windows, Terminal в macOS, терминал выбранной оболочки в Linux. Второй — синтаксис программы ffmpeg, где параметры до и после входа имеют разный смысл. Третий — диагностический вывод в stderr: там видны версия сборки, сведения о входах, выбранные потоки, кодеки выхода, прогресс, скорость и предупреждения. Четвёртый — отдельный инструмент ffprobe, который лучше использовать для формальной проверки медиа, чем пытаться читать весь лог ffmpeg глазами.

Самая важная логика команды — область действия параметров. Общие параметры задаются глобально, входные параметры относятся к следующему входу, выходные — к следующему выходу. Порядок имеет значение. Упрощённая форма выглядит так: ffmpeg [global_options] {[input_options] -i input} ... {[output_options] output} .... Ошибка новичка — поставить параметр туда, где FFmpeg применит его не к тому объекту, или использовать одну и ту же опцию в ожидании, что она автоматически распространится на все выходы.

Что считать проектом, импортом и сохранением промежуточной работы

FFmpeg не импортирует медиа в библиотеку проекта. Путь после -i открывает файл, URL или устройство непосредственно во время выполнения. Поэтому исходник остаётся самостоятельным объектом на диске или в сети. Это снижает риск «потерять медиатеку внутри проекта», но повышает требования к путям: если сценарий перенесли на другой компьютер, относительные и абсолютные пути должны снова указывать на реальные файлы.

Редактируемый промежуточный результат — не специальный формат FFmpeg. Для сложной работы стоит сохранять четыре вещи: неизменённые исходники; текст команды или сценарий; служебные текстовые файлы, например список concat; данные о версии и конфигурации сборки. Если между этапами нужен промежуточный медиафайл, его формат выбирают по задаче. Для без потерь качества можно ремультиплексировать потоки с -c copy, если контейнер их поддерживает, либо использовать подходящий промежуточный кодек. Нельзя считать повторное перекодирование «сохранением проекта»: каждое поколение с потерями может менять качество.

Маршрут первого часа

1. Получить FFmpeg через официальный Download-маршрут и убедиться, что запускаются ffmpeg и ffprobe.
2. Сохранить вывод ffmpeg -version и ffmpeg -buildconf, чтобы знать номер и состав сборки.
3. Взять короткий тестовый файл-копию, а не единственный оригинал.
4. Посмотреть структуру через ffprobe, записать разрешение, длительность, число аудио- и субтитровых потоков.
5. Сделать одну операцию без перекодирования через -c copy, чтобы понять контейнеры и stream mapping.
6. Сделать одно перекодирование на коротком фрагменте и сравнить размер, параметры и воспроизведение.
7. Только после этого переходить к фильтрам, пакетной обработке и длинным заданиям.

Практический справочник: 16 воспроизводимых задач

Как установить FFmpeg и безопасно проверить первый запуск

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

Откройте официальный раздел Download. Для исходников используйте опубликованный архив и при необходимости проверку подписи; для готового бинарника перейдите по ссылке поставщика, перечисленного в разделе вашей ОС. После установки или распаковки откройте терминал в новой сессии, чтобы обновлённый PATH применился, и выполните:

ffmpeg -version
ffprobe -version
ffmpeg -buildconf
ffmpeg -formats
ffmpeg -encoders
ffmpeg -filters

Первые две команды подтверждают, что оболочка находит нужные исполняемые файлы. -buildconf показывает опции сборки. Списки форматов, энкодеров и фильтров важнее чужой инструкции: наличие конкретного libx264, аппаратного энкодера или фильтра зависит от сборки. Если команда «не найдена», не скачивайте второй случайный архив поверх первого. Сначала выясните, где лежит бинарник и какой путь видит оболочка.

Проверка результата. В выводе ffmpeg -version должны быть версия FFmpeg и версии библиотек; ffprobe -version должен запускаться из той же установки. Сохраните этот текст в журнал проекта. Безопасный откат: поскольку установка обычно не изменяет медиаданные, достаточно убрать ошибочный каталог из PATH или удалить распакованную сборку и вернуть предыдущую. Не перезаписывайте системный бинарник вручную.

Как исследовать файл через ffprobe до конвертации

Цель. До любой обработки точно понять, что находится в контейнере: сколько потоков, какие у них типы, длительность и базовые параметры. Это предотвращает ситуацию, когда после конвертации неожиданно исчезает вторая аудиодорожка или субтитры.

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

ffprobe -v error -show_format -show_streams input.mkv
ffprobe -v error -show_format -show_streams -of json input.mkv

Для автоматизации сократите вывод через -show_entries. Например, можно запросить только нужные поля формата и потоков, а -select_streams использовать для выбора определённого типа потока. JSON удобнее свободного текстового лога, потому что его можно разбирать программно. Не пытайтесь определять формат только по расширению файла: контейнер и реальное содержимое нужно смотреть по данным, которые считывает демультиплексор.

Проверка результата. Сверьте количество video/audio/subtitle streams, duration и параметры видеопотока. После обработки повторите тот же запрос для нового файла и сравните структуру. Типичная ошибка: анализировать только первый видеопоток и считать, что других дорожек нет. Откат: ffprobe ничего не изменяет, поэтому повторный запуск безопасен; если путь ошибочен, исправьте путь вместо переименования исходника без необходимости.

Как сменить контейнер без перекодирования потоков

Цель. Перепаковать совместимые аудио-, видео- и служебные потоки в другой контейнер без потери качества от повторного кодирования. Для этого используется stream copy — -c copy. Это быстрый путь, когда кодеки уже подходят целевому контейнеру.

Сначала исследуйте исходник через ffprobe. Затем выберите контейнер, который допускает имеющиеся кодеки. Команда с явным сохранением всех потоков может выглядеть так:

ffmpeg -n -i input.ts -map 0 -c copy output.mkv

-map 0 просит включить потоки из первого входа явным образом, а -c copy запрещает декодирование и повторное кодирование выбранных потоков. -n полезен как страховка: FFmpeg не должен перезаписывать существующий файл. Если контейнер не поддерживает какой-либо поток или его способ упаковки, операция завершится ошибкой; это не повод добавлять -y или удалять поток вслепую.

Проверка результата. Сравните ffprobe до и после: кодеки должны остаться прежними, а контейнер — измениться. Проверьте воспроизведение начала, середины и конца, переключение дорожек и субтитров. Типичная ошибка: ожидать, что -c copy исправит несовместимый кодек. Он ничего не перекодирует. Откат: удалите только новый output.mkv; исходник команда не меняет.

Как перекодировать видео в MP4 с явным выбором видео и аудио

Цель. Получить MP4 с H.264-видео и AAC-аудио для сценария, где такая пара поддерживается целевой системой. Перед запуском проверьте, что ваша сборка действительно содержит выбранный энкодер. Для libx264 он должен присутствовать в выводе ffmpeg -encoders.

ffmpeg -n -i input.mkv -map 0:v:0 -map 0:a:0? -c:v libx264 -crf 20 -c:a aac output.mp4

Знак вопроса после аудиокарты делает наличие первого аудиопотока необязательным; если вход немой, команда не должна падать только из-за отсутствия audio stream. CRF относится к конкретному энкодеру libx264 и управляет компромиссом качества и битрейта, а не является универсальной «шкалой качества FFmpeg». Если libx264 в сборке отсутствует, сначала выберите реально доступный видеокодер и изучите его параметры; простая замена имени без понимания rate control даст другой результат.

Проверка результата. ffprobe должен показать контейнер MP4, выбранный видеокодек и AAC для аудио, если аудио было. Сравните длительность и посмотрите несколько сложных сцен. Типичная ошибка: терять дополнительные дорожки из-за выбора только 0:a:0. Если они нужны, заранее спроектируйте mapping. Откат: благодаря -n существующий файл не затрётся; для нового варианта используйте другое имя, например output-crf22.mp4.

Как уменьшить размер файла без слепого снижения качества

Цель. Снизить объём видео управляемо, понимая, за счёт чего возникает экономия: более сильного сжатия, меньшего разрешения, меньшей частоты кадров, другого кодека или сочетания этих факторов. Опасный подход — просто задать произвольный низкий битрейт и судить по размеру. Правильнее сначала определить требования к воспроизведению и проверить короткий репрезентативный фрагмент.

Для libx264 один из распространённых режимов — Constant Rate Factor. В нём меньшее значение CRF означает более высокое качество и, как правило, больший поток данных, а большее — более сильное сжатие. Это свойство энкодера, а не общий параметр всех кодеков. Пример:

ffmpeg -n -i input.mp4 -c:v libx264 -crf 23 -c:a aac output-crf23.mp4

Не существует одного CRF, гарантирующего заданный размер для любого видео: сложность движения, шум, зерно и детализация меняют требуемый битрейт. Если ограничение связано с разрешением, добавьте масштабирование, например:

ffmpeg -n -i input.mp4 -vf "scale=w=1280:h=720" -c:v libx264 -crf 23 -c:a aac output-720p.mp4

Такое масштабирование принудительно делает 1280×720 и может изменить исходное соотношение сторон. Для реальной работы сначала посмотрите размеры входа через ffprobe и подберите выражение scale, сохраняющее нужную геометрию. Не уменьшайте разрешение автоматически, если конечная система требует исходного растра или если в кадре важен мелкий текст.

Проверка результата. Сравните размер файлов, длительность, разрешение и кодек через ffprobe, затем просмотрите сцены с быстрым движением, градиентами, мелкими деталями и тёмными участками. Типичная ошибка: оценивать качество только по неподвижному первому кадру. Безопасный повтор: храните варианты под разными именами и меняйте один параметр за раз — так понятно, что именно повлияло на результат.

Как точно вырезать фрагмент и не испортить исходник

Цель. Создать отдельный клип заданной длительности, не меняя оригинал. Здесь важно различать быстрое копирование с привязкой к ключевым кадрам и точное декодирование с повторным кодированием. Если нужен монтажный стык «до кадра», stream copy может дать неожиданную начальную точку, потому что кодированный поток не обязан иметь ключевой кадр ровно в требуемом месте.

Для точного практического варианта используйте декодирование и перекодирование. Например, чтобы начать около 30-й секунды и получить 20 секунд:

ffmpeg -n -ss 00:00:30 -i input.mp4 -t 00:00:20 -c:v libx264 -crf 20 -c:a aac clip.mp4

Перед этим убедитесь, что libx264 доступен. -ss задаёт позицию поиска, -t — продолжительность создаваемого фрагмента. Для длинного материала можно сначала сделать черновую копию быстро, но финальный точный стык лучше проверять по кадрам и временным меткам. Если требуется сохранить все дополнительные потоки, явный -map нужно добавить отдельно; команда выше намеренно ориентирована на основной video/audio.

Проверка результата. ffprobe должен показать ожидаемую длительность с учётом особенностей временных баз; визуально проверьте первый и последний кадры и синхронность звука. Типичная ошибка: добавить -c copy, ожидать точный покадровый разрез и считать смещение багом. Откат: новый clip.mp4 удаляется без воздействия на исходник. Если точка неверна, меняйте только -ss и повторяйте под новым именем.

Как извлечь аудиодорожку в отдельный файл

Цель. Получить из видео самостоятельный аудиофайл для монтажа, расшифровки или анализа. Сначала через ffprobe определите, сколько аудиопотоков есть и какой нужен. Не полагайтесь на то, что «первая дорожка» обязательно содержит требуемый язык или микс.

Если нужен универсальный несжатый WAV для дальнейшей обработки, можно декодировать выбранный поток в PCM:

ffmpeg -n -i input.mp4 -map 0:a:0 -c:a pcm_s16le output.wav

Такой файл будет значительно больше сжатого AAC или Opus, зато не добавляет потерь от нового lossy-кодирования. Если задача — извлечь уже существующий сжатый аудиопоток без изменения, сначала выясните его кодек и выберите контейнер, который умеет его хранить, затем применяйте -c:a copy. Расширение не должно выбираться наугад: AAC, Opus и другие потоки имеют разные типичные контейнеры и ограничения.

Проверка результата. Запустите ffprobe для output.wav, сравните длительность и число каналов, затем прослушайте начало, середину и конец. Типичная ошибка: использовать -map 0:a:0 при нужной второй дорожке. Откат: исходное видео не меняется; при ошибочном выборе потока удалите новый WAV и повторите команду с корректным индексом.

Как нормализовать громкость фильтром loudnorm

Цель. Привести интегральную громкость и пики к заданным целям по алгоритму EBU R128, а не просто умножить амплитуду на постоянный коэффициент. В FFmpeg фильтр loudnorm поддерживает динамический и линейный режимы, одно- и двухпроходную обработку файлов. Целевые значения выбираются по требованиям площадки или производственного процесса; универсального значения для любого назначения нет.

Для первоначального анализа можно запустить loudnorm с печатью измерений и не создавать медиавыход:

ffmpeg -i input.wav -af "loudnorm=print_format=json" -f null -

Фильтр умеет работать с целями integrated loudness, loudness range и true peak. Для примера однопроходной обработки можно явно задать цели, но перед публикацией их нужно заменить требованиями вашей системы:

ffmpeg -n -i input.wav -af "loudnorm=I=-16:LRA=11:TP=-1.5" normalized.wav

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

Проверка результата. Повторно прогоните анализ loudnorm или используйте ffprobe/измерительный инструмент, принятый в рабочем процессе. Прослушайте участки с речью и пиками. Типичная ошибка: нормализовать уже клиппированный источник и ожидать восстановления потерянной формы волны. Откат: всегда пишите нормализованный звук в новый файл; исходный WAV остаётся эталоном.

Как выбрать нужные видео-, аудио- и субтитровые потоки через -map

Цель. Явно управлять тем, какие дорожки попадут в выход. Автоматический stream selection удобен для простых файлов, но в архивном MKV с несколькими языками и субтитрами он может не совпасть с вашей задачей. Параметр -map отключает автоматическое сопоставление для соответствующего выхода и задаёт выбор явно.

Сначала получите список потоков:

ffprobe -v error -show_streams input.mkv

Предположим, нужен первый видеопоток и второй аудиопоток, а контейнер менять не требуется. Базовая схема:

ffmpeg -n -i input.mkv -map 0:v:0 -map 0:a:1 -c copy selected.mkv

Если дорожка может отсутствовать в части пакетной коллекции, FFmpeg поддерживает необязательный mapping с суффиксом ?, например -map 0:s:0?. Это удобно в автоматизации, но применять его стоит осознанно: необязательность предотвращает ошибку, однако может скрыть отсутствие обязательных субтитров. Для критического архива лучше сначала проверять структуру через ffprobe и отклонять файлы, которые не соответствуют контракту.

Проверка результата. ffprobe нового файла должен показывать только ожидаемые потоки с правильными индексами и метаданными. Переключите дорожки в проигрывателе. Типичная ошибка: путать глобальный индекс потока 0:2 с типизированным 0:a:1. Откат: mapping не меняет оригинал; удалите выход и скорректируйте индексы после повторной проверки.

Как соединить однотипные файлы через concat demuxer

Цель. Последовательно объединить несколько совместимых файлов без декодирования и повторного кодирования. Concat demuxer читает текстовый сценарий со списком файлов. Для stream copy входные сегменты должны быть достаточно согласованы по потокам, кодекам и параметрам; если они существенно различаются, сначала требуется нормализация или другой метод объединения.

Создайте текстовый файл list.ffconcat. Первая строка может явно задавать версию формата, затем перечисляются файлы:

ffconcat version 1.0
file 'part-01.mp4'
file 'part-02.mp4'
file 'part-03.mp4'

Запустите:

ffmpeg -n -f concat -safe 0 -i list.ffconcat -c copy joined.mp4

-safe 0 нужен, когда список использует пути, которые строгий безопасный режим concat считает небезопасными; для простых относительных имён его можно не добавлять. Сам файл списка следует хранить рядом со сценарием — это часть воспроизводимого «проекта». Если один сегмент имеет другую частоту кадров, размер кадра, аудиосхему или временную базу, простое склеивание может дать ошибки или дефекты. Тогда сначала приведите сегменты к общему профилю или используйте фильтр concat с перекодированием.

Проверка результата. Сверьте суммарную длительность с ожидаемой, просмотрите каждый стык и проверьте аудиосинхронность после стыков. Типичная ошибка: считать одинаковое расширение доказательством совместимости. Откат: список и новый файл можно удалить; исходные части не изменяются.

Как читать прогресс, сообщения и результат выполнения

Обычный вывод FFmpeg содержит много информации, и полезно разделять её на четыре уровня. Сначала идёт banner со сборкой и библиотеками. Затем описываются входные контейнеры и потоки. После stream mapping выводятся выбранные энкодеры и структура выхода. Во время обработки обновляется строка прогресса с числом кадров, временем, размером, битрейтом и относительной скоростью. Ошибка может появиться раньше последней строки, поэтому при сбое нельзя ограничиваться только финальным «Conversion failed».

Для автоматизации существует параметр -progress, который периодически выдаёт пары key=value и завершает блок строкой progress=continue или progress=end. Это надёжнее, чем парсить визуальную строку состояния, формат которой рассчитан на человека. Параметр -stats_period управляет периодом обновления статистики. Если лог нужно приложить к отчёту об ошибке, -report сохраняет полную командную строку и журнал в файл с временной меткой и включает подробный loglevel.

Как получить один контрольный кадр или серию превью

Цель. Создать изображение из видео для обложки, технического контроля или последующей автоматической проверки. Один кадр удобно извлекать через временную позицию и ограничение числа кадров:

ffmpeg -n -ss 00:00:10 -i input.mp4 -frames:v 1 preview.jpg

Если важен точный кадр, учитывайте тот же принцип поиска, что и при обрезке: позиция декодирования и ключевые кадры могут влиять на скорость и точность в зависимости от размещения -ss и способа обработки. Для серии изображений можно использовать видеовыход в шаблон имён и фильтр частоты кадров, но заранее оцените объём: извлечение каждого кадра длинного 4K-видео создаст тысячи файлов и быстро заполнит диск.

Проверка результата. Откройте preview.jpg, убедитесь, что кадр относится к ожидаемой сцене, а файл не нулевой длины. Если превью используется в автоматизации, отдельно проверьте размеры изображения. Типичная ошибка: сохранять серию кадров в общую папку без шаблона и затем случайно удалить чужие изображения. Откат: вывод должен идти в отдельный каталог; его можно удалить целиком, не затрагивая видео.

Как наложить текст через фильтр drawtext

Цель. Встроить подпись, техническую метку или временную информацию непосредственно в видеокадр. Сначала проверьте наличие фильтра командой ffmpeg -filters или запросите его параметры через ffmpeg -h filter=drawtext. Возможности drawtext зависят от того, с какими библиотеками собран FFmpeg.

Простейший пример задаёт текст, координаты, размер и цвет:

ffmpeg -n -i input.mp4 -vf "drawtext=text='Sample':x=40:y=40:fontsize=32:fontcolor=white" -c:a copy labeled.mp4

Фильтрация видео требует декодирования и нового кодирования видеопотока; копирование аудио через -c:a copy не означает, что видео тоже копируется. Для производственного использования лучше явно задавать видеокодер и его параметры, а также шрифт или файл шрифта, чтобы результат не зависел от разных систем. Строки с двоеточиями, процентами, обратными слешами и кавычками требуют корректного экранирования согласно правилам filtergraph и оболочки. Когда текст длинный, хранить его в отдельном файле обычно проще, чем бороться с несколькими уровнями экранирования.

Проверка результата. Просмотрите начало, участок с самым светлым фоном и кадр у правой/нижней границы, чтобы убедиться, что текст не обрезан. Типичная ошибка: копировать команду с чужим путём к шрифту и получать ошибку загрузки. Откат: подпись впекается в новый видеопоток и не удаляется без повторной обработки, поэтому оригинал нужно сохранять; для изменения текста создайте новый выход из исходника.

Как автоматизировать пакетную обработку и не затереть готовые файлы

Цель. Применить один подтверждённый профиль к набору файлов и получить предсказуемые имена выходов. До пакетного запуска отработайте команду на одном коротком файле, затем включите защиту -n. Никогда не начинайте массовую обработку с параметра -y, если сценарий формирования имён ещё не проверен.

В PowerShell можно обойти файлы и сформировать новый суффикс. Пример предполагает, что libx264 доступен:

Get-ChildItem -File -Filter *.mov | ForEach-Object {
  $out = Join-Path $_.DirectoryName ($_.BaseName + "-converted.mp4")
  ffmpeg -n -i $_.FullName -c:v libx264 -crf 23 -c:a aac $out
}

В Bash та же идея выглядит иначе:

for f in ./*.mov; do
  ffmpeg -n -i "$f" -c:v libx264 -crf 23 -c:a aac "${f%.mov}-converted.mp4"
done

Эти циклы принадлежат оболочке, а не FFmpeg, поэтому правила кавычек и подстановки различаются. Перед запуском на каталоге с пробелами и нелатинскими символами обязательно протестируйте имена. Для программного отслеживания прогресса используйте -progress, а не распознавание визуальной строки stderr. Если важен контроль качества, сценарий должен после каждого файла запускать ffprobe и проверять хотя бы наличие ожидаемых потоков и длительность.

Проверка результата. Сравните число исходных и выходных файлов, проверьте, что ни один выход не равен исходному имени, и выберите несколько файлов разной длительности для ffprobe. Типичная ошибка: цикл повторно подхватывает уже созданные выходы. Предотвращайте это разными расширениями/суффиксами или отдельным каталогом output. Откат: при отдельном каталоге достаточно удалить только пакет результатов; исходники остаются неизменными.

Как собрать локальный HLS-пакет из видео

Цель. Создать плейлист M3U8 и сегменты HLS для тестирования веб-доставки или дальнейшей публикации. HLS — это не один видеофайл: результат включает плейлист и набор сегментов, поэтому заранее используйте пустой рабочий каталог.

Официальная документация muxer показывает, что -hls_time задаёт целевую длительность сегмента, а фактический разрез происходит на следующем ключевом кадре. Для VOD-пакета, где плейлист должен перечислять все сегменты, полезно явно поставить -hls_list_size 0. В примере ниже сначала убедитесь через ffmpeg -encoders, что libx264 есть в вашей сборке:

ffmpeg -n -i input.mkv -map 0:v:0 -map 0:a:0? -c:v libx264 -flags +cgop -g 60 -c:a aac -f hls -hls_time 2 -hls_list_size 0 stream.m3u8

Значение GOP в примере нельзя переносить механически: оно должно согласовываться с частотой кадров и целевой длиной сегмента. Если нужна конкретная совместимость проигрывателей, отдельно задаются видеопрофиль, аудиокодек, пиксельный формат и другие параметры. Для нескольких вариантов качества потребуется более сложное сопоставление потоков и master playlist; не начинайте с multi-variant HLS, пока одноуровневый пакет не проходит проверку.

Проверка результата. В каталоге должны появиться stream.m3u8 и сегменты; плейлист не должен ссылаться на отсутствующие файлы. Проверьте воспроизведение локальным HLS-совместимым клиентом или тестовой средой. Типичная ошибка: удалить «старые» сегменты, не понимая значения hls_list_size и режима плейлиста. Откат: весь HLS-пакет хранится отдельно от входа; удаление тестовой папки полностью отменяет операцию.

Как перенести рабочий процесс FFmpeg на другой компьютер

Цель. Воспроизвести тот же медиапроцесс на новой машине и быстро найти причину расхождения, если результат отличается. Переносить нужно не «проект FFmpeg», которого как отдельного файла нет, а полный набор зависимостей процесса.

Сохраните рядом со сценарием: исходники или их проверяемые копии; командный файл; concat-списки; субтитры; LUT, изображения и шрифты; ожидаемый ffprobe-манифест; сведения о сборке. Зафиксировать сборку можно командами:

ffmpeg -version > ffmpeg-version.txt
ffmpeg -buildconf > ffmpeg-buildconf.txt
ffmpeg -filters > ffmpeg-filters.txt
ffmpeg -encoders > ffmpeg-encoders.txt

На новой машине сначала сравните версию, флаги сборки и наличие энкодеров/фильтров. Даже совпадающий major release не гарантирует одинаковый набор внешних библиотек. Затем запустите процесс на коротком эталонном файле и сравните ffprobe-структуру результата. Абсолютные пути к шрифтам и ресурсам лучше заменить контролируемой структурой каталогов или параметрами сценария.

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

Как собрать диагностический отчёт и безопасно повторить неудачную команду

Цель. Получить полный журнал сбоя, не ухудшая ситуацию многократным запуском с перезаписью. Добавьте -report к проблемной команде и используйте новое имя выхода либо -n:

ffmpeg -report -n -i input.mkv -map 0:v:0 -map 0:a:0? -c:v libx264 -c:a aac diagnostic-output.mp4

-report сохраняет полную командную строку и подробный log output в файл с именем, содержащим программу, дату и время; параметр также включает debug-level logging. В журнал могут попасть абсолютные пути и сетевые URL. Перед передачей отчёта другому человеку удалите секреты, ключи публикации, токены и персональные пути, если они присутствуют.

Диагностика идёт сверху вниз: подтвердите версию сборки; найдите описание входа; проверьте stream mapping; найдите первую содержательную строку ошибки; затем смотрите контекст перед ней. Сообщения «Unknown encoder», «No such filter», «Invalid argument», ошибки открытия файла и несовместимость контейнера требуют разных исправлений. Не лечите их одним -y: этот параметр отвечает только за разрешение перезаписи.

Проверка результата. После исправления повторите команду с новым выходом и без лишней отладочной детализации, затем проверьте файл через ffprobe. Типичная ошибка: отправлять лог с секретным RTMP/HTTP URL. Откат: диагностический выход и report-файл можно удалить; исходник остаётся неизменным.

Таблица «задача → инструмент → результат → что проверить»

Форматы: как не путать контейнер, кодек и поток

FFmpeg поддерживает большое количество demuxer, muxer, decoder и encoder, но конкретный перечень зависит от сборки. Поэтому корректный вопрос звучит не «поддерживает ли FFmpeg MP4», а «может ли эта сборка прочитать такой контейнер, декодировать его потоки и записать нужные кодеки в целевой muxer». Расширение файла — лишь верхний слой. В MP4 может быть несколько допустимых сочетаний видео и аудио; MKV способен хранить ещё более широкий набор потоков; MPEG-TS и HLS рассчитаны на иные сценарии доставки.

Команды ffmpeg -formats, ffmpeg -codecs, ffmpeg -decoders и ffmpeg -encoders отвечают на разные вопросы. Кодек может быть распознаваем для декодирования, но не иметь энкодера в конкретной сборке. Название формата в документации тоже не гарантирует, что любой произвольный набор потоков можно упаковать в него без ограничений. При ошибке muxer сначала проверьте сочетание потоков, а не меняйте расширение файла.

Быстрый результат и максимальный контроль

Сценарий «быстрый результат»

Для единичного файла используйте минимальное число явно нужных параметров. Сначала ffprobe, затем короткая команда, запись в новое имя, потом повторный ffprobe и воспроизведение. Не оптимизируйте всё сразу: если нужно только перепаковать контейнер, начинайте с -c copy; если нужен новый кодек, не добавляйте одновременно масштабирование, нормализацию звука и сложный filtergraph. Один изменяемый слой делает ошибку локализуемой.

Сценарий «максимальный контроль»

Для производственного процесса сначала формализуйте входной контракт: допустимые контейнеры, число и назначение дорожек, частоты, разрешения, цветовые параметры и метаданные. Затем задайте stream mapping явно, фиксируйте выбранные энкодеры и фильтры, сохраняйте версию сборки, пишите прогресс в машинном формате и запускайте post-check через ffprobe. Если процесс длительный, обрабатывайте тестовый отрезок теми же настройками, прежде чем запускать полный файл. Отдельно определите политику при ошибке: остановить весь пакет, пропустить файл или поместить его в quarantine-каталог.

Производительность, CPU, GPU и рабочий диск

Скорость FFmpeg нельзя оценить одним числом для программы. Remux через -c copy в основном ограничен чтением и записью данных и обычно требует значительно меньше вычислений, чем перекодирование. Программный H.264/HEVC/AV1 encoder может загрузить много ядер CPU; фильтры добавляют собственную стоимость. Аппаратный encoder способен ускорить часть цепочки, но его наличие, названия и поддерживаемые пиксельные форматы зависят от ОС, драйвера и сборки. Список распознаваемых методов hardware acceleration можно начать проверять через возможности конкретной установки, а не через чужой пресет.

Перед длительным заданием оцените свободное место. Перекодирование создаёт новый файл, а не «редактирует исходник внутри себя». Двухпроходные схемы могут создавать служебные данные; HLS производит множество сегментов; последовательность кадров — тысячи изображений; -report добавляет подробный лог. Если выход расположен на медленном сетевом ресурсе, пропускная способность хранилища может стать узким местом независимо от мощности CPU.

Показатель speed в прогрессе полезен как относительная скорость к реальному времени: значение выше 1x означает, что обработка идёт быстрее длительности материала, ниже 1x — медленнее. Но сравнивать два запуска корректно только при одинаковом входе, одинаковой сборке, параметрах и нагрузке системы. Нельзя превращать одну строку speed в универсальный benchmark FFmpeg.

Приватность, сеть и данные

Для локальной команды с локальным входом и локальным выходом медиаданные обрабатываются на машине пользователя; учётная запись FFmpeg для такого сценария не нужна. Но FFmpeg умеет читать и писать сетевые URL и поддерживает протоколы, поэтому команда с HTTP, RTMP, RTP и другими сетевыми адресами закономерно передаёт данные соответствующему удалённому узлу. Если в URL встроен секрет или token, он может оказаться в истории оболочки, process list или диагностическом report.

Практическое правило для сетевой автоматизации: не хранить ключ публикации прямо в публичном сценарии; ограничивать права на файлы конфигурации; перед отправкой report удалять секреты; разделять тестовый endpoint и production. Если задача не требует сети, используйте локальные пути и не добавляйте удалённые источники ради удобства. С точки зрения восстановления это также лучше: локальный эталонный input можно повторно обработать даже при недоступности сервиса.

Сильные стороны FFmpeg

• Явная воспроизводимость. Команда фиксирует входы, выбор потоков, фильтры, энкодеры и параметры выхода. Её можно хранить в системе контроля версий и повторять на новых файлах.
• Разделение анализа и преобразования. ffprobe позволяет формально проверять контейнер и потоки до обработки и после неё, что удобно для автоматических конвейеров.
• Широкий мультимедийный охват. Проект включает демультиплексоры, мультиплексоры, декодеры, энкодеры, фильтры, сетевые компоненты и библиотеки, а не только один тип «конвертера видео».
• Stream copy. Там, где кодеки и контейнер совместимы, можно менять упаковку или выбор дорожек без повторного кодирования.
• Filtergraph. Видео- и аудиофильтры можно соединять в цепочки, передавая данные между несколькими входами и выходами без ручного экспорта каждого промежуточного шага.
• Автоматизация. Командная модель естественно встраивается в Bash, PowerShell, CI-задачи, серверные очереди и собственные программы.
• Диагностика. Подробный stderr, машинный -progress и -report помогают разбирать сбои без графического интерфейса.

Реальные ограничения и когда FFmpeg неудобен

• Высокий порог входа. Пользователь должен понимать разницу между контейнером и кодеком, stream mapping, область действия параметров, правила filtergraph и особенности выбранного энкодера.
• Нет монтажного GUI. В базовом FFmpeg нет таймлайна, визуального обрезания мышью, инспектора эффектов и истории Undo. Для творческого монтажа это существенный минус.
• Состав сборок различается. Команда из документации может требовать encoder, filter или внешнюю библиотеку, отсутствующие в конкретном бинарнике.
• Ошибки часто технические. Сообщение может описывать несовместимый pixel format, timestamp, muxer или decoder; без чтения контекста исправление неочевидно.
• Нет универсального пресета «лучшее качество». Параметры зависят от кодека, вида материала и требований конечной площадки.
• Нет собственного проектного контейнера. Пользователь сам отвечает за сохранение сценариев, путей, шрифтов, LUT, списков файлов и данных о сборке.
• Сетевые команды требуют операционной дисциплины. URL и ключи публикации могут попадать в историю терминала и отчёты, если обращаться с ними как с обычным именем файла.

Совместимость рабочих процессов и риск потери редактируемых данных

В графическом редакторе «совместимость проекта» означает возможность открыть файл проекта в другой версии программы. У FFmpeg основной риск другой: команда может синтаксически запускаться, но давать отличающийся результат из-за новой версии энкодера, другой external library, изменившегося default или отсутствующего фильтра. Поэтому переносимость обеспечивается не одним расширением, а фиксацией среды.

Для долгоживущего процесса храните рядом с командой текстовое описание входного контракта и ожидаемого выхода. Например: «один H.264-видеопоток 1920×1080; до двух AAC-аудиодорожек; первый audio обязателен; subtitles копируются в MKV; выходная длительность должна отличаться от входной не более допустимого технического отклонения». Такая спецификация позволяет понять, что проверять после обновления, и не превращает сценарий в набор магических параметров.

Не удаляйте исходники после успешного первого encode только потому, что файл проигрывается. Для архивной или производственной задачи сначала проверьте все нужные дорожки, метаданные, синхронизацию, начало/конец и пригодность в целевой системе. Особенно опасна цепочка «перекодировать → удалить оригинал → заметить пропавшие субтитры»: FFmpeg не сможет восстановить не включённый в output поток из уже удалённого source.

Чек-лист безопасного обновления FFmpeg

1. Сохраните вывод текущих ffmpeg -version и -buildconf.
2. Зафиксируйте списки энкодеров и фильтров, которые реально использует рабочий сценарий.
3. Не удаляйте прежнюю сборку до проверки новой.
4. Проверьте страницу Download и текущий стабильный release; не заменяйте рабочую сборку случайным nightly-архивом без причины.
5. Запустите новый бинарник на эталонном коротком наборе входов.
6. Сравните ffprobe-манифесты выходов и параметры кодирования.
7. Повторите один тяжёлый filtergraph и один пакетный сценарий, если они используются в работе.
8. Проверьте аппаратные энкодеры отдельно: наличие FFmpeg ещё не гарантирует совместимость драйвера и выбранного hardware path.
9. Только после успешной проверки переключите PATH или production-сервис на новую сборку.
10. Оставьте способ быстро вернуть предыдущий бинарник и его конфигурацию.

Настройки и возможности, которые полезно проверить сразу после установки

Дерево диагностики: симптом → причина → проверка → исправление

Сравнение с другими аналогами

Ни один из следующих вариантов не является полным «FFmpeg с другим интерфейсом». Они закрывают разные слои задачи: графическое транскодирование, профессиональную подготовку файлов, разработку мультимедийных приложений или монтаж. Сравнивать их корректно по тому, какую часть FFmpeg нужно заменить, а не по длине списка форматов.

HandBrake

HandBrake — свободный open-source транскодер для Windows, macOS и Linux. Его главная задача уже, чем у FFmpeg: преобразовывать видео из множества исходных форматов в набор современных кодеков через графический интерфейс и CLI. Для пользователя, которому нужно регулярно готовить файлы с повторяемыми настройками, HandBrake снижает порог входа за счёт presets, очереди и сгруппированных параметров.

По главным критериям. Платформы настольные и сопоставимы с основными пользовательскими платформами FFmpeg. Порог входа ниже благодаря GUI. Форматная модель ориентирована прежде всего на транскодирование и конкретные выходные контейнеры/кодеки, а не на универсальную работу с произвольными muxer, сетевыми протоколами и filtergraph. Автоматизация возможна через HandBrakeCLI и очередь, но сложные многовходовые медиаконвейеры естественнее выражаются средствами FFmpeg.

Модель оплаты и ограничения. HandBrake бесплатен и открыт. Его стоит выбирать, если центральная задача — сделать понятный повторяемый encode видео на рабочей станции. Он хуже заменяет FFmpeg в случаях с HLS/RTMP, необычным stream mapping, серверным piping, собственными библиотечными интеграциями и сложными фильтровыми графами.

Shutter Encoder

Shutter Encoder — графический конвертер, спроектированный для видеопроизводства и использующий FFmpeg как основу кодирования. Он работает не только с видео: официальный набор функций включает работу со звуком и изображениями, rewrap, extract, merge, субтитры, trimming, анализ и render queue. Есть версии для Windows, macOS и Linux.

По главным критериям. Порог входа заметно ниже прямой командной строки: параметры организованы в панелях, есть встроенный player для выбора участка, очередь и сохранение настроек в preset-файл. Для постпродакшена это сильная замена ручным однотипным командам. Форматный охват широк именно потому, что приложение использует FFmpeg, но доступ к возможностям идёт через интерфейс и перечень функций Shutter Encoder, а не через произвольный CLI/filtergraph.

Модель оплаты и ограничения. Программа распространяется бесплатно без функциональных ограничений и поддерживается пожертвованиями. Её стоит выбирать для ручной/очередной подготовки медиа с визуальным контролем. Она уступает чистому FFmpeg там, где команда должна стать частью server-side pipeline, где требуется нестандартный protocol graph или точная программная генерация параметров для тысяч заданий.

GStreamer

GStreamer — open-source мультимедийный framework под LGPL для построения графов из media-handling components. Это самый близкий из списка аналогов по уровню «инфраструктуры», но не по пользовательскому интерфейсу. Его применяют разработчики приложений для playback, streaming, захвата и сложной обработки через систему элементов и plugins.

По главным критериям. GStreamer кроссплатформенный; официальный проект публикует бинарники и SDK для нескольких настольных и мобильных платформ. Порог входа для конечного пользователя не ниже FFmpeg, потому что нужно понимать pipeline, caps negotiation, элементы и плагины. Зато разработчик получает архитектуру графа, рассчитанную на долговременные media pipelines и интеграцию в приложение. Автоматизация — программная, а не очередная GUI-обработка.

Модель оплаты и ограничения. Framework открыт и распространяется под LGPL. Он хорошо заменяет FFmpeg как основу собственного приложения, если архитектура GStreamer подходит проекту. Для простой команды «перекодировать каталог файлов» FFmpeg обычно выражает задачу короче; для пользователя без программирования ни один из двух вариантов не является графическим конвертером.

Кому какой подход подходит

Новичку

Если задача — несколько раз в месяц перевести обычное видео в совместимый формат, не стоит начинать со сложного filtergraph. Освойте ffprobe, -c copy, один проверенный профиль перекодирования и защиту -n. Если даже эта модель кажется избыточной, графический конвертер вроде HandBrake, Shutter Encoder или рекомендуемого ВидеоМАСТЕР даст более короткий путь до результата.

Для регулярной работы

FFmpeg начинает окупать порог входа, когда один и тот же технический профиль повторяется. Храните команды как сценарии, формализуйте входы, используйте ffprobe до/после, машинный progress и отдельный output-каталог. Не усложняйте команду без необходимости: понятный pipeline, который можно диагностировать, ценнее одной огромной строки с десятками незафиксированных допущений.

Для сложного проекта

Сложный процесс нужно проектировать как систему: версия сборки, контракт входов, выбор потоков, фильтры, encoders, handling ошибок, disk budget, network credentials, post-validation и rollback. Если обработка становится частью продукта с постоянными живыми pipeline, сравните FFmpeg libraries и GStreamer. Если сложность связана прежде всего с творческим монтажом, перенесите timeline-задачи в подходящий NLE, а FFmpeg оставьте для технических этапов.

Типичные ошибки и решения

1. «ffmpeg» не является известной командой

Причина. Оболочка не видит каталог с бинарником или запускается сессия со старым PATH. Диагностика. Найдите фактический ffmpeg.exe или бинарник FFmpeg и попробуйте выполнить его полным путём; затем сравните с обычным ffmpeg -version. Исправление. Добавьте правильный каталог в PATH или используйте полный путь. Не копируйте бинарник в случайный системный каталог. Проверка. Новая сессия терминала должна показывать ожидаемую версию.

2. Unknown encoder или Requested output format недоступен

Причина. В установленной сборке нет нужного encoder/muxer либо имя указано неверно. Диагностика. Используйте ffmpeg -encoders, ffmpeg -formats и -buildconf. Исправление. Выберите реально доступный компонент либо установите подходящую сборку из проверенного источника. Проверка. Минимальная команда на коротком тестовом файле должна стартовать без ошибки и ffprobe должен показывать ожидаемый codec.

3. После обработки исчезли аудиодорожки или субтитры

Причина. Автоматический stream selection выбрал не все потоки или явные -map включили только часть. Диагностика. Сравните ffprobe -show_streams для входа и выхода. Исправление. Сформируйте mapping явно и решите, какие дорожки копируются, а какие перекодируются. Проверка. В выходе должно быть ожидаемое число дорожек; переключите их в проигрывателе. Без исходника пропавшую дорожку восстановить нельзя, поэтому оригинал не удаляют до проверки.

4. -c copy завершается ошибкой при смене расширения

Причина. Расширение поменяло ожидаемый контейнер, но сами потоки остались прежними и могут быть несовместимы с muxer. Диагностика. Посмотрите codecs входа и сообщение muxer. Исправление. Выберите контейнер, который допускает потоки, или перекодируйте только несовместимую дорожку. Проверка. ffprobe должен успешно открыть новый файл, а проигрыватель — видеть все нужные streams.

5. Получился файл заметно больше исходного

Причина. Новый codec/rate control требует больше данных для выбранного качества, изменилось разрешение, аудиобитрейт или исходник уже был сильно сжат. Диагностика. Сравните ffprobe, encoder и параметры команды, а не только расширения. Исправление. Делайте короткие encode с одним изменением и выбирайте параметр по качеству/размеру. Проверка. Размер оценивают вместе с визуальным качеством и совместимостью, иначе уменьшение файла само по себе бессмысленно.

6. Обрезка начинается не там, где ожидалось

Причина. Использовано stream copy или быстрый seek рядом с ключевым кадром, а ожидалась покадровая точность. Диагностика. Проверьте положение -ss, наличие -c copy и временные метки. Исправление. Для точного финального фрагмента декодируйте и перекодируйте нужный участок. Проверка. Просмотрите первые кадры и синхронизацию звука, а длительность сверяйте через ffprobe.

7. Concat создаёт рассинхрон или сбой на стыке

Причина. Файлы только внешне похожи: различаются stream layout, параметры кодека, временные базы или timestamps. Диагностика. Получите ffprobe для каждого сегмента. Исправление. Сначала приведите сегменты к единому профилю, затем объединяйте; при необходимости используйте перекодирование вместо stream copy. Проверка. Посмотрите каждый стык, особенно звук, и сравните итоговую длительность с суммой частей.

8. drawtext выдаёт ошибку или текст оказывается за кадром

Причина. Фильтр отсутствует, неправильно экранирована строка, не найден шрифт или координаты не соответствуют размеру кадра. Диагностика. Проверьте ffmpeg -filters, ffmpeg -h filter=drawtext и уменьшите filtergraph до одной короткой подписи. Исправление. Добавляйте параметры по одному, задайте контролируемый шрифт и вычисляйте позицию относительно размеров изображения. Проверка. Просмотрите светлые/тёмные сцены и края кадра.

9. Пакетный сценарий перезаписывает или повторно обрабатывает результаты

Причина. Маска входов захватывает созданные файлы, а имена выхода совпадают с существующими; использование -y скрывает проблему. Диагностика. Сначала выведите список файлов, который собирается обработать оболочка, и вручную вычислите несколько имён output. Исправление. Отдельный output-каталог, уникальный суффикс и -n. Проверка. Второй запуск не должен изменять уже готовые файлы, если политика предполагает пропуск существующих.

10. HLS или сетевой поток кодируется, но у клиента ничего нет

Причина. Успешный encoder — только часть пути. Ошибка может быть в URL, сервере, публикации плейлиста, недоступном сегменте, firewall или клиентской совместимости. Диагностика. Разделите цепочку: FFmpeg output, наличие данных на сервере, доступность playlist/stream и воспроизведение клиентом. Исправление. Сначала добейтесь локально проверяемого одноуровневого результата, затем подключайте сеть. Проверка. Клиент должен получить все части потока, а не только успешный exit code FFmpeg.

11. После обновления старая команда перестала работать

Причина. Изменилась версия, конфигурация, external library, encoder/filter availability или поведение конкретного компонента. Диагностика. Сравните сохранённые -version, -buildconf, список encoders/filters и полный report. Исправление. Возвратитесь на прежнюю сборку для production, разберите различие на тестовом наборе и только затем обновляйте сценарий. Проверка. Эталонные входы снова проходят post-validation.

12. Диагностический лог содержит секреты

Причина. Полная командная строка включает URL с token, ключ трансляции или приватный путь, а -report сохраняет её целиком. Диагностика. Откройте report как текст до отправки. Исправление. Удалите/замаскируйте секреты и по возможности передавайте их сценарию безопаснее, чем в публичной строке. Проверка. В публикуемом логе не должно быть рабочих credential; скомпрометированный ключ следует отозвать на соответствующем сервисе.

Резервное копирование и восстановление после сбоя

FFmpeg обычно создаёт новый output, поэтому лучший способ защиты — не превращать выход в единственную копию входа. Держите source read-only или хотя бы не используйте одинаковое имя. Параметр -n — простая страховка от случайной перезаписи; -y оправдан только в контролируемом pipeline, где политика замены заранее определена и вход физически отделён от output.

Для длинных задач сбой в конце не означает, что частично созданный файл годится к использованию. Некоторые контейнеры требуют финализации структуры; незавершённый output может не открываться или иметь неполные индексы. После ненулевого exit code не публикуйте файл автоматически. Поместите его в отдельный каталог failed, сохраните report и повторите обработку из исходника. Если процесс построен из нескольких этапов, полезно делать проверяемые checkpoints в форматах, которые действительно нужны, а не сохранять lossy-копию после каждого мелкого действия.

Резервная копия рабочего процесса должна включать не только медиа, но и сценарии, списки concat, внешние шрифты, LUT, subtitle files и манифест версии FFmpeg. Без этого восстановить точную обработку бывает сложнее, чем восстановить сами исходники.

Финальный чек-лист перед сохранением, экспортом или публикацией результата

• Исходник сохранён и не был перезаписан.
• Команда и версия FFmpeg зафиксированы для повторения.
• ffprobe входа и выхода показывает ожидаемое число video/audio/subtitle streams.
• Контейнер и кодеки соответствуют требованиям конечного проигрывателя или площадки.
• Разрешение, pixel aspect/display aspect и частота кадров проверены, если они менялись.
• Длительность соответствует задаче; начало и конец не обрезаны случайно.
• Проверены несколько сложных сцен, а не только первый кадр.
• Аудиодорожки воспроизводятся, каналы не перепутаны, синхронизация не уехала.
• Нужные субтитры и metadata действительно присутствуют после mapping.
• Если применялся loudnorm, результат повторно измерен по тем же критериям.
• Для HLS все playlist references разрешаются в существующие сегменты.
• Для network output отдельно проверена сторона сервера/клиента.
• В публичных логах и сценариях нет stream keys, token и других секретов.
• Пакетный процесс не захватывает собственные выходы при повторном запуске.
• Есть достаточно места для следующей операции и служебных файлов.
• Только после полного контроля можно удалять временные файлы; оригиналы удаляются лишь по отдельной политике хранения.

Итог: когда оставить FFmpeg, а когда выбрать ВидеоМАСТЕР

Оставляйте FFmpeg, если ценность задачи — в точном управлении потоками, нестандартных форматах, фильтрах, пакетной обработке, серверных сценариях, streaming, ffprobe-проверках или встраивании мультимедиа в программный продукт. Он особенно силён, когда команда становится частью воспроизводимого конвейера и должна работать без ручного интерфейса.

Если основной сценарий проще — открыть несколько видео, выбрать понятный формат, настроить качество, при необходимости сделать базовые изменения и получить готовый файл без изучения stream mapping и синтаксиса — разумнее графический конвертер. Из разрешённого AMS-каталога наиболее близок ВидеоМАСТЕР: он ориентирован на повседневную конвертацию видео через GUI и снижает порог входа. Это не полная замена FFmpeg: сложный filtergraph, произвольные сетевые pipeline, программный анализ ffprobe и инфраструктурная автоматизация остаются зоной FFmpeg. Но для пользователя, которому нужен результат, а не управление мультимедийным стеком на уровне команды, ВидеоМАСТЕР даёт более прямой рабочий путь.