FFmpeg: Must-Know Шпаргалка Для Разработчика

TL;DR

FFmpeg – это утилита командной строки, которая незаметно работает почти во всех продуктах, связанных с видео: Netflix, YouTube, OBS, VLC, Plex, Zoom, любые облачные транскодеры и браузерные программы для записи экрана. Это один бинарный файл на языке C, способный читать более 400 входных форматов, записывать более 200 выходных, кодировать и декодировать все активно используемые видео- и аудиокодеки, а также комбинировать фильтры для масштабирования, обрезки, наложения водяных знаков, подавления шума, деинтерлейсинга и перераспределения аудиоканалов. Проблема в том, что официальная документация огромна, синтаксис известен своей сложностью, а ошибка в одном флаге может привести к повреждённому результату, который обнаружится только в продакшене. Эта шпаргалка предлагает двадцать команд, покрывающих девяносто процентов реальных задач в разработке – анализ, копирование, транскодирование, упаковку, добавление водяных знаков, создание миниатюр, использование аппаратного ускорения и стриминг – с объяснением «почему» за каждым флагом, чтобы вы могли безопасно адаптировать их под свои нужды.

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

Если вы создаёте продукт, связанный с видео – стриминговый сервис, обучающую платформу, телемедицинское приложение, видеоконференц-связь, дашборд видеонаблюдения или инструмент для подкастов, – FFmpeg станет тем слоем, который превращает «у нас есть файл» в «пользователь смотрит его на телефоне через пять секунд без зависаний». Ваши инженеры будут писать команды FFmpeg, DevOps – запускать его в контейнерах, а счёт в AWS будет измеряться в CPU-часах, потраченных на FFmpeg. Продакт-менеджер, понимающий, что FFmpeg умеет делать одной командой, а чего – нет, экономит команде недели споров «разрабатывать самому или использовать SaaS». Основатель, способный прочитать лог FFmpeg, в два часа ночи вместе с CTO разбирается с инцидентом в продакшене, а не ждёт утра.

Эта статья даёт практические знания. Начинаем с ментальной модели – что такое FFmpeg на самом деле и чем он не является, – а затем проходим через рабочие процессы: inspect, copy, transcode, package, watermark, accelerate, которые реально используются в продуктах. Мы разберём математику за цифрами, чтобы вы могли уверенно их менять. К концу статьи вы сможете прочитать любую FFmpeg-команду, найденную в интернете, оценить, подходит ли она для вашей задачи, и писать свои варианты, не копируя с Stack Overflow.

Что такое FFmpeg на самом деле

До команд – уточним ментальную модель. FFmpeg – это три компонента в одном пакете: утилита командной строки (ffmpeg), инструмент анализа (ffprobe) и набор C-библиотек (libavformat, libavcodec, libavfilter, libavutil, libswscale, libswresample), которые и используются самой утилитой. Именно эти библиотеки делают FFmpeg универсальным стандартом – с libav* под капотом работают VLC, OBS, MPV, HandBrake, Plex, Jellyfin, Bitmovin, Mux, AWS Elemental и почти все браузерные записчики. Устанавливая FFmpeg, вы устанавливаете движок, на котором работает половина стримингового интернета.

Проект начался в 2000 году как личная инициатива Фабриса Беллара, тогда ещё аспиранта в Париже, и с тех пор поддерживается непрерывно – ротацией волонтёров и штатных сотрудников компаний, зависящих от FFmpeg. 1 Последний стабильный релиз на май 2026 – FFmpeg 8.1 «Hoare», вышедший в марте 2026 года, добавил поддержку кодирования JPEG-XS через libsvtjpegxs, аппаратного кодирования H.264 и AV1 с использованием Direct3D 12, декодирования через Rockchip MPP, мультиплексирования IAMF Ambisonic spatial audio и экспериментальный декодер xHE-HE-AAC. 2 Ветка 7.1, последний раз обновлённая до версии 7.1.4 в мае 2026 года, является LTS-релизом, на который пинятся большинство продакшен-пайплайнов. 3

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

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

Ментальная модель: demux, decode, filter, encode, mux

Любая команда FFmpeg выполняет определённый поднабор из пяти операций в определённом порядке. Освоив эти пять – и синтаксис перестанет казаться произвольным.

Первый шаг – demux, сокращение от demultiplex (разъединение мультиплекса) – это разбор контейнера. Контейнер, подробно описанный в нашей статье про контейнеры, – это формат файла, который объединяет дорожки видео, аудио, субтитры и метаданные в единый воспроизводимый файл. Demux извлекает эти дорожки обратно в отдельные потоки, с которыми FFmpeg может работать независимо.

Второй шаг – декодирование – превращает сжатые биты каждого потока обратно в исходные кадры. Сжатый H.264-поток представляет собой несколько мегабит в секунду непрозрачных чисел; после декодирования это становится последовательностью сырых пиксельных кадров объёмом около 1,5 гигабита в секунду для разрешения 1080p. Декодер – это алгоритм, выполняющий это преобразование.

Третий шаг – filter – применение преобразований к исходным кадрам: изменение размера, обрезка, наложение водяного знака, удаление шума, изменение частоты кадров, коррекция цвета, пропуск кадров, наложение нескольких входных потоков друг на друга. Фильтры обрабатывают сырые декодированные кадры. Хотите обработать изображение – без декодирования не обойтись.

