Если "дожил" до этой ошибки, скорее всего версии "скоординированы"
А .avs такой:
LoadPlugin("c:\alonzo\plugins\MPEG2DEC.dll")
mpeg2source("G:\simpsons\disk4.d2v")
LoadPlugin("c:\alonzo\plugins\decomb510.dll")
Telecide(order=1,post=2)
Decimate(cycle=5)
crop(8,0,-16,-8)
BicubicResize(608,464)

(да, да ... скоро будет 3ий сезон симпсонов в приватах )

Как видишь параметр post стал не boolean а int
order=0 или 1 в зависимости от порядка чего-то там ...
прокрути в дубе - post=0 быстрее всего. post=2+ лечишь интерлейс.
Полчаса стоит на это угробить.
ЗЫ. Сообщи, разобрался или нет

http://sourceforge.net/projects/avisynth2/ - последняя версия AVISynth от авторов
http://nic.dnsalias.com/mpeg2dec3.html - последняя версия MPEG2Dec3 от авторов
http://www.neuron2.net/decomb/decombnew.html - последняя версия Decomb от авторов


В закладки!

Пардон, убрал написанное, так как у меня Decomb еще 4-й версии стоит, а в пятой всё кардинально изменилось. Так что у кого неразруливаемые проблемы, используйте пока лучше 4-ю версию.

Правильно.
А сложность там в том, что на doom9 лежит (по умолчанию) 5ая версия декомба, а она работает только с версией 2.5 avisynth.
А для неё нужен mpeg2dec3 . На том же doom9 лежит старая версия mpeg2dec, при установке которой появляются странные ошибки (типа того что не может открыть файл)
А ещё в нек. версиях mpeg2dec3 называется mpeg2dec.dll, что делает её абсолютно неотличимой от старой версии
ЗЫ. только что понял почему VirtualDub память жрал: в версии 1.0.6 mpeg2dec3 memory leaks.
Ощущение будто вернулся во времена, когда лучшей прогой был Flask

По моей ссылке (чуть выше) лежит MPEG2Dec3 1.1.0 (вот прямой линк).
На этом сайте выкладывают MPEG2Dec3 прямо от авторов. Две другие ссылки - также на первоисточники.

А по поводу памяти, если ее 512 метров и больше, можно еще попробовать поставить в скрипте команду
SetMemoryMax(128)
Мне показалось, что чуть быстрее кодироваться стало. Проверить не получается, ибо последнее значение запоминается, по всем признакам (как минимум до перезагрузки - дальше не проверял).

вау все поехало , всем огромадное спасибо!!!

Превосходно! Теперь вернёмся к моей просьбе.
Алонсо!!!!! Пожалуйста, обнови своё руководство
(докричусь ? или ПМ лучше послать ?)

Всем спасибо. С ДЛЛами разобрался и фильм закодировался. Не было времени написать только. Всем наилучшие пожелания. Слушайте, может Алонцовское руководство на WikiWiki перевести? Тогда всем скопом можно его будет усовершенствовать и обновлять - с ссылками на софт и все такое.

Привет, снасибо за guide, 3 день разбираюсь вроде всё как написано сделал, но есть такая проблема, после того как создал avs файл, он нормально открылся в Дубе, сделал всё по инструкции, получил first pass и second, пробую открыть bs плейером, выдаёт такое сообщение: file is corrupted, seeking will be very slow потом просто показывает чёрный экран. Укажите чайнику на ошибку плиз

Так с предыдущим вопросом разобрался, ещё раз спасибо за хороший guide, качество отменное, но возникла проблема при разбивании на два файла, после разбивки русский перевод спешит секунд на 3-5, в полном(нерезаном) варианте всё ОК

Скажите (мне так показалось) а почему вы Gordian Knot' том не пользуетесь - все в одном флаконе и если что можно ручками итоговый файл подправить

2 Egorych:
Мне, к примеру, гораздо легче руками всё в скрипте прописать. Да и "стандартные" значения параметров я не люблю. Когда делаешь руками, намного надежней. И лучше понимаешь процесс. GKnot слишком многое решает за тебя.

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

Посмотрел Guide Alonzo
Добавочка - избавится от интерлейса можно значительно лучше(для NTFS источника) если написать так

Telecide(order=1,post=1,hints=true, show=true, vthresh=45)
KernelDeint(order=1, threshold=10, map=true)
Decimate()

параметр threshold=10 при уменьшении сильнее деинтерлейсит
когда все это грузим в VD увидим приятную статистику о том какие кадры Telecide посчитал прогресивными, а какие нет.
А также белые и черные полосы на интерлейсных кадрах, чем больше белых тем больше деинтерлейснулось

варьируя vthresh=45 можно менять порог при котором Telecide считает кадр интерлейсным
таким образом можно подогнать параметры, чтоб нужные кадры после Telecide обработал KernelDeint и не трогал и так нормальные дабы не портить края

А GK я использую как большой удобный калькулятор, с хорошей возможностью для изменения разрешения видео и обрезки мусора по краям

з.ы. спасибо что помог мне по этому поводу Shalcker

2 Egorych:
К какому плагину относится KernelDeint? Не Decomb-у же.

