Search options (Page 4 of 47)

//smooth.scene.blend            = true;
//smooth.scene.limits.m1        = 1800;
//smooth.scene.limits.m2        = 2500;
smooth.scene.limits.scene        = 4400;
smooth.scene.limits.zero        = 0;
smooth.scene.limits.blocks        = 23;
Т.е. условно хорошие блоки не используем в расчетах?

Как бы, разжевывать остальные параметры особой цели нет....
Но механизм ловли артефактов, примененный на сегодня, не является таковым.
Худо- бедно работает, на сильно зажатых векторах. Что и есть по умолчанию. Грубо говоря, свп в состоянии найти точное попутное движение крупных объектов в кадре. то бишь тушку...Но руки-ноги, не говоря уже об рогах и копытах...будут получены наложением.
Сегодня механизм нацелен на качество контуров - именно по ним ориентируется.
ориентируется только по оригинальному кадру - крайне зависит от резкости, контрастности и шума.
И, самое главное, не в состоянии поймать"стрекоз" или наложение объектов- разрывы. Ибо детектировать подобные артефакты, посредством непохожести блоков= САД, можно только, когда эти объекты полностью попадают в блок поиска=сравнения.
Т.е. детект должен быть на каждом уровне пирамиды поиска, а не как сейчас, по ногтю мизинца правой стопы - пусть даже Хоббита.

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

Имеет смысл избавиться от всех профилей - ес_ЯЯ?

Что пишет?

analyse.main.search.coarse.width    = 2100;
Эту строчку попробуй убрать, не помню, есть ли она в 3.1.7

Сегодняшний профиль для свп 3.1
Блоки 32*32 с уточнением. Адаптивный режим, 11 блочный.
Подходит для видео высотой больше 720 строк. Меньшие размеры просто увеличиваем.

Жаль потерянного на свп4 времени. Против свп 3.0, на мой вгляд, лишь более адекватное приведение размера входящего видео к экрану.
Давать окша за обрезание - православному не понять.

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

Nurk
В этих видео даже на стандартных настройках SVP редко отключает плавность.

Стандартные настройки ловли артефактов - скорее дырка от бублика.
Железная уплавнялка умеет оценить вращение и зум , свп не умеет.

Скрипт, что выше, имеет достаточно агрессивную настройку смены сцен=ловли артефактов . Весьма близкие задачи , не правда ли?
Главным образом, поджал из-за 21 шейдера.

smooth.scene.limits.m1        = 1800; для 13 шейдера и ремуксов скорее подойдет значение 2000-2400
smooth.scene.limits.blocks        = 10; здесь 15-20 для 13 шейдера.

Chainik
я всегда был за 21-й по умолчанию

Так что мешает удовлетворить себя=любимого (я тоже за 21) и общественность - оставаясь при этом в рамках "до частоты экрана" ?

Chainik
Вот у gaunt-а та же проблема, его хрен заставишь выдать конкретные кадры и скрипт...

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

Поскольку видяйки у меня нынче нет , особого прихода от свп 3.1 тоже нет. Т.е. эти скрипты для 3.0.7
Решил поделится профилем для видео высотой от 720 строк , впрочем остальное тоже смотрибельно.
Профиль предназначен для режима 24-60. Вернее для режима , когда из 5 кадров лишь 2 расчетные.
В менеджере нужно выбрать 24-60 2м . Уточнение желательно.
Для режима "до частоты экрана" настройки смены сцен слишком мягкие .

James D
В ветке по кодеру h265 все сошлись на мысли, что кодирование с 10bit кодером, пусть даже и исходника в 8 бит, улучшает готовую картинку.

10 бит есть целочисленное представление цветовых составляющих , против 8 бит "с весами" каждого цвета от яркости- которые по идее считаются до третьего знака после запятой .
Естественно "при округлении"= неизбежном замыливании при перекодировании предпочтительно иметь более точный исходник , представленный 10 бит . Результат округления должен быть точнее .

Chainik
Тогда профит должен быть примерно такой же, как от GPU vs. CPU построения в SVP (потому что на GPU все считается в float).Только SVP рожает новые кадры, ему некоторая фантазия простительна, а декодер выстраивает имеющиеся.

На грубых уровнях пирамиды 30-битный цвет будет точнее . Был 16 бит , сейчас 12 .
Мой рабочий профиль 3.0 вообще не считает цвет , ибо 12битное представление только вносит дополнительное усреднение при расчетах . ТЧК.