Четвёртый шаг – encode – преобразование (возможно, отфильтрованных) исходных кадров обратно в сжатый поток с помощью выбранного кодека и под заданное качество. Это медленный и ресурсоёмкий этап. Файл в разрешении 1080p на высоком качестве кодируется со скоростью 1×–5× реального времени на современном процессоре.

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

Шорткат, к которому первым делом тянется любой пользователь FFmpeg, – stream copy, пишется как -c copy, – пропускает середину decode-filter-encode и копирует сжатые биты прямо из входного mux в выходной mux. Stream copy работает со скоростью 50×–200× реального времени, потому что вообще не трогает пиксели – и это правильный ответ всегда, когда вы меняете только контейнер или режете по keyframe-границам. Первая команда в статье – именно про него.

Установка и фиксация версий

Установите FFmpeg через менеджер пакетов (apt install ffmpeg на Debian/Ubuntu, brew install ffmpeg на macOS, winget install ffmpeg на Windows) или скачайте статический сборку от надёжного дистрибьютора – релизы BtbN на GitHub для Linux, Gyan.dev для Windows, официальные ссылки с ffmpeg.org для остальных платформ. 4 В продакшене фиксируйте конкретную версию: переход с 6.0 на 7.1 может изменить поведение фильтров по умолчанию, пресеты кодеков и даже битрейты при одинаковом входе. Два безопасных варианта на середину 2026 года: 7.1.x – для стабильности и 8.1.x – для самых свежих возможностей.

Что у вас установлено:

# Версия FFmpeg и библиотеки, против которых он собран.
ffmpeg -version

# Список всех кодеков (D = декодер, E = энкодер, V = video).
ffmpeg -codecs | grep -i av1

# То же для аппаратных ускорителей (cuda, qsv, vaapi, videotoolbox, d3d11va).
ffmpeg -hwaccels

Если команда ffmpeg -hwaccels не выводит ожидаемый ускоритель – значит, бинарник собран без поддержки этого ускорителя. Статические сборки BtbN включают всё необходимое; дистрибутивные пакеты часто исключают NVENC и кодеки, защищённые патентами, по умолчанию.

1. Проверка перед преобразованием

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

# Pretty-print кодек каждого потока, разрешение, frame rate, битрейт и длительность.
ffprobe -hide_banner -show_streams -show_format input.mp4

Вывод плотный. Читайте сверху вниз: format_name (контейнер), duration (секунды), bit_rate (общий), затем по одному блоку на каждый поток. В каждом блоке: codec_name (h264, hevc, aac, opus), width × height, r_frame_rate (24/1, 30000/1001, 60/1), pix_fmt (yuv420p, yuv420p10le – для 10-битного, yuv422p10le – для ProRes-уровня), тайминги.

Для однострочного резюме в CI-лог – JSON-вывод и небольшой фильтр:

# JSON для машинного разбора — пайпите в jq для точных полей.
ffprobe -hide_banner -v error -print_format json -show_streams -show_format input.mp4

# Только кодек, разрешение и битрейт нулевого видеопотока.
ffprobe -v error -select_streams v:0 \
        -show_entries stream=codec_name,width,height,bit_rate \
        -of csv=p=0 input.mp4

Вывод выглядит как h264,1920,1080,5024000 – это 1080p H.264 с битрейтом около 5 мегабит в секунду. Эта строка помогает понять, нужно ли транскодировать файл, воспроизведётся ли он на целевом устройстве и сколько примерно места займёт одна минута видео.

Три вещи, на которые стоит обращать внимание при каждой инспекции:

• pix_fmt – yuv420p – это 8-битный формат с субдискретизацией 4:2:0, универсальный и совместимый по умолчанию. yuv420p10le – 10-битный, обязательный для HDR, но не поддерживается некоторыми старыми браузерами и устройствами. Форматы yuv422p, yuv422p10le, yuv444p обеспечивают профессиональное качество субдискретизации хроминанса, но не воспроизводятся на потребительском оборудовании без перекодирования.
• profile – для H.264: Baseline работает везде, но плохо сжимает; Main поддерживается повсеместно; High – современный стандарт для веба; High 10 и High 4:2:2 – профессиональные профили. Для H.265: Main – универсальный, Main 10 – для HDR, Main 4:2:2 10 – для вещания. Если отправить High 10 H.264 на старый Android, получите чёрный экран с аудио.
• r_frame_rate – задаётся как числитель/знаменатель. 30000/1001 – это 29,97 кадров в секунду (NTSC), 24000/1001 – 23,976 (кино), 25/1 – PAL, 60/1 – вещательный 60p. Если в одном пайплайне смешать 29,97 и 30 fps, через полминуты воспроизведения начнётся дрейф.

Если вы ничего больше не сделаете из этой статьи – запускайте ffprobe перед каждым важным транскодированием. Пять секунд сэкономят вам перестраивание тысяч файлов из-за ошибочной догадки о пиксельном формате.

2. Самая быстрая операция: копирование потока

Когда нужно просто сменить контейнер или обрезать по границам keyframe, не проводите транскодирование. Используйте копирование потока – и задача займёт секунды, а не минуты.