Ну скачать его можете здесь
http://neuron2.net/kerneldeint/kerneldeint140.zip

с PAL я очень мало работал, у мя все диски были то из японии, то из америки, а они NTFS в основном. Найду какой-нибудь PAL посмотрю

2 Egorych:
Спасибо за инфу!
Надо будет попробовать...

2 Egorych:
Спасибо!

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

LoadPlugin("C:\AviSynth 2.5\MPEG2DEC3dg.dll")
mpeg2source("L:\Brigada7-9\brigada.d2v")
LoadPlugin("C:\AviSynth 2.5\decomb511.dll")
Telecide(1)
BicubicResize(512,384)

Всё вродебы хорошо, только вот Telecide хочет либо 0 либо 1, обьясни пожайлуста что поменялось.

2 alexshura:

1 и 0 - это порядок полей (Field Order) в NTSC.
1 - это порядок полей, начиная с верхнего (TTF - Top Field First)
0 - начиная с нижнего (BTF - Bottom Field First)

Определяется следеющим образом:

Создаём скрипт, в котором, кроме загрузки видео-источника *.d2v и необходимых плагинов, будет ТОЛЬКО следующая строчка (нужна только для определения порядка полей и при кодировании не используется):

AssumeTFF().SeparateFields()

После этого загружаем скрипт в VirtualDub и смотрим покадрово. Если движение будет происходить поступательно, то порядок полей TFF, то есть ставим 1, если же будут попадаться кадры с откатами движения на фрейм назад, то значит это BFF, то есть ставим у Telecide параметр в 0.

В случае порядка полей, начиная с нижнего, можно еще попробовать строчку:

AssumeBFF().SeparateFields() - с ней движение должно стать корректным.

На основе полученных данных пишем окончательный скрипт.


P.S. Кстати, "Бригада", по идее, должна быть в PAL, и Telecide, в этом случае, там не нужен абсолютно.

Спастбо kvappa!

Сегодня обязательно попробую. А Бригада - как раз тот один из самых мучительных вариантов, всё в однов флаконе - NTSC, фреймы интершмайзинг, ну и 97 частота, недолго ей каблучится осталось. Сегодня расчехлю

2 alexshura:
Если у это DVD 25FPS->NTSC, то могу поздравить. 100% качества уже не будет точно.
Тут можно попробовать следующее:

Telecide(order=x, post=1, vthresh=n)
TomsMoComp(x,1,5)
Decimate(6)
Где х - порядок полей (0 или 1), а n - от 30 до 150

Или другой вариант:
Bob()
Repal()

Не известно, как выйдет лучше.
TomsMoComp и Repal - это отдельные плагины.

прочитав гайд так и не понял как правильно как правильно перевести фильм из 29.97 в 23.97 и из 25 в 23.97 кадров. пробовал во время кодирования в виртуал дабе изменить частоту кадров, но получилась рассинхронизация со звуком. как правильно перевести частоту кадров без рассинхронизации?

2 lalex:
Думаю что никак - ручками, ручками прийдется звук править

Слушайте..я ваще начинающий..но вот юзаю GKnot последней версии + Codec pack и вот по одному гайду сделал рипик.....походжу Resolution маленький поставил, а bits/(pixel*frame) = 0.42 помоему...Gknot после compression check выдал мне что ето 91% правильности..т.е всё ок..
И фильм действительно получился ничё..
Но тут некоторая братва из тимы мне выдала что надо бы увеличить REsolution, будет всё ок..
Слушай..какие параметры будут оптимальными...?
Можешь мне выдать табличку с этим Bits*(Pixel*frame) по отношению к Resolution?
Пасиба.

2 temnovs:

а ты в первом посте ссылку на гайд не заметил? >>>>>

В связи с развитием темы хотел бы внести некоторые свои коррективы в данный гайд.
1. С появлением Avisynth 2.55 в него был включен новый чудесный метод ресайза (Lanczos4Resize), который дает лучшие результаты, чем предыдущие методы (BicubicResize, LanczosResize) . Привожу выдержку из официального фака:"LanczosResize is an alternative to BicubicResize with high values of c about 0.6 ... 0.75 which produces quite strong sharpening. It usually offers better quality (fewer artifacts) and a sharp image.

Lanczos was created for AviSynth because it retained so much detail, more so even than BicubicResize(x,y,0,0.75). As you might know, the more detail a frame has, the more diffiult it is to compress it. This means that Lanczos is NOT suited for low bitrate video, the various Bicubic flavours are much better for this. If however you have enough bitrate then using Lanczos will give you a better picture, but in general I do not recommend using it for 1 CD rips because the bitrate is usually too low (there are exceptions of course).

Lanczos4Resize is closely related to LanczosResize (correct name: Lanczos3Resize). The latter uses 2*3=6 lobes and the former 2*4=8 lobes to do the resizing. The result is that Lanczos4Resize produces sharper images. Especially usefull when upsizing a clip.

