VKI patch для DivX 3.1a. Точность и практическое применение.

Насколько точен patch VKI?

VKI - Virtual (а правильнее Variable) Keyframe Interval, или иначе "Scene Detect Patch" предназначен для автоматического определения разницы между KF(I) и DF(P), и замены DF на KF, при превышении порогового значения (превышении массы DF над массой KF, поставленного в том же месте). Проще говоря, кодек при вставке очередного дельта кадра (DF) проверяет, сколько весил бы в этом месте ключевой кадр (KF), и если KF весит меньше, то кодек заменяет в данном месте дельта кадр на ключевой.

Некоторые кодеры считают, что VKI одинаково справляется со своими задачами в обоих типах кодека и KF попадают всегда на одно и то же место, вне зависимости от внешних причин (динамичности фильма, типа кодека, заданных в кодеке битрэйта и сглаживаемости), кроме конечно же заданного в кодеке расстояния между KF в секундах (естесственно при заданном значении 1, KF будут расположены более часто, чем при 9999, когда KF должны попадать только на смену сцен). А значит новую версию можно спокойно продолжать применять для оцифровки фильмов переменным (двойным) битрэйтом (FM-LM или LM-LM).

Теоретически, т.к. кадр при различных условиях сжатия получается разного качества и веса, то VKI может неоднозначно при разных условиях решить, достигнут ли порог, при котором меняется DF на KF. В результате KF могут попасть не на одинаковые кадры и их количество может не совпасть в фильме, сжатом с разными установками кодеков.

Поставим небольшой эксперимент. Возьмем достаточно динамичную, быстроменяющуюся сцену (лучше всего для этого подходят динамичные видеоклипы, т.к. в фильмах любая сцена тянется гораздо дольше, кроме компьютерных, которые слишком дороги и трудоемки, чтобы их тянуть, можно скажем взять какую-нибудь динамичную сцену из "Кролика Роджера") не более 1 минуты. Сожмем ее кодеком LM VKI с установками 300-0-999 (kbit-smooth-KFI) и FM VKI 6000-100-999. Такие крайние значения заданы для усиления разницы в качестве, конечно в реальном кодировании разница меньше, но тогда нам придется брать более длинный кусок. А затем сравним, что нам скажет на каждый из получившихся файлов AVI Info.

Для эксперимента я брал небольшой заданный в Virtual Dub 1.4c фрагмент из клипа YELLO 'Rubberbandman'. Я сжал файлы без аудио, установив кодеки как сказано выше и задав уменьшение размера кадра (resize/precise bicubic) от 720х576 до 384х288. Вот что мне показал AVI Info:

Мы видим, что в потоке FM ключевых кадров в два раза меньше, чем в LM, естесственно отличается и количество DF. Из этого можно сделать вывод, что точность VKI вовсе не гарантирует нам попадание KF в одно и то же место двух фрагментов фильма, пожатых с разными установками (типами кодека), а значит могут появится и рывки (пропадание кадров) и повторение кадров.

Практически, учитывая то увеличение качества, которое дает нам VKI patch, можно конечно не обращать внимания на такие мелочи. Но там, где хотелось бы сохранить идеальное качество без таких, даже мелких огрехов (скажем в интересных видеоклипах), лучше все таки пользоваться одним кодеком с одной установкой, т.е. без двойного битрэйта. Лучше установить побольше битрэйт и не гнаться за экономией места, зато получить качественный фильм. Скажем использовать LM VKI 2400-100-1 для кадра 576х432. Обычно этого достаточно, но при динамичном фильме (клипе) возможно понадобится использование FM VKI 6000-100-1. Все это уже конечно на ваш вкус - подбор установок и определение качества оцифровки обычно идет уже на глаз.

Реальное применение пары с VKI для фильма с VBR.

Как использовать фильмы с переменным интервалом между ключевыми кадрами (VKI)? Есть по крайней мере три основные программы для создания VBR (Variable Bit Rate) фильмов (с переменным битрэйтом) из двух. Это Make Film TNG, Project DivX, AVI Revolution. Virtual Dub MM4 здесь не рассматривается, т.к. делает VBR фильм из одного исходника (при этом мы не можем предугадать или повлиять на конечный размер файла).

Даже при одном лишнем KF, Make Film просто скажет вам "AVI's has different keyframe distances" и откажется создавать выходной фильм.

Project DivX на первый взгляд создает вполне нормальный фильм. Я попробовал подсунуть ему два экстремальных фильма в 30 сек. (LM VKI 300-0-999 и FM VKI 6000-100-999), отличающихся количеством KF в два раза (148 и 79 соответственно). В результате получился фильм с интересным количеством KF - 87! Насколько я знаю, Прожект берет для анализа ключевые кадры из своего Fast окна, т.е. ключевых кадров получилось больше, чем он сам их мог проанализировать. Откуда же взялись лишние KF? Продолжая эксперимент, я поменял местами фильмы и загрузил LM в Fast окно, FM в Low. Т.е. количество KF для анализа у него теперь стало 148. Результатом стал фильм, ужасный по качеству, но со 146 KF внутри. Можно просмотреть покадрово результирующие фильмы и найти, где он ставит LM, а где FM - их несложно отличить при экстремальном кодировании, но я пока поленился это делать, т.к. вывел теоретическую причину таких различий в количестве KF. Когда в правом, анализирующем, окне KF меньше, а в результирующем фильме их больше, то это не значит, что он их откуда-то взял или переделал DF в KF. Просто он, сравнивая фильмы по редким KF правого окна и пропуская частые KF левого, вставил целиком лучшие по его мнению левые (Low) куски вместе с лишними KF, даже не подозревая об их существовании. Аналогично и исчезли несколько KF - вставился кусок из FM, у которого внутри не было пары KF.

Отсюда вывод. Кодируя LM на низких битрэйтах с VKI (SDP) мы провоцируем кодек ставить KF чаще, чем при кодировании с FM VKI на более высоких битрэйтах, для увеличения качества фильма - более плавного сдвига кадра, без проявления артефактов. Скажу больше - есть прямая зависимость частоты наставления KF от динамичности сцены у обоих кодеров. Причем FM VKI не считает сменой сцены скажем сдвиг на пару точек (он для этих сдвигов оптимизирован), а вот LM VKI уже может и посчитать это сменой сцены. Использовать часто наставленные и не совпадающие с FM фильмом KF мы не имеем возможности - порезать в этом месте фильм нельзя ни автоматически, ни вручную, т.к. Прожект не перекодирует фильм, а только режет его по KF и если во втором фильме в этом месте стоит DF, то соответственно и порезать в этом месте мы не можем. Следовательно, в случае, если мы сами, или Прожект автоматически, занесет этот кусок целиком в таблицу, то кусок повлияет положительно на презентабельность фильма, но если пара кадров из этого куска покажется программе или нам не очень хорошими, то пропадет весь кусок с лишними KF - его придется заменить на аналогичный из FM. Хотя в принципе весь проект от разницы в количестве ключевых кадров при работе в Project DivX, в отличие от Make Film TNG, не страдает.



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