# Перепаковать MKV в MP4 без перекодирования видео и аудио.
# Работает на 100x+ realtime, потому что трогает только заголовки контейнера.
ffmpeg -i input.mkv -c copy output.mp4

Шорткат -c copy означает «копировать каждый поток без перекодирования». Можно указать явно: -c:v copy -c:a copy. Некоторые аудиокодеки, поддерживаемые только в формате MKV – например, FLAC, Vorbis и отдельные профили TrueHD, – не помещаются в MP4, и FFmpeg откажется их копировать. Решение: перекодировать только аудио: -c:v copy -c:a aac -b:a 192k. Видео остаётся бит-в-бит идентичным, а аудио пересобирается.

Trim со stream copy, когда нужно резать по существующим keyframe'ам:

# Вырезать с 10-й по 70-ю секунду без перекодирования. Точки реза прыгают на ближайший предыдущий keyframe.
ffmpeg -ss 00:00:10 -to 00:01:10 -i input.mp4 -c copy output.mp4

Флаг -ss перед -i – это «быстрый поиск»: переход к ближайшему ключевому кадру (keyframe) до указанного таймкода без декодирования. Это делает операцию мгновенной, но неточной – реальный разрез может начаться на одну длину GOP (обычно 2 секунды) раньше запрошенного момента. Если нужна точность до кадра – поставьте -ss после -i и будьте готовы к декодированию всего видео до точки реза.

Для веб-доставки добавляйте +faststart, чтобы перенести MP4-метаданные в начало файла – тогда плеер сможет начать стриминг до полной загрузки.

# Перепаковать в MP4 с moov atom в начале для HTTP-стриминга.
ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4

Этот один флаг – разница между видео, которое начинает воспроизводиться в браузере уже через 200 мс, и тем, что должно полностью загрузиться до первого кадра. На стороне кодирования он бесплатен – FFmpeg дважды записывает файл, переставляя боксы, – и окупается всегда.

3. Скучный, но надёжный веб-транскод

Самая распространённая задача – взять произвольный входной файл и получить MP4, который будет воспроизводиться в любом браузере, на любом телефоне и любом смарт-ТВ без сюрпризов с совместимостью. Ниже приведён рецепт, который мы используем в 70% веб-проектов Фора Софт, и за семь лет он ни разу нас не подвёл.

# Универсальный совместимый веб-MP4: H.264 High Profile, AAC, faststart, кэп 1080p.
ffmpeg -i input.mov \
       -c:v libx264 -preset medium -crf 23 \
       -profile:v high -level 4.0 -pix_fmt yuv420p \
       -c:a aac -b:a 192k -ac 2 \
       -movflags +faststart \
       output.mp4

Читаем слева направо. -i input.mov – это исходный файл. -c:v libx264 выбирает x264 – лучшую программную реализацию H.264 в мире, бесплатную и не нарушающую патентные права. -preset medium задаёт баланс между скоростью и эффективностью кодирования; доступны пресеты: ultrafast, superfast, veryfast, faster, fast, medium (по умолчанию), slow, slower, veryslow, placebo. Каждый шаг влево удваивает скорость обработки и увеличивает размер файла на 5–10% при неизменном визуальном качестве.

-crf 23 – Constant Rate Factor, параметр, отвечающий за качество кодирования, подробно описан в нашей статье про rate control. Шкала: от 0 (без потерь, огромные файлы) до 51 (худшее качество, минимальный размер). Значение 23 – стандартное для x264, при котором видео выглядит визуально прозрачным на разрешении 1080p. Уменьшайте до 18 для архивного качества, увеличивайте до 28 для максимальной экономии трафика на мобильных устройствах. Каждые 6 пунктов шкалы примерно удваивают или вдвое уменьшают размер файла.

-profile:v high -level 4.0 ограничивает кодек профилем H.264 High на уровне 4.0 – самой широко поддерживаемой современной комбинацией. Уровень 4.0 ограничивает разрешение до 1080p при 30 кадрах в секунду; для 1080p@60 нужен уровень 4.2; для 4K – уровень 5.1.

-pix_fmt yuv420p заставляет использовать 8-битный формат 4:2:0. Без этого флага FFmpeg может сохранить 10-битную или 4:2:2 хрому источника и выдать файл, который 30% телефонов не смогут аппаратно декодировать.

-c:a aac -b:a 192k -ac 2 перекодирует аудио в стерео AAC со скоростью 192 кбит/с. AAC – универсальный аудиокодек; 192 кбит/с в стерео – оптимальный баланс для музыки и речи.

-movflags +faststart помещает метаданные MP4 в начало файла, что обеспечивает мгновенное воспроизведение – как указано выше.

Арифметика оценки размера:

целевой битрейт видео ≈ 1080p при CRF 23 ≈ 4 Mbps для обычного контента
аудио = 192 кбит/с
всего = 4 192 000 бит/с
1 час = 3600 секунд
размер ≈ 4 192 000 × 3600 / 8 = 1,89 ГБ в час

Правильный порядок величины для часа видео в разрешении 1080p с talking head – около 1 ГБ. Спорт и анимация требуют больше места (больше движения = больше бит при том же CRF), а статичные вебинары – меньше.

4. Современный кодек: AV1 с SVT-AV1

