Close Topic Options

Тема для обсуждения номер 1 - ^Fast recompress^ в Дабе :

- "Известно" что ^fast recompress^ оставляет то цветовое пространство в котором был сделан источник а не перегоняет его в ^RGB24^ как ^Full recompress^ , правда нельзя пользоватся/добавить Дабовские фильтры. У кого то есть коментарии ?

- Что именно делает ^Normal recompress^ ?

- Вчера кодировал один сериал с ^DVD^ на ^fast recompress^ с ^XviD 1.0^ в 2 прохода в результате не важно какой битрейт я ставлю после определённого битрейта (в раёне 800) не размер файла не конечный битрейт "не растут" , пусть даже я ставлю 3000. Кто может обяснить/прокоментировать ?




Тема для обсуждения номер 2 - "странные" ^fps^ (29.7,...) :

- Откуда они берутся ?

- Есть тот же сериоал о котором говорилось выше , рип делался при помощи ^RoboRip^ , сериал вроде ^NTSC^ , почему когда ^RoboRip^ запустил ^DVD2AVIdg^ то там (а затем конечно и в конечных ^AVS^ и ^AVI^) стало 29.7 ?


Тема для обсуждения номер 3 - ^Field operation^ в ^DVD2AVI^ :

- Что это такое , с чем его едят и почему в приведенном примере с сериалом в конечном в двуй из трёх серий когда ^DVD2AVIdg^ работал у меня всё время мигало между ^NTSC^ и ^FILM^ а в одном всё время "горел" ^FILM^ , при этом в конечных ^.D2V^ файлай для первых двух я получил ^Field Operation^ как 0 (^None^) а в том что всё время "горело" ^FILM^ получил ^Force FILM^ , кроме того этот последний фильм запаковался гораздо лучше , если два других "остановилис" на битрейте в раёне 800 то этот на 670.
То есть я знаю что есть такая вещь как ^Film^ с 24фпс и есть такая вещ как ^NTSC^ с 29.97х2 ^fields^ , а в ^MPEG2 (DVD ? )^ пишется 30фпс для их конверсии используется алгоритм под названиен ^TELESYNE^ но как он работает реально , или проще говоря что мы должны делать имея ^NTSC DVD^ что бы получить "идеальный" рип ?


^Set^ , ^valja^и другие спецы - ждём разяснений , думаю разобратся во всём этом будет интересно не только мне одному.

This post has been edited by Lord KiRon on 20-05-2004, 14:03

1. Это как раз просто, подробности о сих режимах содержались в старом хелпе Дуба:

Fast repack (Fast recompress)

Fast repack mode allows a video stream to be recompressed. In this mode, VirtualDub hooks decompressor directly to compressor and tries to find the fastest way from one video format to another.

Advantages:

· Depending on the video codecs involved, recompression might take place in a faster format, such as YUV. This can significantly speed recompression.

Disadvantages:

· May not work if the codecs cannot agree on a common image format.
· Video cannot be viewed during process.
· No image processing possible.
· Some video codecs handle YUV data incorrectly, which can result in upside-down video in this mode.

Slow repack (Судя по всему это и есть Normal recompress )

VirtualDub decompresses the input video to RGB and compresses it using the selected video compressor.

Advantages:

· Allows a video stream to be recompressed from any video format to any other, provided compressors and decompressors are available.
· Compatible with more video codecs, because RGB is a very ‘safe’ format.

Disadvantages:

· Often slower than fast repack mode.
· Compressors and decompressors must be compatible; if the decompressor only decompresses to 16-bit RGB, and the compressor only accepts 24-bit RGB, this mode won’t work.

Full processing (default)

The full video processing pipeline is enabled. This involves a full conversion to 32-bit RGB and back, and the video runs through the current set of video filters.

Advantages:

· All filtering options are functional.
· Any decompressor-compressor pair can be used as long as the decompressor outputs some form of RGB and the compressor accepts 16- or 24-bit RGB.

Disadvantages:

· The slowest mode.
· Requires the most memory, since all images must be decompressed to 32-bit RGB, and then converted back to a form suitable for the compressor.

А я пока разобрался насчет 2 , связанно это всё дело с ^NTSC^ , оказывается у американцев всё не как у людей -
Телевиденье работает не на 30 ^fps^ а на 29.97 ( а если точнее 59.95 ^fields^ - полей) , 30 ^fps^ делается только когда делают прогресивный ^MPEG^.

