Воспользовался утилитой от Haali, mkv2vfr, которая для mkv-файлов показывает интервалы внутри видео с разной частотой кадров. Получилось следующее:

Rimsky: PSNR.Planetes.01 (1)-004.mkv

# timecode format v1
Assume 23.976
0,2243,23.9764

Первая частота - из заголовка. Далее - интервалы кадров (первый, последний) и частота кадров на этом интервале. Здесь интервал один. Обе частоты примерно совпадают, этот файл корректно работает и в текущей версии SVP 3.0.1.

Mikluhamaklay: Planetes_TV_05 (1) -001.mkv

# timecode format v1
Assume 23.976
0,0,30.3030
1,1,10.0000
2,277,29.9707
278,1112,23.9757

Если опустить первые единичные два кадра, которые имеют собственную частоту кадров, то остается два интервала:
1. Кадры 2-277. Частота 30 fps
2. Кадры 278-1112. Частота 24 fps
227 кадров на частоте 30 fps это почти 8 сек. На восьмой секунде происходит переход между частотами кадров. 30 fps понижается до 24. Сейчас SVP 3.0.1 не умеет на лету приспосабливаться к таким изменяющимся условиям. Поэтому и наблюдаются либо завышенные, либо заниженные значения SVP-индекса. Если научить отображать правильный SVP-индекс у меня уже получилось, то вот во время изменять коэффициент повышения плавности - пока нет. Проблема в том, что ffdShow показывает это изменение частоты кадров на 8 секунде не как резкую смену частоты, а как плавное падение частоты на протяжении оставшихся секунд ролика. Это затруднит выбор правильного коэффициента повышения плавности, и плавность при этом будет искажена, частота кадров видео перестанет быть равной частоте обновления экрана.
Нужен способ более быстрого определения текущей частоты кадров.

Mikluhamaklay: Bakemonogatari_[06]_[BDRip_720p_x264_FLAC][Noir] -001.mkv

# timecode format v1
Assume 23.976
0,2715,30.0001

Видно, что интервал один, но частота в заголовке отличается от реальной частоты кадров.
Такая ситуация отлавливается весьма корректно. ffdShow быстро начинает показывать реальную частоту кадров. В готовящемся исправлении SVP такие файлы будут уплавняться корректно.

Mikluhamaklay: [AniDUB]_Kaibutsu_Oujo_[08_of_25]_[RUS_JAP]_[DivX_704x396]_[Cuba77_&_Ellorial]-001.mkv

# timecode format v1
Assume 23.976
0,3,23.9521
4,5,29.8507
6,346,23.9769
347,347,20.0000
348,348,23.8095
349,349,30.3030
350,504,23.9753
505,506,20.0000
507,507,23.8095
508,545,29.9685
546,546,24.3902
547,547,19.6078
548,548,24.3902
549,554,30.0000
555,555,23.8095
556,556,20.0000
557,557,23.8095
558,563,30.0000
564,564,23.8095
565,565,20.0000
566,566,23.8095
567,572,30.0000
573,573,24.3902
574,574,19.6078
575,575,24.3902
576,581,30.0000
582,582,23.8095
583,583,20.0000
584,584,23.8095
585,585,30.3030
586,586,23.8095
587,587,20.0000
588,588,23.8095
589,599,29.9728
600,600,24.3902
601,601,19.6078
602,602,24.3902
603,643,29.9708
644,644,23.8095
645,645,20.0000
646,646,23.8095
647,657,29.9728
658,658,23.8095
659,659,20.0000
660,660,24.3902
661,661,29.4118
662,662,24.3902
663,663,20.0000
664,665,23.8095

Тяжелый случай. Выделена частота кадров на интервалах, длиннее 3 кадров. Видно, что идет увеличение частоты с 24 до 30, но эта частота периодами "гуляет" туда-сюда. Я пока не знаю как повышать плавность такому видео.
Скорее всего никак hmm

Mikluhamaklay: Rozen Maiden - 04 (DVDRip 1024x576 x264 AC-3) [HQR] (1)-001.mkv