Если ваша аудитория использует современные браузеры – Chrome, Firefox, Edge, недавние версии Safari, Android 12+, iOS 17+ – и вы готовы потратить время на кодирование, AV1 обеспечивает примерно на 30% лучшую компрессию, чем H.265, и на 50% – чем H.264 при одинаковом воспринимаемом качестве. Scalable Video Technology AV1-энкодер, SVT-AV1, изначально разработанный Intel и Netflix и переданный в AOMedia в 2020 году, – это open-source энкодер промышленного уровня; он на порядок быстрее референсной реализации libaom-av1 при сопоставимом качестве. 5

# Современный AV1 для веба с SVT-AV1, 10-бит, preset 6.
ffmpeg -i input.mov \
       -c:v libsvtav1 -preset 6 -crf 30 \
       -pix_fmt yuv420p10le \
       -svtav1-params tune=0:film-grain=8 \
       -c:a libopus -b:a 128k \
       -movflags +faststart \
       output.mp4

Новые флаги: -preset 6 выбирает компромисс – пресеты SVT-AV1 идут от 0 (медленный, лучший) до 13 (быстрый, худший); значение 6 – рекомендуемый баланс для VOD и примерно соответствует medium в терминах x264. 6 -crf 30 – цель по качеству AV1 на собственной шкале от 0 до 63; значение 30 визуально прозрачно на 1080p для обычного контента. -pix_fmt yuv420p10le выбирает 10-битный цвет – исследование Netflix показало, что 10 бит дают бесплатный прирост качества на 5–10% даже для 8-битных источников, без штрафа на совместимость в современных декодерах.

-svtav1-params tune=0:film-grain=8 – строка тонкой настройки для SVT-AV1. Параметр tune=0 оптимизирует субъективную резкость, а не PSNR (по умолчанию tune=1 ориентирован на PSNR, хотя человеческий глаз на него и не реагирует); film-grain=8 включает синтез плёночного зерна – энкодер удаляет шум с входного изображения, кодирует очищенную картинку (которая сжимается эффективнее) и добавляет синтетическое зерно при декодировании, неотличимое от оригинала. Синтез зерна – одна из ключевых особенностей AV1, повышающих эффективность; на плёночном контенте он позволяет сэкономить 20–30% битрейта.

-c:a libopus -b:a 128k выбирает Opus для аудио. На скорости 128 кбит/с Opus по восприятию эквивалентен AAC на 192 кбит/с и уже десять лет является стандартом открытого веба.

Trade-Off: SVT-AV1 на preset 6 кодирует со скоростью 0,5×–2× от реального времени на современном восьмиядерном CPU – примерно в 10 раз медленнее x264 на preset medium. Для VOD, который хранится на CDN месяцами, это разовая стоимость, которую стоит понести. Для одноразовых транскодов – оставайтесь на x264.

5. HEVC / H.265 для аудитории Apple

Если ваша аудитория в основном использует iOS и macOS, H.265 / HEVC попадает в «сладкую точку»: каждый iPhone, начиная с модели 6s, декодирует его аппаратно, все версии macOS с High Sierra и новее воспроизводят его нативно, размеры файлов примерно вдвое меньше, чем у H.264 при том же качестве, а HLS-пайплайн Apple поддерживает его как первоклассный формат.

# HEVC для Apple-экосистемы: x265, capped CRF, hvc1 тег (Apple-совместимый).
ffmpeg -i input.mov \
       -c:v libx265 -preset medium -crf 26 \
       -x265-params vbv-maxrate=5000:vbv-bufsize=10000 \
       -tag:v hvc1 \
       -pix_fmt yuv420p \
       -c:a aac -b:a 192k \
       -movflags +faststart \
       output.mp4

Два новых флага. Флаг -tag:v hvc1 заставляет MP4 использовать четырёхбуквенный код hvc1 для объявления HEVC-трека вместо альтернативного hev1. QuickTime, Safari и AVPlayer от Apple требуют именно hvc1; без этого тега файл воспроизводится на Android и в Chrome, но отображается как непригодный для воспроизведения на iPhone. 7

-x265-params vbv-maxrate=5000:vbv-bufsize=10000 применяет capped CRF – кодирование, ориентированное на качество, но с ограничением битрейта до 5 Мбит/с, чтобы сложная сцена не выбила вас из CDN-бюджета. Соотношение буфера к битрейту 2× – стандартная настройка для VOD (см. статью про rate control).

6. Аппаратное ускорение: когда оно нужно, а когда – нет

Программные энкодеры – x264, x265, SVT-AV1 – обеспечивают лучшее качество на бит, но работают медленно. Аппаратные – NVIDIA NVENC, Intel QuickSync (QSV), AMD AMF, Apple VideoToolbox, Linux VAAPI – используют специализированный кремний и работают в 10–100 раз быстрее программного кодирования, при этом теряя в качестве – от «незаметного» (у современного NVENC) до «заметного» (у старого AMF). Правильный выбор зависит от того, что является узким местом: время кодирования или качество.

Правило большого пальца: аппаратные решения выигрывают в live-стриминге, реальном времени конференцсвязи, многопоточной записи видеонаблюдения и везде, где зритель ждёт завершения кодирования. Программные – в VOD, хранящемся на CDN месяцами, в мастеринге, архивировании и везде, где файл будет просмотрен много раз, и стоимость кодирования окупается. Отчёт NETINT State of Video Encoding 2025 показал, что аппаратные энкодеры обеспечивают 60% новых часов live-стриминга, но лишь 15% часов VOD – разрыв обусловлен сценариями использования, а не самой технологией. 8

