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

TL;DR

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

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

Если вы строите что-то, что касается видео – стриминговый сервис, обучающую платформу, телемедицинский продукт, видеоконференц-приложение, дашборд видеонаблюдения, инструмент для подкастов, – FFmpeg будет тем слоем, который превращает «у нас есть файл» в «пользователь смотрит это на телефоне через пять секунд без зависаний». Ваши инженеры будут писать команды FFmpeg; ваш DevOps будет запускать FFmpeg в контейнерах; ваш AWS-счёт будет измеряться в FFmpeg-CPU-часах. Продакт-менеджер, понимающий, что 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 универсальным стандартом – VLC, OBS, MPV, HandBrake, Plex, Jellyfin, Bitmovin, Mux, AWS Elemental и почти каждый браузерный записчик линкуются с libav* под капотом. Устанавливая FFmpeg, вы устанавливаете и движок, на котором работает половина стримингового интернета.

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

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

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

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

Любая команда FFmpeg выполняет какой-то поднабор из пяти операций, в порядке. Выучите эти пять – и синтаксис перестанет выглядеть произвольным.

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

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

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

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

Пятый шаг – 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. Inspect перед transcode

Единственная привычка, предотвращающая большинство продакшен-инцидентов, – запускать 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-grade), тайминги.

Для однострочного резюме в 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 – продакшен-grade chroma subsampling, не проиграется на потребительском железе без перекодирования.
• profile – для H.264: Baseline играет везде, но плохо сжимает; Main поддерживается широко; High – современный веб-дефолт; High 10 и High 4:2:2 – профессиональные. Для H.265: Main универсален, Main 10 – HDR, Main 4:2:2 10 – broadcast. Отправите High 10 H.264 на старый Android – получите аудио на чёрном экране.
• r_frame_rate – пишется как numerator/denominator. 30000/1001 – это 29.97 fps (NTSC), 24000/1001 – 23.976 fps (кино), 25/1 – PAL, 60/1 – broadcast 60p. Смешав 29.97 и 30 в одном пайплайне, через полминуты воспроизведения вы получаете дрейф.

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

2. Самая быстрая операция: stream copy

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

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

Шорткат -c copy говорит «копировать каждый поток без перекодирования». Можно писать явно: -c:v copy -c:a copy. Некоторые MKV-only аудиокодеки не помещаются в MP4 – FLAC, Vorbis, отдельные TrueHD-профили – и 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 – это «fast seek»: прыжок к ближайшему keyframe до запрошенного таймкода без декодирования. Это делает его моментальным, но неточным; реальный рез может начаться до одной длины GOP (обычно 2 секунды) раньше, чем вы попросили. Если нужна точность до кадра – поставьте -ss после -i и заплатите за декодирование всего до точки реза.

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

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

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

3. Скучный надёжный веб-transcode

Самая распространённая задача: взять произвольный входной файл и получить 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 выбирает trade-off скорость/эффективность; пресеты идут ultrafast, superfast, veryfast, faster, fast, medium (дефолт), slow, slower, veryslow, placebo. Каждый шаг влево удваивает скорость и добавляет 5–10% к размеру файла на том же визуальном качестве.

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

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