# timecode format v1
Assume 23.976
0,19,23.9808
20,119,29.9670
120,123,23.9521
124,138,30.0000
139,142,23.9521
143,242,29.9670
243,262,23.9808
263,292,29.9700
293,328,23.9840
329,363,29.9658
364,371,23.9521
372,456,29.9718
457,488,23.9700
489,493,29.9401
494,541,23.9760
542,991,29.9700
992,993,24.3902

Само видео 24 кадра в секунду, а периодически идут вставки с частотой 30 fps (выделил жирным). Японцы любят такое. Рисованное аниме на одной частоте, а титры и компьютерная графика - на другой. Повышать плавность тут тоже как бы не простая задача. Совсем не простая. ffdShow не успевает отловить переключение частоты кадров. Т.е. такому видео тоже повысить плавность не удастся.

Сообщения о низком значении SVP-индекса перемещены в тему:
Низкий SVP-индекс при неполной загрузке процессора

Обсуждение этой проблемы выделено в отдельную тему

Исправлено и появится в SVP 3.0.3

Исправлено в SVP 3.0.1

agorava
Для начала (как правильно заметил droner) надо привести допинфо: меню - показать - дополнительную информацию.
Выполнить это на том файле, где подсветка не устраивает.

droner
В большинстве случаев допинфо будет достаточно, чтобы ответить на вопрос. Причина обрезания подсветки еще может быть в отрисовщике. Это верно подмечено. wink

NightFox
Называю подергиваньем неравномерность движений. Подергиваний быть не должно ни на 24, ни на 60 fps. На 24 присутствует некоторая "ступенчатость" движений, но при ее равномерности ее нельзя назвать подергиваниями.

Я имел в виду дерганье 60-фпс-ной картинки. Она дергается на слабых компах (и слабых видюхах) куда сильнее, чем аналогичная на квадратах. И разница получается в обратную сторону. На плавных движения дерганья заметны лучше и отрицательный эффект от них больше. При таких подергиваниях 24 кадра смотреть приятнее.

Кстати, эта анимашка перестала открываться.

кубики показывают что между 30 и 60 разницы особой нет
Я отчетливо вижу разницу.

между 24 и 30 разница ощутима
Это на 60 Гц мониторе. 60 не делится нацело на 24. Вы на 120 Гц мониторе смотрели?

DAAO
А мне вот кубики больше нравятся. Показательнее. И если сравнивать кубики с анимашками NightFox, то кубики подергиваются намного меньше.

Mikluhamaklay
Rimsky
Прошу вырезать кусок мегабайт на 20 и выложить. Я собираюсь реализовать уточнение входной частоты во время воспроизведения с плавностью в ближайшем исправлении SVP.

Atag
Руками приходится отключать галки на всех пунктах, начиная с MPEG-1 Video и заканчивая Theora - ОК
Это устаревшая инструкция SVP 2.0. Там надо было делать эти манипуляции.
Для SVP 3.0.1 вообще не надо заходить в настройки. Все настроено сразу после инсталляции и готово к работе. wink
SVP3:Справка:Начало_работы

пусть по дефолту Автомасштаб будет включен
Предложение понятно, но мы наоборот отказались от Автомасштаба. Про это уже упомянул Rimsky.

Почему было решено выключить галку.
Во-первых, многие плееры изначально при открытии не изменяют размер окна. Менять размер окна - это "фишка" сугубо MPC-HC и многих пользователей SVP она раздражает.
Во-вторых, Вы можете после открытия файла вручную масштабировать окно горячими клавишами: Alt-1, Alt-2, Alt-3: 50%, 100%, 200% соответственно. Это даже удобней, чем автомасштаб.

Кому еще нужен автомасштаб. Прошу высказаться.

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

фпс=23,976 неверный фпс=30. Помогает не перезапуск свп во время воспроизведения, а выключения плеера, потом выгрузка свп, и запуск по новой - сначал свп потом плеера
Спасибо за рекомендацию. Многим поможет.
У меня есть большое желание добить подстройку под частоту кадров во время воспроизведения и выпустить это в ближайшем исправлении SVP 3.0.