NVIDIA NVENC на GPU, совместимом с CUDA:

# NVENC H.264 для live ingest: в 100 раз быстрее libx264 ultrafast, на 5% больше файлы.
ffmpeg -hwaccel cuda -hwaccel_output_format cuda \
       -i input.mp4 \
       -c:v h264_nvenc -preset p5 -tune hq -cq 23 \
       -c:a aac -b:a 192k \
       output.mp4

Пресеты NVENC идут от p1 (самый быстрый) до p7 (самый медленный, лучшее качество). p5 – приблизительный аналог x264 medium. Параметр -cq 23 соответствует CRF в NVENC; шкала совпадает с x264 – от 0 до 51.

Intel QuickSync (подробно рассмотрено в нашей статье про hardware-ускорение):

# Intel QuickSync HEVC — Intel iGPU или дискретная Arc GPU.
ffmpeg -hwaccel qsv -hwaccel_output_format qsv \
       -i input.mp4 \
       -c:v hevc_qsv -preset medium -global_quality 23 \
       -c:a aac -b:a 192k \
       output.mp4

Apple VideoToolbox на macOS или iOS:

# Apple Silicon аппаратный HEVC — использует dedicated media engine на чипах M-серии.
ffmpeg -i input.mov \
       -c:v hevc_videotoolbox -q:v 60 -tag:v hvc1 \
       -c:a aac -b:a 192k \
       output.mp4

VideoToolbox использует собственную шкалу -q:v от 1 (худшее качество) до 100 (лучшее); значение 60 считается визуально прозрачным для 1080p. На процессоре M2 кодирование десятиминутного источника 1080p в HEVC занимает около 30 секунд – примерно в 20 раз быстрее реального времени.

Цена аппаратного ускорения – качество. При одинаковом битрейте NVENC HEVC показывает примерно на 1–2 балла ниже по VMAF, чем x265 medium; AMF отстаёт ещё на 2–4 балла. Для стриминга это незаметно, для архивных мастер-версий – недопустимо. Используйте аппаратное кодирование там, где важна скорость, программное – где требуется высокое качество.

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

7. ABR-лестницы для стриминга

Один битрейт не подойдёт каждому зрителю – телефоны на сотовой сети, ноутбуки с домашним Wi-Fi и телевизоры с гигабитным оптоволокном требуют разных потоков. Adaptive Bitrate streaming решает эту задачу, кодируя один исходный файл в пять–шесть ступеней (rung) по битрейту и разрешению и позволяя плееру выбирать нужный фрагмент за фрагментом. FFmpeg генерирует полную лестницу за один проход.

# 1080p источник → четыре ABR rung'а (1080p, 720p, 480p, 360p) одной командой.
ffmpeg -i input.mov \
  -filter_complex "[0:v]split=4[v1][v2][v3][v4]; \
                   [v1]scale=1920:1080[v1080]; \
                   [v2]scale=1280:720[v720]; \
                   [v3]scale=854:480[v480]; \
                   [v4]scale=640:360[v360]" \
  -map "[v1080]" -c:v:0 libx264 -b:v:0 5000k -maxrate:v:0 5500k -bufsize:v:0 10000k \
  -map "[v720]"  -c:v:1 libx264 -b:v:1 2800k -maxrate:v:1 3100k -bufsize:v:1 5600k \
  -map "[v480]"  -c:v:2 libx264 -b:v:2 1400k -maxrate:v:2 1500k -bufsize:v:2 2800k \
  -map "[v360]"  -c:v:3 libx264 -b:v:3 800k  -maxrate:v:3 900k  -bufsize:v:3 1600k \
  -map a:0 -c:a aac -b:a 128k \
  -f hls -hls_time 4 -hls_playlist_type vod \
  -hls_segment_type fmp4 \
  -master_pl_name master.m3u8 \
  -var_stream_map "v:0,a:0 v:1,a:0 v:2,a:0 v:3,a:0" \
  "stream_%v/playlist.m3u8"

Команда длинная, но каждая её часть выполняет одну задачу. Блок -filter_complex разделяет декодированное видео на четыре параллельных потока, масштабирует каждый до целевого разрешения и помечает выходы как [v1080] – [v360]. Строки -map выбирают каждый помеченный выход и назначают ему энкодер с заданным битрейтом, maxrate (верхний предел VBV, на 10 % выше целевого значения) и bufsize (вдвое больше maxrate для VOD).

HLS-специфичные флаги: -f hls выбирает HLS-муксер. -hls_time 4 устанавливает длительность сегмента в 4 секунды – современный стандарт для HLS и DASH. -hls_segment_type fmp4 генерирует фрагментированные MP4-сегменты (совместимые с CMAF) вместо устаревшего MPEG-TS – подробнее о важности этого выбора см. в нашей статье про контейнеры. -master_pl_name задаёт имя мастер-плейлиста, который перечисляет все четыре уровня. -var_stream_map указывает муксеру сопоставлять каждый видеоуровень с одной и той же аудиодорожкой. 9