Однако это не всё , оказываестя все свои фильмы они снимают в ^FILM^ формате как бы на плёнку а там 24^fps^ так вот это они обычно отсняв перегняют в ^NTSC^ (который потом обычно и транслируется и на ^DVD^ пишется ) .

А как перегнать ? придумали такую систему под названием ^TELECINE^ - каждый кадр разбивается на две половинки верхнюю и нижнию которая берётся "вместо" ^NTSC field^ (то есть полу-фрейма) .
То есть получили теперь как бы ^interlaced^ , но надо ещё подогнать ^fps^ по этому делают следущее :

Если ^A^ и ^B^ два последовательных кадра в ^FILM^ то ^Ah^ и ^Bh^ - верхние полукадры а ^Al^ и ^Bl^ - нижние , соответственно имея стрим в ^FILM^ : ^ A,B,C,D...^ записывается ^Ah,Al,Ah,Bh,Bl,Ch,Cl,Ch,Dh,Dl,...^ то есть полуфрейм каждого второго кадра дублируется (по этому эту систему ещё называют 3:2 ^pooldown^ ) , это и позволяет "добавить" недостающие 6^fps^ .

Теперь о практическом применении , иомеем ^NTSC DVD^ если источник ^NTSC^ то делать нечего , надо делать ^deiterlace^ который как мы все знаем немного размазывает изображение , однако если источник ^DVD^ был фильм которому сделали ^Telecine^ то в принципе у нас есть прогресивные полу фреймы да ещё и лишние фреймы (размноженые ^Ah^ из примера) которые не несут ни какой полезной информации а только увеличивают размер конечного файла и время упаковки.

Запускаем ^DVD2AVI^ (или новый ^DVD2AVIdg^ ) - обратите внимание что он во время обработки ^VOB^-ов (когда создаёт ^.D2V^ проэкт постоянно пишет в диалоге статистик ^FILM %^ или ^NTSC %^ , где % исут с числом.
Что проишодит это то что эта программа пытается определить был ли сделан ^Telecine^ на источник и "собрать" ^A,B,C,..^ фреймы "обратно" из их частей выкинув "лишнее" , при этом ^fps^ "падает" обратно до 23.97 (24) и конечный файл получается меньше без потери качества.

Алгоритм работает не 100% точно , ибо после выполнения ^telecine^ видео могли редактировать , например добавить субтитры или вырезать кусок и тогда цепочка ^Ah,Al,Ah,Bh,Bl,Ch,Cl,Ch,Dh,Dl,...^ нарушается , однако ^DVD2AVI^ подсчитывает статистику и если 95% и выше оф фильма "узнано" как ^FILM^ в ^.d2v^ файл записывается информация заставляющая фреймсервер (это отдельная тема, но проще говоря тот ^dll^ через который Даб считывает источник) выполнить процесс обратный ^telecine^ и создать файл с 23.97 ^fps^ , если че меньше 95% то создаётся файл 29.97 ^fps^ с обычным ^NTSC^ который затем рекомендуется прогнать через ^deinterlace^ фильтер .

А на full всё было нормально ?

2. В картинках: "WHAT THE HECK IS 3:2 PULLDOWN?"

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

3. Не знаю насколько полезно, но по теме: http://www.videohelp.com/forum/archive/t57337.html

P.S. Случайно наткнулся: DVD2AVIdg/MPEG2DEC3dg Decoding Fix.

А на full всё было нормально ?

Нет просто с ^full^ потребовался более высокий битрейт пока кодек "остановился" , спашивал на Дум9 - говорят это не проблема , просто кодеку кодировать больше нечего было

Вот ведь, даешь ему битрейту, а он фиг.
Проверил: из 6000 битрейта только 600, и действительно - по статистике получившийся у меня максимальный квант для i и p фреймов = 1.00, для b = 2.00...

ЗЫ Вот только как это всё к качеству рипания относится, лучше бы выяснить чем наиболее качественно деинтерлейс и IVTC делать. Да и о полезных утилитках что-то новое узнать.

Я бы посоветовал не морочить себе голову с рипованием в VDub напрямую.
Весь процесс гораздо проще и безошибочней при работе из Gordian Knot.
Кроме того после того как освоишься с базой, в нем очень удобно редактировать почти готовые скрипты для Avisynth при появлении нестандарных ситуаций.

Ну а читать про все эти дела надо разумеется на www.doom9.org