You are not logged in. Please login or register.
SmoothVideo Project → Эксплуатация SVP → Идеи/предложения для SVP
В любом случае хотелось бы услышать мнение профессионалов, когда представят.)
Есть ещё такой вопрос, насколько я знаю, чтоб получить 16 пикселей на Optical Flow (по умолчанию 4), СВП даунскейлит картинку.
А в документации также написано, что с 3ххх Optical Flow также умеет в поиск по 2х2 и 1х1 пикселям.
В СВП это реализовано? (у меня просто на постоянке 2060, мог не заметить на новой серии)
да даже 4*4 иногда странно выглядит, еще мельче кмк особого смысла нет
плюс дальше обработка идет через CPU (пусть потом и заворачивается обратно на GPU), т.ч. в текущей архитектуре SVP вектора 1*1 просто положат проц, а на 4к так и 2*2
да и еще хз откуда они там берутся эти 2*2 и 1*1
в SDK для 2ххх они тоже были, но тупо считались интерполяцией из 4*4 в самом SDK
может в 3ххх это такая же интерполяция, но "спрятанная" в драйвер, мы ж не знаем 
а если так, то смысла в этом никакого нет, SVP и так делает интерполяцию векторов до 1*1, но на самом последнем этапе
Я согласен, в общем, со всей позицией. Это выглядит совершенно здраво для общего функционала приложения.
Однако, в OpticalFlow и без того параметров маловато, было бы замечательно разделить даунскейл и размер области для векторов. Ведь пусть 4х4 даёт странные артефакты, он также местами выглядит лучше. Поле для экспериментов - то ради чего мы покупаем ПРО версию. (кроме благодарности за шикарный продукт, конечно)
Хотя-бы в виде примера/скрипта для SVPFlow, если его функционала достаточно.
2х2 с даунскейлом (8х8) может оказаться золотой серединой для каких-то случаев.
Ну и в конце-концов, зачем-то АМД и Интел выпускают новые поколения. 
А ещё в документации упоминалось про какой-то легаси режим 8х8 для старых карточек. Его потом выпилили? Или он тоже работает скверно?
P.S.: если не на 3ххх, то на новом поколении есть весомый шанс что 2х2 и 1х1 станут обрабатываться аппаратно. Этот чёрный ящик можно вскрыть разве что практическими тестами.)
SDK NVOF 4.0 выпустили: https://developer.nvidia.com/opticalflow/download
чо-то пока не очень выпустили... sdk не качается, доки на сайте старые...
--
о, заработало
--
нет, наружу там ничего не торчит, черный ящик, без исходников
так что какие там особо хитрые пост-обработки векторов, или там маски на артефакты - мы не узнаем
суй в него два кадра, получай один наружу, конец
параметров вообще никаких, даже параметрами самого по себе NVOF, т.е. поиска векторов, рулить не дают
теоретически можно считать кадр в любой точке времени, но практически сделано всё так что, по крайней мере, в real time можно сделать только удвоение
>Performance: Up to 150 fps at 4K resolution*
А разве старый похожую скорость не давал ? Никто не мерял задержку на предыдущих сериях видеокарт ?
не давал, поэтому dlss3 на старых картах и не дают (одна из причин)
для видео-то пофигу...
Лучше б они качество подтянули вместо своих "150 fps at 4K", там радиус поиска наверняка с дульку.
Радует только что АМД решились на ответ, может FluidMotion в этот раз будет посимпатичнее и по опенсорснее.
"Ada - 15% quality improvement" ага, спасибо Нвидия
Кстати, пишут что можно получить "Request Access to Optical Flow SDK Source Code".
И с gitlab-а смотреть прям исходники, а не просто готовый СДК, если я правильно понял.
https://forums.developer.nvidia.com/t/v … sed/233408
Может, стоит попробовать?
там точно то же самое лежит
Предлагаю добавить возможность управлять ресайзом изображения не только устанавливая максимальные линейные размеры, а и площадь кадра.
Уменьшать нагрузку на видеокарту ресайзом не очень удобно, а с релизом RIFE это должно быть актуально. Если соотношение сторон в видео и параметре frc.frame.resize не совпадает, то площадь результирующего кадра будет меньше чем задано. Следовательно у нас появляется запас в производительности который хочется использовать вместо зашакаливания картинки, а менять значение параметра вручную для каждого(я немного преувеличиваю) фильма не совсем удобно.
Фича не очень востребованная, но и в реализации не сложная, я себе в генераторе скриптов её уже накостылял.
А нельзя-ли что-нибудь сделать с переменной частотой кадров?
Я имею ввиду, что вот в аниме, например, используется во многих сценах 1-2 кадра из 24-х, что приводит к неприятным артефактам, а в экшн-сценах или свайпах (плавное перемещение камеры) задействованы все 24-ри. Уплавнение работает эффективно не всегда.
Некоторые гении могут выложить и обычный видеопоток 24 кадра закодированный в 30 кадров или того хуже.
Я пытался избавится от лишних кадров через фильтр, но такую кашу СВП в риалтайме не может переварить по понятным причинам, у него едет крыша.
По столь же очевидным причинам пытаться увеличивать через х2 видеопоток в 12 раз (например), а потом пытаться сделать из него те же 60 кадров - это плохая идея, картинку рвёт и ломает.
А что если собрать конвертер в самом СВП, который сам отсеет "пустые" кадры и заполнит пропуски интерполяцией?
Это сложно. Кадры-дубли могут иметь произвольные отличия от картинки исходного кадра из-за особенностей кодирования видео с потерями.
Бывают еще пропущенные кадры. см. Замена выпавших кадров (drop'ов) и SVP
Мало того, что определить такие кадры-дубли - это сама по себе творческая и неодноначная задача, так еще и потребуется на лету определять исходную частоту кадров. Отсюда у каждого кадра после его возвращения к первоначальному положению должен измениться тайм-код, а значит и интерполяцию промежуточных кадров потребуется делать с учетом этого, а это потребует заглядывать на несколько (десятков) кадров вперед и делать какой-то анализатор.
Сейчас намного проще и надежней исправлять частоту кадров в предварительном проходе и сохранять видео с постоянной частотой кадров, где каждый кадр содержит движение.
Применять TIVTC, например. см. Просмотр телекино-видео с плавностью
А еще надежнее найти найти в сети другой вариант требуемого видео, сжатый изначально с правильной частотой кадров. 
На лету - точно не стоит, СВП всё ещё заметно подлагивает когда переходит между частотами кадров.
Насчёт детекта, я использовал для теста функцию ffdshow - mpdecimate. И на первый взгляд вполне удовлетворительный результат, на выходе можно получить VFR с 1-24 к/с.
Проблема в том, что уплавнение даже такого "подготовленного" материала через СВП не даёт на выходе нормальные, стабильные 60 кадров, они скачут и подтормаживают как в риалтайме.
Подозреваю, что это связано с потребностью "заглядывать на несколько (десятков) кадров вперед и делать какой-то анализатор", для VFR это должен быть анализатор двух соседних фреймов? Таймкоды там уже должны стоять подходящие, вроде как.
Насчёт TIVTC, штука интересная, спасибо, но как я понимаю, очень узконаправленная, возвращать из 30 кадров родные 24-25.)
mpdecimate - это один из алгоритмов. Что он делает с тайм-кодом каждого кадра мне не известно. Это надо еще проверять. Но точно его результат не совпадет с исходным видео, которое снято с постоянной частотой кадров и равномерно идущими друг за другом кадрами.
> СВП не даёт на выходе нормальные, стабильные 60 кадров, они скачут и подтормаживают как в риалтайме.
Это ожидаемо. SVP требует на входе видео с постоянной частотой кадров. VFR c 1-24 к/с - это наихудший вариант, который заведомо даст дерганное видео.
Делайте CFR. Смотрите его без SVP, если есть равномерность движений, то SVP добавит плавности. Если без SVP дергается, то с SVP эти дергания станут еще заметнее.
Таймкоды там уже должны стоять подходящие, вроде как.
Не обязательно. Чудес не бывает. Каждый проблемный кусок с кадрами-дублями может потребовать разный способ исправления дропа. Автоматизировать практически невозможно. Проще скачать другую раздачу.
Попытка исправить автоматически есть на форуме. См. поиском по форуму скрипт gamedropfix.
График показывает некую величину движений в кадре. Пропуски - дропы (они же дубли). Как видно, график после работы скрипта становится лучше, но не идеал. Всплески остаются.
TIVTC возвращает любое количество кадров из любого количества кадров. Подробности см. в справке к TIVTC.
SVPTube - использую и как качалку видео, очень удобно, спасибо!
Но вот для скачивания чисто аудиодорожки, не очень, т.к. не скачивает в mp3.
Собственно предложение - сложно ли организовать и такой формат?
форматы организует тот сервис, оттуда качается
если на ютюбе нет mp3 - значит нет
DLSS завезут?
RTX Video Super Resolution уже доступно (это где-то рядышком с DLSS):
проблема при использовании SVP + MPC-VR RTX SuperRes
RTX Video Super Resolution уже доступно (это где-то рядышком с DLSS):
проблема при использовании SVP + MPC-VR RTX SuperRes
Затестил. 0 разницы. Причем с MPC-VR RTX SuperRes нагрузка на видюху увеличилась и пришлось снизить количество кадров с 120 до 90 с SuperRes.
Поддержку кодирования в AV1 на nvidia можно добавить в SVPcode?
взять последний билд оттуда - https://sourceforge.net/projects/mpv-pl … les/64bit/
заменить mpv.exe в SVP 4/mpv64
в кодировщике в advanced режиме использовать av1_nvenc
взять последний билд оттуда - https://sourceforge.net/projects/mpv-pl … les/64bit/
заменить mpv.exe в SVP 4/mpv64
в кодировщике в advanced режиме использовать av1_nvenc
Можно пример любой на переменный битрейт 8 мбит.
При использовании SVPtube2 c плеером VLC каждый раз когда запускаешь следующее(новое) видео, не закрывая плеер с придыдущим(или плеер уже открыт и ничего не проигрывает) открывается новый плеер вместо того что бы открыться в уже в открытом плеере. С другими плеерами(MPC-HC, MPV) такого нет - уже открытый плеер "ловит" новое видео. Причем косяк именно при использовании через SVPtube2, если просто открывать видосы, то все в одном плеере открываться. Может я какую-то настройку упустил? Проблема, так-то не критичная, но подбешивает...
наверное, где-то тут собака порылась
vlc.png 43.27 kb, 138 downloads since 2023-05-23
SmoothVideo Project → Эксплуатация SVP → Идеи/предложения для SVP
Powered by PunBB, supported by Informer Technologies, Inc.