Битрейты в примере взяты из спецификации HLS Authoring от Apple и исследования Mux по per-title-encoding – сбалансированная лестница, где каждый уровень примерно вдвое меньше предыдущего, чтобы плеер мог плавно снижать качество при падении скорости соединения. 10

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

8. Фильтры: scale, crop, watermark, deinterlace, denoise

Фильтры размещаются внутри -vf (цепочка видеофильтров) или -filter_complex (многоисточниковый граф). Наиболее часто используемые покрывают 90 % реальной работы.

# Масштаб до 720p с сохранением aspect ratio (-2 держит чётную высоту, требуется H.264).
ffmpeg -i input.mp4 -vf "scale=1280:-2" -c:v libx264 -crf 23 output.mp4

# Crop вертикальный 9:16 из горизонтального 16:9 (центральный).
ffmpeg -i input.mp4 -vf "crop=ih*9/16:ih" -c:v libx264 -crf 23 output.mp4

# Наложить PNG-водяной знак в правом нижнем углу с отступом 20 px.
ffmpeg -i input.mp4 -i logo.png \
       -filter_complex "[0:v][1:v]overlay=W-w-20:H-h-20" \
       -c:a copy output.mp4

# Burn-in timestamp слева вверху, полупрозрачный чёрный бокс за ним.
ffmpeg -i input.mp4 -vf \
       "drawtext=text='%{pts\:hms}':x=20:y=20:fontsize=28:fontcolor=white:box=1:boxcolor=black@0.5:boxborderw=6" \
       -c:a copy output.mp4

# Деинтерлейсинг чересстрочного источника (set-top box, broadcast) фильтром yadif.
ffmpeg -i interlaced.mp4 -vf "yadif=mode=1" -c:v libx264 -crf 23 output.mp4

# Denoise шумного low-light источника фильтром hqdn3d (лёгкий, быстрый).
ffmpeg -i noisy.mp4 -vf "hqdn3d=4:3:6:4.5" -c:v libx264 -crf 23 output.mp4

# Изменить частоту кадров точно до 30 fps с motion-blending интерполяцией.
ffmpeg -i input.mp4 -vf "minterpolate=fps=30:mi_mode=blend" -c:v libx264 -crf 23 output.mp4

Цепляйте фильтры запятыми внутри одного -vf или точками с запятой между несколькими потоками в -filter_complex. Фильтр drawtext требует, чтобы FFmpeg был собран с --enable-libfreetype; статические сборки BtbN всегда включают эту поддержку. Полный список фильтров – их более 300 – приведён в официальной документации. 11

9. Аудио: извлечение, замена, смешивание, нормализация

Аудио – это отдельный мир. Пять команд решают большинство реальных задач.

# Вытащить аудиодорожку как качественный MP3 (320 kbps).
ffmpeg -i input.mp4 -vn -c:a libmp3lame -b:a 320k output.mp3

# Заменить аудиодорожку в видео новым файлом, оставив видео нетронутым.
ffmpeg -i video.mp4 -i music.aac -c:v copy -c:a aac -b:a 192k -map 0:v -map 1:a -shortest output.mp4

# Смешать два аудио-входа (речь и музыка) в одну стерео-дорожку с выбранными уровнями.
ffmpeg -i dialogue.wav -i music.wav \
       -filter_complex "[0:a]volume=1.0[a0];[1:a]volume=0.3[a1];[a0][a1]amix=inputs=2:duration=longest[out]" \
       -map "[out]" output.aac

# Loudness-нормализация до -16 LUFS (стандарт YouTube / подкастов).
ffmpeg -i input.mp4 -af "loudnorm=I=-16:LRA=11:TP=-1.5" -c:v copy output.mp4

# Двухпроходная loudness-нормализация для broadcast-точности.
ffmpeg -i input.mp4 -af loudnorm=I=-16:LRA=11:TP=-1.5:print_format=json -f null -
# (скопируйте измеренные значения во вторую команду)
ffmpeg -i input.mp4 -af "loudnorm=I=-16:LRA=11:TP=-1.5:measured_I=-21.4:measured_LRA=8.2:measured_TP=-1.1:measured_thresh=-31.4:offset=0.5:linear=true" output.mp4

loudnorm – это фильтр нормализации громкости по стандарту EBU R128, тот же алгоритм, что используют вещатели, чтобы рекламные блоки не звучали громче основного контента. LUFS (Loudness Units relative to Full Scale) – перцептивная единица громкости по стандарту EBU; -16 LUFS – де-факто стандарт для YouTube, Spotify и подкастов, -23 LUFS – целевое значение для вещания по стандарту EBU. Двухпроходная форма сначала измеряет, а затем корректирует – она точнее однопроходной, но требует вдвое больше времени.

10. Миниатюры, спрайты и GIF-анимации

Плееры, каталоги видео для электронной коммерции, загрузки в CMS – всем им нужны миниатюры. FFmpeg создаёт их одной командой.

# Один thumbnail на 5-й секунде.
ffmpeg -ss 5 -i input.mp4 -vframes 1 -q:v 2 thumb.jpg

# Кадр каждые 60 секунд (генерация sprite'ов).
ffmpeg -i input.mp4 -vf "fps=1/60,scale=320:-2" -q:v 4 thumb_%03d.jpg

