Virtual Dub. Сравнение 1.4d, ММ4, Nandub, Stas patch для iVTC и VKI.

Обзор появился в связи с выходом давно ожидаемого и широко рекламированного в конфах автором, Стас-патча (заплатки от Стас Корбут) для оригинальной версии Дуба. Автор утверждал, что переработал несколько косячный оригинальный алгоритм iVTC и добавил свой алгоритм VKI, позволяющий сжимать фильмы обычным кодеком 3.11а. Что же из этого получилось?

iVTC и VKI.

Напомним вкратце что такое iVTC и VKI. iVTC - способ перевода фильма с частотой кадров 30 (29.97) в 24 (23.97) Гц без потери информации с целью уменьшить конечный файл и убрать чрезстрочность (interlace). Ранее Дуб был единственной, с моей точки зрения, наиболее корректной программой, позволяющей убрать комбинированный интерлейс (Telecine), но имеющий несовершенный алгоритм и допускающий временами "расческу" и "двойной кадр". VKI - прогрессивный (по сравнению с изначальным) способ расстановки ключевых кадров, при котором КК ставяться не только через определенный временной интервал, но и при смене яркостных сцен в фильме, с целью получить сглаженный кадр на месте стыка (наиболее измененный и не вписывающийся в поток по массе). Эту возможность предоставляли DivX 3.11a VKI patch, VD MM4 и NanDub (SBC).

Эксперимент.

Для эксперимента по точности VKI был взят оригинальный черно/белый трэйлер от фильма "A Hard Day's Night" длиной 1'37". Выбор пал на него, потому что это у меня сейчас единственный ч/б фильм, а они, как показал опыт, являются наиболее проблемными для любых версий VKI. Сграблен с DVD с помощью SmartRipper 2.12. Для Дубов применен фрэймсервер DVD2AVI->VFAPI. На версиях программ с собственным VKI применялся кодек ДивХ 3.11а, на версиях программ без своего VKI применялся кодек DivX 3.1 VKI patch. Исследовалась возможность корректного iVTC и правильность определения стыка сцен разными алгоритмами VKI. Во всех случаях брался LM с установками 1200/100/10. Установки Дуба "Scene change thresholds" не менялись и стояли во всех Дубах по умолчанию (206/64).

