Re: New RIFE filter - 3x faster AI interpolation possible in SVP!!!
But after downscaling is it still necessary to use v2?
Nope, we can use v1 just fine and never see the visual bug.
You are not logged in. Please login or register.
SmoothVideo Project → Using SVP → New RIFE filter - 3x faster AI interpolation possible in SVP!!!
But after downscaling is it still necessary to use v2?
Nope, we can use v1 just fine and never see the visual bug.
dawkinscm wrote:But after downscaling is it still necessary to use v2?
Nope, we can use v1 just fine and never see the visual bug.
Exactly Especially since I can see minor but perceptible differences between v4.15 and v4.15v2 that I don't remember seeing in other models.
Exactly Especially since I can see minor but perceptible differences between v4.15 and v4.15v2 that I don't remember seeing in other models.
So V4.15 is better than V4.15V2 now? Didn't you say that V2 is better? I tried both and couldn't see any visual difference.
dawkinscm wrote:Exactly Especially since I can see minor but perceptible differences between v4.15 and v4.15v2 that I don't remember seeing in other models.
So V4.15 is better than V4.15V2 now? Didn't you say that V2 is better?
I would be surprised if I ever said that Rife v2 has better picture quality, but if I did say that then was incorrect. But there definitely was a time when v2 was better/quicker at FF/REW a video, but that is no longer the case.
I tried both and couldn't see any visual difference.
I said the difference was "minor" but "perceptible" and I'm watching on a very large VR Cinema screen so I'm going to see things that others don't. That's why I wouldn't use anything below Rife v4.9. Over the development time of Rife from v4.6 to v4.15 I've seen artefacts improve to the point where they either disappear or have been reduced. Vertical fast movement artefacts are still an issue but v4.15/v2 handles those the best.
The bottom line with this is that we are all just trying out stuff and reporting back. We are all learning together.
Chainik wrote:dawkinscm
> If you have to use Rife v2 and have picture shaking issues then updating vslmrt makes sense.only for TRT>=9
with TRT8 updating vsmlrt.py most likely does nothing
only difference between SVP's vsmlrt.py and current master is one line:# TensorRT 9.0 or later "ONNXTRT_Broadcast_*:fp32"
After further investigation it seems the v2 issue is caused by old .dll files.
Out of the box svp with rife model 4.9 v2 with tree wiggle present:
https://gyazo.com/67445b08ae0aa2a214e8cb054e051b1b
Out of the box svp with rife model 4.9 v2 with tree wiggle fixed:
https://gyazo.com/61d5906c4bbbe4887171fd5724c6d4edIf u override vsmlrt-cuda and vstrt.dll from rife folder with:
https://github.com/AmusementClub/vs-mlr … 4.test2.7z
Issue gets fixed.
If u downgrade back to:
https://github.com/AmusementClub/vs-mlr … 14.test.7z
wiggle issue will reappear.You can check the example here:
https://drive.google.com/drive/folders/ … sSi1Kl8tSnPlease compare the differences and address this Rife v2 issue when u have time.
Thanks a lot @Chainik!
Would be good if the above is added as an update for those that need it @Chainik
And please update MPV to the latest stable v0.38.0 from 2 weeks ago.
Thank you.
> And please update MPV to the latest stable v0.38.0
nope, it crashes playing DoVi
> And please update MPV to the latest stable v0.38.0
nope, it crashes playing DoVi
Oh wow, that sucks, why would they push that out as a "stable" release. Crazy.
Chainik wrote:> And please update MPV to the latest stable v0.38.0
nope, it crashes playing DoVi
Oh wow, that sucks, why would they push that out as a "stable" release. Crazy.
The way mpv is built and in particular its reliance on other large libraries means that "stable" is relative. So even without the DoVI issue I agree that they shouldn't upgrade. If anything they should be one version behind the latest version to ensure stability.
If you wish to use 0.38 then SVP will still find mpv as long as you put the files in the mp64 folder. Just make sure you stop SVP from installing mpv. This is what I do because I use my own mpv builds.
> Huge improvement over ncnn for Radeon and Arc.
any benchmarks?
Funny, I can't actually find any ncnn vs dml benchmarks for rife. I'm inferring from the relative performance compared to cuda and trt.
https://github.com/n00mkrad/flowframes/ … chmarks.md
Benchmark 2 https://github.com/AmusementClub/vs-mlr … /v14.test4
I might just do some benchmarks myself in VSEditor.
Chainik wrote:dawkinscm
> If you have to use Rife v2 and have picture shaking issues then updating vslmrt makes sense.only for TRT>=9
with TRT8 updating vsmlrt.py most likely does nothing
only difference between SVP's vsmlrt.py and current master is one line:# TensorRT 9.0 or later "ONNXTRT_Broadcast_*:fp32"
After further investigation it seems the v2 issue is caused by old .dll files.
Out of the box svp with rife model 4.9 v2 with tree wiggle present:
https://gyazo.com/67445b08ae0aa2a214e8cb054e051b1b
Out of the box svp with rife model 4.9 v2 with tree wiggle fixed:
https://gyazo.com/61d5906c4bbbe4887171fd5724c6d4edIf u override vsmlrt-cuda and vstrt.dll from rife folder with:
https://github.com/AmusementClub/vs-mlr … 4.test2.7z
Issue gets fixed.
If u downgrade back to:
https://github.com/AmusementClub/vs-mlr … 14.test.7z
wiggle issue will reappear.You can check the example here:
https://drive.google.com/drive/folders/ … sSi1Kl8tSnPlease compare the differences and address this Rife v2 issue when u have time.
Thanks a lot @Chainik!
Thank you for this by the way!
Fixed the small flickering that was happening on static objects such as the mountain in the background at the start of Shang Chi and the Legend of the Ten Rings, or the embedded text in shows like Shogun for example.
Both issues fixed and also 4.16 Lite drops hundreds of frames for me at 4K, while 4.16 Lite (v2) works flawlessly without any dropped frames at 4K x2 with my RTX 3090 and my configuration.
So v2 in some instances definitely performs better, at least with my RTX 3090, I can even downclock and undervolt it and run a completely silent system that does not distract me at all now.
So v2 in some instances definitely performs better, at least with my RTX 3090, I can even downclock and undervolt it and run a completely silent system that does not distract me at all now.
That's why I used v2 for so long. Half the GPU usage, half the noise. But I no longer need v2 now that I'm downscaling.
Blackfyre wrote:So v2 in some instances definitely performs better, at least with my RTX 3090, I can even downclock and undervolt it and run a completely silent system that does not distract me at all now.
That's why I used v2 for so long. Half the GPU usage, half the noise. But I no longer need v2 now that I'm downscaling.
What is the purpose of down-scaling? Sure you gain performance, but you lose the quality of 4K, so why not get your content in 1080p and do native 1080p and you can push 3X for example or 4x with RIFE
The purpose of 4K HDR is to maintain that quality, otherwise it is not worth it to downscale imo
> I can't actually find any ncnn vs dml benchmarks for rife.
TRT is 2 times faster than ncnn
DML is _10_ times slower than TRT
The purpose of 4K HDR is to maintain that quality, otherwise it is not worth it to downscale imo
You are conflating 4K resolution with the important technologies of HDR and WCG. Marketers knew that these technologies wouldn't "sell" to the average joe without significant explanation. But everyone "thinks" they understand resolution so that's the easy sell.
What is the purpose of down-scaling? Sure you gain performance, but you lose the quality of 4K, so why not get your content in 1080p and do native 1080p and you can push 3X for example or 4x with RIFE
When I watch 4K HDR content on my PC, I don't see any detail loss at all, even on a very large screen. So whatever loss there is, isn't significant or obvious without pixel peeping. I can also download 1080p HDR rips that look as good as many 4K discs. That's why I decided to re-encode most of my non Dolby Vision 4K discs down from 60GB+ to half or less, saving disc space while keeping 99% of picture quality.
As for my blu-ray collection, I literally can't see any quality loss at all, and for blu-ray, as long as you are using a decent player then you shouldn't either. 4K HDR playback on a PC is a little trickier, not because of the resolution, but because of HDR. Especially Dolby Vision and HDR10+
Hello folks, For me, films are often interrupted and a Dos window appears. At the beginning it's completely ok, but I don't want it in the middle of the film. can this be stopped?
in the middle of the film. can this be stopped?
https://gyazo.com/3b2771c7a2dee8994b431a283f215f12
Go to Frame Size and change "Black bars detection" to "One Time Only" or disable it.
So v2 in some instances definitely performs better
yes, it's the only reason we use v2
from my benchmark, v2 gives a huge fps boost
yes, it's the only reason we use v2
from my benchmark, v2 gives a huge fps boost
Why HAGS ON? Shouldn't turning it off provide an even bigger fps boost?
aloola wrote:yes, it's the only reason we use v2
from my benchmark, v2 gives a huge fps boostWhy is HAGS ON? Shouldn't turning it off provide an even bigger fps boost?
I want to use Frame Gen in some games that's why I turn it on.
also
HAGS ON gives you better FPS on light tasks, but it's worse on heavy tasks. (in the end, turning it off is still better for RIFE)
Ryzen 5900x + 4080 SUPER
if you want to benchmark with mpv, add the configs to the bottom of your mpv.conf file.
profile = benchmark # add # to disable benchmark
[benchmark]
osd-msg1 = "FPS: ${estimated-display-fps}"
opengl-swapinterval = 0 # {lock☒}
opengl-dwmflush = no # {lock☒}
vulkan-swap-mode = immediate # When using --gpu-context=winvk, if the number of frames is equal to the refresh rate, try changing to mailbox
d3d11-sync-interval = 0 # {lock☒}
d3d11-flip = no # {lock☒} The swapping effect of flip may clamp the extreme frame rate FPS_max=number of front and rear buffers x refresh rate
hidpi-window-scale = no # {lock☒} Disable DPI scaling first and then the specified magnification will be accurate
window-scale = 1.5 # Manually specify the source zoom ratio (limited by --auto-fit=<value>)
sub = no # {lock☒}
audio = no # {lock☒}
keep-open = always # {lock☒}
# display-fps-override = 24 # Match source framerate as much as possible
video-sync = display-desync # {lock☒}
interpolation = no # {lock☒}
Testing RIFE update with SVP's scene change detection added.
Replace script\generate.js, script\base.py and plugins64\svpflow2_vs.dll, restart SVP.
Now THREE different modes are possible, controlled by the "Scene change threshold" profile option:
1. default - old behavior with "dumb" scene change
2. scene change based on SVP's motion vectors - when "scene change threshold" is "6%"
3. scene change based on NVOF's motion vectors - when "scene change threshold" is "8%"
Scene change-related params from override.js should also work, such as smooth.scene.limits.zero, .blocks, .scene (see a short description there - https://www.svp-team.com/wiki/Manual:SVPflow)
UPDATE: svpflow2_vs.dll updated, also supporting blending on scene changes instead of frame repeating.
There's no "processing of scene changes" option in the RIFE profile so you have to set it via 'All settings' - find the profile and set 'fi_scene_changes' to 0 (blend) or 1 (repeat)
UPDATE 2: svpflow2_vs.dll updated, default value for scene.limits.blocks set to 40 for RIFE
UPDATE 3: svpflow2_vs.dll updated, using correct frame for repeating on a scene change
Testing RIFE update with SVP's scene change detection added.
Replace script\generate.js, script\base.py and plugins64\svpflow2_vs.dll, restart SVP.Now THREE different modes are possible, controlled by the "Scene change threshold" profile option:
1. default - old behavior with "dumb" scene change
2. scene change based on SVP's motion vectors - when "scene change threshold" is "6%"
3. scene change based on NVOF's motion vectors - when "scene change threshold" is "8%"Scene change-related params from override.js should also work, such as smooth.scene.limits.zero, .blocks, .scene (see a short description there - https://www.svp-team.com/wiki/Manual:SVPflow)
UPDATE: svpflow2_vs.dll updated, also supporting blending on scene changes instead of frame repeating.
There's no "processing of scene changes" option in the RIFE profile so you have to set it via 'All settings' - find the profile and set 'fi_scene_changes' to 0 (blend) or 1 (repeat)
I was hoping someone would make a change for below 10% because this is what I was using to fix the vertical fast motion issues I saw but the choppiness it introduced elsewhere wasn't worth it.. 8% works well on fixing those issues, but maybe not quite as smooth on one or two other scene changes above 10%. Still testing. 6% is too choppy no matter what. Blending/repeat doesn't seem to make much difference.
Update: Did my ultimate test (introduction to Hugo) and below 10% is way too choppy even at 8%. If a similar SC algorithm fix could be applied to 10 or even 12% that would work. But maybe that's not possible because of how it works?
"6%" or "8%" mean nothing here
IF "6%" THEN USE "scene change based on SVP's motion vectors"
IF "8%" THEN USE "scene change based on NVOF's motion vectors"
ELSE USE "dumb frame comparison"
"6%" or "8%" mean nothing here
IF "6%" THEN USE "scene change based on SVP's motion vectors"
IF "8%" THEN USE "scene change based on NVOF's motion vectors"
ELSE USE "dumb frame comparison"
Thanks. I've tried various combinations including setting SC=100 (turn off?). 6% is a no go. The issues I saw initially with NVOF motion vectors are amplified by the intro to Hugo which is a torture test for SC. The dumb frame comparison is the only algorithm that works for Hugo and works the best all round.
Bottom line:
- 6% no go any algo.
- SC below 10% with the dumb algo fixes the vertical fast motion artefacts at the expense of smoothness.
- NVOF algo fixes vertical motion artefacts but causes problems elsewhere. Hugo just makes those problems more obvious.
- SVP algo doesn't seem to help much.
- Dumb algo works best overall. Smooth with Hugo and everything with exception of "some" vertical fast motion scenes.
I do used fixed 60 fps though, not "To Screen".
> NVOF algo fixes vertical motion artefacts but causes problems elsewhere.
It just can't "cause problems". It can only:
a. (_very_ unlikely!) miss the scene change that is actually a scene change --> which shows RIFE's artifacts at this frame
b. mark a scene change where there's no scene change --> makes it choppy where it could be not choppy
that Hugo?
SmoothVideo Project → Using SVP → New RIFE filter - 3x faster AI interpolation possible in SVP!!!
Powered by PunBB, supported by Informer Technologies, Inc.