"For upsampling (making the image larger), the filter is sized such that the entire equation falls across 4 input samples, making it a 4-tap filter. It doesn't matter how big the output image is going to be - it's still just 4 taps. For downsampling (making the image smaller), the equation is sized so it will fall across 4 *destination* samples, which obviously are spaced at wider intervals than the source samples. So for downsampling by a factor of 2 (making the image half as big), the filter covers 2*4=8 input samples, and thus 8 taps. For 3x downsampling, you need 3*4=12 taps, and so forth.

Thus the total number of taps you need for downsampling is the downsampling ratio times the number of lobes (thus Tx downsampling and LanczoskResize results in T*2*k taps). And practically, one needs to round that up to the next even integer. For upsampling, it's always 4 taps."
Таким образом можно сделать вывод, что при использовании хорошего и чистого лицензионного источника использование Lanczos4Resize вполне оправданно, если же мы имеем немного "грязный" источник для кодирования, то нужно пользоваться BicubicResize который дает меньшую степень детализации кадра в целом.

2. При использовании BicubicResize можно увеличить скорость обработки кодером вашего видеоматериала за счет оптимизации некоторых действий фрейм-сервера. Можно в скрипте использовать комбинированные значения, т.е. BicubicResize(320,240,0,0.3,160,0,160,120), где первая пара цифр - это конечное разрешение, которое мы хотим получить, последние 4 значения - это значения вашего кропинга, 3-е значение (0) менять никогда не нужно, а 4-е значение (0.3) - это значение Sharpena при кодировании. Значения Sharpen-а лучше всего использовать из диапазона 0.25-0.35 (только не нужно увлекаться, потому что вместо увеличения четкости вы получите ухудшение качества картинки за счет появления "песка"). В среднем увеличение скорости обработки составляло 5%

В конечном счете в простейшем случае в скрипте вы должны получить что-то напоминающее это"

LoadPlugin(D:\DGMPGDec\DGDecode.dll")
mpeg2source("D:\DVD\neudergimie\neudergimie.d2v")
crop(22,72,676,432)
Sharpen(0.3)
Lanczos4Resize(640,288)

3. В качестве калькулятора битрейда отлично подойдет GordianKnot, в нем можно прекрасно выбрать конечное разрешение и подобрать параметры кропинга. не кодируйте ничего в GordianKnot-е используйте только VirtualDubMod. В GordianKnot-е так-же вы подберете величину bits/(pixel*frame), которая характеризует качество вашего материала.

4.При использовании кодека DivX (а я надеюсь, вы его используете ) желательно использовать самый медленный алгоритм кодирования. Еще как показывает практика использование проходов больше 2-х дает лучшие результаты в конечном закодированном материале. Для придания картинке большей четкости в самом последнем проходе мог бы порекомендовать подвинуть бегунок Modulation в правую сторону (low-motion) на 0.01-0.05 едениц, но не более. В среднем при bits/(pixel*frame) до 0.3 можно бегунок Modulation можно подвинуть на 0.01-0.02, при bits/(pixel*frame) от 0.3 можно и до 0.04-0.05

5. Так-же для улучшения качества вашего закодированного видеоматериала я б рекомендовал кодировать титры отдельно от фильма. При кодировании в VirtualDubMod нужно выбрать диапазон фреймов от начала фильма (кнопка на клавиатуре Home) и до начала титров (кнопка End) и посмотреть сколько фреймов имеет конечный материал, после возвращаясь к GordianKnot ввести полученное количество фреймов и отнять 7-8 мб от конечного размера файла (т.е. 1392-1393 Мб или 2037-2038 Мб). В результате вы получите битрейд на 5-7% больший нежели при ваших первых расчетах. Этот самый битрейд вы в итоге и потратите на улучшение четкости картинки. А титры можете закодировать точно таким же способом, но используя 1-проходное кодирование с битрейдом около 150 кбит/сек, не переживайте на счет такого низкого битрейда. титры будут прекрасно читабельны. После этого вам предстоит всего лишь склеить 2 части фильма и присоеденить к ним звук.

P.S. коментарии и пожелания принимаются

2 lalex:
Делать Sharpen ДО Resize - мысль довольно спорная.
Поскольку, ресайз производит апроксимацию, используя информацию из соседних точек - и в любом случае, это приводит к уменьшению четкости. Если же попадется контрастная наискосочная линия, к примеру, то Sharpen (увеличение яркостной разницы между пикселями) на таковой уменьшит количество сглаживающей ее информации (переход станет более резким), что после ресайза приведет к образованию "ступенек" (не думаю, что Lancoz полностью лишен этого бикубического недостатка). Вдобавок, Sharpen увеличит зерно, которое могло бы наоборот уменьшится на этапе апроксимации при ресайзе.

Так что, считаю, что Sharpen всё-таки рациональнее использовать после после Resize !

Кстати, при использовании Sharpen после ресайза, требуются меньшие его значения.

Добавление:
Отредактировал сообщение.
В принципе, я понял аргументацию тех, кто использует шарп до ресайза, но по своему опыту, предпочитаю так не делать.

http://www.rusdivx.net/ifm/users/alonzo/guide/
не работает что-то этот линк...

2 Afed:
http://mitglied.lycos.de/alonzo999/guide/
но там многое уже устарело

А где не устарело? (или обновилось?)
Спасибо