[не удалять] Как выбрать оптимальный битрейт и ключевые параметры для рипа в x264 [архив №1]

tartak писал(а):
Первое, что следует делать в подобных ситуациях - четко выяснить, с каким материалом имеешь дело.
Прежде всего, определите какое поле - первое. Это просто - AssumeTTF().SeparateFields(): если вернее поле - первое, то взад-вперед дергаться не будет.
У вас конечно TF первое. Посмотрите на последовательность кадров, один за одним, потом разделите на поля и снова посмотрите.
В телесине (все еще в 29.97 и без обратного пулдауна) вы бы увидели характерную повторяемость группами по 5 кадров (типа 3 прогрессивных кадра, 2 с гребенкой).
Вы видите группы из 5 или что-то другое (скажем, группы из 6 кадров)?
А если разделить на поля (SeparateFields()) - при обычном телесине вы бы увидели повторяемость типа аааввсссdd - группы из 10. Разве у вас такое?
Какая у вас характерная длина группы (если она вообще есть)? А то, что у вас сами поля двоятся, видите? О чем все это может говорить?
lehachuev писал(а):
Просмотрел все глаза, никакой характерной длины не уловил.
Ну, если бы это было так, ни о каком телесине вообще не было бы и речи. Но это не так.
Хорошо, сделаем так: возьмите кусок современного американского фильма на ДВД в NTSC, сделанного крупной американской компанией.
Он будет с настоящим телесином, пулдаун 3:2. Посмотрите на повторяемость типов кадров, с гребенкой и без.
Обозначим кадры с гребенкой буквой I, без - P. Вы увидите характерные группы типа P I I P P, причем этот образец будет все время повторяться.
Посмотрите потом на ваш клип, обозначая гребенку и двоение I. Будут встречаться и P.
Смотрите покадрово, записывайте буквы на бумажке, и определите, какова повторяющаяся группа.
Потом проделайте то же самое, но с разделенными полями.
И на этот раз используйте все буквы, начиная с "а" - одной буквой обозначайте поля, явно относящиеся к одному и тому же моменту во времени.
Смотрите кусок, где есть движение.
В фильме с телесином у вас получится a a a b b c c c d d - три одинаковых (почти) поля, потом два из явно следующего момента, и так далее.
А в вашем клипе?
Присмотрелся. Вроде, смотрел теперь куда надо, ваш совет очень помог, теперь хоть знаю, куда и как смотреть.)
Получилось вот что
Код:
IIIIIP
Код:
aa bb c
За первое ручаюсь, за второе не очень, есть кадры, где общее движение почти незаметно, а есть такие, где оно чуть больше, но тоже похоже все же скорее на дубль. Просмотрел несколько раз, разные эпизоды, вроде порядок во второй строке именно такой.
Да, PIIIII - это именно то, что у вас. Группа из 6 кадров. При обычном телесине группа состоит из 5 кадров, причем 5-й добавляется телесином, чтобы поднять 24 fps до 30. Как вы думаете, какой должна быть скорость исходника, чтобы при переводе в 30 fps возникла повторяемость типа кадра через 6 кадров?
Далее. aa bb c не может быть, это не согласуется с IIIIIP. Если I, то при разделении на поля мы автоматически получаем ab. При разделении IIIIIP, мы получили бы куда больше разных полей, стоящих рядом. Проблема в том, что многие поля двоятся. Но если внимательно присмотреться, каждое такое поле - некое среднее между предыдущим и последующим полем, которые не двоятся. Если их обозначать, как a+b, то получится что-то типа
Код:
a a a+b b b+c c c+d d d ...
Посмотрите, как это выглядит в вашем клипе, выпишите последовательность в разных местах (где легко видно движение). Какой у нее период? Подумайте, а нужны ли вообще эти смешанные поля, есть ли хоть одно, которое несет информацию, не содержащуюся уже в его соседях?
И еще. Фильм ВВС, но в NTSC. Это тоже наводит на определенные мысли.
У меня получилось так
Код:
a a a+b b b+с с с
Пара кадров a a, с с, и т.д. отличаются, насколько мне видно, разве что расположением по вертикали, и все. Можно ли удалить один из этих кадров, я не знаю. Остальные кадры, по-моему, совсем не идентичны, удалять нечего.
Прикинул, вышло у меня, что скорость исходника в моем случае должна быть 20 fps
Никаких мыслей насчет "Фильм ВВС, но в NTSC" у меня, к сожалению, нет - я дилетант в ДВД-шных делах, мне мало о чем это говорит. Знаю только, что NTSC используется в Северной Америке да Японии, вроде. Но не в Британии. А какой из этого сделать вывод - понятия не имею.
По поводу полей - лучше ещё верхнее поле пометить 1, а нижнее 2.
Тогда будет понятней. Т.е. получится что-то в стиле
а1 a2 a1+b1 b2 b1+c1 c2 c1+d1 d2 d1 d2+e2 d1+e1 e2
Вышеозначенную конструкцию я написал условно, смотрите, что у Вас реально...
Из этого надо получить a1 a2 b1 b2 c1 c2 d1 d2 e1 e2
Но это, по-моему, невозможно, так как некоторых полей в чистом виде нет.
Из моего примера можно соорудить такое (c1+d1 и d2+e2 выкидываем, d2 и d1 меняем местами)
а1 a2 a1+b1 b2 b1+c1 c2 d1 d2 d1+e1 e2
Mikky72 писал(а):
ВВС = Англия = PAL = 25 fps.
Т.е. было переделано 25 -> 29,97
Именно. И за такие переделки надо отрывать руки и все остальное. Обычно такими махинациями занимаются дешевые азиатские полуподпольные компании. Фильм был снят на пленку, но для показа по ТВ, в PAL Англии. Когда они вздумали выпустить этого Бида в Штатах, они взяли видео, а не исходную пленку, и перевели 25 fps в 29.97 самым непотребным способом - смешением полей. К счастью, все оригинальные поля на месте, надо "просто" отбросить смешанные (двоящиеся) поля (бывает и такое, что оригинальных полей не остается). Проблема в том, что смешанные поля идут в хитрой последовательности, которая к тому же меняется время от времени. Смешанные поля нужно детектировать, а не полагаться на определенную последовательность. Для этой цели существует замечательный скрипт srestore (скачайте с сайта avisynth). Он находит сдвоенные кадры и может отбросить их. Им же можно установить и окончательный диагноз. Поскольку он работает с кадрами, а не полями, а у нас двоятся именно поля, перед srestore должен идти боб (то есть, кадры разделяются на поля, которые растягиваются до полного кадра, с удвоением частоты). Бобов много - все деинтерлейсеры работают и как бобы. Единственное, деинтерлейсеры с компенсацией движения не слишком хорошо работают с двоящимися полями. Поэтому, используем что-нибудь типа yadifmod(mode=1, edeint=last.nnedi2(-2)). Итак, для анализа делаем
Код:
MPEG2Source("5q1eVTS_01_1.d2v")
yadifmod(mode=1, edeint=last.nnedi2(-2)).Crop(8, 0, -8, -0)
srestore(frate=29.97, cache=10, dclip=last.reduceflicker(strength=1))
mode=1 в yadifmod производит боб. Черные полосы по бокам сразу отрезаны, для улучшения детектирования сдвоенных полей. dclip в srestore служит для той же цели, но в принципе он не нужен.
Если теперь мы посмотрим на кадры, то увидим, что сдвоенные кадры ушли, но каждые 6 кадров один кадр повторяется. При любых идиотских операциях по смешению полей в пределах NTSC, все происходило бы группами по 5, и 6-му кадру было бы неоткуда взяться. Таким образом, мы имеем четкое доказательство, что исходник имел скорость 25 fps. Можно возникнуть желание выкинуть этот 6-й кадр, просто добавив в скрипт Decimate(cycle=6). Но тогда скорость бы упала до 24.975, а каждые несколько секунд возникал бы повторяющийся кадр. Правильней задать скорость в 25 fps в самом srestore. Итак, для рипа:
Код:
MPEG2Source("5q1eVTS_01_1.d2v")
yadifmod(mode=1, edeint=last.nnedi2(-2)).Crop(8, 0, -8, -0)
srestore(frate=25, cache=10, dclip=last.reduceflicker(strength=1))
BicubicResize(640,480,0,0.5)
Можно надеяться, что не будет ни дергаться, ни двоить, и гребенки не будет. И продолжительность не изменилась, со звуком ничего делать не придется.
В принципе, когда диагноз уже поставлен, почти точно такого же результата можно добиться и скриптом AnimeIVTC, который и использует yadifmod + srestore. Иными словами, вместо yadifmod и srestore, написать
Код:
AnimeIVTC(mode=2, normconv=true)
mode=2 направляет на борьбу со смешанными полями, normconv переводит из 29.97 в 25. Вот только обрезать поля после боба, но до srestore, уже не получится.
Дальше конечно можно (и нужно) бороться с шумом, поднять диапазон хромы, вообще поработать с цветом. И так далее. Но это уже из другой оперы.
tartak
А по качеству картинки, что будет лучше - исходник NTSC (со смешанными полями) или восстановленный PAL (c учетом того, что реальное разрешение в 2 раза меньше - кадр восстановлен только из одного поля)?
Mikky72
Это же деинтерлейсный боб, а не простой. Так что, каждый кадр строится на основе всех доступных полей. Разрешение останется неизменным, а общее качество будет несравненно лучшим (я надеюсь).
tartak
А как, например, восстанавливается кадр "b", если для него присутсвуют поля:
1) a1+b1 (интерполяция между верхними полями a и b кадров);
2) b2 (родное нижнее поле кадра "b");
3) b1+c1 (интерполяция между верхними полями b и c кадров);
а Вы пишете - "смешанные поля выкидываются"?
Mikky72
А ведь вы правы, 2/3 кадров будут восстановлены из только одного чистого поля. Для них разрешение упадет. Но сравнивать с разрешением раздвоенных полей в любом случае не приходится.
В принципе, потерянные поля можно восстановить - вычитанием. Для VCD есть такой скрипт, но он работает только для фиксированной последовательности. Чтобы это провернуть, надо модифицировать srestore, поскольку он смешанные поля выкидывает, заменяя их на лучшее из соседних. Не уверен, что что-то хорошее из этого получится - у меня сложилось впечатление, что даже веса при смешении не обязательно 1:1.