-pix_fmt yuv420p форсит 8-битное 4:2:0. Без этого флага FFmpeg может сохранить 10-битную или 4:2:2 chroma источника и выдать файл, который 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. Спорт и анимация выше (больше движения = больше бит при том же 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, – это продакшен-grade 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 выбирает trade-off – пресеты 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 – fine-tuning string для SVT-AV1. tune=0 оптимизирует субъективную резкость, а не PSNR (дефолт tune=1 целится в PSNR, на который человеческий глаз на самом деле не смотрит); film-grain=8 включает синтез плёночного зерна – энкодер чистит шум входа, кодирует чистую картинку (которая сжимается лучше) и подмешивает синтетическое зерно при декодировании, неотличимое от исходного. Grain synthesis – одна из фирменных AV1-побед в эффективности; на плёночном контенте экономит 20–30% битрейта.

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

Trade-off: SVT-AV1 на preset 6 кодирует на 0,5×–2× realtime на современном восьмиядерном CPU – примерно в 10 раз медленнее x264 на preset medium. Для VOD, который лежит на CDN месяцами, это одноразовая цена, которую стоит заплатить. Для ad-hoc transcodes – оставайтесь с 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 объявлять свой HEVC-трек четырёхбуквенным кодом hvc1 вместо альтернативного hev1. QuickTime, Safari и AVPlayer от Apple требуют hvc1; без этого тега файл играет на Android и Chrome, но показывается как невоспроизводимый на iPhone. 7

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

6. Hardware-ускорение: когда оно нужно, когда нет

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

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

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

# 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 – NVENC-эквивалент CRF; шкала совпадает с 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× realtime.

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

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

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-muxer. -hls_time 4 ставит сегмент на 4 секунды – современный дефолт для HLS и DASH. -hls_segment_type fmp4 выдаёт fragmented MP4-сегменты (CMAF-совместимые) вместо legacy MPEG-TS – см. нашу статью про контейнеры, почему это важно. -master_pl_name пишет верхнеуровневый плейлист, перечисляющий все четыре rung'а. -var_stream_map говорит муксеру парить каждый видео-rung с одной и той же аудиодорожкой. 9

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

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

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

Фильтры живут внутри -vf (chain видеофильтров) или -filter_complex (multi-input граф). Самые частые покрывают 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. Аудио: extract, replace, mix, normalise

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

# Вытащить аудиодорожку как качественный 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 loudness-нормализационный фильтр, тот же алгоритм, который вещатели используют, чтобы рекламные блоки не были громче передачи. LUFS (Loudness Units relative to Full Scale) – перцептивная единица громкости EBU; -16 LUFS – де-факто стандарт YouTube, Spotify, подкастов, -23 LUFS – broadcast-цель EBU. Двухпроходная форма сначала меряет, потом корректирует – точнее однопроходной, но занимает вдвое больше времени.

10. Миниатюры, sprite'ы и GIF'ы

Плееры, e-commerce-каталоги видео, 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-ingest в стриминговый сервер FFmpeg говорит на RTMP (legacy-дефолт, ровесник 2002, но до сих пор везде), SRT (современный надёжный-UDP-замену) и с FFmpeg 7.1 также на WHIP (WebRTC-HTTP ingestion 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 читает вход с его нативной частотой кадров (чтобы не заливать сеть burst'ами). -tune zerolatency переключает x264 в low-latency-режим – без B-кадров, без look-ahead. -g 60 -keyint_min 60 форсит keyframe каждые 60 кадров (2 секунды на 30 fps), стандартная ingest-каденция. -sc_threshold 0 отключает scene-change keyframe'ы, ломающие фиксированную каденцию.

# 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-ingest. 13

12. Частые ошибки (и как их чинить)

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

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

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

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

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

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

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

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

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

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

Полезный бенчмарк: на 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 и Internet TV, видеонаблюдении, e-learning, телемедицине и AR/VR. В стриминге и OTT гоняем multi-rung ABR-лестницы через SVT-AV1 и x265 на AWS Elemental или self-hosted NETINT VPU-фермах, пушим выход как CMAF для унифицированного HLS и DASH, водяной знак ставим на каждый rung индивидуально. В телемедицине FFmpeg записывает fMP4 из WebRTC-трека, нормализует аудио через loudnorm и выдаёт и доказательный MP4, и low-bandwidth proxy. В видеонаблюдении используем NVENC для real-time многопоточного HEVC-захвата с десятков IP-камер в long-retention архивы. В e-learning кодируем загрузки преподавателей через x264 с content-aware capped CRF и burn-in таймкодов через drawtext. Паттерн повторяется: правильный энкодер под бюджет скорость-качество, зафиксированная версия FFmpeg, каждый флаг – как контракт, переживающий следующий релиз.

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

• FFmpeg – пятистадийный пайплайн (demux → decode → filter → encode → mux); любая команда – поднабор стадий.
• ffprobe перед каждым важным transcode – пять секунд инспекции экономят часы починки неверного вывода.
• -c copy – самый быстрый режим; берите его всегда, когда меняете только контейнер или режете по keyframe'ам.
• Для универсальной веб-доставки: x264 + AAC + +faststart + yuv420p; для Apple HEVC добавьте -tag:v hvc1; для современного веб-AV1 – libsvtav1 -preset 6 -crf 30.
• Hardware-энкодеры (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