droner wrote:

настройка действует пока не выключили плеер

Настройка действует и после переоткрытия плеера. Я эту настройку включаю. Некоторым это не нравится, т.к. плеер меняет размер окна по размеру кадра каждого открываемого файла.

5,738

(466 replies, posted in Эксплуатация SVP)

DAAO
Спасибо, уточнил в выводе про WinXP.

5,739

(466 replies, posted in Эксплуатация SVP)

Rimsky
а на семерке? evr так же дропает?
Если на этом же слабом железе, то могу проверить, но не скоро - этот комп стоит на работе, Win7 не установлена. Т.е. это специально винду и дрова ставить и час-два времени на замеры и тесты. wink
Вот на домашней машинке скоро сделаю такую же табличку. Но там и железо в разы быстрее.

при прочих равных условиях разные операционки одинаковые результаты по рендерам показывают?
Не проверял. Пока нет таких условий, да и задачи такой не ставилось. Стоял вопрос какой отрисовщик лучше для моей конкретной системы. Вот на него я ответ получил: Overlay.

почему настройки для игр влияют на картинку?
Без понятия. У меня нет Radeon'а.

мои результаты не впишутся в общую картину
Правильно. Они свою картину напишут. Кого-то как раз будет интересовать таблица совместимости отрисовщиков с плавным видео как раз на системе подобной твоей (квад9550+амд6900). wink

5,740

(466 replies, posted in Эксплуатация SVP)

Завершу картину про отрисовщики PotPlayer'а. Пригодность их для повышения плавности в SVP.
Померял на слабом компе.

ТТХ: Core 2 Duo E4500 2.67 ГГц, GeForce 8500 GT, монитор 1280x1024 @ 60.024
Софт: WinXP SP3, nVidia driver 260.99, DirectX June2010, SVP 3.0.1, PotPlayer 1.5.27833
Тестовый ролик: VID-2D_to_720p.mp4 (из MVFlowFps HD Test)
Плавность: 1280x720 @ 23.98 * (5:2) = 59.95 fps
Профиль: Обычное / 1. Простой / До частоты / До пкс / 16x16 / Без / Среднее / Обычная / Повторять / Не уменьшать

http://www.svp-team.com/forum/misc.php?item=246

Делал несколько замеров подряд. Брал среднее значение. Измерял в полноэкранном режиме.
Как можно видеть, на этой слабой системе (С2D 2.2 + GeForce 8500 GT) плавную картинку дают только 3 отрисовщика (рендерера). Лучшим по низкому значению загрузки оказался Overlay Mixer. Занял первое место. На втором - Old Video Renderer, на третьем - VMR7 Windowed. Остальные отрисовщики дают либо подергивания картинки, либо даже пропускают кадры пачками.

Вывод: на слабых системах с WinXP пользоваться Overlay Mixer'ом.

Кому интересно, проводил подобное сравнение отрисовщиков на Media Player Classic: Core i7 + GTX 260, C2D + 8500 GT.

что это?

5,742

(466 replies, posted in Эксплуатация SVP)

Rimsky
разрабы часто путают и ставят для русских СР1250, 1252...
Я поступаю проще, я не пользуюсь такими кривыми программами wink

Lotus Notes 6.5 - 2003 год, есть более свежие версии.

sergioleon
См. первое сообщение темы. Там все написано. Никаких цифр не требуется. Но и просто названий фильмов и ссылок - этого недостаточно. wink
Было бы здорово узнать впечатления от просмотра. С пометкой с плавностью смотрелось или без.

Например, тех же интернов моя сестра без всякой плавности смотрит. Говорит, "я не плавность движений смотрю, а сериал". Открывает в мелком окне на четверть экрана и параллельно еще пасьянс раскладывает или чем-нибудь более полезным занимается.
А я фильмы смотрю исключительно с плавностью, на весь экран.

Чувствуете разницу?

5,744

(466 replies, posted in Эксплуатация SVP)

