Кто-нибудь имеет скрипт для наиболее эффективного сжатия видеоматериалов?

Я использую https://avidemux.sourceforge.net/ потому что голый ffmpeg я не осиливаю, а тут кнопочки, галочки и менюшки. 99% задач по работе с видео у меня «соединить вместе кусочки и\или перетоптать», а он ЕМНИП только это и обучен делать.

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

А там есть множественное конвертирование? Мне нужно файлов более 100 конвертировать.

Я тоже как проф. ламер думаю, что можно повысить качество с помощью нейросетки если очень нужно.

Для бытовых и архивных нужд я кодирую в h264 и играюсь в основном с 4 настройками, это ШиринаВысота, БитрейтВидео, БитрейтЗвука, ФреймРейт. Выставляю их по чуйке и здравому смыслу, если например это скринкаст про то как программировать на Расте и там просто спикер стоит и на доске слайды переключает раз в минуту, то тут очевидно много фреймрейта для видео выставлять не нужно, хватит и 8-12 если не меньше. Ну и в таком духе прикидываю параметры.

handbrake

пару дней назад в дрезденском банхофе видел на огромном мониторе рекламу handbrake. Не врубился почему и зачем, но факт )

Если вопрос в эффективности, то:

-c:v libx264 -crf 30 -maxrate 100k

equals

-c:v libx265 -crf 30 -maxrate 50k

Короче, hevc заюзай.

Добавляешь -preset veryslow и сжатие становится эффективным. Но медленным.

https://trac.ffmpeg.org/wiki/Encode/H.264#Preset

-crf и подобное это не «эффективность» сжатия а настройка компромисса между потерей качества и большим размером выходного файла.

Хочешь сказать что x265 жмёт детализированные сцены при равном качестве и дефолтных настройках до вдвое меньшего объёма в байтах?

Цель не обозначена. Я на пожатии видео поел немало собак уже. И доволен результатами. Но важен контекст задач.

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

Ну нет. У тебя что, мобила в прорезе снимает что ли? (у меня такая есть). Там в 10 раз поверю еще. Обычно мобилки и так все сильно жмут. Ты даже в 2 раза сжав уже пошакалишь.

Битрейт штука такая… не бывает универсального. Ты же понимаешь, что сцены «кафельный морг ничего не двигается» и «лес птички ветер деревья» - требуют ну очень разного битрейта для одинакового визуального качества? Ясен намек?

Ну к твоей задаче ближе всего -crf (выше уже советовали https://trac.ffmpeg.org/wiki/Encode/H.264, там есть)

Он типа визуальное качество сечет. Под него подбирая битрейт. Но могут быть просто адовые пики по битрейту, даже не всегда по факту оправданные. Поэтому надо еще -b:v -maxrate -bufsize добавлять. А тут… ну блин, или под заданную ширину (канала), либо на глаз.

Мучения все это, если нужна и хорошая картинка и размер поменьше.

Дальше вопрос - тебе тупо архивирование как видеофиксация факта «тут на пятой секунде выбежала собака» или хорошая картинка?

Не проще купить винт еще на пару тб?)

264 самый совместимый, 265й жмет получше, vp9 еще лучше, av1 еще лучше (но ничем толком не поддерживается еще). За все платишь процессором. Каждый следующий кодек еще медленнее.

Ах да, аппаратное сжатие на видеокарте - говно. Оно только для стримов и т.п. И оно в crf не умеет.

рекламу handbrake

Я не врубился, этого самого конвертера handbrake?

Да, у меня для сжатия не фильмы на blueray, качество видео приемлемое, но размер файлов непримемлемо большой по сравнению с качеством, как будто в 4к снято, ан нет всего-лишь 720p. Поэтому решил убрать лишние данные посредством конвертации. Спасибо, но пресет -veryslow делает файл больше чем crf 30 а разницы по качеству не заметно.

Я знаю что 265 жмёт лучше, но не в 2 раза же. А то там выше предложили «эквивалент» в виде вдвое меньшего битрейта чем у 264.

Да по битрейту я понимаю, что чем больше битрейт тем больше информации можно добавить в кадр. Собственно количесто килобайт в секунду это ясно.

Хах, и да мне чисто для архива. Картинка нужна смотрибельная (можно сказать на грани появления квадратиков, но без них).

У онлайн сервисов почему-то даже лучше получается сжимать. Вот я и подумал, может есть какой секрет, который мне неведом.

Только в Линукс зачем-то пытаются использовать mencoder или ffmpeg. Для кодирования на трекерах используют чистый x264 через какой-нибудь MeGui например или просто бинарник из командной строки. В Винде пираты получается более следуют юниксвею чем

Ну как ты читаешь? Повторю ещё раз другими словами.

При сжатии у тебя есть, условно, три интересные метрики: качество получившегося видео, размер его в байтах и количество потраченных на сжатие проовых мощностей (времени).

preset - это компромисс между последним (расходы проца) и двумя остальными. crf и прочие битрейты - это компромисс между первыми двумя (качество и размер).

preset и crf это разные вещи, они друг друга не заменяют, задавать надо оба. Если ты не задал preset, то выбирается дефолтный средний.

veryslow пресет позволяет в то же количество байтов запихнуть лучшее качество, либо наоборот оставить такое же качество но уменьшить размер файла (всё это по сравнению с другими пресетами).

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

50% в лучшем случае.

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

Да, спасибо, я действительно не правильно понял в тот раз эту мысль с preset

Нет. Не зная входящие данные и то, что вы хотите получить на выходе наванговать не возможно.

