Blackfyre wrote:

You can read more about them on their pages. But also, if you want an article explaining them, as well as better shaders that are more demanding which I cannot run with an RTX 3090 while using RIFE, have a read through this: https://artoriuz.github.io/blog/mpv_upscaling.html

I tried to download ArtCNN since it says here that it beats FSRCNNX:
https://artoriuz.github.io/blog/mpv_ups … ng_results

When starting a video on my RTX 4080, it froze my mpv for 120 seconds to create a cache somewhere. Once it finished, it loads instantly every time.
Try to get it from here and wait for it to finish caching ArtCNN_C4F32_CMP for 3-6 minutes and it should probably run ok:
https://www.svp-team.com/forum/viewtopi … 264#p84264

donnieyeen wrote:

Did anybody try to manually update the TRT libraries to v15.1: latest TensorRT library? Any benefits over the standard TRT install from SVP?

According to Chainik, we should not upgrade yet cause we only get "10-15% performance drop":
https://www.svp-team.com/forum/viewtopi … 612#p84612
For now i would recommend to upgrade with TRT 9.2 from here which fixes a pixels shake issue on rife (v2) models (IF you are using those):
https://www.svp-team.com/forum/viewtopi … 795#p84795

dawkinscm wrote:

Nowadays I mostly use in-built scalers.

I found this link with upscaler examples really useful:
https://github.com/LitCastVlog/Plex-GLSL-Shaders

the ultimate goal is to improve visual quality, so we will always try to pick the combination that makes it look better overall
can u please explain which in-built scalers combination u use so we can try that too?
i preffer to set max visual quality + resize down until GPU stops dieing, than watch pure image native 24 fps. xD

Chainik wrote:

flowreen91
> When trying to transcode ... to see the difference between scene changes

Hint: press '.' key in mpv to step frame by frame. Or "Ctrl+right" in MPC-HC.

By spamming '.' in following example we can see that the cape scene frames are correctly repeated only for the Image comparison algorithm:

SVP motion vectors:
https://gyazo.com/e72e6ff3a090edd396057d0b26eee3f7
NVOF motion vectors:
https://gyazo.com/1b5a7afb1ceabf2ecd0f4a9c6b250de8
Image comparison:
https://gyazo.com/050c30df626410bde53291b9d8c47f76

Is there anything we can do to increase NVOF and SVP algorithms strength in order for them to correctly detect it and not interpolate that cape scene change?

Chainik wrote:

it's clearly a scene change and SVP do everything right - see f1.jpg before SC and f2.jpg after SC

When trying to transcode with following settings https://gyazo.com/219cab646d448fdd8b58d99d07504a2d with Repeat Frames to see the difference between scene changes i'm getting the following:

DoctorStrange2.SVP_sc06nvofmotionvectors.mp4 and DoctorStrange2.SVP_sc99nvofmotionvectors.mp4 have same file sizes
meaning changing rife_sc value doesn't increase the scene detection strength and they both can't detect the cape scene to repeat it.

DoctorStrange2.SVP_sc06svpmotionvectors.mp4 and DoctorStrange2.SVP_sc99svpmotionvectors.mp4 have same file sizes
meaning changing rife_sc value doesn't increase the scene detection strength and they both can't detect the cape scene to repeat it.

DoctorStrange2.SVP_sc15imagecomparison.mp4 doesn't detect the cape scene to repeat it.
DoctorStrange2.SVP_sc06imagecomparison.mp4 detects the cape scene and repeats correctly the frame to skip interpolating it.

Questions:
1. is that cape scene not detectable by nvof and svp motion vectors? cause it always tries to interpolate it, creating 10 frames of rife.jpg
2. or since they are new functionalities they aren't correctly passed to transcoding functionality?
3. if works ok, is there a way to increase/decrease scene detection strength for nvof/svp motion detector until it detects the cape scene as a scene change to be able to repeat those frames?

Thanks!

You can check the examples here:
https://drive.google.com/drive/folders/ … tb3OOUgkz7

106

(5 replies, posted in Using SVP)

SamE wrote:

If i try to uninstall and reinstall the whole SVP thing, will i lose all my setting and profiles then?

My local SVP4 settings and profiles are located here:
"C:\Users\username\AppData\Roaming\SVP4\settings"
Try to make a backup of it first.

dawkinscm wrote:

Doesn't setting it to 100% effectively turn it off.