# Собрать sprite-sheet (8 столбцов x 5 рядов) из 40 равномерно расположенных кадров.
ffmpeg -i input.mp4 -vf "fps=1/60,scale=160:90,tile=8x5" -q:v 4 sprite.jpg

# 5-секундный качественный GIF-preview на 12 fps, 480 px по ширине, оптимизированная палитра.
ffmpeg -ss 30 -t 5 -i input.mp4 \
       -vf "fps=12,scale=480:-1:flags=lanczos,split[a][b];[a]palettegen[p];[b][p]paletteuse" \
       preview.gif

Двухстадийный трюк palettegen / paletteuse создаёт GIF с кастомной 256-цветной палитрой, подобранной под конкретный контент: размер файла на 30% меньше, а качество изображения заметно выше, чем при простом использовании -c:v gif.

11. Live-стриминг: RTMP, SRT, WHIP

Для live-ингеста в стриминговый сервер FFmpeg поддерживает RTMP (устаревший, но до сих пор повсеместно используемый протокол, появившийся в 2002 году), SRT (современную надёжную замену на основе UDP) и, начиная с версии 7.1, также WHIP (WebRTC-HTTP Ingest Protocol – стандарт WebRTC для одностороннего вещания). 12

# RTMP ingest в Twitch, YouTube или любой RTMP-сервер.
ffmpeg -re -i input.mp4 \
       -c:v libx264 -preset veryfast -tune zerolatency -b:v 4500k -maxrate 4500k -bufsize 4500k \
       -g 60 -keyint_min 60 -sc_threshold 0 \
       -c:a aac -b:a 160k -ar 44100 \
       -f flv "rtmp://live.twitch.tv/app/STREAM_KEY"

Новые флаги: -re читает входной поток с его родной частотой кадров, чтобы избежать перегрузки сети всплесками трафика. -tune zerolatency переводит x264 в режим низкой задержки – без B-кадров и предварительного анализа. -g 60 -keyint_min 60 заставляет генерировать ключевые кадры каждые 60 кадров (то есть каждые 2 секунды при 30 fps) – стандартная частота для приёмных систем. -sc_threshold 0 отключает автоматическое создание ключевых кадров при смене сцены, что позволяет сохранить фиксированную периодичность.

# SRT push в CDN ingest endpoint (заменяет RTMP для low-latency-вещания).
ffmpeg -re -i input.mp4 \
       -c:v libx264 -preset veryfast -tune zerolatency -b:v 4500k -maxrate 4500k -bufsize 4500k \
       -g 60 -keyint_min 60 \
       -c:a aac -b:a 160k \
       -f mpegts "srt://ingest.example.com:9000?streamid=publish/event42"

# WHIP ingest в WebRTC origin (FFmpeg 7.1+).
ffmpeg -re -i input.mp4 \
       -c:v libx264 -preset veryfast -tune zerolatency -b:v 2500k -maxrate 2500k -bufsize 2500k \
       -profile:v baseline -level 3.1 \
       -c:a libopus -b:a 96k -ar 48000 -ac 2 \
       -f whip "https://whip.example.com/publish/event42"

Форма WHIP – новая: она позволяет FFmpeg напрямую транслировать поток в любой WebRTC-сервер, поддерживающий стандарт IETF WHIP (драфты с 2022 года), используя синтаксис, аналогичный RTMP и SRT. Обратите внимание на ограничения по кодекам: WebRTC требует H.264 baseline (или VP8/VP9/AV1) и Opus, поэтому флаги энкодера отличаются от broadcast-ингеста. 13

12. Частые ошибки (и как их исправлять)

Перечисленные ниже ошибки стоят больше времени в продакшене, чем все остальные проблемы FFmpeg вместе взятые.

Первая – -ss после -i для fast trim. Размещение -ss после -i работает, но при этом декодируются все кадры с начала файла до точки обрезки – это медленно, особенно на двухчасовом фильме. Чтобы ускорить процесс, ставьте -ss до -i – тогда будет использоваться быстрый поиск по ключевым кадрам (keyframe-accurate seek). Используйте -ss после -i только в тех случаях, когда нужна точная обрезка по кадрам, а скорость не имеет значения.

Вторая – забыли -pix_fmt yuv420p при транскодировании из профессионального источника. ProRes или DNxHR мастер – 10-битный 4:2:2; без явного указания -pix_fmt FFmpeg сохраняет эту хромину в H.264-выходе, и файл не воспроизводится примерно на трети телефонов. Всегда указывайте -pix_fmt yuv420p для доставки в веб.

Третья – -crf и -b:v в одной команде. Эти параметры взаимоисключающие: -crf задаёт постоянное качество, а -b:v – постоянный битрейт. FFmpeg молча игнорирует один из них и применяет второй, но какой именно – зависит от кодека. Выбирайте один режим и придерживайтесь его (или используйте ограниченный CRF с -crf + -maxrate + -bufsize – современный компромисс).

Четвёртая – -c copy вместе с применением фильтра. Фильтры работают только с декодированными кадрами. Если вы просите FFmpeg одновременно применить фильтр и выполнить копирование потока, он либо выдаст странную ошибку, либо просто проигнорирует фильтр. Для работы фильтра нужно указать -c:v <encoder>, а не -c:v copy.

