Search options

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

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

RAM - 2047 Мб
CPU - Intel Pentium4,3200, x86, MMX, SSE, SSE2, SSE3 (2 логических ядра)
mpc-hc - комплектный с SVP.
"Железо" хилое, не спорю. Но даже оно крутит HDR c загрузкой всего 3-8%. Спокойно, без рассинхрона и пропуска кадров крутит FHD без серьёзной постобработки.
Дело наверное не в железе, если ошибка при выполнении SVPMgr.wsf без видеоматериала и какой либо загрузки вообще.
Скажите, выполнения каких "хитрых" команд требует SVP от железа? SSE999+? Или SUPER MEGA PUPER 8DNow?
Или SVP вообще ничего не требует, поскольку никакого медийного кода не выполняет, а только организует работу стандартных библиотеки и лишь пишет для них скрипт?
Если я не прав и SVP лично генерит кадры, то пусть спотыкается, пытается, вылетает. Но он даже не может организовать и пропустить поток через SVPflow.
Последние Splash Pro EX и Daum PotPlayer работают. Как то умудряются поднимать фпс в 2 и 2.5 раза без танцев с бубном и патченных библиотек.
Хочется сравнить аппаратный "TruMotion" на LG (лучшего интерполятора я не встречал) и SVP.
Попробую старые версии, спасибо.

Свежеустановленная и даже твиканутая. В любом случае - спасибо.

У меня в системе расширение wsf ни с чем не ассоциировано, двойной тык по SVPMgr.wsf резонно приводит к появлению окна выбора программы. Странно всё это. Установка SVP никак не связывает *.wsf хотя использует эту связку.
Значит чего то не хватает в системе? Подскажите, куда думать дальше.