SVP не работает, помогите разобраться

1. Что возвращает запуск windows-скрипта SVPMgr.wsf из папки SVP?
2. Работал ли пакет SVP на этом компьютере раньше?

dranduletov, открыть папку с SVP, два раза щёлкнуть по файлу SVPMgr.wsf, при появившемся окне ошибки нажать CTRL+C, сюда вставить и отправить.

На свежей, нетвиканутой WinXP SWP тоже капризничает, ошибки другие. При открытии видео значек SVP делает один кувырок и MPC-HC выкидывает:
"MPC-HC - Mini Dump
---------------------------
Работа MPC-HC прервана. Чтобы помочь нам в решении этой проблемы, пожалуйста, отправьте файл
'C:\Documents and Settings\Admin\Application Data\MPC-HC\mpc-hc.exe.1.7.3.dmp' на наш баг-трекер.
Хотите ли вы сейчас открыть папку, содержащую дамп-файл, и перейти на баг-трекер?
---------------------------
Да   Нет"

Выполнение SVPMgr.wsf выдает ошибку:
Windows Script Host
---------------------------
Сценарий:    C:\Program Files\SVP\SVPMgr.wsf
Строка:    97
Символ:    3
Ошибка:    Путь не найден
Код:    800A004C
Источник:     Ошибка выполнения Microsoft JScript
---------------------------
ОК   

До кучи прицепил:
скрипт последнего запуска ffdshow.avs
журнал последнего запуска Log.txt
доп. инфорормация debuginfo.txt

Подскажите, как лечить?

Починилось. Заменил svpflow_cpu.dll, взял тут http://www.svp-team.com/forum/viewtopic.php?id=902
Chainik, спасибо!
Больше ничего не делал.
Не так уж и ресурсоемок этот SVP.
Попробую им на три, до 75fps множить.

Chainik
Мне не на чем смотреть 4K. Наверное не созрею для этого. Не испытываю никакой потребности в четкости 4K.
Для меня 720р вполне комфортно. С расстояния 3-4 метра на 40 дюймовой панели почти не отличаю 720р от 1080р.
В движении по крайней мере. Ну а если чертеж какой, в тонких линиях, да еще с биноклем, то разницу конечно видно. Только это статичная картинка, один кадр. Никакие мощности для ее отображения не требуются.
Вот глубина цвета в видео явно недостаточна. Плавные цветовые градиенты часто передаются грубыми и ступенчатыми. Их бы еще интерполировать. И 24-25 кадров в секунду невозможно смотреть на 40 дюймах. Я физически не могу воспринимать это слайд шоу.
Это даже не "истиное кино", как его называют поклонники обтюратора, а издевательство над глазами. Тут интерполяторы нужны без сомнения.
Только работают они, по моему мнению не рационально. Наверное во всех схемах промежуточные каждры расчитываются после декодирования. Т. е. декодер дает два кадра, интерполятор на основании этих двух выстраивает промежуточные. Это мартышкин труд и лишние вычисления. Надо заново дробить картинку на блоки, просчитывать вектора движения.
Декодер на этапе декодирования может настрогать сколько угодно промежуточных кадров. При декодировании всегда  есть предыдущий кадр и есть вектора изменений. На соновании этих данных можно построить конечный кадр, если использовать всю величину векторов, либо промежуточные, используя долю от модуля векторов. По моему так.
Вот только влезть в кодек я не смогу, так как нифига не программист.

SVP хорошо работает. Даже с дробными множителями дрожания нет. C профилем по умолчанию качественней, чем Splash на максимуме.
Респект разрабам.
Chainik, а как? Что может мешать декодеру, в дополнении к основному результату, на основании всех данных для его вычисления выдать еще и промежуточные? Только то, что разработчики этого не заложили.
Вот, например декодер играет в шахматы. Текущая позиция - ранее просчитанный кадр. Для построения следующего в потоке есть инструкция, вектор - переместить ферзя по диагонали, на 7 клеток. Направление - по диагонали. Величина - 7. Несложно получить промежуточные кадры, используя уже существующий вектор и доли от его модуля.
Но на практике эту партию разбирает еще один учасник - интерполятор. Берет две позиции, дробит доску уже на другие, свои клетки, ищет закономерности, выдумывает, какая фигура куда уехала, расчитывает новые, свои вектора и по ним рисует промежутки. Ну явный избыток вычислений. 

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

MAG79, интерполятор не учавствовал ни при кодировании ни при съемке. Поэтому никакого дополнительного, заточенного под себя кода в поток не вносил. Вернутся в прошлое и выудить от туда информацию для промежуточных кадров он тоже не может. Поэтому, интерполятор оперирует информацией ТОЛЬКО от декодера и ниоткуда больше.
  В самом простом и применимом на практике случае, интерполятор использует лишь два соседних кадра от декодера. Все полученные промежуточные кадры могут быть результатом лишь линейной интерполяции. Ничего точнее получено быть не может. (Через две точки можно провести только прямой отрезок, промежуточные значения - только точки на этом отрезке. Кусочно-линейная апроксимация). Это с успехом может выполнить сам декодер, на основании существующей  информации, и по штатным алгоритмам, т. е. без существенного усложнения.
  Аанализируя ряд кадров (3, 4, больше нет смысла), уже можно восстановить траекторию движения (кривую). На этой кривой можно брать уточненные вектора и строить промежуточные кадры,  более точно отражающие состояния картинки в межкадровом интервале.
Но вся эта информация опять же - только от декодера и ниоткуда больше. Нет никаких технических препятствий для выполнения и этих, якобы хитрых и неспецифичных расчетов в самом декодере. Эти причины скорее организационно-консерваторные.
Я не против самостоятельных интерполяторов. Часто пользуюсь ими при просмотре контента с низким fps. Tелек прекрасно принимает 24-60 по HDMI, и делает из них приятные 48-120. Тут этапы декодирования и постобработки физически разделены и никуда не денешся. Эфирные каналы вещания - тоже узкое место. Не передают пока контента с высоким fps, а может и нет смысла, если его можно восстановить. Старые, черно-белые фильмы времен Чаплина очень натурально выглядывают после повышения fps. Исходный в них совсем низкий, 12 по моему.
  Я против неоптимального кода, избыточных, часто аналогичных  вычислений и нерационального использования ресурсов.
Многие вещи, для работы которых изначально требовался суперкомпьютер, в конечном итоге комбинируются, сокращаются и оптимизируется, и выполняется примитивным процессором, а часто микроконтроллером на борту какого нибудь копеечного девайса. Примеров полно. Везде натыканы аппаратные кодеры и декодеры H.264. Готовятся к выпуску Н.265.
Было бы неплохо, что бы новые кодеки умели повышать fps. Вот я за что.