Если вы создаёте видео, конвертируете готовые файлы или готовите видеоконтент для сайта, один из важнейших вопросов — выбор формата и параметров сжатия. Самый маленький файл не обязательно самый удачный. Видео также должно надёжно воспроизводиться в браузерах и на смартфонах, эффективно декодироваться и сохранять качество изображения, достаточное для своих задач.
Я изучил MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, пресеты кодировщика x264, совместимость с браузерами, аппаратное декодирование на мобильных устройствах и методы измерения качества видео. Кроме того, я провёл практические эксперименты по сжатию: закодировал один и тот же исходный ролик с несколькими значениями CRF и сравнил результаты визуально и по объективным метрикам.
В итоге я решил отдать предпочтение MP4 с H.264, когда один видеофайл должен работать на максимально широком круге браузеров, телефонов и сторонних приложений.
Для коротких роликов, предназначенных прежде всего для просмотра на смартфонах, где быстрая загрузка и небольшой размер важнее сохранения мельчайших деталей, я выбрал x264 CRF 30. При обычном воспроизведении я не увидел существенной разницы между CRF 22 и 30 даже на большом мониторе компьютера.
Однако здесь необходима важная оговорка: CRF 30 — не моя рекомендация для фильмов, высококачественного видеопроизводства или материалов, в которых принципиально важно максимально точно сохранить изображение. В таких случаях более консервативное значение, нередко около CRF 20, может быть лучшей отправной точкой. Сопоставимого исследования полнометражных фильмов и качественного кинематографического материала я не проводил, поэтому эти настройки следует рассматривать лишь как ориентиры для отдельных испытаний.
В этой статье я разберу технические причины выбора, реальные результаты сжатия и их ограничения, а также объясню, как подобрать формат и качество видео для своего проекта.
1. Контейнер и кодек — разные вещи
Прежде чем сравнивать MP4 и WebM, необходимо разобраться в разнице между контейнером и кодеком.
Контейнер объединяет в одном файле видео, звук, временные метки и метаданные. Видеокодек определяет, как видеокадры сжимаются и декодируются.
Например, контейнер MP4 может содержать видео H.264, HEVC или AV1. Несмотря на одинаковое расширение файла, эти сочетания различаются эффективностью сжатия и требованиями к устройствам.
| Компонент | Примеры | Назначение |
|---|---|---|
| Видеоконтейнер | MP4, WebM, MOV, MKV | Объединяет видео, звук и временные данные |
| Видеокодек | H.264, HEVC, VP9, AV1 | Сжимает и декодирует видеокадры |
| Аудиокодек | AAC, Opus, MP3 | Сжимает и декодирует звук |
| Видеокодировщик | x264, x265, SVT-AV1, libvpx-vp9 | Реализует сжатие видео |
Переименование файла из .webm в .mp4 не меняет видеокодек. Точно так же размещение AV1 внутри MP4 не обеспечит воспроизведение на устройствах без поддержки декодирования AV1.
Обсуждая совместимость видео, всегда рассматривайте сочетание всех параметров: контейнер, видеокодек, аудиокодек, профиль кодека, битовую глубину и среду воспроизведения.
2. MP4 или WebM: что лучше для видео на сайте?
И MP4, и WebM — полноценные современные видеоконтейнеры. Ни один из них не превосходит другой во всех случаях: практические свойства зависят от кодеков внутри файла.
MP4 с H.264: максимально широкая практическая совместимость
Сочетание видео H.264 и аудио AAC в контейнере MP4 отличается исключительно широкой совместимостью, проверенной временем. Его поддерживают популярные настольные и мобильные браузеры, системные видеоплееры и многие сторонние приложения.
Аппаратные видеодекодеры смартфонов и компьютеров также обычно поддерживают этот формат. По сравнению с программным декодированием аппаратное может снизить нагрузку на процессор, повысить эффективность воспроизведения и сократить энергопотребление.
Основной недостаток — эффективность сжатия. Более новые кодеки нередко обеспечивают сопоставимое воспринимаемое качество при меньшем битрейте.
Тем не менее H.264 остаётся отличным выбором, если надёжное воспроизведение важнее минимально возможного размера файла.
WebM с VP9: эффективное решение для браузеров
Контейнер WebM обычно содержит видео VP8, VP9 или AV1, а звук, как правило, кодируется с помощью Opus или Vorbis.
VP9 часто сжимает эффективнее H.264 при сопоставимом визуальном качестве. Его широко поддерживают современные браузеры, включая актуальные версии Safari.
Утверждать, что Safari вообще не поддерживает WebM или VP9, было бы ошибкой. Совместимость браузеров с этими технологиями заметно улучшилась.
Более существенное ограничение — совместимость за пределами браузера. Системные приложения, старые устройства и сторонние программы могут работать с WebM менее предсказуемо, чем с обычным MP4/H.264.
Если приложение рассчитано исключительно на браузер и вы контролируете возможности воспроизведения, WebM — хороший вариант. Но для видео, которое посетители могут скачать и открыть в произвольной программе, MP4/H.264 остаётся более предсказуемым решением.
Сравнение на практике
| Критерий | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Воспроизведение в современных браузерах | Отлично | Очень хорошо |
| Поддержка старых браузеров и устройств | Обычно шире | Сильнее зависит от среды |
| Совместимость скачанных файлов | Обычно шире | Менее предсказуема в системных приложениях |
| Эффективность сжатия | Хорошая | Часто выше |
| Аппаратное декодирование | Очень широко распространено | Распространено, но зависит от устройства |
| Лучше всего подходит для | Одного файла с широкой совместимостью | Эффективной доставки через сайт на известные устройства |
Главный вопрос не в том, хорош ли WebM. Нужно понять, оправдывают ли преимущества сжатия связанные с ним компромиссы по совместимости именно в вашей среде.
3. H.264, H.265, VP9 или AV1: какой кодек выбрать?
У каждого распространённого видеокодека свой баланс эффективности сжатия, затрат на кодирование, аппаратной поддержки, программной совместимости и условий лицензирования.
| Кодек | Эффективность сжатия | Практическая совместимость | Типичное применение |
|---|---|---|---|
| H.264 / AVC | Хорошая | Отличная | Обычное веб-видео, мобильное воспроизведение, скачивание |
| H.265 / HEVC | Как правило, выше, чем у H.264 | Зависит от среды | Совместимые устройства Apple, контролируемые среды, видео высокого разрешения |
| VP9 | Как правило, выше, чем у H.264 | Очень хорошая в современных браузерах | Доставка видео через браузер |
| AV1 | Потенциально отличная | Растёт, но есть ограничения старых устройств | Современный стриминг и совместимые устройства |
Это качественное сравнение, а не универсальный рейтинг по битрейту. Реальная эффективность зависит от содержимого видео, реализации кодировщика, целевого качества, пресета и способа измерения.
H.264: зрелый кодек с быстрым декодированием и широкой поддержкой
H.264 хорошо оптимизирован и поддерживается огромным количеством устройств и программ. Зрелость технологии особенно полезна, когда видео должно надёжно воспроизводиться без специального приложения.
Его слабая сторона — более новые кодеки нередко сжимают видео эффективнее. Кроме того, для H.264 существуют патентные и лицензионные ограничения, которые следует учитывать при соответствующих сценариях коммерческого распространения.
H.265 / HEVC: лучшее сжатие с компромиссами по совместимости
При сопоставимом качестве HEVC может существенно снизить битрейт относительно H.264. Он особенно интересен для видео высокого разрешения и сред с заранее известной совместимостью устройств.
Многие устройства Apple отлично поддерживают HEVC. Однако поддержка в браузерах и сторонних программах различается в зависимости от операционной системы и установленных компонентов декодирования. Не стоит забывать и о лицензировании.
HEVC может оказаться прекрасным вариантом, но я не стал бы автоматически делать его единственным форматом скачиваемого видео на универсальном сайте.
VP9: практичная открытая альтернатива
VP9 обеспечивает хорошее сжатие и широкую совместимость с современными браузерами. Это привлекательный вариант для видео, которое остаётся внутри браузера и воспроизводится в предсказуемой среде.
В моём случае главный недостаток заключался в неопределённости: пользователи могут скачать ролик или открыть его в системном приложении, где поддержка WebM или VP9 бывает неполной.
AV1: высокая эффективность, но аппаратная поддержка пока не универсальна
AV1 — один из самых перспективных современных видеокодеков. Он способен существенно уменьшать битрейт по сравнению со старыми кодеками, а поддержка аппаратного декодирования продолжает расширяться.
Тем не менее на старых устройствах декодера AV1 может не быть, поэтому потребуется программное декодирование. При высоком разрешении оно способно сильнее нагружать процессор, расходовать заряд аккумулятора и вызывать проблемы с воспроизведением на слабых устройствах.
Если вы контролируете среду воспроизведения, AV1 заслуживает серьёзного внимания. Если же один файл должен работать на старых и новых устройствах и в обычных сторонних плеерах, H.264 остаётся более безопасным вариантом по умолчанию.
В руководстве MDN по видеокодекам подробно описаны эти кодеки и требования к их поддержке в браузерах.
4. Один видеоформат или несколько версий?
Это одно из важнейших архитектурных решений при доставке видео.
Если можно хранить несколько версий, сайт способен отдавать AV1 или VP9 совместимым устройствам, а в остальных случаях использовать H.264. Такой подход повышает эффективность сжатия без существенного сокращения охвата устройств.
Но поддержка нескольких версий усложняет кодирование, хранение, кеширование, проверку файлов и выбор подходящего варианта для воспроизведения.
Если для каждого исходного ролика вам нужен ровно один готовый видеофайл, часто разумнее прежде всего ориентироваться на совместимость.
Я выбрал MP4/H.264, потому что хотел иметь один файл для основных браузеров, смартфонов и типичных сценариев скачивания и просмотра без запасных форматов.
Это не означает, что MP4/H.264 обеспечивает лучшее сжатие. Я просто поставил предсказуемость воспроизведения выше потенциальной экономии места от нового кодека.
5. Почему для мобильного видео важны другие приоритеты
Настройки сжатия должны соответствовать тому, как люди будут смотреть видео.
Короткий ролик, который преимущественно смотрят на смартфоне, и полнометражный фильм для большого телевизора требуют разного подхода. В первом случае быстрая загрузка и экономия мобильного трафика могут быть важнее тонких деталей. Во втором главным приоритетом может стать качество изображения.
Для коротких роликов, ориентированных на смартфоны, меньший размер файла даёт несколько преимуществ:
- До начала воспроизведения нужно передать меньше данных.
- На медленном соединении скачивание может завершиться быстрее.
- Файл занимает меньше памяти устройства.
- Пользователь расходует меньше мобильного трафика.
- При меньшем битрейте воспроизведение может лучше переносить ограничения пропускной способности.
Однако маленький файл не гарантирует отсутствие остановок и буферизации. На результат также влияют колебания скорости сети, пиковый битрейт, работа сервера, буферизация плеера и производительность декодирования на устройстве.
Совместимость с мобильными устройствами определяется не только расширением файла: важны аппаратное декодирование, профиль и уровень кодека, битовая глубина, цветовая субдискретизация, разрешение, частота кадров и пиковый битрейт. Видео шириной 390 CSS-пикселей на экране смартфона с высокой плотностью пикселей может занимать гораздо больше физических пикселей. Поэтому просмотр кадра, уменьшенного до 390 пикселей, не обязательно равнозначен просмотру исходного видео на таком телефоне. Проверяйте результат на настоящих устройствах и в реальных условиях.
CRF управляет качеством, а не задаёт строгий верхний предел битрейта. Даже сравнительно небольшой файл со сложным видеорядом может содержать участки с высоким пиковым битрейтом. Если особенно важно стабильное воспроизведение на очень медленном соединении, рассмотрите явные ограничения битрейта или VBV, разумные пределы разрешения и испытания в реалистичных сетевых условиях.
Главный принцип прост: оптимизируйте видео под реальный сценарий просмотра, а не ради абстрактного максимального качества.
6. Как работает CRF в x264: меньше значение — выше качество, больше — меньше файл
После выбора H.264 нужно решить, насколько сильно сжимать видео.
В x264 параметр Constant Rate Factor, или CRF, определяет компромисс между сохранением деталей изображения и размером файла.
Как правило, более низкий CRF даёт более качественные, но крупные файлы. Более высокий CRF — файлы меньшего размера, но с большими потерями от сжатия.
CRF не задаёт точный битрейт или размер результата. Кодировщик распределяет биты в зависимости от исходного материала, поэтому простая и очень детализированная сцены при одинаковом CRF могут давать совершенно разные размеры файлов.
Сам по себе CRF также не определяет базовую совместимость с декодером. Два корректно закодированных видео H.264 с CRF 22 и CRF 30 могут иметь одинаковые кодек, профиль, уровень, формат пикселей, размеры кадра и частоту кадров.
Разница прежде всего в степени сжатия, качестве и характеристиках битрейта.
Важно: значения CRF нельзя напрямую сравнивать между разными реализациями кодеков. CRF 30 в x264 не означает того же визуального качества, что CRF 30 в кодировщике AV1.
7. Мой практический эксперимент со сжатием: CRF от 22 до 32
Я хотел выяснить, насколько сильно можно сжать ролик, прежде чем разница станет заметной при обычном просмотре.
Я взял один короткий ролик, который уже был сжат, и подготовил версии H.264 со значениями CRF 22, 24, 26, 28, 29, 30, 31 и 32.
Основные свойства видео — разрешение, частота кадров, продолжительность и количество кадров — были сохранены. Остальные настройки кодирования также оставались одинаковыми, чтобы можно было оценить именно влияние CRF.
Размеры файлов заметно различались.
| CRF | Примерный размер относительно исходника | Что это означает |
|---|---|---|
| 22 | 63% | Более щадящее сжатие и лучшее сохранение деталей |
| 24 | 49% | Меньший файл с умеренным дополнительным ухудшением качества |
| 26 | 38% | Дополнительная экономия при сохранении значительной детализации |
| 28 | 30% | Компактный файл с относительно высоким сходством с исходником |
| 29 | 26% | Более агрессивное сжатие |
| 30 | 23% | Предпочтительный для меня компромисс на проверенном материале |
| 31 | 21% | Ещё меньший размер при меньшей точности передачи исходника |
| 32 | 19% | Самый маленький тестовый файл и наибольшая измеренная потеря качества |
Эти проценты относятся только к проверенному исходнику и не должны восприниматься как типичная экономия для любых видео. Значения в таблице округлены независимо друг от друга; для точного сравнения нужно использовать исходные размеры файлов, а не делить округлённые проценты.
Самым неожиданным оказалось то, что при обычном воспроизведении я не заметил существенной визуальной разницы между CRF 22 и CRF 30 даже на большом мониторе компьютера.
Я также посмотрел версии с ещё более сильным сжатием, включая CRF 32, и при обычном просмотре именно этого ролика не увидел существенных различий.
Это наблюдение было особенно важным, поскольку ролики в первую очередь предназначались для небольших мобильных экранов. Если ухудшение качества не мешало мне даже на настольном мониторе, я не видел смысла существенно увеличивать файлы ради деталей, которые не улучшали мой сценарий просмотра.
Однако это субъективное наблюдение на материале одного типа. Оно не доказывает, что у всех зрителей, на всех смартфонах и с любыми видео результат будет таким же. На мобильных экранах с высокой плотностью пикселей и при просмотре с близкого расстояния артефакты всё же могут быть заметны, особенно на мелких деталях и градиентах.
8. Объективные измерения подтвердили реальные потери качества
Если при просмотре разница незаметна, это не значит, что два видео математически идентичны.
Я также сравнил закодированные версии с помощью объективных метрик качества изображения. По мере увеличения CRF сходство с исходником уменьшалось.
Для сравнения с одинаковым уменьшением разрешения, призванного приблизить условия к просмотру на мобильном экране с высокой плотностью пикселей, характерные значения SSIM составили:
| CRF | Примерное значение SSIM | Размер относительно CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
Тенденция очевидна: более сильное сжатие снижало измеренную точность воспроизведения исходного видео. При внимательном рассмотрении обнаруживались и небольшие различия в тонких линиях и текстурах.
При этом обычное впечатление от просмотра проверенного ролика оставалось почти таким же. Именно поэтому объективные метрики стоит сочетать с субъективной оценкой.
SSIM измеряет сходство изображений, а не весь опыт человеческого восприятия видео. Метрика не может полностью учесть временные артефакты, воспринимаемую резкость, особенности движения и субъективную важность отдельных деталей.
Ещё одна полезная метрика воспринимаемого качества — VMAF. В июне 2026 года Netflix выпустила модели VMAF v1, в том числе модель, ориентированную на просмотр с телефона. В них прямо учитывается, что воспринимаемое качество отчасти зависит от размера экрана и относительного расстояния до него.
Для одного из образцов с более щадящим сжатием в исследовании было указано среднее значение VMAF около 95. Но сопоставимого набора измерений VMAF для всех агрессивных значений CRF не было. Поэтому я не использовал VMAF как доказательство того, что CRF 30 или 32 соответствует какому-либо универсальному порогу качества.
Практический вывод получился более узким: при обычном воспроизведении проверенный короткий ролик очень хорошо перенёс сильное сжатие H.264.
9. Почему для коротких мобильных видео я выбрал CRF 30
После сравнения файлов я остановился на CRF 30 для похожих коротких роликов, которые преимущественно смотрят на смартфонах.
Причины были простыми:
- Ролики короткие и не претендуют на кинематографическое качество изображения.
- Быстрая загрузка и небольшой размер скачиваемых файлов были важны.
- На большом мониторе я не заметил существенной разницы между CRF 22 и 30.
- При CRF 30 файлы оказались значительно меньше, чем при более щадящих настройках.
- CRF 32 тоже выглядел приемлемо на тестовом образце, но внушал меньше уверенности для более сложного материала.
По сравнению с CRF 28 значение CRF 30 уменьшило размер тестового файла примерно на 21%. Относительно CRF 22 экономия превысила 60%.
Для коротких мобильных роликов, где важны приятная картинка, быстрая загрузка и разумный расход трафика, такой компромисс меня устроил.
Но здесь принципиально важно условие: я выбрал 30 исходя из реального сценария просмотра и результатов проверки конкретного материала, а не потому, что CRF 30 сам по себе лучше всего подходит смартфонам.
Смартфону не требуется именно CRF 30. Он способен отлично воспроизводить видео и с гораздо меньшими потерями качества. CRF 30 — осознанный обмен части точности изображения на уменьшение файла там, где такой обмен приемлем.
Прежде чем применять эту настройку ко всей коллекции существенно различающихся видео, я проверил бы несколько характерных роликов: со сложным движением, тёмными сценами, градиентами, текстом и мелкими текстурами.
10. Почему я не советую CRF 30 для фильмов и видео высокого качества
Это самое важное ограничение моего эксперимента.
Не следует бездумно переносить результат с CRF 30 на полнометражные фильмы, премиальный видеоконтент, профессиональные съёмки или видео для больших экранов.
В таком материале могут быть тонкие градиенты, плёночное зерно, слабоосвещённые сцены, сложное движение, мелкие текстуры и тщательно выстроенная цветокоррекция. Сохранить эти детали иногда важнее, чем немного сэкономить на трафике.
Для обычного качественного видео 1080p я начал бы с гораздо более щадящей настройки x264 — около CRF 20 — и проверил соседние значения с учётом исходного материала.
Когда важна точность изображения, практическим начальным диапазоном может быть CRF 18–22. Однако подходящее значение бывает и за его пределами: всё зависит от разрешения, содержимого и требований.
Такая рекомендация согласуется с распространёнными руководствами по кодированию. Например, документация HandBrake по качеству для многих сценариев x264 в разрешении 1080p рекомендует примерно RF 20–24.
Я не проводил аналогичного контролируемого исследования полнометражных фильмов или премиального кинематографического материала. Поэтому не могу утверждать, что CRF 20 оптимален всегда, что CRF 22 неизменно достаточно или что какой-то конкретный фильм обязательно будет плохо выглядеть при CRF 30.
Правильный подход — выбрать характерные сцены, закодировать несколько вариантов качества, сравнить их на предполагаемом экране и определить, когда дальнейшее сжатие начинает заметно вредить изображению.
Если видео предстоит архивировать, повторно редактировать или использовать для последующего кодирования, качественный мастер-файл нужно хранить отдельно от сжатой версии для просмотра.
11. Почему я использовал пресет x264 veryslow
CRF управляет одним аспектом качества сжатия, а пресет x264 определяет, сколько усилий кодировщик тратит на поиск эффективных решений.
У x264 есть пресеты от очень быстрых до очень медленных. Как правило, более медленные настройки требуют больше процессорного времени, но способны обеспечить более эффективное сжатие при сопоставимом визуальном качестве.
Я сравнил пресеты medium и veryslow на одном исходнике. При проверенном уровне качества veryslow дал файл меньшего размера.
Когда кодирование выполняется офлайн один раз, а результат затем используется многократно, дополнительные затраты времени могут окупиться.
Поэтому я выбрал -preset veryslow.
Однако это не универсальный оптимум. Если ролики нужно обрабатывать немедленно, вычислительные ресурсы дороги или необходимо переработать огромную очередь файлов, более удачным рабочим компромиссом могут оказаться slow или medium.
Пресет главным образом влияет на сложность кодирования и эффективность сжатия. Он не превращает H.264 в другой кодек и не делает получившийся файл по своей природе несовместимым со смартфонами.
12. Для аниме я использую настройку x264 animation
Если исходник содержит рисованную анимацию или изображение в стиле аниме, я использую с x264 -tune animation.
Эта настройка отличается от CRF. Параметр tune меняет некоторые решения кодировщика с учётом визуальных особенностей материала. Настройка animation предназначена для рисованных контуров, областей с ровной заливкой и стилизованного движения.
Поэтому мои предпочтения такие:
- Аниме и рисованная анимация:
-preset veryslow -tune animation. - Обычное видео с реальными съёмками: не включать animation автоматически; начать со стандартных параметров кодировщика или отдельно проверить подходящий tune.
Важно правильно понимать действие настройки: -tune animation не гарантирует ни видимого улучшения качества, ни уменьшения файла. Она меняет работу кодировщика, а результат зависит от материала.
Я провёл отдельное сравнение с фиксированным CRF и включённой настройкой animation. В нём получившийся файл был примерно на 6% больше, а измеренное сходство с исходником слегка улучшилось. Визуальная разница была небольшой.
Основной эксперимент по сравнению размеров при CRF 22–32 проводился без настройки animation. Поэтому нельзя считать, что полученные размеры и коэффициенты сжатия сохранятся в точности после включения -tune animation.
Тем не менее для аниме я предпочитаю специализированную настройку animation, оценивая размер и качество файла в рамках выбранного профиля кодирования.
Настройки кодировщика следует рассматривать как поправки под конкретный тип контента, а не как универсальный способ повысить качество.
13. Мои настройки FFmpeg для короткого аниме-видео на смартфонах
Для обычного аниме-видео в SDR, которое действительно необходимо перекодировать, я бы использовал в качестве отправной точки такую команду:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4Эта команда явно задаёт основные параметры:
-c:v libx264— программный кодировщик H.264.-preset veryslow— приоритет эффективности сжатия над скоростью кодирования.-tune animation— настройки кодирования с учётом особенностей анимации.-crf 30— выбранный для таких коротких роликов агрессивный уровень постоянного качества.-profile:v high— широко поддерживаемый современными устройствами профиль H.264.-pix_fmt yuv420p— выходное видео с 8-битной глубиной и субдискретизацией 4:2:0.-map 0:v:0— выбор первого видеопотока.-map '0:a:0?'— необязательное включение первого аудиопотока.-c:a aac -b:a 128k— кодирование звука в AAC с указанным битрейтом, если звук присутствует.-movflags +faststart— перенос служебных данных инициализации MP4 ближе к началу файла.
Это пример, а не универсальная команда для любого источника. Для конкретного видео могут понадобиться дополнительные действия.
В частности, нельзя бездумно преобразовывать HDR и 10-битный материал в 8-битный SDR без корректного управления цветом: это может привести к неправильным цветам, потере деталей в светлых участках и заметным полосам на градиентах. Также следует учитывать метаданные поворота, переменную частоту кадров, соотношение сторон пикселя, чересстрочные источники, необычные конфигурации аудио и ограничения по разрешению.
Если частота кадров и размеры исходного видео уже подходят, их сохранение обычно упрощает сравнение и помогает избежать ненужного масштабирования или изменений движения. Не стоит принудительно устанавливать постоянную частоту для источника с переменной частотой кадров без необходимости: это может приводить к дублированию или пропуску кадров. При изменении размера сохраняйте соотношение сторон изображения и следите, чтобы размеры подходили для выбранного пиксельного формата 4:2:0. Очень высокие разрешения, частоты кадров или уровни H.264 могут превышать возможности декодирования старых устройств, поэтому ради совместимости иногда приходится сознательно уменьшать разрешение или частоту кадров.
14. Более щадящие настройки FFmpeg для качественного видео
Если точность передачи изображения намного важнее размера файла, начните с меньшего CRF и проверьте результат.
Например, для обычных видеосъёмок в SDR разумной отправной точкой для эксперимента будет такая команда:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4Пресет slow в этом примере — практичная универсальная отправная точка, а не утверждение о его превосходстве над veryslow. Если дополнительное время кодирования допустимо, вполне разумно использовать и veryslow.
Этот профиль высокого качества я рекомендую лишь как вариант для проверки: мой эксперимент с коротким видео его не подтверждал.
Для премиального видеоконтента проверьте CRF примерно 18, 20 и 22, а затем выберите значение по визуальному результату. Сложное зерно или движение могут потребовать других параметров; мастер-файлы для архива нередко требуют намного более щадящего сжатия.
15. Не перекодируйте видео без необходимости
Сжатие видео с потерями не проходит бесследно. Повторное кодирование уже сжатого файла может добавить артефакты, даже если новый результат выглядит почти как исходник.
Прежде чем перекодировать видео, проверьте, не отвечает ли исходный файл вашим требованиям к совместимости, размеру и качеству.
Если файл уже содержит совместимые видео H.264 и аудио AAC, а преобразовывать изображение не нужно, копирование потоков может быть лучше очередного кодирования с потерями.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4Эта операция копирует сжатые потоки без нового кодирования. Она позволяет изменить организацию контейнера, не добавляя ещё одного поколения потерь видеосжатия.
Обычно это не даёт такого же уменьшения размера, как новое кодирование с пониженным качеством.
Если исходное видео уже компактное, совместимое и визуально приемлемое, лучшая оптимизация — вообще его не трогать.
16. Проверяйте закодированные видео, а не только размер файла
Успешное завершение FFmpeg ещё не доказывает, что видео соответствует всем требованиям.
Начните с проверки выходных потоков через FFprobe:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Проверьте кодек, формат пикселей, размеры кадра, частоту кадров, продолжительность и аудиопотоки.
Затем полностью декодируйте результат, чтобы выявить некоторые повреждения и ошибки декодирования:
ffmpeg -v error -xerror -i output.mp4 -f null -В экспериментах по сжатию сравнивайте версии, созданные из одного исходника. Сохраняйте важные переменные неизменными и меняйте за раз только один основной параметр.
Смотрите видео в движении, изучайте мелкие детали и обращайте внимание на градиенты, тёмные области, движущиеся объекты и текст.
По возможности дополняйте визуальное сравнение объективными метриками SSIM, PSNR или VMAF. Не считайте высокий показатель одной метрики доказательством полной незаметности всех артефактов.
Наконец, проверьте воспроизведение на характерных устройствах и после скачивания файла. Сведения о поддержке браузерами полезны, но если совместимость — главный приоритет, особенно важна реальная проверка.
17. Убедитесь, что сайт правильно отдаёт MP4
Даже хорошие настройки кодирования не компенсируют ошибки доставки видео через сайт.
Для обычного прогрессивного воспроизведения MP4 настройте заголовок Content-Type: video/mp4 и поддержку HTTP-запросов диапазонов байтов там, где необходимы частичная загрузка и перемотка.
Параметр FFmpeg +faststart переносит информацию для инициализации MP4 ближе к началу обычного файла. Это помогает прогрессивной загрузке, но не влияет на визуальное качество и не снижает битрейт.
Для вывода одного MP4 с H.264 достаточно базового HTML-элемента video:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>Атрибут preload — лишь подсказка браузеру, а не строгое ограничение скачивания. Правила браузеров для автоматического воспроизведения могут также требовать отключённого звука или отсутствия аудиодорожки.
Если на странице несколько роликов, не стоит сразу скачивать их все. Загрузка видео только по мере необходимости экономит мобильный трафик и может ускорить воспринимаемую работу страницы.
Для коротких мобильных роликов правильный момент начала загрузки бывает не менее важен, чем уменьшение закодированного файла.
18. Какой формат и уровень качества выбрать?
Ответ зависит от ваших приоритетов.
| Ваша цель | Рекомендуемая отправная точка |
|---|---|
| Один файл для сайта и скачивания с широкой совместимостью | MP4 + H.264 + AAC при наличии звука |
| Доставка через современные браузеры с несколькими форматами | AV1 или VP9 с резервным H.264 |
| Максимальное сжатие на поддерживаемых устройствах | Оценить AV1 |
| Контролируемая среда с поддержкой HEVC | Рассмотреть MP4 + HEVC |
| Короткие мобильные ролики, где прежде всего важен размер | Рассмотреть x264 CRF 30 после проверки характерных образцов |
| Аниме или рисованная анимация | Проверить x264 с -tune animation |
| Качественные фильмы и премиальный видеоконтент | Начать с более щадящего CRF около 20 и проверить |
| Офлайн-кодирование, когда время CPU не так важно | Рассмотреть x264 slow или veryslow |
| Быстрая обработка при ограниченных ресурсах CPU | Рассмотреть x264 medium или slow |
| Существующее видео уже отвечает требованиям | Оставить как есть или заменить контейнер без повторного кодирования |
| Архивирование или последующее редактирование | Хранить высококачественный мастер отдельно от файлов для просмотра |
19. Мой окончательный выбор и что эксперимент действительно показал
Изучив форматы, совместимость, эффективность кодирования и реальные результаты сжатия, я выбрал практичный профиль доставки коротких роликов для мобильного просмотра.
Форматом я выбрал MP4 с H.264, поскольку предсказуемая совместимость с браузерами, смартфонами, скачиваемыми файлами и сторонними программами была для меня важнее минимального размера, которого можно добиться с более новым кодеком.
В качестве кодировщика я выбрал libx264 с пресетом veryslow, поскольку мог кодировать видео офлайн и дополнительные затраты времени были допустимы.
Для аниме я использую настройку animation, понимая, что она меняет поведение кодировщика, но не гарантирует ни меньшего размера файла, ни улучшения изображения во всех случаях.
Для коротких мобильных роликов я выбрал CRF 30, поскольку в моём сравнении он значительно уменьшал файл без существенной визуальной разницы при обычном воспроизведении, даже на большом мониторе компьютера.
Этот результат не означает, что CRF 30 идеален для фильмов или высококачественных съёмок. Если мелкие детали, градиенты, зерно и общая точность изображения важнее, я начал бы проверку с CRF около 20 или другого достаточно щадящего значения. Аналогичного контролируемого исследования кинематографического материала я не проводил, поэтому не выдаю это число за экспериментально доказанный оптимум.
Самый важный вывод: не существует одного лучшего кодека, контейнера или значения CRF для абсолютно всех видео.
Если вам нужна максимальная совместимость и всего один файл, MP4/H.264 — надёжный вариант по умолчанию. Если вы можете предусмотреть резервные форматы и хотите повысить эффективность сжатия, изучите VP9 и AV1. Если кодируете короткие ролики преимущественно для телефонов, проверьте, позволяет ли более высокий CRF достаточно уменьшить файлы без ущерба для предполагаемого просмотра. Для фильмов и премиального видео выбирайте более щадящие параметры качества и тщательно проверяйте результат.
Сначала определите требования к воспроизведению, затем выберите кодек и только после этого — качество сжатия. Проверьте результат на тех устройствах и в тех условиях, которые действительно важны. Такой подход надёжнее слепого выбора кодека или CRF лишь потому, что он новее, эффективнее или часто встречается в рекомендациях.