Search options (Page 3 of 9)

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)

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.

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

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!

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.

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

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.

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! 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.

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

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.

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

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

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)