droner, Rimsky
Я бы не стал рекомендовать вносить эти изменения в реестр для поддержки русского языка. Это работающий, но сильно варварский прием, от применения которого могут быть весьма неприятные последствия. Уж лучше штатными средствами корректно включить язык: в панели управления Windows -> язык и региональные стандарты -> выбирается страна Россия, язык Русский, и на последней вкладке для не-Unicode программ тоже Русский. Для применения изменений перезагрузиться.

Chainik
Может все-таки Win Vista, 7 или 2008 не хватает?
Только сейчас, перечитывая тему, заметил этот комментарий. Да. На самом деле. Проверялось на WinXP. Именно в этом может быть причина, по которой на C2D + GeForce 8500 GT не включились два аппаратных декодера: Cyberlink HAM и PotPlayer DXVA.
Надо будет как-нибудь попробовать на Win7. cool

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

7sh3
нет никакого смысла использовать svp на интерлейсном видео
Я согласен с этим утверждением в отношении материала, содержащего 30 чересстрочных кадров в сек.
Но что если источник PAL (25 кадров с чересстрочкой)? Тогда деинтерлейс даст 50 кадров. А для компьютерного монитора надо 60.

так получается сперва замажем софтовым деинтерлесом, картинку изуродуем и потом кадры искусственно добавим с увеличением частоты
Есть качественные софтовые деинтерлейсеры, которые не "замазывают" и не "уродуют" картинку. Правда они медленные. В таком случае можно найти компромисс скорости и качества. Я, например, использую yadif из ffdShow. Из чересстрочного PAL получаю 50 кадров/сек. SmoothVideo Project 3 умеет увеличивать плавность с 50 до 60 к/сек, а главное, движения становятся действительно плавнее. Смотрю так MPEG-2 записи. КВН, например.

NightFox
Да... Проблемки... Может пойти по пути видео, а не флеш?
Если оставаться на флэше, то надо повырубать все эффекты, там полупрозрачность, еще всякое... И главное, картинку скадрировать меньше раза в 4 по площади. Чем она больше - тем тормознее отрисовывается. Не зря же пример с прыгающим квадратом небольшой в размерах. wink

komandors
наблюдаю при включении размытия движения в SVP
Текущая версия SVP не имеет такой настройки.
Вы пользуетесь SVP 2.0?

NightFox
Бешеные "бумеранги". и логотип SVP тоже бешеный. smile
Скорость надо раз в 5 снизить. Не видно же ничего. И вращать если хотите, то вращайте без пропадания картинки, иначе она плоская и при опреденных углах вообще исчезает.

NightFox
Спасибо, но именно такие круги на таком поделенном пополам прямоугольнике не совсем то, чего хотелось бы.

DAAO
Рассинхрон наводит новичка на мысль об изменении скорости
Да, такое может случиться.

Разница между 30 и 60 тут даже для меня не очевидна
А я без напряга вижу. wink

лучше самим сделать гифку или флэшку с быстрым движением
Наверное, да.

сам сделал, но не умею пока
Тоже не берусь, но по причине наличия более важных работ над SVP wink

5,750

(466 replies, posted in Эксплуатация SVP)

Banny61rus
что с Hааli?

C Haali все в порядке wink
Вот что пишет про отрисовщик Haali пользователь форума doom9 Egh (перевод части его сообщения):

Отрисовщик Haali подобен VMR9 в том смысле, что так же явлется DirectShow-отрисовщиком.

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

Правильный бикубик должен быть двух-проходным процессом, и насколько я знаю, это одна из причин для нового отдельного отрисовщика. По-просту говоря, его невозможно реализовать в двух проходном режиме через шейдеры в MPC с VMR9. Но, как Haali сам указал, что это потребует некоторого кодирования от Gabest... которое он, очевидно, не очень-то хотел делать. Таким образом, бикубическое изменение размера MPC в VMR9 режиме, как предполагается, уступает в скорости отрисовщику Haali (по причине использования одного прохода в VMR9).

В логике последнего утверждения не согласен с Egh, т.к. два прохода должны быть медленней одного. Или это трудности перевода wink

Rimsky
если дирекс 9 использует почему виснет на радеонах 6900 евр опенцл?
Кто бы знал бы...  hmm