Scene change 100% allows rife to interpolate everything all the time.
Scene change at 99% and below enables the selected scene change detector to compare the frames
if a scene change is detected then it will prevent the interpolation by repeating the same frame and creating a "microstutter" in order to prevent visual issues that happen when camera teleports around.

dawkinscm wrote:

I tested using an MPV build from this week with the latest SVP update.

With the MPV update, your mpv.conf file reseted, probably you should apply your previous mpv optimizations to get back to the old performance (if u had any).

New Rife 4.18 here:
https://github.com/AmusementClub/vs-mlr … nal-models

This is soooo cool!
https://gyazo.com/cd0cc66a7e77fc893d0d3cc4e8298b89

gerappa wrote:

Before the topic started i used avisynth

SVP devs please provide the avisynth rife.dll too with same fix applied. Maybe it won't have the seek crash.
Thanks!

Chainik wrote:

.dll attached

gerappa's reaction:
https://gyazo.com/a7a6cfd662e826dac89d6b08adf9bd4c

Chainik wrote:

why exactly you want this?

We want this:
1. to just keep stuff up to date whenever possible
2. to see if gerappa can use 2 threads if that line was turned into a warning:
more specifically it mentions on this commit that they changed the crashing "gpu_thread must be between 1 and 1 inclusive" into a warning:
https://github.com/styler00dollar/Vapou … r9_mod_v14
3. maybe u can recompile the old SVP compatible vs_rife.dll file with that fix so gerappa can check if it unlocks that extra thread?

gerappa wrote:

Change the DLL also didn't worked at all (actually froze the video completely).
just the stupid driver not allow it/limit it (if i understands well). But why?

@SVP devs, for us to correctly use the latest rife_vs.dll file from https://github.com/styler00dollar/Vapou … n/releases do we need to update something else too?

gerappa wrote:

Is there anything i can do about it?

Refund the Radeon RX 7900 XT and get any cheap RTX.
Or downgrade the driver like gerappa managed to fix it here:
https://www.svp-team.com/forum/viewtopi … 001#p84001

According to this video it says that installing "Driver Only" prevents issues:
https://www.youtube.com/watch?v=xCX3acP3At4&t=128s
Does the GPU thread issue persists even in this case?

gerappa try to go to
https://github.com/styler00dollar/Vapou … n/releases
and download each windows .dll from recent releases, rename it to rife_vs.dll and replace the initial "C:\Program Files (x86)\SVP 4\rife\rife_vs.dll"

more specifically it mentions on this commit that they changed the crashing "gpu_thread must be between 1 and 1 inclusive" into a warning:
https://github.com/styler00dollar/Vapou … r9_mod_v14

not sure if it would actually fix anything, but please take a look.
Thanks!

jdg4dfv7 wrote:

@flowreen91
Made the line change ("True"), nothing works.

Try with these:
https://drive.google.com/drive/folders/ … SzUp1SAzbx

jdg4dfv7 wrote:

So I understand it was the correct way to do?

Sounds like you made it work, well done!

From what i see if i revert the following step, the old SVP vsmlrt.py file still works for all models including latest 4.17_lite.

Step 5: Edit helpers.py replace line 52
old TensorRT 8.5:
return RIFE(clip,multi,1.0,None,None,None,model_num,backend,ensemble,implementation)
new TensorRT 10.1:
return RIFE(clip,multi,1.0,None,None,None,model_num,backend,ensemble,True,implementation)

And i didn't see any signficant improvements if i replace it with latest vsmlrt.py file from last week:
https://github.com/AmusementClub/vs-mlr … /vsmlrt.py

So for now we can continue using the old file until somebody notices something.

RAGEdemon wrote:

With RIFE ~4.4/4.6, you can easily get 2X - this will up 24fps to 48fps

For minimum loss of quality we should not use RIFE and just go with the SVP's Automatic interpolation because it's not a resource hog.

Xenocyde wrote:

Unfortunately I can still see microstuttering

I noticed that if i exit specific background apps like TeamViewer, i suddenly get 20-30 extra fps with SVP.
I believe TeamViewer reads the memory and causes a bottleneck even when it's minimized in taskbar.

Xenocyde try to close your 200 Chrome tabs and other background apps and see if u find the specific app that causes that microstuttering. It's good to know.
Try it with the 4.17 lite version cause it's easier on the GPU:
https://github.com/AmusementClub/vs-mlr … nal-models
Or... nevermind, try with other models.

pensioner600 wrote:

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

