Search options (Page 12 of 17)
cemaydnlar wrote:v1.14 v2 is the smoothest version of them all for me somehow...
v1.14 v2 is so smooth that I made sure to back everything up 
cemaydnlar wrote:It gave a weird error while caching but is somehow working without doing that caching cmd again.2nd i don't see any improvement for gpu usage. İt's the same as v.14. Is it normal?
If the messages come after the "profiling" statement then my understanding is that the warnings are part of the profiling process. As for the performance, that might depend on you GPU memory bandwidth. The Nvidia 3070Ti and above start at 600GB/s memory bandwidth. The 4070Ti has the same memory bandwidth as a 4080 at 700GB/s. But he older 3080 and 3090 series cards might perform better with 4.14 "lite" than the 4080 because of higher memory bandwidth. Below this class of card YMMV.
The new technique used for the "lite" versions is potentially a little more accurate than the normal versions but I suspect that GPUs with low internal memory bandwidth will have issues with v14 "lite". I'm keeping it for now and will see what happens further down the line.
Edit:
The figures from @aloola and @RickyAstle98 show that this is a heavy model. But now everything has kind of bedded in, Rife v1.14 "lite" (v2) is using a little less GPU resources than before, down from 94-100% with Rife v1.14 to between 86-92% with "lite" while "so far" retaining the same quality as before. It's also very smooth. YMMV on GPUs with limited memory bandwidth.
So far v14.4 lite uses more GPU than the non lite version. I thought it was may be because of the changes I made but I reverted back to SVP standard configs and it's the same. Maybe there is an issue they need to fix.
Update:
It uses about the same amount of GPU resources but it works in a different way which makes it more dependant on memory bandwidth than GPU resources. I've read up a little on the new methodology and it is interesting the result is that the "lite" version may not be as "lite" before.
flowreen91 wrote:There may be fixes and enhancements in the latest v14 releases which is not in v13. If you're willing to help test, I would try downloading https://github.com/AmusementClub/vs-mlr … 4.test2.7z and unzipping
and the folder
into
C:\Program Files (x86)\SVP 4\rife
I've updated and I don't see any obvious differences. But I have thought about updating for the latest fixes to TensorRT and Cuda so thanks
flowreen91 wrote:Current default SVP installation has 4.6/4.9 v1 models which means average user never saw this jiggling issue.
In the future when SVP devs will want to add the v2 models they will surely update the default old TensorRT libraries too so your average user will never see this issue.
Until then we should follow @cws guide on how to update our own TensorRT library from https://github.com/AmusementClub/vs-mlrt/releases if we want to play around with latest RIFE models:
cws wrote:Right, TensorRT 9.x is in "beta" and not officially released. Still, v13 was released when TensorRT 8.5 was the latest version, when there is a new release of TensorRT 8.x (which is 8.6.)
There may be fixes and enhancements in the latest v14 releases which is not in v13. If you're willing to help test, I would try downloading https://github.com/AmusementClub/vs-mlr … 4.test2.7z and unzipping
and the folder
into
C:\Program Files (x86)\SVP 4\rife
If true then this is not so much a vsmlrt fix as it is a Cuda/TensorRT fix. I think the last time I tried this my Tensor libraries weren't updated but I might use the info above and try again.
Yep. That's where I got the last copy from too. It's configured for Catmull Rom. The ones I saw configured for Mitchell must have been local variations by other users.
Blackfyre wrote:ontop
glsl-shader="C:\Users\Username\AppData\Roaming\mpv\Shaders\SSimDownscaler.glsl"
FYI While I think SsimDownscaler by default was configured for Mitchell, some configs out there have it configured for Catmull Rom.
cws wrote:It's true there's no significant performance improvement, but there may be fixes and other minor improvements.
Specifically, when using v13 (with TensorRT 8.5 / CUDA 11.8) with the v2 models, I can see some blurriness and pixels shifting in the bottom right corner if there is some obvious static content there like a logo. If this is something you can reproduce, try using the latest v14 (with TensorRT 9.x / CUDA 12.x)
Thanks. If you see a particular issue that you want fixing then this does make sense. Especially if you are saying that v14 fixes this issue for you. I still do testing of new models, changing code etc but I think SVP is stable and works well now so I would not recommend most people do this. Why fix something when it ain't broken ?
flowreen91 wrote:dawkinscm wrote:It's a change to the code in base.py. I got this from a previous post by @blackmickey1007 for completely disabling SC.
SVP4\script\base.py
input_m = input_m.misc.SCDetect(threshold= 0.1 or 0.2).
The old line is:
input_m = input_m.misc.SCDetect(threshold=rife_sc)
and changing it manually to 0.1 and 0.2 values translates to:
- selecting "Scene change threshold" from SVP and selecting "10%" or "20%"
- or by going to application settings and search "rife_sc" and set it to 10 or 20 like in following image:
https://gyazo.com/714dd3a8a3159f1ac7f496126d92ee70
dawkinscm i suggest you revert that line change since SVP devs were nice enough to allow us to control it from both mentioned places.
For "completely disabling SC" just set "rife_sc" application setting at 100 to see max smoothness with zero animation stuttering.
Thanks for clarifying. I just used that the 0.1/0.2 examples from the original post. I've tried 100 and other high values before and Rife is smooth with anything from 15% or 100% on my machine.
But the double image issue I'm talking about you may never see this issue depending on the the type of stuff you watch. I want to fix this while keeping the smooth motion which is pretty much impossible. With a low enough value, the stutters disappear but also causes slow pan stutters. My actual setting is a decimal fraction below 10% and rife_sc only accepts integers. Increasing fps actually fixes the issue but causes slow pan stutters and resource issues. The only real solution is for the model to get better and I've noticed a couple of small improvements so hopefully that trend will continue.
BTW I didn't want to say it before without more testing but Rife 4.14 uses a little less GPU resources than 4.12/4.13. YMMV.
I use a number of videos highlighting different artefacts. But Alita might be the best because it has different types of fast movement and exposes a couple of minor artefacts. One of which has been fixed by Rife 4.14.
cemaydnlar wrote:Can you share that setting with me ?
It's a change to the code in base.py. I got this from a previous post by @blackmickey1007 for completely disabling SC.
SVP4\script\base.py
input_m = input_m.misc.SCDetect(threshold= 0.1 or 0.2)
The threshold values are just suggestions. You will need to experiment to see what works for you. You won't find a pefect setting because when you fix double images from fast movement it will break slow panning. When you reset for slow panning you get double images in fast movement. But you can get a compromise which improves fast movement a little without breaking slow panning. I couldn't get even this minor improvement in 4.12/4.13 but 4.14 does seem to be better overall for fast movement so here it was possible.
Rife 4.14 is out. There's fast movement artefact I saw in one movie which is now gone. There are some sc settings I make in the code that work a lot better to reduce a different more problematical fast movement artefact. It's still there, but less so than before. Rife 4.14 seems to be better overall for fast movement.
Blackfyre wrote:ontop
vo=gpu-next
fbo-format=rgba16hf
spirv-compiler=auto
dither-depth=auto
scale=ewa_lanczossharp
cscale=ewa_lanczossharp
dscale=ewa_lanczossharp
sigmoid-upscaling=yes
glsl-shader="C:\Users\YourUsernameHere\AppData\Roaming\mpv\Shaders\KrigBilateral.glsl"
glsl-shader="C:\Users\YourUsernameHere\AppData\Roaming\mpv\Shaders\FSRCNNX_x2_16-0-4-1.glsl"
glsl-shader="C:\Users\YourUsernameHere\AppData\Roaming\mpv\Shaders\SSimDownscaler.glsl"
I'm not going to comment on config for OLED. It's best you experiment for yourself. Here are some points to think about.
dither-depth=auto and spirv-compiler=auto is the default so not necessary
fbo-format is disabled in gpu-next so is not needed and won't work anyway.
KrigBilateral isn't really necessary and although I've never seen it myself it can apparently cause mistakes.
Is FSRCNNX_x2_16-0-4-1.glsl that much better than FSRCNNX_x2_8-0-4-1.glsl considering the extra processing power needed?
Do you need to use both FSRCNNX_x2_16-0-4-1.glsl and SSimDownscaler.glsl? That's a lot of processing and sharpening.
SSimDownscaler.glsl is configured by default for Mitchell but you are using ewa_lanczossharp. So that is not optimal.
You are sharpening in upscale, shader and downscale. Although FSRCNNX might not be doing anything because by default it only works when a x2 or greater upscale is needed. This might be why you can get away with running FSRCNNX_x2_16 and SSimDownscaler which are very GPU heavy.
Some shaders overwrite others so it's best to use append when you want multiple shaders to work at the same time.
Hope this helps a little.
cws wrote:Right, TensorRT 9.x is in "beta" and not officially released. Still, v13 was released when TensorRT 8.5 was the latest version, when there is a new release of TensorRT 8.x (which is 8.6.)
There may be fixes and enhancements in the latest v14 releases which is not in v13. If you're willing to help test, I would try downloading https://github.com/AmusementClub/vs-mlr … 4.test2.7z and unzipping
and the folder
into
C:\Program Files (x86)\SVP 4\rife
According to the info about the code, v14 is no improvement over v13. Having personally tested the v14 versions I would say that if anything they might use a little more GPU resource. Maybe that's because they are designed for AI GPUs.
flowreen91 wrote:dawkinscm wrote:Does changing the code in the way I mentioned do this?
https://gyazo.com/c71046909c565742a9c8b94a6929f11f
For values integers higher than 2 it will play the video track at 2x 4x 8x the speed while sound track would still be played at 1x.
For values lower than 2 it will crash with error 'fractional multi requires plugin akarin (https://github.com/AkarinVS/vapoursynth-plugin/releases) version v0.96g or later.'
Try to play the video with MPC-HC if you want to see big error logs on your screen when you test with different values.
dawkinscm wrote:after a few seconds the screen goes blank
that's what happens when you run out of video track 
follow aloola's suggestion and just select your FPS from the top right
Now that you have said it is obvious. I already knew what multi does in theory. But what I didn't realise was that in practice it directly relates to the fps which again is now obvious. Thanks
As stated in the docs, the v14 test releases are not designed for our GPUs even though they will work. SVP is not and should not be using them
aloola wrote:why do you need to change it there when you can easily do it here?
Thanks but that's not what I'm trying to do. Or at least I don't think that's what I'm trying to do. Does changing the code in the way I mentioned do this?
From looking into the rest of the code I decided to set multi to an odd number in the Rife return function and it no longer crashes. But it no longer removes the double images either. Any help @Chainik or other dev would be appreciated
Hi
I want to change the value of "multi" which I think increases the number of frames? In helpers I can replace multi with an integer the Rife return function which works. But then after a few seconds the screen goes blank then it looks like Rife stops working. I have changed it in vsmlrt but it has no effect. I assume that is because the variable is being set somewhere else.
I see rife_num and rife_den set in the script generated in APPDATA which is used by multi elsewhere.
Xenocyde wrote:Deleted, redownlaoded, still doesn't work. Do I need some new version of Python or TRT maybe?
Nope. As long as you have downloaded the latest version of SVP, it comes with everything you need. I have manually modified some things over time and still do occasionally. But after the recent updates, I only do it now for experimentation because it's really not necessary any more. If I was in your position I would uninstall everything and start again, especially the Rife model folders. Once SVP is set up it just works for everything up to Rife v4.13 v2.
Xenocyde wrote:Decided to test 4.13 and 4.13 v2.
4.13 works well, Win resource monitor shows ~50% GPU utilization regardless of the video resolution. Also, the 4.9 model included with SPV by default now has almost the same performance, mostly sitting at ~50% regardless of resolution.
I'm using my GPU heavily and can easily hit 100% usage with 4.12.4.13 but max out at 80% with 4.9. So maybe you don't see it under lighter loads?
Xenocyde wrote:Decided to test 4.13 and 4.13 v2.
4.13 v2 doesn't seem to be working, however. Every time I try to play a video, it compiles the cache file and after around 50 seconds it stops and the video plays without RIFE. Can't really see if it gives an error cuz the window closes fast.
Make sure you have a 4.13 onnx file in the "v2" folder. If you do then delete it and any files created by it, download the v2 onnx file again and put the new onnx file into the "v2" folder.
aloola wrote:currently, the best quality that almost gets rid of the soap effect is models 4.12 and 4.13.
my recommended models are: 4.6, 4.9 and 4.13
The Soap Opera Effect is exactly what you are trying to get. If you "get rid of the soap effect" then it's not working.
flowreen91 wrote:My suggestion would be to delete cache folder from here:
"C:\Users\username\AppData\Roaming\SVP4\cache"
every time you update rife models and let them generate fresh.
This is not necessary. In the SVP rife folder, just replace the onnx file for the model you want updated then delete the generated model and engine files. This will trigger regeneration. But if you are using model names that are different to the actual model being used then I don't know since I stopped doing this some time ago.
flowreen91 wrote:A v2 jaggedness/zigzag bug was fixed on 3 November
It was never a v2 issue, it was a model issue. The only v2 issue that has been recently fixed was lower quality output from source material over 2k.
RickyAstle98 wrote:
They have pattern match and random zigzag artefacts, where too many same lines onscreen or objects, interpolated by error too, regardless of the overall frame!
Model 4.9 almost eliminates that effect, even with very low frame rate videos, but more GPU sensitive...
This is correct. But some users may not have seen the issue depending on the videos they are watching. A good example of this effect is the Blade Runner 2029 intro with the patterned landscape. The zigzag artefact can be seen clearly just before the ship flies overhead with v4.6. but is minimised and only occurs once the ship flies over in v4.9. In v4.12 the artefact is gone.
scb wrote:So what about 4.13v2 lite, how does that rank?
Don't worry about the Lite versions, at least not yet. If Rife 4.9 v1 or v2 works for you then stick with that. if it's too much then use Rife 4.6 v1 or v2. But if you have a 3090 (or maybe 3080) or above then you can also try 4.12/4.13.
RickyAstle98 wrote:What happens when someone upload onnx packages for 4070 users? Will work for anyone who has the same GPU or not? I have v1/v2 prebuilt for HD/FHD sources with TRT boost enabled!
What about reverse engineering method for 4060Ti and 4060 owners too?
Average onnx build time v1 ~1/1.5 min HD/FHD
Average onnx build time v2 ~2/2.5 min HD/FHD
There are no specific onnx builds for 4070 or any other users. What you have are builds that the 4070 has enough power to process. In general, higher build numbers tend to require more powerful GPUs. I think Rife 4.6 and Rife 4.9v2 are you best bets but other 4070 users might be more helpful here.
Posts found: 276 to 300 of 425