Получил ответ, что нет универсального скрипта. Нейронка исправит ситуацию. Пока буду делать как получается. Остаётся эксперементировать.

Вот пример одного из файлов. 184 МБ, длительность 1:49, размер 1280x720, кодек h264, битрейт 14145 kb/s

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'VID_20230402_103130.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    creation_time   : 2023-04-02T07:33:21.000000Z
    com.android.version: 10
  Duration: 00:01:49.50, start: 0.000000, bitrate: 14145 kb/s
  Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, smpte170m), 1280x720, 14020 kb/s, SAR 1:1 DAR 16:9, 29.98 fps, 30 tbr, 90k tbn, 180k tbc (default)
    Metadata:
      creation_time   : 2023-04-02T07:33:21.000000Z
      handler_name    : VideoHandle
      vendor_id       : [0][0][0][0]
  Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 96 kb/s (default)
    Metadata:
      creation_time   : 2023-04-02T07:33:21.000000Z
      handler_name    : SoundHandle
      vendor_id       : [0][0][0][0]
At least one output file must be specified

Конвертер заранее не может предсказать, какой у него получится битрейт. Выбирается по факту не битрейт, а куча всяких разных тонких настроек сжатия. Поскольку большинство обычных видео весьма предсказуемые в плане сжимаемости, конвертер видит что у него получалось в уже сжатом куске видео, и использует это для предсказания битрейта в будущем (и подгонки параметров сжатия очередного кадра под нужный битрейт). Но всё-таки в видео бывают неожиданности - когда плавная сцена резко сменяется на динамичную, например. Конвертер уже настроился на сжатие плавных сцен, и неожиданно возникшая динамичная (по крайней мере, её начало) будет сжата с не тем битрейтом/качеством как ты хотел. Двупроходное конвертирование нужно чтобы исключить такие ситуации: сначала собирается реальная статистика по всему видео, и потому уже, всё зная. каждому кадру выбираются настройки сжатия, нужные именно для него, а не для тех что были перед ним. Полезный результат: более однородный расход битрейта на разные куски видео, без ситуаций когда одна неожиданная сцена сожрала кучу байт и не оставила ничего следующей после неё.

Проявляется на практике всё это редко, но бывает. Нужно это тебе или нет, решай сам.

Да, есть

Есть:

1) Поставь preset в соответствии с желаемыми затратами процессора: чем медленнее, тем лучше, но вдруг ты торопишься и не хочешь слишком долгую конвертацию, или у тебя там много терабайт роликов, и ты предпочитаешь конвертировать их всего один год, а не два. На моём опыте -preset slower может дать всё ещё заметную пользу по сравнению с -preset slow (особенно в условиях ограниченного битрейта), а вот -preset veryslow уже начинает походит на прожигание проца впустую, но если ты не торопишься, то лучше veryslow.

2) Выбери несколько роликов (или отрывков хотя бы по 5 минут), на которых будешь тестировать пережатие: с динамичными сценами и с медленными, с большой детализацией и без мелких деталей.

3) Сконвертируй ролики с выбранным пресетом и -crf 17, 23, и 28, сравни что получилось. Если они все выглядят одинаково, то либо оставь 28, либо повтори сравнение с 28, 32, 36, итд. Делать меньше 17, пишут, смысла нет, но вообще можешь попробовать.

В итоге найдёшь crf такой, что дальнейшее его уменьшение бесполезно, а увеличение приводит к нежелательной потере качества.

4) Необязательно, но можно настроить maxrate. Он, по идее, должен выбираться в зависимости от разрешения конвертируемого видео. Для этого поконвертируй с выбранными -preset -crf несколько разных роликов этого разрешения (можно взять уже сконвертированные на прошлом этапе), посмотри как среди них максимальный битрейт, умножь его на 2-3 и пропиши в -maxrate и в -bufsize. Для других разрешений бери пропорционально количеству пикселей. Допустим, для 1920х1080 у тебя самое жирное видео получилось с битрейтом 10k, значит берёшь 20k или 30k и пишешь, например -maxrate 30k -bufsize 30k для 1920х1080. Для 1280x720 ставишь 30k/(1920*1080)*(1280*720) примерно 15k и так далее.

5) Команда готова, вид примерно такой

ffmpeg -i source.mp4 -c:v libx264 -c:a copy -preset название -crf число [-maxrate число -bufsize число] -f mp4 output.mp4

4) Команда готова

Не проще купить винт еще на пару тб?)

Вот уж точно!

for f in /ПУТЬ_ДО_ПАПКИ_С_ВИДЕО/*.mkv ; do
ffmpeg -i "${f}" scale="'w=if(gt(a,16/9),3840,-2):h=if(gt(a,16/9),-2,2160)'" -r 25 -crf 25.0 -vcodec libx264 -preset slower -bufsize 8M -acodec aac -strict -2 -ac 6 -ar 48000 -ab 128K -coder 1 -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -me_method hex -subq 6 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -b_strategy 1 -threads 0 -pass 1 -y "${f}_.mp4"
rm -if ${f}
done

4K: scale=«'w=if(gt(a,16/9),3840,-2):h=if(gt(a,16/9),-2,2160)'» - указывает на то, что видео будет масштабироваться, чтобы картинка и лица не растягивались.
-preset - ultrafast,superfast,veryfast,faster,fast,medium,slow,slower,veryslow,placebo
Перед -bufsize 8M можно добавить -b 9M -minrate 9M -maxrate 9M
rm -if ${f} - удалить исходник

Спасибо! Классный скрипт!!!

Пожалуйста)

Чтобы скрипт работал в фоне (можно выйти из терминала)

nohub ./convert.sh &