CRF(pass) [k0stix, @lolkin@, komisar666]
Constant Rate Factor есть модель, ориентированная в отличие от битрейта не на биты и байты, а на оптимизированные исходя из психовизуальных выкладок потери lossy кодирования, чем ниже, тем. меньше потери. Пропорциональная зависимость CRF от битрейта лишь следствие этого.
Есть общая тенденция, при подборе битрейта как правило близким к оптимальному будет битрейт при том значении CRF, при котором кванты I фреймов не упадут ниже 16-17 (более низкие значения обычно сигналят об откровенном перерасходе), а B-фреймов не подскочат выше 25-25.5 (более высокие значения как правило вызывают явно различимые артефакты). Всё что находится в промежутке между этими значениями - надо сравнивать глазами, чтобы оценить возможность/необходимость поднять кванты повыше/пониже. В большинстве случаев комбинация близкая к qi18-qp20-qb23 даст результат, максимально приближенный к оптимальному.
Если нужно выжать из объёма максимум, попав при этом в точный размер, не выходя за пределы левелов аппаратной поддержки, не жалея времени, то целесообразно делать мультипроходный CRF
Первый проход: --crf ??.? --pass 1 --stats "stats.txt"
Второй проход: --bitrate < битрейт, полученный на первом проходе, скорректированный под целевой > --pass 3 --stats "stats.txt" --vbv-...
Если аппаратная совместимость не актуальна (для SD разрешения она в том числе неактуальна), то тратить время на мультипроход из соображений часы/"выигрыш в качестве" не вполне целесообразно.
Если судить по квантам, уже 2-проходный на основе crf выигрывает в сравнении с однопроходным, даже без mbtree. Точно так же и на глаз.
crf никак не привязан к какому-то определенному битрейту, он дает битрейта ровно столько, сколько надо на данный отрезок видео. Т.е. надо, чтоб битрейт подскочил на 420 кбпс и сохранялся таким в течение 5 минут, crf столько и выделит. С кодированием в битрейт все вертится вокруг заданного битрейта, грубо говоря, на графике это выглядело б как кривая, постоянно ходящая вокруг оси координат (заданного битрейта), постоянно пытаясь вернуться к заданному значению. Помимо того, это и разные алгоритмы сжатия. crf, опять-таки, как я понял, больше внимания уделяет не слишком динамичным сценам, т.е. там, где действительно можно глазом уловить разницу во время просмотра. На ядреной такой динамике может что и пропустить.
При одинаковом битрейте 2-ой проход на основе статистики с crf дает ощутимое преимущество в сравнении с просто crf-ом, как по попугайчикам, так и визуально
1. Для quality-based кодирования вполне достаточно 1-Pass CRF. Нужно вписаться в ограничения хардварных декодеров?, CRF+VBV сейчас прекрасно работает.
2. Есть острая необходимость вписаться в конкретный битрейт/размер файла - 2-pass CRF. Причем первый с --slow-firstpass, вторым тюним если промахнулись.
Q: Есть ли ещё какие-либо критические моменты или рекомендации к CRF энкоду, в плане настроек, кроме --no-dct-decimate --no-fast-pskip --direct spatial ?
A: В остальном от мультипрохода твикинг однопроходного CRF'а не отличается, за исключением того, что при кодировании HD сигнала лучше делать тот же CRF, но в два прохода, чтобы не вылезти за пределы допустимого с точки зрения хардварных чипов VBV, особенно 1080p касается. )
Q: Если выбран crf 20, 20 это средний квант для P ?
A: Это значение RateFactor в понятии кодека, при котором получается некое "постоянное качество", но никак не квант.

--crf 21.0 --preset medium --tune film --profile high --level 3.1 --aq-strength 0.8 --deblock -2:-1 --merange 20 --b-adapt 2 --trellis 2 --no-fast-pskip --qpmin 10 --qpmax 51 --psy-rd 1:0.2 --vbv-maxrate 17500 --vbv-bufsize 14000 --subme 9 --me umh --rc-lookahead 60 --extra:

--crf 19.0 --preset medium --tune animation --profile high --level 3.1 --aq-strength 1.0 --deblock -1:-1 --merange 20 --b-adapt 2 --trellis 2 --no-fast-pskip --qpmin 10 --qpmax 51 --psy-rd 0.7:0.00 --vbv-maxrate 17500 --vbv-bufsize 14000 --subme 9 --me umh --rc-lookahead 60 --extra: