You are not logged in. Please login or register.
SmoothVideo Project → Posts by lionessb
https://github.com/hzwer/Practical-RIFE/issues/90
В ходе переписки с создателем я так понял что у меня какая то индивидуальная проблема.
https://www.youtube.com/watch?v=D6gMDvqvr30&t=18s
Делал по этому видосу. Возможно причина в неточностях перевода при переписке на гитхабе либо видос слишком старый и уже неактуальный
Скорость не имеет значения, особенно интересует обработка аниме с нормальной дедубликацией
(когда частота анимации персонажей в 2-3 раза ниже чем исхлдная частота видео).
Вроде dain в этом плане давно уже сдал позиции
Желательно не програмным кодировщиком
Возможно это связано как раз с тем что при куда идёт работа с кодированием/декодированием большого количества phgшек + задержки при чтении/записи большого количества кадров в отдельные файлы на ссд? Если только из-за этого то можно ли как то отключить создание секвенции у куда версии? Чтоб она работала как нснн/вс? (обработка потока без предварительного сохранения в секвенцию)
Почему медленнее?
Сравнение версии 4.6 под куду и нснн/вс. Видно что куда больше грузит проц и из-за этого график загрузки гпу более рваный, в то время как нснн/вс менее требователен к процу и график загрузки гпу более стабилен. + нснн/вс версия не требует предварительной раскадровки в секвенцию всего видео файла. По времени обработки. На 1080р и выше разница не такая уж и большая но при более низких разрешениях она становится существеннee ввиду более низкой требовательности нснн/вс к цп
Или я что то не так делаю?
Кто нибудь в курсе, разработка ncnn/vs версии заброшена ? Как и разработка flowframes? Ничего не смог найти новее 4.6, в то же время cuda версия уже обновилась до 4.13.
Но в ncnn/vs версии нравилась скорость обработки, видимо сказывалась оптимизация (в сравнении с аналогичной версией cuda)
И вообще, какой сейчас самый качественный алгоритм уплавнения в принципе (dain не в счет) скорость обработки значения не имеет, особенно интересует обработка аниме.
Хотя нет, перепроверил, mpc render тоже дропит.
720р, 1080р 2560р при 120, 240 фпс - дропит
но при этом 4к 60фпс - не дропит, хотя это более массивный поток чем 720р 240фпс, поэтому проблем с нехваткой пропускной способности тоже быть не должно, дропит именно если фпс выше 60, в чем может быть проблема?
Тестирую на мониторе 2560р 240гц разные интерполированные видосы.
60фпс и все что ниже идет абсолютно плавно но начиная со 100фпс и выше идет периодический дропинг и как следствие микрофризы.
Проблема не в нехватке ресурсов т.к дропинг проявляется даже на самых низких разрешениях, + что на 100гц что на 240гц дропинг ведет себя абсолютно одинаково (при 240 гц дропинг не усиливается в сравнении со 100гц)
Пробовал на встроенном рендере МРС так там вообще даже поток 2560р 240гц ведет себя абсолютно стабильно. Но переходить на него не вариант т.к сравнивать его по функционалу с madvr - просто смешно.
Вопрос по части Flowframes, на официальном форуме бардак и каждый "разговаривает сам с собой". Поэтому может здесь подскажут ?
Проблема в искаженных цветах в сохраненном видео, причина не в самом ии алгоритме поскольку если сохранять
результат в виде секвенции то там интерполированные кадры имеют корректные цвета точно такие же как и в исходнике.
Но если сохранять как готовый ролик то цвета тусклеют:
Подозреваю что проблема в неправильной работе ffmpeg энкодера
При переходе с 980ti на 3070ti столкнулся с проблемой, на copy-back просто неадекватно растет жор гпу по сравнению с native
хотя загрузка видеоядра в обоих случаях одинаковая. И на 980ти по умолчанию загрузка и видеоядра и загрузка гп были одинаковы что в native что в copy-back.
На скрине 4к 60фпс, при 8к 60фпс на copy-back уже загрузка гп под 70-90% и начинаются сильные фризы.
Возможно ли как то снизить нагрузку на гп при copy-back до уровня как на native ?
На sdr экране оно и не нужно. Мне важно получить корректные цвета при преобразовании (помоему чисто объективно это слева на 1 скрине)
Если такой результат на выходе получается путем:
при включенном ffd raw filter hdr обрезается до sdr а потом madvr пытается восстановить получившийся sdr обратно до hdr,
то можно ли сделать такой же результат на выходе сразу из исходного hdr не преобразуя его перед этим в sdr ?
Если это делается через avsf то как ?
Раньше для нормальной коррекции hdr на sdr экране достаточно было поместить hdr видео в папку hdr=on.
Сейчас же вне зависимости от того где лежит hdr файл madvr по умолчанию начал применять какую то
свою вырвиглазную коррекцию для hdr, а старый метод с перемещением работает только для sdr видео.
Как сейчас можно вернуть такую коррекцию (которая на 1 скрине слева) для hdr ?
1. Как настроить mad vr чтоб он автоматом распознавал hdr видео восстанавливая цвета и чтоб не приходилось перетаскивать видео в папку "hdr=on" ?
2. Возможно ли у svpcode при перекодировке с hdr исходника получить sdr на выходе с восстановленными цветами ? (как у mad vr при проигрывании из папки "hdr=on")
1. У меня есть подозрение что вся разница между Rife и Dain кроеся только в одной опции TTA так ли это ? т.к при ее включении скорость становится примерно равной скорости самого dain если кодировать из самого дэйна (512х288 3-4фпс на 980ти)
2. Планируется ли добавить алгоритм dain в дистрибутив svp ?
3. На что это влияет ?
Вроде как последователь dain, в последних версиях по качеству сравнялся с ним только в 25раз быстрей и видеопамяти сжирает в разы меньше. Реально ли там так все гладко как преподносят разрабы ? Просто в бесплатном доступе его дистрибутив так нигде и не нашел.
Никакого русскоязычного форума по дайну не нашел, поэтому еще один вопрос: дайн поддерживает multi-gpu ?
Уже потестил dainapp, ресурсопотребление конечно конское но не суть. Возник вопрос: он умеет увеличивать фпс только кратно, если исходная частота видео не кратна частоте монитора а хочется получить на выходе максимально-возможно качественный результат с частотой равной герцовки монитора, как такой вариант?: Допустим монитор 120 гц а видео в 25фпс, если я уплавню видео через дайнапп с 8х уплавнением до 200гц, а потом получившийся результат переконвертирую через svp code в 120гц. То часть кадров все равно будут отброшены до значения ниже 120 и часть из получившихся 120 все равно будет достроенна по аглоритмам svp ? Или из потока в 200гц просто будет отброшена часть кадров до 120 и как то равномерно распределено (напободие тройной буферизации, к примеру когда смотришь 25фпс видео на 60гц мониторе и не видишь подергиваний) ?
Ну собственно 2 вопроса
1. Попробовал софт topaz a.i который путем нейроаглоритмов увеличивает разрешение изображений пытаясь дорисовать отсутвующие детали , выглядет все конечно кривовато но не суть,
это подтолкнуло на вопрос: чисто теоретически в дальнейшем будущем есть мысли о реализации чего то подобного в построении кадров для svp ?
2. Неужели у svp до сих пор нет конкурентов в данной области ?
Проблема в том что при включенном уменьшении шага загрузка цп что с гпу ускорением что без него одинакова, если же сравнивать с ускорением и без него при отключенном уменьшении шага то разница в загрузке цп существенна. Что жрет процедура уменьшения сетки? цп или гп ?
Какие опции нужно прописать в svpcode чтобы задействовать lossless режим для h.264 и 265 ?
Переустановил винду со всем софтом и теперь без всяких правок в независимости от разрешения ролика в цветах нет никакой разницы, итоговое видео выходит точно с такой же цветовой схемой как и в буфере vfb как и должно быть (хоть и видео имеет все то же пространство bt 709)
Для начала разобраться на каком этапе цвета искажаются. Если уже на выходе из 3Ds Max, то искать настройки в нем.
с исходно отрендеренными изображениями все в порядке.
отрендеренные png (каждый файл это будущий кадр для видео) - цвета коректные
несжатый avi созданный из png секвенции - цвета коректные
перекодирование из несжатого avi в mp4 (H.264) - а вот тут самое интересное: на этом этапе как раз и происходили искажения, попробовал вставить опцию "colorprime=bt709" и разница пропала , в финальном результате теперь цвета такие же как и в исходных png кадрах. Только вот теперь даже если эту опцию удалить то разница в цветах все равно отсутствует (хотя должна вроде как вернуться) 
Работаю со связкой 3dmax + vray, отреднерил кадры анимации в секвенцию но при сборке изображений в кадры видео и перекодировании происходит так что при разрешении 720р и выше наблюдается искажение цветов (по всей видимости изза цветового пространства bt709), если кодировать ролик с разрешением ниже 720р то исходные кадры и получившееся видео абсолютно идентичны по цветам, в MPC есть шейдер "bt709 to bt601" он исправляет ситуацию при воспроизведении но меня интересует как само по себе видео сделать без цветовых искажений с разрешением от 720р и выше ?
Вобщем что и требовалось доказать поставил обратно 1709 и все отлично работает. С помощью твикера заблокировал скачивание именно этой крупной обновы до 1803 и поставил все кроме неё.
lionessb wrote:exusive mode в mad vr. при переключении в эксклюзив изображение подвисает на 2-3 сек потом только начинает воспроизводить, если эксклюзив отключить то воспроизводится нормально
Так это нормальная работа madvr. При первом запуске всегда в переход(выход) madvr exclusive экран тухнет и зависает видео на некоторое количество секунд, после всё без нюансов. На самом форуме по madvr предупреждали о подобных "багах".
Было давно такое но при этом экран буквально за полсекунды несколько раз мигал черным и звук паралельно с этим не переставал пвоспроизводиться. Это уже давно пофиксили. На 1803 же именно 2-3 сек при переходе висло намертво, звук при этом тоже обрывался и ни на какие нажатия система не реагировала и лишь через 2-3 сек отходило.
SmoothVideo Project → Posts by lionessb
Powered by PunBB, supported by Informer Technologies, Inc.