Chainik wrote:

BTW: if you just replace vsmlrt.py with the latest git, then it will use V1 models instead of V2

Yes, cause in december 2023 the dev updated the signature of the RIFE method:
https://gyazo.com/bde7edb2b4deb80294dbbaf71b757cc2
but he didn't add it as last element of the method so please fix it by updating helpers.py to send video_player True or False as 10th parameter:

return RIFE(clip,multi,1.0,None,None,None,model_num,backend,ensemble,False,implementation)
or
return RIFE(clip,multi,1.0,None,None,None,model_num,backend,ensemble,True,implementation)
(not sure which one is best for SVP)

Chainik wrote:

I'd say this's because of color space converted back and forth, noticeable in a very high contrast areas only.
Probably hmm
...and your "shaking" is not like Blackfyre's V2 shaking, which is quite obvious not only on those lines but in a whole frame

Yes, i think you're right. I tried to simplify the base.py and generate.js and ended up with this:
https://gyazo.com/5f8efd7ead2c79d6a3afeaa852161184
but micro shaking still persists. Which confirms that it's caused by the color space conversion required for Vapoursynth.
Easiest way to fix it would be to allow Vaporsynth to also apply the same conversion process on the source frame too.
This way all outputed frames should line up and 100% fix the micro-shaking.
Is this possible? (even if it will increase the computational processing needed)

Blackfyre's V2 whole-frame obvious shaking takes priority, though.
Thanks again for putting the time and effort to look through the magnifying glass.

2

(2 replies, posted in Using SVP)

Check your windows volume mixer settings maybe?
https://gyazo.com/89cec6c5a4908fc2f59e4120e5c94249
Download older MPC-HC versions and check if issue persists from here:
https://github.com/clsid2/mpc-hc/releases

lurker wrote:

rife 4.17 lite v2

There was a recent SVP update which made it load the slower v1 models when u select the v2 models.
Try to use the files from here and see if it gets fixed?
https://www.svp-team.com/forum/viewtopi … 577#p85577

4

(3 replies, posted in Using SVP)

narkohol wrote:

Things I tried:
Any ideas or suggestions?

Wow that's a lot of trial and error!

I'm having a fun time with the mpv config from here:
https://www.svp-team.com/forum/viewtopi … 352#p83352

It has both
video-sync=display-resample
that is explained here:
https://github.com/mpv-player/mpv/wiki/ … ronization
and
d3d11-sync-interval=0
which makes the video player spam frames. So even if you drop a frame it will try to display it again instantly.
https://gyazo.com/beac3ba10706cdca0ce07864e17b31c3

Not sure if there exists an actual solution to fully prevent dropped frames yet.
Please let us know if u find a video player that does that.

I believe if RIFE detects more stuff that have to move between two different frames, it might cause it to do extra calculations which could cause a spike in computing power which lead to frame drops.
Actually we have no clue since only it's developer knows what's in there and how to train an AI.
Just resize down the video a bit to give your PC less work to do.

Gippy wrote:

Watching 1080p anime with RIFE set to 60fps and with MadVR postprocessing to 4K. 4080 Super, AI 4.9.

I'm finding that with RIFE TensorRT, outlines and edges shimmer (the outline width noticeably changes) when panning or scrolling happens. This does not happen with RIFE ncnn/Vulkan or standard SVP interpolation. I tried changing AI models and they all do this. Disabling MadVR doesn't seem to fix it either; it happens with all renderers. It's off-putting enough that I've stuck with standard SVP interpolation for now. Is there a fix for this, or is this a known issue? There's no point in the performance increase of TensorRT if it looks like dogshit.

When doubling FPS of the test scene from here:
https://www.svp-team.com/forum/viewtopi … 509#p85509
We can see how the directly generated video of RIFE has no shake of the white lines on the right side of the screen.
But when transcoding it with SVP, every interpolated frame has different positioning of the white lines than the non-interpolated frames.
It's like you show the video normally on the non-interpolated frames and then reduce the height by a few pixels on the RIFE generated frames which makes the pixels not align with the original movie, adding a shake-like effect on the static white lines that is obvious for big screen users.

SVP devs please take a look:
https://drive.google.com/drive/folders/ … gbYN3w1Eeo
Thanks!

Please try to record your screen with an obvious scenario of "outlines and edges shimmer (the outline width noticeably changes) when panning or scrolling happens."
That way SVP developers can check and fix the issue hopefully.
Also mention where you downloaded the source of that video sample so they can download it too from same place and compare.

Blackfyre mentioned a recent "shake" issue:
https://www.svp-team.com/forum/viewtopi … 509#p85509
that gets fixed with this:
https://www.svp-team.com/forum/viewtopi … 522#p85522

Maybe what u found is something new.

For potato PC, try to increase/decrease the resize setting until it is smooth for your desired FPS:
https://gyazo.com/3c78beeb8888c82912a64633311f5391
and enable Super Resolution in MPC Video Renderer so it will look as good as 4K.

8

(13 replies, posted in Using SVP)

XDark187 wrote:
Chainik wrote:

the only workaround I can see now is don't put vf into mpv.conf, toggle it manually with the keyboard shortcut

Fixed the issue, thank you

Actually, you don't need to manually toggle the filter with a hotkey anymore. You can use a Lua script that automatically applies the d3d11vpp filter with a 3-second delay after video playback starts. This way, the filter will be applied without having to manually press a hotkey.
Save this file in your MPV scripts folder, which is located at C:\Program Files (x86)\SVP 4\mpv64\scripts\ for SVP users.
Now, when you play a video, the Super Resolution will automatically activate after 3 seconds, saving you the hassle of manually toggling it with a hotkey.

pensioner600 wrote:
Xenocyde wrote:

Will test MPC-BE for microstuttering.

If you plan to melt above 160 fps, then I recommend version 0.7.1.2172 of mpcVR. Here (and in the following messages) it’s clear why.  The developer does not fix this error and wants a high-frequency monitor))
https://mpc-be.org/forum/index.php?topi … 18#msg8818

@pensioner600 The mpcVR devs are looking for you:
https://mpc-be.org/forum/index.php?msg=8944

RickyAstle98 wrote:

Nevermind, just say default align/valign values, thanks!

Renaming the SVP folder from Roaming, generates a fresh config that looks like this:
https://gyazo.com/d8f75344daafabb8ecdcaeaecc2db2d3

dawkinscm wrote:

Nope. Still crashes out. I've got the TRT error log and it says that broadcast dimensions must be comformable.

It seems 4.26 also crashes when the width or height of the resized video is not divisible by 64 with:

[   1.419][f][vapoursynth] Script evaluation failed:
[   1.419][f][vapoursynth] Python exception: vsmlrt.RIFEMerge: tile size must be divisible by 64 (416, 256)
[   1.419][f][vapoursynth] 
[   1.419][f][vapoursynth] Traceback (most recent call last):
[   1.419][f][vapoursynth]   File "src\\cython\\vapoursynth.pyx", line 3121, in vapoursynth._vpy_evaluate
[   1.419][f][vapoursynth]   File "src\\cython\\vapoursynth.pyx", line 3122, in vapoursynth._vpy_evaluate
[   1.419][f][vapoursynth]   File "C:\Users\Flowr\AppData\Roaming\SVP4\scripts\1c2e810c.py", line 83, in <module>
[   1.419][f][vapoursynth]     smooth =  interpolate(clip)
[   1.419][f][vapoursynth]               ^^^^^^^^^^^^^^^^^
[   1.419][f][vapoursynth]   File "C:\Users\Flowr\AppData\Roaming\SVP4\scripts\1c2e810c.py", line 62, in interpolate
[   1.419][f][vapoursynth]     smooth = RIFE_imp(input_rife,multi=rife_num,model=rife_mnum,backend=trt_backend)
[   1.419][f][vapoursynth]              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[   1.419][f][vapoursynth]   File "C:\Program Files (x86)\SVP 4\rife\helpers.py", line 23, in RIFE_imp
[   1.419][f][vapoursynth]     return RIFE(clip,multi,1.0,None,None,None,model_num,backend,ensemble,False,implementation)
[   1.419][f][vapoursynth]            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[   1.419][f][vapoursynth]   File "C:\Program Files (x86)\SVP 4\rife\vsmlrt.py", line 1215, in RIFE
[   1.419][f][vapoursynth]     output0 = RIFEMerge(
[   1.419][f][vapoursynth]               ^^^^^^^^^^
[   1.419][f][vapoursynth]   File "C:\Program Files (x86)\SVP 4\rife\vsmlrt.py", line 1049, in RIFEMerge
[   1.419][f][vapoursynth]     raise ValueError(
[   1.419][f][vapoursynth] ValueError: vsmlrt.RIFEMerge: tile size must be divisible by 64 (416, 256)

So we also need to change the code from "C:\Program Files (x86)\SVP 4\script\generate.js" from:

    var pw = Math.floor((media.dst_w-1)/32+1)*32 - media.dst_w;
    var ph = Math.floor((media.dst_h-1)/32+1)*32 - media.dst_h;

to

    var pw = Math.floor((media.dst_w-1)/64+1)*64 - media.dst_w;
    var ph = Math.floor((media.dst_h-1)/64+1)*64 - media.dst_h;

Attaching files that load both v1 and v2 correctly below.

12

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

A reddit post mentions RTX 4070 super as the best price/value graphics card from the 4000 series:
https://www.reddit.com/r/nvidia/comment … _thinking/

John86 wrote:

how to install it? Previously I just dragged the .onnx file into the models/rife folder

Ignore the google drive link.
You go to models page and get rife that contains the .onnx files here:
https://github.com/AmusementClub/vs-mlr … nal-models

Nice! A new SVP update!

Blackfyre wrote:

I will put back v1 models and test performance difference now between v1 and v2 properly.

Nice! Please check so we'll conclude if we can fully remove/ignore the v2 models.
To test the performance also try to set target fps to something high
and add in mpv config:

# D3D11 renderer (default) is required for the HDR playback
gpu-api=d3d11
# disable VSync so MPV will be able to output more frames than your monitor supports
d3d11-sync-interval=0
video-sync=audio

to disable the fps limit. (probably you will have to resize to a smaller than 4K resolution) xD

"RIFE v2 models which handle paddings internally and reduce memory transactions on heterogeneous devices."
Every time i tested on my setup, v2 was a bit faster.
The developer explanation of the difference between them can be found here:
https://github.com/AmusementClub/vs-mlrt/issues/66

Example 1:
https://gyazo.com/366e7ecfd2d4180d45062b9668449c23
This combination of 1 rife thread + v2 gives me 200 fps.
Same combination of 1 rife thread + v1 gives me 180 fps. sad

Nvidia App Overlay displays current FPS, GPU%, CPU% while you are watching that video maybe that helps.

Blackfyre wrote:

To test properly, remove all the models inside v1, so SVP doesn't fall back to them. That's what I am doing.

Yup doing that and works for me with files attached above:
https://gyazo.com/a8b01ddcff578c3033de7b50522481a1
Try to delete the old cache folder from here "C:\Users\Blackfyre\AppData\Roaming\SVP4\cache" and restart SVP maybe?

17

(10 replies, posted in Using SVP)

Yes, it seems SVP detects something really wrong if u want to double the frames:
https://gyazo.com/ece3993a94f81d6a5f9aced049eddd99
Probably LosslessCut breaks something.

If i re-encode your video with https://handbrake.fr/ it detects the source frames correctly afterwards:
https://gyazo.com/30ed5fdb98f6c772c39b4dc77de561ea

So try to play around with LosslessCut encode settings until it exports a SVP compatible video.
Or re-encode your video again with handbrake if u want for the source frames data to be detected ok.

18

(10 replies, posted in Using SVP)

narkohol wrote:

Mmm... all those videos are 23.976 fps.

They are test scenes I cut from the original source videos using LosslessCut.

I installed SVP yesterday, how can I update it more?

Weird that it detects higher fps that 23.976 and crashes.
Please share an example of the cut test scene that gives that error.
You are using latest then, all good.
To update it in the future, right click the SVP icon and select "Additional programs and features..."
https://gyazo.com/f7f87353420412aa1250b1fbabcff7e9

TechnoStone wrote:

Messed with reinstallations, BOTH of these methods just make svp use v1 models

Hahaha you are right! I never noticed that.
It means the fix is actually longer than one line, hidden somewhere in the vsmlrt.py file from scripts.v15.4.7z
Will wait for SVP developers for actual fix.
Thanks TechnoStone!

Temporarily we can use these that don't have the v2 shake and load v2 models correctly:
Attaching latest version of vsmlrt.py from here https://github.com/AmusementClub/vs-mlr … /vsmlrt.py

dawkinscm wrote:

video_player: bool = False should be the default setting.

Attaching sending video_player False to RIFE as dawkinscm suggests in helpers.py

20

(10 replies, posted in Using SVP)

narkohol wrote:

05:04:18.996 [E]: Playback [c0145ab3]: VS - ValueError: vsmlrt.RIFE: RIFE: multi must be at least 2

But setting to "Fixed 60fps" doesn't solve it.

It means the video u are opening already has 60 fps.
Try specifying a higher fps value.
And also update SVP.

Chainik wrote:

I believe that all "fixes" the latest vsmlrt.py contains are included in SVP's one

The v2 shake issue seems to get fixed if u add this on line 1027:
    video_player: bool = False,
https://gyazo.com/d7798e1ee97ecfa658d8587466561630
(nevermind it seems it just makes it load the v1 model instead)

Blackfyre wrote:

Also thanks to flowreen91 for posting the original fix for screen shaking in some scenarios while using v2's

The old tree wiggle issue was present only on TensorRT v14.test2 and older, and was fixed just by upgrading to TensorRT 14.test3 or newer.
https://www.svp-team.com/forum/viewtopi … 617#p84617
It was unrelated to what's inside the vsmlrt.py file.

But if u indeed manage to reproduce a new screen shaking issue and fix it on your 4K screen while using latest TensorRT please provide more data/video/recording example so Chainik can look into it. ^_^

John86 wrote:

4.18 (v2) still the best atm?

On RIFE page: https://github.com/hzwer/Practical-RIFE
RIFE devs say "For anime scenes, it is recommended to choose 4.22.lite, and for real scenes, it is recommended to choose 4.18."
So i would go with 4.22_lite v2 cause it's fastest recent lower computational cost model.

Wasn't this a great time to fully switch to the v2 models?
Or are there certain scenarios where they actually perform slower than v1 models?

25

(9 replies, posted in Using SVP)

nielvm wrote:

No one? :-(

If madvr is too slow, maybe try MPC VR or mpv instead?
https://www.svp-team.com/forum/viewtopi … 359#p85359

Here there are some parameters that add some metadata, not sure if it has your desired effect:
https://www.svp-team.com/forum/viewtopi … 885#p84885

If you have a non-HDR video, you can enable Nvidia App's HDR filter on it by using https://www.nexusmods.com/site/mods/781
This should display any non-HDR video in full HDR.