@Chainik would it be possible to downgrade the out of the box SVP MPC Video Renderer from current version which is MPC VR 0.7.3.2210 down to MPC VR 0.7.1.2172 ?

Pensioner discovered that all newer versions hard cap the frame rate of MPC-HC at ~160 FPS even at 240p:
https://gyazo.com/b843d14264fb4539fe8be37dd94c9c69
while the version he found working seems just fine:
https://gyazo.com/39f0b09b4c266914d9fe57780343a475

You can try it out by downloading it from here:
https://github.com/Aleksoid1978/VideoRe … /tag/0.7.1
and unzipping the contents of it in "C:\Program Files (x86)\SVP 4\mpcVR"
and selecting in Options->Playback->Output MPC Video Renderer https://gyazo.com/7be0464a7540355c1716fa6699c0d6a4

This makes the average user believe that their PC is not strong enough, when actually developers broke something in the video player.

dlr5668 wrote:

I like MPC-HC with super res and built-in switching monitor hz.

We'll still be able to use the amazing RTX Super Resolution so it should be OK.

Or should we ignore this issue cause MPC-HC guide does not recommend using that specific Playback Output?
https://www.svp-team.com/wiki/SVP:MPC-HC

pensioner600 wrote:

The developer does not fix this error and wants a high-frequency monitor))

Poor developers, they haven't heard of 60 fps yet.

Xenocyde wrote:

how do I force MPC-BE to always start with RIFE?

Hmm maybe Drakko can explain here what to do.

Xenocyde wrote:

I removed the # before "disable VSync" from the config file and I can still see microstutters. Let me know if that is what you wanted me to test.

2-3 stutters per 40+ minute sounds actually OK.
In mpv.conf the lines with "#"  in front are actually comments, so u can delete them. I only wanted u to check if u add these to see if it improves anything:

gpu-api=d3d11
video-sync=audio
d3d11-sync-interval=0

"but I was getting screen tears"
If u see these then try above commands while keeping Nvidia Control Panel Vsync enabled.
The commands are meant for mpv to display stuff faster internally big_smile
If no visible improvements, then keep what u were using before that had the most stable fps.

There are specific scenes where RIFE doesn't know how to scene change and might cause microstutters, but otherwise seems fine to me.

Joke: Double your fps target so it will half the microstutters duration.

67% GPU sounds good. Don't think it's a resource issue then.
V2 models give much better fps than V1 models. So u should see significant improvements from using them.

Xenocyde wrote:

Yes, vsync is always on.

Try to set rife_sc to 100 in SVP so it will not cause microstuttering from repeating frames when a scene change is detected.

Xenocyde, could vsync syncing cause microstuttering then? Cause every time i try to test with video-sync=display-resample it breaks the soap opera effect on panning scenes.
Try to test with it temporarily disabled by adding these in mpv config too:

# D3D11 renderer (default) is required for the HDR playback
gpu-api=d3d11
# disable VSync
video-sync=audio
d3d11-sync-interval=0

Removing vsync wait times from the equation should allow the RIFE generated frames to be displayed realtime. Even if u set it to 120 fps on a 60 fps capped monitor. xD

Xenocyde wrote:

is there really nothing I can do to get rid of microstuttering?

Did u try to enable Statistics in Nvidia App and check if you are giving extra breathing room for your GPU?

For example if it mentions your assigned fps target but it shows something like 98% GPU usage and the FPS value keeps dropping under it like this:
https://gyazo.com/1d9f9788ebecaadbca8a74f8ccd5bb0d
then u should resize it down a bit until your GPU usage % goes down and your FPS value is more stable like this:
https://gyazo.com/a4829e2299a9c51fec02e24ff41c8e29
That should lower significantly the instances when micro stutters happen cause of low resources.

Ooh by the way if u accidentally use the vsmlrt.py from 9.2 archive it will fail to find the rife_v2 folder models.
Attaching below the out of the box SVP vsmlrt.py file cause it still works with 9.2 and can also find the rife_v2 folder models.

Hottea wrote:

(i heard this version works best with RIFE 4.15)

Please share where you found this information.

It's easy, to upgrade to the TensorRT version 9.2 from here:
https://github.com/AmusementClub/vs-mlr … /v14.test3
you just have to download this big archive:
https://github.com/AmusementClub/vs-mlr … 4.test3.7z
and then copy pasta these files in "C:\Program Files (x86)\SVP 4\rife\"
https://gyazo.com/53e859fd5306eb8ce5f896bd87b22bd8