Почему конвертация двух похожих файлов из mp4 в webm дает очень разные результаты?

Question

[l4m3r]

Есть 2 похожих mp4-файла. Одинаковый размер видео, почти одинаковые продолжительность, fps, кол-во фреймов, кодек. Размер файлов тоже: один 30 (битрейт 1.9М), другой 35 (битрейт 1.3М).
Конвертирую их в webm (vp9). При одних параметрах - один сжимается, другой многократно увеличивается с 30 мб до 160. (битрейт выходного файла становится из 1.3M в 9M, хотя я задавал b:v 1M). При других - наоборот. Почему такое может происходить? Как получить похожий результат сжатия для обоих?

На скрине можно заметить, какие разные результаты для 1 и 2 при одинаковых параметрах конвертирования:

Answer 1

[nidalee]

Во-первых, если ваш энкодер умеет CRF, CQP и прочие адаптивные битрейты \ стратегии энкодера, нужно использовать их. О стратегиях энкодера (Encoder Strategy \ Rate Control \ и прочее названия одного и того же) можно почитать здесь.
Вы не можете знать, какой битрейт нужен каждому отдельному кадру видео, поэтому ваши попытки указать битрейт вручную практически обречены на провал:
1) Если указанный вами битрейт ниже реально необходимого, вы получите ухудшение качества картинки и артефакты сжатия.
2) Если указанный вами битрейт выше реально необходимого, то качество видео останется неизменным, но файл будет "весить" больше, чем мог бы.
Более того, вы указываете битрейт на все видео, в то время как переменный битрейт может быть больше в начале файла (например, где много движения, и требуется больше битрейт), а в конце файла могут быть длинные статичные планы - там битрейт нужен сильно меньше.

Таким образом, поскольку вы используете VP9 (WEBM), вам следует использовать CRF (Constant Quality):

To trigger this mode, you must use a combination of -crf and -b:v 0. Note that -b:v MUST be 0. Setting it to anything higher or omitting it entirely will instead invoke the Constrained Quality mode.

ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 30 -b:v 0 output.webm

The CRF value can be from 0–63. Lower values mean better quality. Recommended values range from 15–35, with 31 being recommended for 1080p HD video.

Поэтому все -b:v без CRF сразу выкидывайте.

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

ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 30 -b:v 2000k output.webm

The quality is determined by the -crf, and the bitrate limit by the -b:v where the bitrate MUST be non-zero.

У вас, кроме того, достаточно нескромный для VP9 CRF - 20 - это для 4К без видимых потерь качества. Уверены, что вам нужно такое? Посмотрите гайд от гугла по VP9 - для 1080P они предлагают устанавливать CRF в 31.
Второй файл с CRF 30 без ограничения битрейтом почти не увеличился. Что по качеству? Просело?

Я не знаю, какой именно кодек используется в вашем MP4 исходнике, но если это HEVC\H.265, то там можно наколдовать более эффективное и качественное сжатие, особенно если есть много лишнего времени на медленные пресеты или ручной их тюнинг. Такой файл после конвертации в VP9 раздует наверняка.
Если исходник H264, то он практически всегда должен сжимать хуже VP9, и значит проблема в ваших настройках.

В общем и целом, при прочих равных, файлы с минимальными изменениями в кадре сжимаются лучше, чем экшн-сцены. То есть если у вас 20 минут абстрактного видео, 2\3 которого - статичное изображение, он будет легче, чем 5 минут абстрактной экшн-сцены.
Опишите или покажите оба видео, и тогда картина наверняка прояснится.

Comments

[l4m3r]

Спасибо за развёрнутый ответ! Почитаю
Дело в том, mp4 загружают пользователи на сайт, а я хочу подобрать какой-то унивесальный алгоритм конвертирования в webm, чтобы:
1) уменьшить размер
2) не ухудшить сильно качество (не в разы)
3) не очень долго (ну макс 5 мин на конверт)
Не вдаваясь в подробности, скажу что mp4 проходят предобработку пропорционально уменьшая размер, чтобы вписывался в квадрат 600x600 и fps 24. То есть все видео маленькие. Это единственное что общее у них. Я не могу играться с каждым, подбирая оптимальные параметры. Вот и ищу хоть какой-то универмальности.

И, в принципе, для таких небольших видеороликов (30-70 мб в среднем) мне хватало универсального `-deadline good -cpu-used 2 -b:v 1 -threads 8`. Но вот попалось одно видео в 30 мегабайт и битрейтом 1.5M, для которого эта конвертация дала результатирующий файл в 150 мб :) вот теперь не пойму почему так происходит

[l4m3r]

Вот данные первого файла который хорошо сжимается и приемлемым качеством при -b:v 1M, но увеличивается в размере при -b:v 0 -crf 30

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '1.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.20.100
    location-eng    : +56.6825+085.0315/
    location        : +56.6825+085.0315/
  Duration: 00:02:11.92, start: 0.000000, bitrate: 2500 kb/s
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc), 720x404 [SAR 101:320 DAR 9:16], 2365 kb/s, 24 fps, 24 tbr, 12288 tbn, 48 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 129 kb/s (default)
    Metadata:
      handler_name    : SoundHandler

[l4m3r]

Вот данные второго файла который проблемый. -b:v 1M увеличивает его в 5-6 раз.
а -b:v 0 -crf 30, размер остается как был mp4, но качество так себе

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.20.100
  Duration: 00:02:27.75, start: 0.000000, bitrate: 1649 kb/s
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 720x404 [SAR 404:405 DAR 16:9], 1515 kb/s, 24 fps, 24 tbr, 12288 tbn, 48 tbc (default)
    Metadata:
      handler_name    : ?Mainconcept Video Media Handler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default)
    Metadata:
      handler_name    : #Mainconcept MP4 Sound Media Handler

[nidalee]

l4m3r, найдите самое большое видео, аномалию, и используйте ее как образец. Жмите через -crf от 32 до 34 (если совсем плохо выходит по качеству, то повышайте) с ограничением битрейта сверху через -b:v 1485 (вот эту цифру настраивайте по вкусу, используя видео-образец, чтобы оно не сыпалось совсем в кашу, в общем - чтобы вас устраивало).
Можете также пойти другим путем, если с первым будут какие-то проблемы:

You can also specify a minimum and maximum bitrate instead of a quality target:

ffmpeg -i input.mp4 -c:v libvpx-vp9 -minrate 500k -b:v 2000k -maxrate 2500k output.webm

[nidalee]

l4m3r, к сожалению, подсмотреть в файле, с какими параметрами энкодера он был сжат, можно не всегда. Узнать, какую стратегию использовали и вовсе невозможно (насколько мне известно).
Поэтому выдача ffmpeg по файлу вам скорее всего ничего не даст.
Максимум, вы можете узнать распределение битрейта по ключевым кадрам видео, используя, например StreamEye Studio и аналоги. Но там очень низкоуровневая информация.
Если в файл затесалась информация о параметрах энкодера, то ее можно будет увидеть в текстовой выдаче MediaInfo.
Если хотите так глубоко копаться, то милости прошу, но в целом это вряд ли вам сильно поможет.

Другой кодек использовать нельзя?

[l4m3r]

nidalee, спасибо за ответ. Буду думать
Другой кодек использовать нельзя?
Какой например? Это даст преимущества?

[nidalee]

l4m3r, если для хранения, то H.265. Если для выдачи клиентам, то VP9 универсальнее, конечно.
H.265 на более медленных пресетах сжимает лучше VP9.