Пятая – сломанный HEVC на iPhone из-за hev1 вместо hvc1. Устройства Apple требуют four-character code hvc1, а по умолчанию FFmpeg для libx265 использует hev1. Всегда указывайте -tag:v hvc1, если целевая платформа – Apple. Мы уже упоминали это в разделе про HEVC, но проблема возникает настолько часто, что стоит повторить.

Шестая – смешение 29.97 и 30 в одном пайплайне. На первый взгляд они выглядят одинаково, но уже на 18-й минуте 0,1%-ный дрейф может сбить синхронизацию на один кадр. Зафиксируйте частоту кадров на этапе инспекции и сохраняйте её на всех этапах: используйте -r 30000/1001 или -r 30 везде – но не оба варианта одновременно.

13. Производительность: что масштабируется, а что – нет

CPU-нагрузка FFmpeg в основном определяется энкодером. Декодирование занимает около 5–10% общей нагрузки процессора, фильтрация – ещё 5–20% в зависимости от сложности, а кодирование – оставшиеся 70–90%. Это означает:

• Потоковая обработка масштабирует энкодер. x264 и x265 поддерживают до 16 потоков нативно; SVT-AV1 линейно масштабируется до 64 потоков. На сервере с большим количеством ядер лучше запускать по одному экземпляру FFmpeg на файл, а не один FFmpeg с множеством потоков – накладные расходы на процесс ниже, а загрузка ядер эффективнее.
• GPU-ускорение полезно для кодирования, но не для фильтрации. Переход с libx264 на h264_nvenc сокращает время кодирования на 90%. Перенос операции -vf scale=1280:720 с CPU на GPU-скалер экономит секунды, а не минуты. Оптимизируйте только после профилирования.
• Двухпроходное кодирование удваивает время, но повышает качество на 1–2 балла по VMAF при одинаковом среднем битрейте. Оно оправдано для мастер-файлов VOD; бессмысленно при трансляции в реальном времени или одноразовом рендере.
• NVMe-диски критически важны для работы с 4K и несжатыми источниками. Необработанный 4K-мастер требует пропускной способности 12 Гбит/с; SATA SSD ограничены 4 Гбит/с и становятся узким местом. NVMe и enterprise SSD в формате U.2 справляются, а HDD – нет.

Полезный бенчмарк: на 16-ядерном AMD EPYC при использовании FFmpeg 7.1 кодирование часа видео в разрешении 1080p с параметрами libx264 -preset medium -crf 23 занимает около 12 минут. Тот же источник с libx265 -preset medium -crf 26 – 22 минуты, а с libsvtav1 -preset 6 -crf 30 – 45 минут. Переход на h264_nvenc -preset p5 -cq 23 на одной RTX A4000 снижает время обработки H.264-кейса до менее чем 90 секунд – с потерей примерно 1,5 балла по VMAF.

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

Мы запускаем FFmpeg-пайплайны более чем в 239 видеопродуктах с 2005 года – в видеостриминге, видеоконференцсвязи, OTT и интернет-ТВ, видеонаблюдении, e-learning, телемедицине и AR/VR. В стриминге и OTT строим многоуровневые ABR-лестницы с использованием SVT-AV1 и x265 на AWS Elemental или собственных фермах на базе NETINT VPU, выводим результат в формате CMAF для унифицированной поддержки HLS и DASH, а водяные знаки накладываем на каждый уровень отдельно. В телемедицине FFmpeg записывает fMP4 из WebRTC-потока, нормализует аудио с помощью loudnorm и генерирует как доказательный MP4, так и легковесный прокси-файл для низкой пропускной способности. В системе видеонаблюдения применяем NVENC для реального времени многопоточного захвата HEVC с десятков IP-камер в архивы с долгосрочным хранением. В e-learning кодируем загружаемые материалы преподавателей через x264 с адаптивным ограничением CRF, ориентированным на содержание, и встраиваем таймкоды с помощью drawtext. Паттерн остаётся неизменным: правильный энкодер под баланс скорости и качества, фиксированная версия FFmpeg, каждый флаг – как контракт, сохраняющий работоспособность при обновлении.

Ключевые тезисы

• FFmpeg – пятиступенчатый пайплайн (demux → decode → filter → encode → mux); любая команда – это подмножество этих стадий.
• ffprobe перед каждым важным транскодированием – пять секунд анализа сэкономят часы на исправление ошибочного вывода.
• -c copy – самый быстрый режим; используйте его всегда, когда меняете только контейнер или режете по keyframe’ам.
• Для универсальной веб-доставки: x264 + AAC + +faststart + yuv420p; для Apple HEVC добавьте -tag:v hvc1; для современного веб-формата AV1 – libsvtav1 -preset 6 -crf 30.
• Аппаратные энкодеры (NVENC, QSV, VideoToolbox) выигрывают в live- и real-time-сценариях; программные (x264, x265, SVT-AV1) – в VOD, хранящемся на CDN месяцами.
• Фиксируйте конкретную версию FFmpeg в продакшене – 7.1.x для стабильности, 8.1.x для новых возможностей аппаратного кодирования – и относитесь к каждому флагу как к контракту.

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

• Контейнеры: MP4, fMP4, MKV, WebM, MOV, MPEG-TS
• Rate control: CBR, VBR, CRF, ABR, capped CRF
• AV1: новый стандарт интернета и где он сейчас в 2026