RTX 4090
The settings from UI are enough.
But you can play around with other relevant settings if you're really really bored:
https://www.svp-team.com/forum/viewtopi … 352#p83352
You are not logged in. Please login or register.
SmoothVideo Project → Posts by flowreen91
RTX 4090
The settings from UI are enough.
But you can play around with other relevant settings if you're really really bored:
https://www.svp-team.com/forum/viewtopi … 352#p83352
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
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
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
flowreen91
> When trying to transcode ... to see the difference between scene changesHint: 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?
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
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.
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.
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
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!
.dll attached
gerappa's reaction:
https://gyazo.com/a7a6cfd662e826dac89d6b08adf9bd4c
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?
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?
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!
@flowreen91
Made the line change ("True"), nothing works.
Try with these:
https://drive.google.com/drive/folders/ … SzUp1SAzbx
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.
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.
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.
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.
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
The developer does not fix this error and wants a high-frequency monitor))
Poor developers, they haven't heard of 60 fps yet.
how do I force MPC-BE to always start with RIFE?
Hmm maybe Drakko can explain here what to do.
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 ![]()
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.
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
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.
SmoothVideo Project → Posts by flowreen91
Powered by PunBB, supported by Informer Technologies, Inc.