| текущая версия нуль-пять
Писал так: сначала самое важное
(название кнопки), потом суперзапутанное объяснение как эта
кнопка круто нажимается, а потом немерянно тусовочная формула
чиста для прадвинутых пацанов, которые знают мудрёную науку
арифметику. Ну и под конец мои 5копеек :)
Отмазка: Сий документ предназначен
тем, кто примерно представляет, что эти опции значат, и хочет
узнать поподробнее. Новичкам будет туго :р
Итак. Чтобы не получить гавно после
кодирования, надо четко разбираться, что означают
все
опции. В нандабе все настройки по умолчанию заточены под
голивудскую жвачку, поэтому не пройдёт скачать конфиг
какого-нибудь "авторитета" и получить грамотный рип.
Настройки, которые достаточно освещаются в newbie-guide-ах, я
рассмотрю поверхностно, а остальные - поподробнее :)
Поехали.
Маленькое пояснение, почему куча
настроек контролирует битрейт и куда его потом суют.
Начать придётся издалека. Каждый кадр
может быть сжат
с различным уровнем какчества. Эти уровни называются drf (detail-remove-factor/data-reduction-factor/и много другого
:). В теории кодек может кодировать с drf 2-32
(1-сжатие без потери качества, mjpeg этого делать
не может, 32- макроблок(блок из 16х16 пикселей) практически однотонный).
Нандаб использует drf 2-16 по умолчанию, так
как Вальдо (хлопец, этот нандаб написавший) посчитал,
что для HQ(хай-какчество) сжатия этого более
чем достаточно. Также я взял короткие ролики,
в которых были как статичные, так и динамичные сцены, и
кодировал их с фиксированным drf от 2 до 16. Внизу список сумм
размеров дельта-кадров для каждого drf, и на сколько процент
сильнее сжалось.
Внимание!!! Данная таблица точна
только для конкретного ролика, но приблизительно годится для
всех аниме. Полученные результаты, мягко говоря, усредненны и
ни в коем случае не могут использоваться для расчёта точного
размера отдельных кадров при заданном drf. Но обычно, чем
больше движения в кадре, тем хуже он сжимается на drf>10.
Дополнение: в последнем столбце я написал результаты похожих
издевательств над очень динамичным кусочком Акиры (720х, полёт
по коридорам.). Кусочки эти я могу выложить на инет (заодно
желающие смогут посмотреть, насколько хуже станет динамика при
повышении drf.)
Статичный кусочек.(512х)
Динамичный HQ кусок. (720х)
drf02 1009k 100% 10125к
drf03 0789k 79\75 7354
drf04 0625k 62\55 5591
drf05 0540k 54\46 4644
drf06 0464k 46\38 3862
drf07 0418k 41\33 3354
drf08 0372k 37\29 2928
drf09 0338k 34\xx ----
drf10 0310k 31\xx ----
drf11 0290k 29\xx ----
drf12 0276k 27\19 1970
drf13 0264k 26\xx ----
drf14 0251k 25\xx ----
drf15 0241k 24\xx ----
drf16 0236k 23\15 1509
Визуально - 3-4 - разница заметна
на статичной картинке только при увеличении, 5-7 - разница
малозаметна на статичной картинке и незаметна на динамичной,
если не присматриваться, 8-12 - заметны макроблоки, но
терпимо. 13-16 - полный отстой.
Выше видно, что для кодирования
статики уровни drf выше 5 просто бессмысленны - слишком мала
отдача и велика потеря качества. Но если вы хотите получить
красивый мувик, то вам придётся ограничить drf 6-ю, а то и 8-ю
для динамичных сцен. Какой max drf выбрать - исходите из своих
запросов и того, насколько сильно надо сжать конечный файл.
Итак, в конечном итоге нандаб
скармливает кодеку для каждого кадра два значения, drf и
crispness. Кодек сначала замыливает кадр, опираясь на
crispness, и сжимает его до конкретного drf. Так как два
разных кадра при одном и том же увеличении drf могут сжаться с
разной силой, nandub сначала определяет, сколько битов он
потратит на этот кадр, а потом угадывает, какой он ему
назначит drf так, чтобы и биты как можно точнее потратить, и
размер кадра не превысить. Вальдо божится, что этот алгоритм
работает идеально, и судя по всему так оно и есть. То, сколько
битов будет выделяться на кадр, выставляется в следующих
местах(пока я их просто перечислю): crosspoint,bitrate,minimum
allowed bitrate,motion based curve modulation,curve
modulation(3 settings),luminance correction
(2settings),filters(2 settings),bitrate redistribution(2
options),smoother,gauge(5settings,2 options),ecf file. Много,
не правда ли? Но Вальдо говорит, что вся эта лабуда
необходима. Решать вам. Настройки по умолчанию заточены под
голливудские фильмы, т.е. оставив всё как есть, ты получишь
гарантированно средненький результат.
Что такое Ключевой Кадр (Keyframe,
kf), и нахрена он тут нужон.
Вообще-то для
работы мувика нужен минимум 1 (один) kf. Kf, в отличие от df
(Delta frame, Промужуточный кадр, содержит только отличия от
предыдущего кадра. kf содержит всю картинку) вообще-то для
нормального проигрывания мувика не-ну-жен. Тогда зачем мы
мучаемся с этой байдой? Во первых, при скроллинге плейер
мувика считывает кадр, с которого он начнёт играть мувик,
потом перематывает на последний kf перед этим местом, после
чего распаковывает все кадры до нужного. Отсюда чем реже
встречаются kf, тем тормознее скроллинг. Также некоторые серии
кадров с перевёрнутыми макроблоками (inverted macroblocks-
мелкие квадратики, появляются и исчезают на пару секунд)
лечатся, когда в середину этой серии ставится kf. Также, если
несколько макроблоков в кадре будут битые (но заголовок кадра
сохранится), на kf мувик самовосстановит изображение. Вот
почему kf нужны посередине мувика. На смене сцены их ставят
потому, что тогда незаметно лёгкое подёргивание картинки,
которое всегда происходит на kf. Кроме того, редактировать
divx-овую авишку без перекодирования (только меняя заголовки
кадров) можно только от kf до kf. Обычно издеваются над
конкретной сценой. Также при смене сцены размер df сравним с
размером kf. Отсюда: kf должно быть как можно меньше, но не в
ущерб скроллингу, и желательно они должны быть на смене сцены.
Лишние kf уменьшают качество мувика - проверенно.
Options-prefences-Scene
Вопреки распространённому мнению,
оба алгоритма хороши. Встроенный(который сверху) ловит
различия motion между кадрами. Альтернативный просто смотрит
разницы значения luminance. По уму надо бы их пользовать
вместе, но тогда nandub начинает срать kf-ами. По моде будем
использовать нижний. Multiplier для аниме надо выставлять
выше, чем для фильмов. Так как кодек и так засовывает kf
каждые n секунд и туда, где он не может без них обойтись,
можно смело ставить цацку на 70-90. Поставишь выше - возможны
глюки.
Как работает: пусть разница люмы
для предыдущего и текущего кадров соответственно называются
last_diff и curr_diff. Алгоритм тогда выглядит так:
if( curr_diff > last_diff ) -> encode as kf
last_diff = curr_diff * multiplier / 10 ;
if ( 10000
> last_diff ) last_diff = 10000
Отсюда: После постепенного
затемнения картинки резкая смена сцены может быть не
обнаружена.
Options-prefences-SBC-crosspoint
Фишка для расчёта curve
compression. Перед вторым проходом пишешь значение, какое тебе
нравится а потом тыркаешь в кнопЭчку
calculate-curve-compression. Эта опция оперирует значением
BR(bits reservoir), и немного тормознута. Чем больше это
значение, тем меньше битов будет выделяться большим кадрам, и
больше - маленьким. Также все кадры с битрейтом меньше n будут
кодированны с drf=2. По мнению "распальцованных", оптимальное
значение будет bitrate*factor, где фактор - значение
максимальной компрессии, то есть для максимального drf=5 это
будет 0.5, а например для max drf=12 - 0.25. Ниже
(pixels-per-frame)/1000 опускаться не рекоммендуется. На самом
деле, значение это весьма и весьма дискретное и его изменения
на 10-20 ничего не меняют.
Картинка показывает эту байду в 2D
:). Вальдо схалтурил, когда её рисовал 100%.
Эта фишка сама на размер мувика
влиять на должна, но она, сука, почему-то влияет, если
выставить её слишком большой или маленькой.
Дополнение: эта зараза не просто меняет
цифирку в окошке, она меняет bitrate curve соответственно картинке
Video-SBC Options-SBC
Setings-DivX
Bitrate - Сколько битов кодек
выделит на секунду видеопотока. Как прикинуть битрейт читай
здесь.
Keyframe Interval - если не было
kf в течении n секунд, закодировать кадр как kf. Для удобств
навигации по файлу. Ставь 10, не ошибешься. На конечный размер
файла влияет исчезающе слабо, пока значение достаточно
высокое.
Minimum allowed bitrate - После
того, как нандаб полностью просчитал битрейт для текущеко
кадра, он сверяет его с minimum allowed bitrate, и если тот
меньше n, то ставит битрейт для текущего кадра=n. Если ставить
меньше 270 (для 512х384), могут появиться фризы. Происходит
это потому, что divx3.11a плохо работает с сильно сжатыми
маленькими кадрами. Все кадры, размером меньше minimum allowed
bitrate получат столько битов, сколько они потребовали при
первом проходе.
Internal SCD - Встроенный в
Виртуалдаб Детектор Смены Сцены (далее iSCD) оперирует
значением motion для текущего кадра. Если current
motion>300*n/100, то кодек ставит kf. Этот алгоритм позорно
тупой, и в сценах с очень высокой динамикой срёт kf-ами. Так
как у нандаба максимальное значение motion для кадра - 299, то
выставляя эту фишку на 100%, вы этот бред вырубаете.
SpaceKFs - пока не прошло n
кадров, kf не ставить. Если оставить на 24-х, то в сценах,
когда по экрану кто-то шустро скачет или туда-сюда всякая
хрень болтается, _иногда могут_ появиться макроблоки(это глюк
divx311a). Сейас модно ставить от 14 до 18. Но если врублен
antishit/antifreeze, то можно смело ставить 2-3 секунды,
меньше kf - лучше мувик. Храбрые ставят 72 и без antishit, им
не страшно =)
ANTISHIT (Антисрач :)
Очень полезная вещь для создания
"домашних" рипов. Распаковывает каждый полученный кадр, и
прикидывает, насколько он отличается от исходного. _Редко_
срётся. Слабо чуствителен к картинке с маленькой люмой.
Оперирует drf, игнорируя bitrate curve. Если после сравнения
разница больше n (это обратная зависимотсь от того, что ты
напишешь в окошке, то есть чем выше полученное значение в dB,
тем выше какчество кадра, например), то кадр перекодируется с
более низким drf, и сравнивается опять. Если дошел до 2х и
облажался - ставит kf. Также если с самого начала фигня
выходит, сразу кодит как кейфрейм.
Сейчас вот прочитал, что написал
:) Невнятно немного. Ниже "народная" табличка
dB - это такие попугаи, которыми
nandub какчество считает :) Какчество у нас, оказывается,
бывает от 0 до 96dB. Вах вах. Разведка докладывает:
0
- мусор на входе, мусор на выходе.
1-5 - дрянь картинка,
ничего не разглядеть.
6-20- примерно как 16-8 drf.
21-30- разница малозаметна
35-50- разница незаметна
выше начинаются штормы kf, т.е. алгоритм парится.
В Antishit 3 значения.
Antishit =) - если dB меньше n,
сразу кодировать как kf. Если поставить много, то появятся
ненужные kf.
Min quality - основное значение.
выше 35 лучше не подниматься.
Motion modulation - при наличие
движения в кадре снижать чуствительность алгоритма. (50% - в
два раза например при motion=299)
Antifreeze - редко, но бывает так,
что при чиста пацанских настройках у кодека едет крыша, и он
рожает битый файл =) Antifreeze этому препятствует. Full
Antishit включает в себя и эту фишку тоже. Эта фишка в нандабе
реализована так, что когда она видит, что говно дело, то кодит
кадр как ключевой. Если такое безобразие не катит, то пробуй
полный antishit с as:16,mq:1.
Зашибись
вещь, да? Мааленький минус - при полном antishit скорость
кодирования падает в 4-5 раз. Но это простой способ быть
уверенным, что твой рип будет с красивой картинкой. И ещё -
размер файла при увеличении min quality растет оочень быстро.
Не рекомендую antishit для релиз-рипов, но если ничто не помогает, то вперёд.
Video-SBC Options-SBC
Setings-Bitrate Curve
Collect in - Тут указываем
директорию, куда будут новые .stats файлы складываться, C:\My
Documents\ по умолчанию.
Optional data-scene changes - надо
ли в .stats файл засовывать результаты SCD. Подтормаживает
незначительно, но позволяет использовать пару толковых фишек,
поэтому включать обязательно. Одна из них - "вумное
распределение kf". Например, если kf распределены так: 0
---------- 10 ---------- 20 - 21, где 0 и 21 - смены сцены а
10 и 20 -kf вставленные кодеком, то они будут перераспределены
так: 0 ------- 7 ------- 14 ------- 21, что есть немного
толковее.
Encode using - .stats файл с
первого прохода.
Motion based curve modulation -
Уменьшает кол-во битов, выделяемые на кадры с наличием "motion
blocks". 100% - уменьшает кол-во битов наполовину 50% - на
четверть. Аккуратнее с большими значениями этой переменной,
если antishit вырублен и drf ограничен снизу то битов на кадры
будет не хватать, и кодек их будет стараться кидать :)
Curve compression - nandub читает
стат-файл, и из значений каждого кадра строит эту двухмерную
кривую. Поверх неё рисуется прямая битрейта. Компрессия прямой
выпрямляет её, и при 100% кривая совпадает с прямой :) Это
симметричная. Ассиметричная принимает во значение только
величины, большие или меньшие битрейта, соответственно high и
low. Например если кадр в первом проходе занимает 6400 байт
(для второго прохода), а битрейт - 1000 кбит (5333 байта на
кадр) и симметричная компрессия 50%, то для кадра будет
выделено (6400-5333)*0.5+5333=5866байт. Значение надо
подбирать исходя из того, каким местам надо ыделить больше
битов. Общая тенденция такая, что чем меньше значение
компрессии, тем ближе будут drf кадров к среднему drf.
Уменьшение компрессии позволяет сократить число перепадов drf,
бо из-за них картинка мелко и неприятно дрожит(иногда) :(
Особенно сильно этот эффект знаком любителям кодить с minQual.
Luma correction - встречаются в
фильмах кадры, где есть большие участки однотонной
поверхности, иногда с постепенным изменением яркости
(маленькая контрастность то бишь). На таких кадрах пикселяция
(Задолбало меня это слово писать, далее это будет гордо
именоваться "макроблоки". Что это означает, см. сноску
где-нибудь внизу.) особенно заметна (Не "сильнее", а
"заметна". Заметили разницу?). Для того, чтобы никакая гадина
не могла к этому кадру придраться, существует фишка "Luma
correction". По идее, алгоритм находит кадры с такими
участками и даёт им больше битов, отчего они становятся
(теоритически) белыми и пушистыми. На практике же получается
полная дрянь. _В nandub-е алгоритм luma correction запорот_.
Ну не совсем запорот, но обсчитывает не то :) В фильмах это
ещё кое как работает, но аниме не корректируется. В последнее
время это до кого-то дошло, и был даже разработан патч. Как
только Waldo очнётся от спячки, в нандабе это будет пофиксено.
Пока что коррекцию отрубаем. Запоротые кадры приходится потом
выставлять вручную. Antishit этот эффект в какоё-то степени
нивелирует. Но кратко я по опциям пройдусь.
Threshhold - здесть вводим цифирь,
(Как она считается, я не имею никакого понятия. Возьмите
анализатор и прикиньте, какие кадры сколько очков получают :)
когда кадр оценён ниже этой цифры, то он начинает получать
дополнительные биты.
Gain(max) - сколько дополнительных
битов получает кадр при минимальной "цифири". Тут простой
пример - Threshhold=5, Gain=50%, кадр с люмой 2.500 получит
n*1.25 битов, а кадр с 0.05 - n*1.49. 5 и выше не меняются.
End credits. Опции понятны, я
думаю :) Битрейт можно смело опускать до 350-ти, никто никого
ещё не упрекал за слишком сильно сжатые титры :) Когда кодек
доходит до кадра, который ты впишешь в окошке, он переключится
на другой конфиг, с именем default.end.credits.vcf. Этот
конфиг достаточно подобрать раз и навсегда.
Filters-high pass - Делает то же,
что и minimum allowed bitrate, но во время искажения bitrate
curve(т.е. позже). Перебивается им же. При выставленном
min.allowed.bitrate начинает гадить. Чтобы этого не было,
ставь равным нулю.
Filters-low pass - Все кадры, с
битрейтом больше n кастрируются (т.е. им выделяется кол-во
битов, равное low pass), а лишние биты распределяются по
bitrate curve. Определяет тормознутость мувика (частично). Не
поднимай более 4500, если у тебя не p4 :). На antishit и max
drf не влияет.
Bitrates redistribution - Когда
кодек находит дополнительные биты и распределяет их по bitrate
curve, то раздача пряников происходит следуюцим образом: bias
- поровну, proportional - по-братски, то есть кто потолще,
получает побольше :) (вдвое толще - вдвое больше битов).
Smoother -
Усредняет битрейт всех кадров, идущих подряд и различающихся
на n процентов. например 95,100,105кбит кадры станут тремя
кадрами по 100кбит, если smoother=5 или больше. Убейте меня,
но нахрена это надо, ума не приложу.
Video-SBC Options-SBC
Setings-Motion
Motion curve parameters-span -
сколько кадров надо анализировать(перед и после текущего
кадра), чтобы посчитать движение. Никто нигде эту восьмёрку не
трогает :) А вот почему. Дело в том, что восьмёрка очень дюбит
назначать под шумок большой motion статичным кадрам рядом с
динамичными сценами. span оценяет кадры до и после
неодинаково. Для троечки это будет 1,2,3,7,6,5,4. Для 8 -
1,1,2,2,3,4,5,6,7,6,5,4,4,3,3,2,1(это непроверенная
информация) .Значение усредняется. Для более резких скачков
motion можно опустить span на 2-3 нупкта. Ведь в аниме намного
чаще происходят резкие изменения в течении 2-5 кадров, чем в
фильмах. Кроме того, span=5 перестаёт ловить движение при
медленном панорамировании, что тоже имеет свои плюсы, картинка
сдвигается мягче.
Sensitivity - чем выше это
значение, тем сильнее должно быть отличия от предыдущего в
текущем кадре, чтобы motion стало максимальным, т.е. 299.
Кодек сравнивает некие "keyblocks" в обоих кадрах, и в
зависимости от них награждает motion-ом текущий фрейм. Сенс
может быть от 1 до 11 (а не 10, как написано в Nandub Options
Explained), соответственно при сенсе 10 и 5 изменившихся
keyblocks в кадре, motion = 150. На практике эта опция
позволяет профилировать bitrate curve на пару с motion based
curve modulation.
Motion based DLL switch - уже не
используется. Оба на 300.
Motion based crispness modulation
- немного замыливает кадр, если у последнего ненулевой motion.
Замыливание происходит силами самого кодека, кто хоть раз
кодировал старым divx3.xx кодеком, то видел эту фишку, там это
обзывалось crispness. Crispness33 примерно равен blur фильтру
по эффекту. По умолчанию нандаб все кадры кодит с
Crispness=100, и при наличии motion снижает этот Crispness, до
100-n при motion=299. Если у тебя сенс 8-10, то при max
drf=5-7 и crispness modulation=50 визуальных отличий в
динамике не будет, а процент-другой ты выгадаешь. Если ты
используешь высокий max drf, то ставь 20-30. В аниме
замыливание сильно заметно. Эта фишка мылит картинку очень
слабо(а может, просто не работает у меня), не то что wma кодек
:(.
Enable Bits
Reservoir modulation - при значениях BR_state, близких к
gauge_min, нандаб будет понижать crspness. Насколько сильно -
неясно. Смысла использовать - никакого.
Video-SBC Options-SBC
Setings-Gauge
В этом разделе находятся
настройки, ответственные за раздачу пряников, то есть разного
кол-ва битов разным кадрам. Тут необходимо небольшое
пояснение. [cut] То, что я тут накатал, я перенёс в начало
этой страницы, т.к. иначе будут возникать дурные вопросы.
Gauge - самый запутанный алгоритм в нандабе, но понимание, как
он работает, необходимо для профилирования bitrate curve
Как работает Gauge. Для начала нам
потребуется такое понятие как deviation (отклонение от
заданного битрейта, т.е. профицит/дефицит битов при
положительном / отрицательном значении). Как его считает
нандаб: deviation = deviation + bitrate/fps - actualFrameSize.
При кодировании можно это значение видеть в окошке. BR (bits
reservoir, резервуар битов), равен Bitrate*5, то есть кол-ву
битов на 5 секундах мувика. Для контроля deviation существует
параметр payback, влияющий на текущее значение BR.
Global deviation
compensation-payback delay - Далее pbdelay. pbdelay - Это на
сколько кадров расчитывать компенсацию текущего отклонения от
заданного битрейта. Равно например для 24фпс payback delay*24.
Как это обссчитывается: BR_state(текущий
статус)=br_state+(deviation / pbdelay). Например при дефиците
в мегабайт, 24фпс, pbdelay=45 и BR_state=5000к, Резервуар
будет равен 5000*1024+(-1048576/45*24)=4998кбит. Для людей, у
которых туго с арифметикой: эта фишка не может вам устроить
5секунд с максимальным какчеством и 40 с говённым. Нафиг этот
резервуар нужен, написано ниже.
Corrections on lower bitrate
conditions-enabled - Если текущий кадр попадает под minimum
allowed bitrate, то значение BR_state при кодировании этого
кадра не меняется. Modulated - Лишние биты, которых этому
кадру при drf=2 не хватило до minimum allowed bitrate,
добавляются в резервуар. Помечайте обе фишки, они толковые.
Gauge_min - если после кодирования
текущего кадра значение BR_state упало ниже gauge_min, то для
след. кадра BR_state=gauge_min. То есть ниже этого значения
BR_state не опустится.
Gauge_start - в начале кодирования
BR_state выставляется равен gauge_start.
Gauge_max - Если после кодирования
текущего кадра значение BR_state превысило gauge_max, то для
след. кадра BR_state=gauge_max.
Если всё ещё неясно, попробуйте
представить BR_state как gauge_level. :)
Hacks-KF boost - если текущий кадр
есть kf, то добавить n процентов к BR_state. (Сам kf на
BR_state никак не влияет). 0-5, не больше не меньше.
Freeze - зафиксировать BR_state на
n процентах от максимума в течение всего мувика. Для
тестирования only.
А теперь, для чего нужен BR_state
:) Дело в том, что drf напрямую зависит от процентного уровня
BR_state. Соотношения такие:
BRstate (gauge) = 60%
-> frame compressed with cl = 2
BR = 30% -> cl = 3x
BR = 20% -> cl = 5x
BR = 10% -> cl = 10x
BR
= 5% -> cl = 14x
BR = 2% -> drop frame (!)
Так
чтоеслиBR_state=1500kbit(min_gauge= 30%),
фпс=24и bitrate= 1000, то
если будет сжиматься кадр размером 8килобайт, то он будет
выкинут, если 6кб, то с drf=14, если не ограничить drf.
Поэтому не оставляйте настройки gauge по умолчанию, ничего
хорошего из этого не выйдет. (правда это был худший случай).
Более оптимистично: пусть deviation неотрицательна и
BR_state=50%, фпс24, битрейт 700 а размер кадра (открываю
эпизод 512х и смотрю среднее значение дельты) - 2600байт.
BR_state=35% и drf=2.
Дополнение.
Вальдо писал, что значение 35% для min_gauge является
пороговым, и если оно меньше, то нандаб будет очень легко
повышать drf. Вот один метод, как можно примерно прикинуть
значение min_gauge: допустим, что ты хочешь, чтобы в среднем
drf в твоём мувике болтался около значения 2-4, и был выше
лишь в "тяжёлых" случаях. Тогда ты считаешь средний размер
кадра из первого прохода, прикидываешь, насколько в среднем он
сжимается при drf4, и думаешь примерно так: кадры пойдут в
среднем по 12000байт, drf4 это 60%, то есть 7500, при BR_state
на минимуме кадры должны компрессится в среднем на drf4 и
BR_state должен немного расти. Точная прикидка этого момента
приблизительно будет выглядеть так: [cut] (Слишком большой
разброс результатов, и на практике не получается удерживать
drf в заданном диапазоне. Формула получается слишком
громоздкой, и мне просто не хватает терпения и грамотности её
вывести. Если кто мне в этом деле может помочь, напишите). По
моему опыту: min_gauge лучше всего работает от 35до 40
прицентов, при этом на 35% средний дрф на участках с малыми
перепадами битрейта стремится к 3-4, а при 40% - к
2.7-3.3(точное значение зависит от того, насколько избыточен
битрейт) Тут надо смотреть на first/second pass ratio, если он
55-60, то надо ставить 35-36, если 65-70, то 38-40. Значение
gauge_start может быть любым, от min_gauge до max_gauge, и
зависит от того, насколько динамичное начало у мувика, если
там идут статичные картинки с надписями, то можно ставить
gauge_start =min_gauge, если наоборот - gauge_start
=max_gauge. Соответственно пойдёт любое значение между этими
двумя. Gauge_max в общем есть величина, показывающая,
насколько сильно может меняться drf для мест, при подходе к
которым у кодека скапливается достаточно много битов. Разница
между min и max не должна быть более 40%, и менее 20, это
просто сделает неэффективным работу
резервуара битов.
Video-SBC Options-SBC
Setings-Compression levels
DRF min/max - Граничные drf,
которые нандаб будет использовать для дельта-кадров. На
bitrate curve не влияют. Это значение проверяется перед самым
сжатием, и кодек не вылезет за эти границы при кодировании
дельты ни при каких обстоятельствах (кроме ECF). В моих
"советах" будут использоваться drf= от 2 до 5/7.
use min/max - в этих полях можно
выставить motion-based-drf. Все пять строк связаны между собой
и вырублены по умолчанию (min n max m w/motion-over 300). Если
вы хотите, чтобы например при motion=200 и более кадр был сжат
с drf=4-7, то пишете "min 4 max 5 w/motion-over 200". Кодек
обрабатывает эти поля по очереди, начиная с нижнего и идя
вверх. Пример: 2x 5x 100 (slower motion)
3x 6x 150
4x 7x 200
6x 16x 270 (faster motion)
Пример. Кадр имеет motion 180 и
нандаб хочет сжать его с drf=10. Он начнёт снизу, пропустит
две нижние строки и сожмёт кадр с drf=6. Без надобности
motion-based-drf не используйте, потому как можете очень легко
облажаться.
Keyframes quality
min, соответственно граничные
значения drf для kf. По умолчанию стоит 2/31, то есть всё
оставленно на выбор кодека. Так как следующий за kf
дельта-кадр будет зависеть от drf kf-а, (чем меньше
различаются их drf, тем меньший размер будет иметь df, меньше
загрузка проца, меньше дёрганья картинки) по уму надо бы
ставить это значение равным min-delta-drf.
max - Это значение ограничивает
drf kf-a сверху. Работает только если больше максимального
значения drf для дельты. Можно не трогать, хуже от этого не
станет, а kf ниже дельты и так почти никогда не опускаются.
Для функционирования требует включенной Optional data-scene
changes.
Video-SBC Options-SBC Setings-ECF
Filename-ECF - это у нас
encoding-control-file. В этом файле можно покадрово говорить
кодеку, что делать, и он будет делать именно это. В файле
example.ecf всё расписано, и я ничего нового не добавлю.
Единственное, если вы например кодите кусочек с 1000 по 2000
кадр, то кадры в ecf тоже надо указывать как 1000-2000, а не
0-1000.
Материалы брались: readme.doc,
идущий в поставке с нандабом, Maras nandub giude ака Nandub
Options Explained, и полностью перерытый архив форума на
www.doom9.net, где тусуется Вальдо. Кое что я выяснял сам (в
основном там, где отписано "для аниме").
|