Для второго эксперимента, больше касающегося правильности iVTC, был взят кусочек (27") из начала клипа 'Baby One More Time', подходящего под условия - современный (хорошая детализация, яркий не размытый цвет, высокая резкость), динамичный клип с быстро меняющимися сценами LM и FM. Последовательность расчесок в этом клипе меняется быстро, но отследить ее здесь легче, чем на ч/б кинотрэйлере 65 года. LM 1500/100/3, остальное аналогично предыдущему эксперименту.

Очень интересно, как относятся сами авторы к своим детищам.

Avery Lee при выпуске версии 1.4d объявил, что это версия последняя, исключительно для исправления мелких глюков, что далее в таком виде он ее продолжать не может, т.к. она уже не соответствует его концепции, надо полностью переписывать код и вообще все менять ("I really don't want to make any big changes to the V1.4x series, because it would prolong a codebase that truly needs to die"), но времени у него на это нет, поэтому наберитесь терпения и ждите, возможно все интересные фичи, которые вы там патчите в моем Дубе, выпущу когда-нибудь под одной крышей, но ничего не обещаю. Короче Дуб маст дай - (с) автора. Надо сказать главнейшее отличие этой новой версии - большое количество хинтов, которые к тому же невозможно отключить...

Nandos (1.4с) в своем readme пишет, что времени и так нет, выпускаю "как есть", безо всяких объяснений, с настройками (а их там немало, и не все интуитивно понятны, т.к. автор использовал свой слэнг, не совпадающий с устоявшимися у нас определениями) дескать разбирайтесь сами, и отсылает к известному автору англоязычных обзоров - doom9.

Стас пишет, что алгоритм переработан и Дуб (1.4d) теперь ПОЧТИ не ошибается в определении последовательности расчески (так он и раньше ПОЧТИ не ошибался, а надо-то чтоб СОВСЕМ не ошибался) и более корректно расставляет КК. Добавлен лог-файл, насколькоя понимаю "In" в нем - это номера кадров входящего фильма, "Out" - исходящего. Подождем дальнейших разъяснений автора, который к сожалению не прилагает к своему варианту никакого ридмА, даже на русском (в случае, если он плохо владеет тем африкаансом, на котором обычно пишутся подобные опусы).

Зато автор ММ4 патча Дуба (патч на 1.4b) все описывает подробно, выдает "на гора" кучу графиков, примеров из интерфейса, формулы подсчета и т.д. Видимо более всех болея за свой продукт. Что не оправдывает его продукт ни в коей мере. Мне нравится окончание его ридма: "Last recommendation: use the regular VirtualDub to edit your AVI files, this one could be fucked up by my hacks." Запад, цивилизация... Найдите ка у нас описание кряка со словами - "пользуйтесь иногда исходной программой, а то мой ё"№$%й кряк может что-нибудь испортить"... А? Каково? В общем не ешьте на ночь сырых помидоров, чтобы не причинить вреда своему кошельку.

Последствия.

Выяснилось, что мой вариант Нандуба (18b) совершенно не желает работать с ivtc - он просто вылетает на оцифровке первых же кадров при установленном флажке "reconstruct from fields - adaptive". При установке Change to... frames per second он выдал фильм, соответствующий по плэерам 23.97 fps, но при этом занимающий место, как при 30 fps (и количество кадров было соответствующем 30 fps). Постоянно в настройках SBC проскакивает "Abbrechen" (Cancel), что указывает на национальность автора и его некорректность по отношению к оригинальному варианту программы и к нам, пользователям. Либо на глючность его программистского софта. Кстати этим же страдает и VD-ММ4.

Во всех без исключения вариантах Дуба проявились артефакты (не всегда совпадающие по местоположению в кадре), что я отношу к несовершенству кодека.

Интересные данные получились по количеству КК и по массе файлов.

"Hard Day's Night" VD 1.4d +VKI VD Stas patch VD MM4 VD SBC (Nandub) Flask 0.6 +VKI
file, kb 12 009 12 044 18 067 18 069 14 562
KeyFrames 30 46 124 33 28
frames 2321 2324 2318 2911 2333
bitrate 121 kBps (968) 121 kBps (968) 182 kBps (1456) 145 kBps (1160) 146 kBps (1168)

*"Baby One More Time" VD 1.4d +VKI VD Stas patch VD MM4 VD SBC (Nandub)
file, kb 4 450 5 814 8 482 5 402
KeyFrames 42 41 81 25
frames 600 603 594 760
bitrate 173 kBps (1384) 225 kBps (1800) 334 kBps (2672) 208 kBps (1664)

*Фласка во втором эксперименте не участвовала, т.к. в ней невозможно выставить аналогичный кусок, плюс iVTC в ней нет (по утверждению автора) и ее использование в данном случае было бы некорректным. Nandub был использован только для компании, т.к. в нем iVTC (у меня) не работает.

Рассмотрим первую таблицу. О чем говорит нам различие в количестве ключевых кадров (KF)? Вовсе не о разном количестве сцен в одном и том же куске, а о различиях в алгоритмах определения смены сцены. А вот о чем нам говорит разница в количестве кадров в конечном фильме??? О косяках конечно! В этих самых алгоритмах. Оригинальный фильм занимает 2911 кадров (Nandub сохранил это количество кадров, несмотря на то, что ему дали команду на изменение фрэймрэйта, и что проигрывается фильм с частотой 23.97). По пропорции (2911/30*24) конечный фильм должен занимать 2328 (± 1-2) кадров. Ни одна программа не выдерживает правильной пропорции кадров, хотя ближе всего к этому значению подошли с разных сторон Фласка и Стас-патч. О чем это говорит? О том, что конечный фильм будет не точно 23.97, а немного больше-меньше fps.

Все то же самое мы наблюдаем и во второй таблице (должно быть 608 кадров, ближе всего Дуб СК). Вот откуда берется несовпадение аудио и видео потоков при iVTC или смене фрэймрейта - от некорректности алгоритмов пересчета фрэймрэйта программ перецифровки (в том числе, т.к. наверняка есть и другие причины для несовпадения).

Битрэйт в первом эксперименте ни один Дуб (кроме Нан) корректно не выдержал, несмотря на большой размер кадра - 720х480. В отличие от них, Фласка приблизилась к корректному битрэйту (1168 кбит) при уменьшении количества кадров (следовательно поток в пересчете на кадр и качество этих самых кадров окажется выше, чем у любых Дубов). Приближение к нужному битрэйту у Нандуба пока что ничего не дает без iVTC - во-первых, размер файла больше в полтора раза, во-вторых, поток распределяется на бОльшее количество кадров, следовательно на каждый кадр остается меньше потока, ну и в-третьих собственно отсутствие iVTC заставляет нас делать деинтерлейс (потеря времени и качества). Большой поток и размер файла у ММ4 объясняется излишним количеством ключевых кадров (в 3-4 раза больше!), по сравнению с остальными вариантами. Возможно качество от этого выигрывает, а вот расчет битрэйта фильма под размер CD сильно проигрывает. Кстати такое различие в реальных битрэйтах, по сравнению с заданным, дает основание утверждать, что конечный битрэйт определяет не только кодек, но и программа, его использующая.

Во втором случае мы так же наблюдаем расхождение в битрэйтах. И основательное. Причем если у обычного Дуба с обычным DivX VKI наблюдается отставание от заданного битрэйта, то у остальных - увеличение битрэйта. И как обычно ММ4 по количеству КК опережает всех в 2-2.5 раза, а битрэйт у него увеличивается по сравнению с заданным почти в 2 раза! Какие тут могут быть расчеты - непонятно. Миша Громов со своим калькулятором просто отдыхает - можно спокойно стирать его кальк, т.к. теперь он не расчитает нам ни FM, ни LM... Отсюда и фильмы типа 487 мег на кадэшку... Интересно, что Nandub нашел почти в два раза меньше смен сцен, чем остальные - практически все случаи именно на сменах сцен, а не на изменениях сцены, хотя я с ним не во всех случаях согласился бы, стоило бы и побольше наставить.

Перейдем к качественному показателю - на глаз. Стас в своей статье утверждает, что его алгоритм наиболее совершенен в определении последовательности комбинированного интерлейса. Как мы видим - нет совершенства в этом мире. Во втором эксперименте (не говоря уже о первом), с достаточно легкими условиями для определения, по прежнему остаются расчесанные кадры (в том числе на малоподвижных сценах). А это означает, что мы не имеем никаких преимуществ в сравнении с оригиналом - деинтерлейс все равно придется применять, теряя качество и время. Хотя действительно не наблюдаются двойные кадры. Но! Появился другой интересный баг - время от времени (зависимости пока не нашел) ключевой кадр попадает не на смену сцены, а на следующий после смены сцены кадр! В результате сначала проходит, весь квадратный, кадр сразу после смены сцены, а за ним уже нормальный сглаженный - ключевой. В общем впечатление от патча невеселое, единственное преимущество - нет двойных кадров, хотя на этом же месте появились интерлейсные, совершенно ничего не изменилось в плане подбора последовательности полей для уничтожения расчески, добавлены глюки в определении смены сцены. Стас не оправдал своей рекламы. И это печально.

Как обычно, в стандартном Дубе нашлись "двойные кадры", причем не только на сменах сцен, но и в совершенно обычных, "спокойных" местах (кстати Дуб-ММ4 создал двойные кадры в абсолютно тех же местах). Но как оказалось, это не предел. В оцифровке Нандубом нашлись даже "тройные кадры"! И также не на стыках, а посреди сцены. Возможно если бы в нем заработал инверс телесина, то кадры стали бы "двойными". Хотя эффект пришелся совершенно на другие места, не совпадающие с оригинальным Дубом и ММ4, значит алгоритм как-то был переписан, правда похоже кривыми руками.

Еще один вопрос хотелось бы поднять, на случай, если этот обзор будут читать те люди, которые реально смогут пропатчить Дуб или написать свою прогу, без наворотов, исключительно для оцифровки, с минимумом фильтров и кропом-ресайзом, но с учетом печального опыта предыдущих писателей. Это расческа на стыке сцен, когда клип-фильм клеится именно встык, а не через фэйд. Очень неприятный момент, когда сцена переходит не резко, а через интерлейс - такую последовательность видимо трудно отловить, и почти всегда такие места остаются интерлейсными. На них у обычного VKI чаще всего попадает КК (хоть в NTSC, хоть в PAL-SECAM). Т.к. такой кадр содержит максимум (50%) изменений по сравнению с предыдущим и последующим, то у VKI может идти два-три КК подряд - интерлейсный стык и следующий за ним кадр новой сцены. В результате количество КК и поток (и масса файла) увеличивается. Я думаю стоило бы такие стыки убивать обычным дублированием одного поля (предыдущей или последующей сцены), для уменьшения избыточной информации, но это уже деинтерлейс. На худой конец такие кадры можно вообще убивать, т.к. информации в них - минимум. Причем речь идет не о фэйдах (плавных переходах между сценами или затемнением-засветлением), а именно о резких переходах, попадающих двумя полями из разных сцен на один кадр. Писатели, попробуйте разработать алгоритм для таких случаев, конечно как частный случай telecine, с которым пока так и не справились.

Выводы.

1. Дуб как был, так и остается наиболее корректным продуктом с поддержкой iVTC. Что однако не оправдывает глюков при работе с ним. "Наиболее" != "исключительно".
2. В любом случае, абсолютно корректной работы с iVTC мы не получили и применяя iVTC для уменьшения количества кадров, а с ним и массы файла, все равно придется применять деинтерлейс для сглаживания остающихся расчесок.
3. Применять патч от Стаса можно тем, кто часто получает эффект "двойного кадра", видимо на очень быстрых сценах. Но с условием, что Стас все таки доработает свой алгоритм по поводу попадания ключевого кадра на второй кадр после смены сцены. Еще одно мелкое замечание - в меню Frame rate почему-то не входят до конца строки "Reconstruct from...", причем обрезаются на последней букве все эти четыре строки. И желательно как-нибудь обозначить версию патча, дабы легче было отследить последующие изменения.
4. Nandub (18b) глючит при применении iVTC. Посмотрим на следующие версии. Пока его применять для этих целей нельзя. Даже без применения iVTC в нем проявляется эффект аж "тройного кадра" - изображение замораживается на три кадра, а потом "прыгает" сразу на четвертый (этого эффекта во фреймсерверном оригинале и в других Дубах не было). Эту версию Дуба стоит рассмотреть более детально - можно ли им вообще пользоваться без потери качества.


(c) июнь 2001, Сибирский Лихоман http://mydivx.lihoman.ru
Следующая статья раздела
Возврат на список статей