Замена выпавших кадров (drop'ов) и SVP (Page 4 of 11)

спасибо, ребята, что ответили, искренне; и так быстро - спасибо.

a. это показатель нормально по свп-тесту - 0.68, на быстром профиле по тесту у меня индекс 0.95. причем здесь настройки свп? мне не нужен баланс производительность-качество, это для просмотра и прочих развлечений. свп на мой взгляд качественнее mvtools2 повышает плавность, хотя на сборке mvtools2 от свп я еще не проверял. я свп хочу использовать для кодирования плохого видео с разных фотоаппаратов и вебкамер в какой-то единый стандарт выхлопа, и я остановился на 30 кадрах в секунду.

b. судя по всему, дропов у меня достаточно, видел в ависинте как ваш скрипт подписывает в прав. нижн. углу ту замену, что он сделал. забавно даже. а при обычном просмотре не заметно. я раньше думал, что это вина подвешенной линзы в объективах (та что против дрожания рук), она при съёмке видео с проводкой весьма заметно дергает кадр, но сейчас думаю что эти дропы могут быть вызваны например заполнением буфера, слабым процессором фотоаппарата, или тормозной флешкой... однако есть сомнение: а если фотик все-таки снял без тормозов, и это реальность такая дерганная была перед сенсором, тут сложно полагаться на визуальный просмотр, нужен более академический взгляд, с твердыми критериями, программно определяемыми, не субъективно то есть.

c. по делу.

это ваш скрипт. я писал в начале

- я уже с неделю как погряз в этом вопросе... мне, в основном приходится иметь дело с HD файлами, и из-за слабого компа мне хочется по-меньше кодировать, и по этому я стараюсь выкручиваться как получается...
я пользуюсь MeGUI 2418 (начинал с хелпов на рутрекере) - замечательная прога для x264 - все работает. но как подгружаешь все эти фильтры и библиотеки в ависинт, начинается пляска с бубном... я не против поплясать, но к сожалению она совсем не работает с ависинт 2.5 (я перепробовал несколько вариантов ависинта, в том числе и ваш мод свп), а вот сам свп с ависинт 2.6 MT c doom9 - работает.
при 2.5.8МТ (СВП) ависинте, не работает... и ведь только это сообщение в кадре... или, может ли вся функция в скрипте из-за этого не выполняться? может, это не так уж сложно, исправить скрипт - что бы 26МТ не выдавал на экран сообщения о незнакомой переменной?
вот что пишет мегуи в логе:

[10.04.2014 10:19:51] [avisynth @ 0003b7e0] Video input from AviSynth 2.5.8 is not supported. Please upgrade to 2.6.

мои скрипты во вложении, правда они уже переписаны под 2.6 (из всех них только поиск дропов - с надписью на экране о неизвестной переменной), а остальные работают отлично. я ваш алгоритм не менял. я очень аккуратно отношусь к коду, которым надо пользоваться, но который в значительно степени не понимаю. все изменения вокруг да около, вы и сами заметите. я там постарался сделать как-то управляемый скрипт, может вы по организации тоже что-нибудь подскажете? винда 7 64, в сисВОВ - ависинт 258 от свп. Мегуи пользуется своим, у нее автоапдейт и слежение за версиями. для ваших скриптов с doom9 скачан 26МТ и только у ависинта мегуя заменена dll. у меня есть 4 версии этой библиотеки, я все перепробовал, последняя бета с doom9 лучше. последний стэйбл имеет те же проблемы, здесь везде разговор про версии МТ. на буржуйских форумах по 25 МТ очень хвалят 26МТ говорят много ошибок уже исправили в 26МТ. масктулс у меня masktools-v2.0a48 - распоследняя альфа, ибо на doom9 писали о глюках с ависинтом МТ до сих пор не поправленных; DSS2 версии 2.0.0.10; проц атлон Х2 64 3800+ 2 гб. из-за этого снижен MemoryMax в скрипте с 1024 как у вас до 512, (я пробовал и 768 и 1024, просто при 512 у меня еще и фаерфокс в памяти помещается), если это недопустимо - скажите;

d.

вы же сами писали:
http://www.svp-team.com/forum/viewtopic … 792#p24792

всё делаю по вашим советам.

e. насколько я понимаю, утверждение о том, что "настройки свп - это личное дело каждого" исходит из многообразия систем и цели свп - показывать. качеством тут легко жертвуют ради производительности. но сам алгоритм - великолепен! я уже убедился в этом. я бы хотел использовать его как фильтр при кодировании видео (не кино), когда источник не достаточно хорош, свп - выруливает. посему вопрос:
существует ли какой-то законченный набор настроек свп, с целью достигать качества, в ущерб скорости?
и пусть управление опциями остается ависинту, ведь для кодирования достаточно ядра свп.
будет ли отличаться скрипт, созданный из меню свп, в зависимости от размера конечного видео, ведь если у меня монитор не 1920, а видео как раз такое - возникает вопрос, а можно ли напрячь свп по-круче, по-точнее, не смотря на маленький монитор, и оставить все это на ночь вертеться?
я здесь где-то встречал высказывание "что задвинуть все ползунки на максимум, не значит получить наивысшее качество", а как тогда быть если я не могу это увидеть, но могу это закодировать, нужно какое-то управление, но без гуй-ное. можно же написать несколько разных скриптовых функций по типу профилей 264, ссылающихся на корневую функцию, как это сделано при автоматическом создании скрипта самим свп - в начале набор параметров, потом универсальная функция, шаблонно их выполняющая. несколько разных наборов параметров, с заточенностью под качество в ущерб скорости в качестве первого, несколько промежуточных вариантов, и заканчивая фастом, как это сделано для 264. вот тогда по этим примерам, можно будет уже изучать как они отличаются друг от друга, по хелпам каждой функции - чем я жертвую, что бы не кодировать 2 дня, а всего один. хотелось бы не субъективные критерии, а как-то более инженерно по реальным критериям. а пока обучение доступно в основном людям с опытом программирования, у кого еще хватит терпения и разума изучать переменные и функции "языка" ависинта, да еще и не только базовые, ведь свп довольно узко заточена - поднятие частоты кадров. изучать очень много. еще актуален вопрос понижения частоты кадров, возможны ли интелектульные алгоритмы, способные сохранить зрительное восприятие при уменьшении частоты? алгоритмы свп могли бы пригодиться?

может я просто не опытен, может подобное уже существует? я очень рад, что могу обратиться и мне ответит разработчик свп, мне немного неловко вас напрягать, я бы выслал вам видеофайл, если вы позволите, но у меня таких много, мне бы самому научиться разбираться, мне достаточно подсказки или пары скриптов для кодирования типа верислоу, слоу и нормал, а фаст в общем-то и не нужен. и определится автоскрипт свп - он к какой из этих категорий принадлежит?

ой, как многа букав... еще раз спасибо вам, MAG79 и участники - очень полезненькая ветка.

спасибо, вы очень отзывчивый человек.

https://drive.google.com/file/d/0B4MWe7 … sp=sharing
пароль на архив: svp-team
вот мои теперешние скрипты: я разделил обработку на 2 части, одну под 25 ависинт, другую под 26. в имеющихся логах MeGIU можно посмотреть что как кодировалось, хотя промежуточные файлы я потер. в папке __33.av2526\ лежат батники для оперативной замены ависинта, исходный файл (MJPEG, YUY2 4:2:2p, 20fps), и скрипты, скорректированные под ависинт 25. в папке \ лежат скрипты постобработки, для них нужен файл с первого этапа __44.avi (YV12 4:2:0p). также там лежит mkv (конечный результат), что бы вы могли посмотреть, что у меня получилось сразу.
так сделано, потому что, многие мои плагины и запланированные скрипты требуют очень нового ависинта, местами ависинта+. на данный момент, главное для меня различие между 25 и 26 - расширенные возможности работы с цветовыми пространствами, да и многие скрипты с плагинами для OpenCL вычислений поддерживают интерфейс 25 только для совместимости, являясь полноценно плагинами 26 ависинта (ведь используются новейшие версии зависимых плагинов). в моих условиях это важно. поэтому попрошу:

1. могли бы вы сделать, что бы GameDropFix_v4, внутренне заработал в RGB?

корректная работа с цветными составляющими потока, как я уже убедился, делает картинку резче заметно, хоть и не на много. не хотелось бы терять на апроксимации подробность цветовых отсчетов. я пробовал ваш скрипт запустить в 26МТ поменяв в нем в 2 строках ConvertToYV12 на ConvertToYV16 (4:2:2), подав на ему вход соответственно YV16, открывая файл в RGB и конвертируя его в 4:2:2 (в новых конверторах 26МТ есть ресайзеры хромы)
DSS2(sfile, fps=20, pixel_type="RGB32", lavd="l0 r2 ti1")
ConvertToYV16(matrix="PC.601", chromaresample="spline64")

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

а при ConvertToYV12(matrix="PC.601", chromaresample="spline64") получалась просто более резкая картинка. к сожаленю, ResampleHQ:
ResampleHQ(dstcolorspace="YV12",srcmatrix="PC.601",dstmatrix="TV.709",dither=true,kernel="Spline64",chroma_kernel="Spline64")
хоть и обладает другими достоинствами, и ресайзерами, (является плагином 25, и разработка новых цветовых пространств только планируется) - не столь резок по хроме (нужна ярко красная нитка в видео, тут есть на воротнике красный бордюрчик), как мне показалось.

есть еще второстепенные проблемы:
2. в конце клипа появляется лишние примерно 200 кадров (1400-1690). в исходном этого нет
3. подскажите пожалуйста на примере, как корректно убрать вывод названия коррекции кадра (надпись справа внизу, типа -fx33)
4. в MVtools2 от SVP при желании работать с GPU, нужно вписывать в переменную путь к gpu.dll. а в скриптах SVP этого не нужно? она сама подхватывается?
5. мне показалось, что срабатываний GDF4 слишком много, хотелось бы услышать и ваше мнение, действительно ли столько дропов?
(ведь тогда надо советовать купить более быструю карту памяти, прошивку фотика обновлять и прочее, что затратно и обычно не делается...)

файл: https://drive.google.com/file/d/0B4MWe7 … sp=sharing
прошедший все фильтры, с тех времен, когда я еще не разделил обработку на 2 этапа. на нем видны ошибки, 200 лишних кадров и надпись скрипта о переменной.

спасибо еще раз, искренне, и от всей души. успехов вам!

1. не совсем понятно; верно ли, что при конвертации форматов 4:4:4, 4:2:2 в 4:2:0 усреднение хромы настолько незначительно, что нет смысла стремится сохранить исходную раскладку, например 4:2:2 в результате после кодирования? многие плагины работают в RGB внутренне; я понимаю, что СВП "показывательный" плагин ависинта, но в контексте кодирования, по вашему, на подобные усреднения можно не обращать внимание? я спрашиваю не про сам RGB, а про "является ли конвертация вниз упрощением информации, и насколько много при этом теряется" если вы знаете, прикиньте в процентах пожалуйста, различие между исходным 422 и результирующим (422->420->422); эта цифра упростит мои сомнения и избавит от напрасного рытья интернета.

2. верно ли, что для разных исходников нужен разный виртуалдаб?
2.1. это точно исходный файл. необязательно писать видео на флешку, и в том числе, не обязательно алгоритмами прошивки. существуют способы захвата видео с матрицы при поднятом зеркале, подобными программами через usb, hdmi, хоть и не для всех моделей, но для многих. например для контроля или записи на ноутбуке на большом экране, хотя это уже ближе к хакингу; есть также флешки-вай-фай; и в usb можно воткнуть блутуф, и прочее радио со всеми удобствами и недостатками. ExtraWebcam - это собственно сам рипер. вы можете писать видео или складывать фотки не (или не только) на флешку, но и на винт ноутбука в рюкзаке, за спиной или в укромном месте; так у вас останутся фотки, если вас заставят отформатировать флешку в угрюмой ситуации... но в такой длинной цепочке тормоза могут быть где угодно, что не отменяет всех удобств.
это конкретно видео снято фотиком Canon EOS-450D, (12мп) матрица которого сканируется прошивкой 20 раз в секунду. видео вполне годное для dvd, и весьма резкое, а то, что вы называете потерей фокуса, в фотографии и профессиональном видео называется "боке" - весьма значительная характеристика объектива (затем и снимают видео фотиками, потому что объективов великолепных и доступных - множество). в этом видео есть все примитивы при сьемке фотоаппаратом: проводка, скольжение, наезд, наезд из не-фокуса, длинный зум, который трудно удержать в руках, эффект линзы коррекции дрожания рук; все очень наглядно продемонстрировано. когда эти поведенческие примитивы все вовремя, человек получит удовольствие от созерцания - оскара за операторскую работу не даром дают, это нелегко.

5.1. не совсем понятна ваша эмоция; 14% - это много или мало?
5.2. как вы смотрите покадрово? у меня в mpc-hc при постановке в паузу картинка прыгает гораздо дальше чем покадрово. это можно включить?
5.3. скачки это проблема, желающая исправления... если вы можете уделить толику времени, прошу вас; это при съемке, скорее всего, будет повторятся неизбежно, и всегда будет требовать пост коррекции.
5.4. стабилизация и фокус зависят от прямоты рук фотографа, штатива и прочих принадлежностей. здесь просто показательный кусок, но снятый нашару.
просто до плагинов по стабилизации еще не дошло мое погружение в ависинт.
5.5. роллинг-шаттер - штука, как я понимаю, не исправимая? плохо предсказуемая в пост анализе, или все же существуют алгоритмы?
возможно, один из mkv, тот что с ошибкой, после уплавнения до 60 был еще раз уплавнен до 30 ConvertFPS()-ом; я перепробовал много способов получить 30 фпс, кажется ConvertFPS не выкидывает кадры, а пытается их не-выкинуть и т.д. он давал сильные наклоны вертикальных линий. в исходном клипе вы это искажение заметили? просто фотик криво держали; не знаю, знакомы ли вы с обычными искажениями фотообъективов, в этом видна "подушка", чем ближе к краю на серединной горизонтали, тем сильнее изгибаются вертикали наружу, в вертикальном смысле тоже самое; может быть и обратный эффект - вогнутость краев. это форма оптического исправления не-плоской поверхности изображения в сложных зумах и сильно широких объективах. напротив, при съемке на сильном зуме куба, его задняя часть будет больше передней, что очень неестественно выглядит. здесь больше похоже на подушку, чем на роллинг-шаттер.
даже после моего комментария вы останетесь при своем мнении - здесь роллинг-шаттер, и его надо исправлять?
5.6. наличие прелестей - это же идеальный вариант для тестирования ремонт-алгоритмов?

6. ваши вопросы. ситуация, (не для узкого профессионала, для обывателя), возможно необычна, но удобство огромное, о котором мало знают, из-за кривых рук и нежелания погружаться в нестандартные способы решений давно привычных проблем; если возможно, чуть позже я вам вышлю запись с Canon 5D Mark II, 1920p, записано родной прошивкой на флешку, но в некоторых местах видны неожиданные для него проблемы, хотелось бы знать что это такое с ним.
6.1. съемка велась фотоаппаратом полу-профессионального класса Canon EOS-450D, через usb подключение к риперу ExtraWebcam в MJPEG avi. у вас оригинал. возможно, прошивка фотоаппарата при таком освещении не могла давать более короткие выдержки, чем 1/20 секунды (на видео заметно как прыгает яркость), возможно 20 фпс - это аппаратный предел этого фотика, (я уверен, что когда я это снимал, я выставил на максимум все возможные параметры качества, мне нужно было взять с него все, что он может).

7. мне стоит по-короче выражаться? или этот форум позволяет так? просто при общении по реплике раз в несколько дней, хочется развернуто ответить, чтобы минимизировать второстепенные вопросы.

спасибо вам. я посмотрю по вашим подсказкам видео с Марка2, и отпишусь здесь. еще раз спасибо! Удачи вам.

О каком качестве вообще можно говорить, если программа для другого? Что за извращения? Сам автор про нее пишет что:

ТОЧКА. Тема закрыта. Хотите качества пишите на хорошую флешку. Не надо жрать кактусы.

Забудем про роллинг-шаттер. Тут не он главное препятствие.

Вот проводка камерой с 41-го по 150-ый кадр.

Показано горизонтальное смещение картинки в пикселах в каждом кадре. Видно, что есть скачки, длиннее в два раза, чем остальные, есть даже скачок трехкратной длины (кадр 133).

Статистика по данному отрывку видео:
кадров-дублей (нулевое смещение): 13
скачков (двукратных): 22
скачков (трехкратных): 1

Алгоритм исправления:
- выкинуть кадры-дубли
- найти кадры-скачки со смещением, явно большим чем остальные (двухкратным и более)
- вставить перед ними интерполированный кадр (либо два интерполированных, если скачок трехкратный)
- что-то придумать со съехавшей синхронизацией со звуком, т.к. видеодорожка изменится по длительности нелинейно

Если приводить к идеально-плавному движению, то из 110 кадров нужно удалить 13 дублей, добавить новых интерполированных кадров 22+2=24, получим 110-13+24 = 121 кадр. Если сохранять длительность, то частоту кадров придется поднять с 20 до 22 к/сек. Но это только на данном куске видео.

LaleksUi

кажется, для удаления дублей можно использовать готовый плагин
Дубли=выпавшие кадры. Тут вся тема про это. Можно использовать

картинку, что я вижу, (в меру моего понимания) - разве (авто) скрипт SVP не тоже самое делает?
Нет. Совсем не то же самое. Общее только одно слово "интерполяция"

синхронизация со звуком сама получается, или нет?
В том и дело, что повышение плавности скриптами SVP заботится о синхронизации со звуком. Это достигается тем, что положение всех объектов в кадре остаются строго на том же месте, что и в исходнике. Рассчитываются лишь промежуточные положения, но они не сдвигают исходные кадры. Поэтому картинка становится плавней БЕЗ ускорений и замедлений видеоряда.

Нарисованная анимация лечения скачков не отвечает этим требованиям. Исходные кадры свободно гуляют по оси времени вперед-назад из-за нерегулярности расположения дублей и скачков в видео.

GDFv4, потом SVP до 60 кадров, потом ChangeFPS()-ом до 30 кадров/сек...
если посмотреть его, картинка его кадров будет похожа на этот красивый GIF в последней фазе?
Даже не смотря скажу: нет, не похожа. И приведенные скрипты в этой ветке и ChangeFPS так же, как и SVP-скрипты, не сдвигают исходные кадры со своих мест.

Вам сохранение звука важно для записей с EOS 450D через ExtraWebcam? Если да, то приведенный алгоритм Вам не подходит. Тогда в угоду сохранения синхронизации со звуком придется приносить в жертву плавность. А впредь либо не пользоваться ExtraWebcam, либо установить в ней частоту кадров много выше 20 fps, чтобы исключить скачки. Предлагаю 50 или лучше 60 fps. Дропы в таких записях вылечатся намного проще, например, скриптом  GameDropFix_v4.

Помоему, раз вам так хочется хорошего видео, уж лучше на камеру поставить Magic Lantern. Вот там точно все будет отличнейше. Другу на ЕОС600Д ставил, впечатлил HDR эффект при съемке видео, это чтото......

это все замечательно, спасибо;
но я бы хотел спросить по алгоритму: MAG79, если для звука так нужно "не сдвигать исходные кадры", что мешает не [удалять дубли сдвигая исходные кадры], а [удалять дубли, заменяя их интерполяцией, оставляя исходные кадры на своих местах]. это возможно?

например, что мешает превратить дубль в дроп, и прогнать по GDFv4-му алгоритму снова?
ведь происхождение дублей (виртуально) очень сходно с происхождением дропов без скачков;
это незначительно увеличит сложность скрипта, ведь достаточно в блоке поиска добавить критерий нахождения дублей, который будет реагировать на них как на дропы. или я что-то недопонимаю?

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

а что если (после GameDropFix_v4) для кадра n, который скачок, заменить n-1 и n+1 кадры на интерполированные от n-2 до n и от n до n+2 соответственно?
например, скажем специально, что n-1 и n+1 кадры - это дропы, и вставим на их место интерполяцию?

или вот так (точнее): a= i(n-1,n); n-2= i(n-2,a) ; n-1=i(a,n), где а - временная переменная, i - интерполированный кадр.

или так n-1=  i(  i(n-2,а) , a ) - медленный рост (n-1 получится ближе к n-2), вершина будет более острой;
иначе - сначала быстрый рост, пологая вершина - n-1= i(n-1,n) - n-1 получается ближе к n.
справа от n - подобно.

я не мастер рисовать графики в фотошоп, но тут всего 2 кадра вокруг скачка, и по 1 кадру снаружи (всего 5)

или все таки качественнее будет пойти по пути малого увеличения частоты кадров?

вот вы говорите что SVP делает не так, но ведь при уплавнении с 20 до 60 SVP за каждым кадром добавит еще 2 интерполированных: n-1, i1, I2, N, I3, i4, n+1.
потом я ConvertFPS-ом выброшу каждый 2 кадр и получу 30 fps: n-1, I2, I3, n+1. и со звуком все в порядке.

что скажете?

перечитал сейчас 4-ю страницу ветки. какое-то общее впечатление складывается, что вы мягко, ненавязчиво, так нежно-нежно транслируете мне "да не занимайтесь вы этим, это трудно преодолимо, а ваших условиях вообще, обойдите проблему, жизнь продолжается, просто не попадайте в такие условия... и т.п." чтож, соглашусь с вами. гораздо полезнее поизучать множество других плагинов ависинта, хороших и нужных... а достигнутый результат по сравнению с исходником уже и так замечателен... у меня только последнее сомнение осталось:
эти скачки, это же обыкновенные пре-дропы, которые оказались не записанными в видео поток, и может, заголовок файла правильный, и 200 с лишним пустых кадров, это и есть они, может видео-дорожка сейчас короче аудио-дорожки, и в видео как раз надо повставлять эти отсутствующие дропы из этого кредита в 200 кадров, и синхронизация как раз восстановится? ведь при просмотре оригинального MJPEG в плеере, их в конце нет, а после вывода через ависинт они появляются как-будто бы в конце. почему так? кстати, микрофон использовался компьютера, на 450D микрофона нет. как бы не глючила передача данных видео, ExtraWebCam писала аудио с другого апп. устройства, и из того, что ориг. видео в плеере со всеми его скачками и и дропами звучит синхронно, вытекает что ависинт не точно открывает видео, возможно, не считываются какие-то задержки или растяжки - в плеере-то видео скачет, и благодаря скачкам аудио на своем месте, ведь так?

может напишете мне патч для вашего скрипта, там же всего пара-тройка строк, это же замена типа "дроп, затем скачек", а она у вас уже реализована, надо лишь добавить анализ длины скачка, на 1 дроп, или 2. и проверку на оставшийся "кредит" из лишних кадров. и пусть видео растянется, а я бы это все проверил. нет возможности переснять. и 450-го уже давно нет, и кэнон с никоном не мои, и проц у меня не и5, а амд х2 2.1 ггц. я с ависинтом знаком 2-ю неделю.
как бы вы не ответили, я вам благодарен. мое видео станет намного лучше, благодаря вам, пусть и не все ошибки исправлены. спасибо за всё. Удачи вам!

LaleksUi
может видео-дорожка сейчас короче аудио-дорожки
Нет. Они очень близки по длительности. См. скриншоты.

ависинт не точно открывает видео
В данном случае точно так же, как и плеер. Причина в некорректном заголовке в этом файле. Уже разбиралось выше. Пошли по второму кругу?

возможно, не считываются какие-то задержки или растяжки
Во-о-от! Их нет в файле и не должно быть в видео. Их не предусматривает видео с постоянной частотой кадров. Т.к. видео отображается на мониторах с постоянной частотой обновления экрана.

нет возможности переснять. и 450-го уже давно нет
приходится время от времени склеивать видео с разных фотоаппаратов... приходится поднимать фпс
Тогда предлагаю такое решение: сразу поднять частоту кадров записям с 20 до 30 к/сек, расставив в записи РАВНОМЕРНЫЕ дропы по одному через каждые два кадра. А потом просто воспользоваться скриптом GameDropFix_v4. Это даст сокращение числа перекодировок, сократит время обработки, и оставит больше исходных кадров в видео. При таком расположении дропов у любого скачка окажется дроп либо слева либо справа от него и этот скачок будет корректно сглажен. Ну а места без скачков будут просто проинтерполированы, как это сделал бы SVP при повышении частоты кадров с 20 до 30 к/сек.

Для этого надо взять скрипт GameDropFix_v4 и добавить строчку

после строки SetMTMode(2)

Для ускорения работы скрипта можно еще и GPU задействовать. gpu:0 заменить на gpu:1. Мне это кроме всего прочего позволило избежать вылетов скрипта на видео с EOS 450D в районе 30-го кадра.