Chainik wrote:

dawkinscm
> If you have to use Rife v2 and have picture shaking issues then updating vslmrt makes sense.

only for TRT>=9
with TRT8 updating vsmlrt.py most likely does nothing
only difference between SVP's vsmlrt.py and current master is one line:

# TensorRT 9.0 or later
"ONNXTRT_Broadcast_*:fp32"

After further investigation it seems the v2 issue is caused by old .dll files.

Out of the box svp with rife model 4.9 v2 with tree wiggle present:
https://gyazo.com/67445b08ae0aa2a214e8cb054e051b1b
Out of the box svp with rife model 4.9 v2 with tree wiggle fixed:
https://gyazo.com/61d5906c4bbbe4887171fd5724c6d4ed

If u override vsmlrt-cuda and vstrt.dll from rife folder with:
https://github.com/AmusementClub/vs-mlr … 4.test2.7z
Issue gets fixed.
If u downgrade back to:
https://github.com/AmusementClub/vs-mlr … 14.test.7z
wiggle issue will reappear.

You can check the example here:
https://drive.google.com/drive/folders/ … sSi1Kl8tSn

Please compare the differences and address this Rife v2 issue when u have time.
Thanks a lot @Chainik!

Chainik wrote:

dawkinscm
> If you have to use Rife v2 and have picture shaking issues then updating vslmrt makes sense.

only for TRT>=9
with TRT8 updating vsmlrt.py most likely does nothing
only difference between SVP's vsmlrt.py and current master is one line:

# TensorRT 9.0 or later
"ONNXTRT_Broadcast_*:fp32"

You are actually right! We were looking at commit messages only and we got confused. Sorry for that!
I need to check better what exactly fixed it.

Guide for updating RIFE to latest TensorRT from 3 days ago: https://github.com/AmusementClub/vs-mlrt/releases

Step 1: Download https://github.com/AmusementClub/vs-mlr … uda.v14.7z
Step 2: Go to C:\Program Files (x86)\SVP 4\rife\ and move the following to a backup folder: vsmlrt-cuda,vstrt.dll,vsmlrt.py
Step 3: Open vsmlrt-windows-x64-cuda.v14.7z and copy vsmlrt-cuda,vstrt.dll,vsmlrt.py in their place

Step 4: Edit vsmlrt.py replace line 1821
old:
tempfile.gettempdir(),
new:
os.path.expandvars("%APPDATA%\\SVP4\\cache\\"), #!SVP

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

Step 6: Enjoy 10-15% performance drop caused by upgrading to latest code!

Noteable issues:
Your PC might not have the power to 2x a 4K video, and mpv might display desync errors that cancel SVP interpolation https://gyazo.com/a4714c85227b5b596a5f71084b5c2fae
so u should test it with a frc.frame.resize -19201080 or lower

pensioner600 wrote:

How can I change the TRT version?

pensioner600 if you would like to update vsmlrt to fix the v2 picture shake, follow the instructions from here:
https://www.svp-team.com/forum/viewtopi … 735#p83735

dawkinscm wrote:

There was a bug with Rife v2 which has been fixed since vslmrt script 3.18.4 released November last year. I think this bug caused picture shake issue.

Details about how they fixed it back then on 3.18.4:
https://github.com/AmusementClub/vs-mlr … 746eaad885

dawkinscm wrote:
pensioner600 wrote:

I also noticed that ALL versions of V2 give the entire picture a shake,

There was a bug with Rife v2 which has been fixed since vslmrt script 3.18.4 released November last year. I think this bug caused picture shake issue.

Should SVP devs upgrade the out of the box vsmirt script so they will fix it for all users?
(knowing that non-lazy users might play around with v2 versions for that extra performance and run into that bug)


Chainik wrote:

one more time, what is the exact point of "v2"? hmm

it's not-faster or even slower, and it takes more RAM. so, why?
just because "v2" is cooler than "v1"? big_smile also tensort rt v10 is cooler than v8...

Never noticed, nevermind then. xD
If the upgrade to it would be safe and not create other issues, it would be nice for current SVP to be forward compatible with the future v2 models that they create.


dawkinscm wrote:

While it's no longer significantly faster, the release notes say it reduces "PCie traffic flow". From personal experience this helps a lot for real time processing and provides more GPU headroom.

I'm experiencing the same thing on my 4080. Our GPU is more bottlenecked by PCIe traffic flow than RAM at this point.
End goal should always be a stable product that users would brag about how good it is. "Random picture shake" effect when watching movies should not be one of it's downsides.

RickyAstle98 wrote:

Just this issue happens no matter what TRT installed, I have exactly same issue, and my friend with almost same PC build too, but reencoding some HEVC sources back AVC again, I said earlier its user related issue a bit, its only realtime playback bug, which mostly use, but not prerendered, I dont want render any movie or TV episodes, you maybe not facing this issue!
This is how issue look like (video is predelayed for showcase purposes) >
https://drive.google.com/file/d/1tGmkW6 … ojEPp/view

pensioner600 wrote:

I noticed that setting the scene change threshold (rife_sc) to 100% is a very bad idea. And for some reason I noticed this specifically in The Last of Us)) At the change of scenes from dynamic to dynamic, it happens, I don’t even know what to call it, back and forth for a moment. This happens at any high values

Ricky did u try to fix it with lower rife_sc values as pensioner600 mentioned?

gtl.spam wrote:

RIGHT  seek  5 exact
LEFT   seek -5 exact

No clue why these commands don't do anything.
If i add following in mpv.conf it starts seeking in increments of 5 seconds just like you mentioned:
hr-seek=yes

aloola wrote:

also for mpv I found this is a good shader for anime/real-life videos https://github.com/cunnyplapper/CuNNy/t … r/mpv/fp16

Aloola I tried the CuNNy-8x32-DS.glsl from your suggested link but i still see lots of blur compared to this one:
https://www.svp-team.com/forum/viewtopi … 264#p84264
Do you know a CuNNy shaders combo that might improve visual clarity too? (i hate seeing blurred pixels in games and videos)
Thanks!

RickyAstle98 wrote:

just reencode files, voila!

Please attach a 1 minute of the badly encoded video and 1 minute of the fixed encoded video for future reference.
That way we can compare the differences in how RIFE runs on our system. Thanks!
The car moving backwards is funny as hell. xD

RickyAstle98 wrote:

How to trim source bad encoded video without reencoding? tongue

Nevermind, link the full version for that one then.

RickyAstle98 wrote:

you can upload your entire rife folder from SVP package

We can safely assume average user has the default out-of-the-box SVP installed. Easier to get it by doing a fresh install.
Provide the devs a badly encoded video and they should be able to find the code to fix it. No need for you to keep investigating it.

RickyAstle98 wrote:

2) No you can play clip on anything

Well if the devs could have reproduced it on anything then they would have fixed it already >_>

110

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

RickyAstle98 wrote:

I found a temporary FIX for my issue, I detect RIFE prerendered video has no issues while playback, only realtime playback (even just only 24>48 hd source, easy for 4070 isnt it?) improper encoded movies MKV containers broke models frame handling, because I reencoded same video to MKV back again, and voila no issues! Also this is HEVC issue, LOL!

LOL! Well done for finding the origin of the issue.
@Chainik can u add something from SVP side to correct/prevent/fix this blocker issue?
We don't want other SVP users to go through all the stress of trying to figure it out like Ricky just did.

111

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

RickyAstle98 wrote:

2) Начиная с моделей 4.9 по 4.16 кадры будто сдвигаются в обоих направлениях, видео перестало быть плавным

Hmm, did you try these too in order to fix the frames stutters?
1. stop using Lossless Scaling on top of SVP
2. change MPV config to prevent additional frame blending like:
video-sync=audio
interpolation=no
gpu-api=d3d11
hwdec=no
3. RIFE GPU threads = 2 (can interpolate better than 1 thread)
4. frc.frame.resize to smaller resolution until your GPU has enough extra bandwidth for the worse case scenario interpolation scenarios
5. check if issue persists on v1 without performance boost (in case there are major internal differences between that and v2 with performance boost that we don't know about)
Compare it on a basic predictable panning scene like:
https://drive.google.com/drive/folders/ … nG0qJnlw4I

According to
https://www.vapoursynth.com/doc/functio … esize.html
https://chat.openai.com/share/f97b59fe- … 6333e9422b
it seems Spline64 is max computational max quality option.
(I'll use that from now on locally, thanks Chainik!)

pensioner600 wrote:

maybe I missed something

Please compare if there are any noticeable performance differences if you switch to software decoding here:
https://gyazo.com/d54298fdce3238ddb7502698bfba9ad3 (i am just curious)
Overall your settings are great. Good job!

RickyAstle98 wrote:

5c. There is no point in 240 frames because RIFE will encounter the problem of the SVP algorithm, where excessive interpolation starts duplicating its own created frames (depends on the resolution)!

As long as the two source frame images are not identical, RIFE will try to make a smooth transition between them so it will generate all the intermediary frames. If you set Scene change threshold 100 it will not duplicate frames.
If you set a low Scene change threshold like 1-15 then it will compare the two images and it might come to the conclusion that the difference between the two source images is big enough that it will consider it a scene transition.
When it concludes that it is a scene transition it will stop generating intermediary frames and start duplicating/reusing the same source frame so instead of a smooth transition it will "teleport" to the new source frame instead.
So use a high Scene change threshold value (or 100) for 240 fps+ to address this problem.

dawkinscm wrote:

BTW Is the number being used in your attachment 2560x1440 resolution?

No, i just searched the resolution pensioner600 was asking for.
For 240 fps RIFE we must go much much lower than that.

dawkinscm wrote:

I found I had to turn SCT back for best overall smoothness.The default value of 10 works best although 12 works better for one particular instance. YMMV.

Interesting. Are you talking about this particular instance? https://www.svp-team.com/forum/viewtopi … 121#p84121
Share the video if not.

pensioner600 wrote:

Can I ask you a few questions?

1. Both work, MPV slightly faster.
2. Both work. Use which one you have better results.
3. Search "resize" in settings and specify your exact resolution downscale value https://gyazo.com/755782ab2c201f627031aa450509fa10
    Try to add various shaders to regain visual quality.
    Probably not possible to apply the mpcVR downscaling shaders before SVP resize. Developers might know more.
4. 2 threads+, enabled. Use which one you have better results.
5. Ensemble = testing purposes, ignore it.
    V2 = faster than V1 because "v2 models handle paddings internally and reduce PCIe traffic flow", use with Performance boost enabled. Always use this.
    Lite = uses less resources, less precise, lower quality than non-Lite. It's ok cause allows 4K enjoyers to watch at 48 fps.
    Newer versions = usually smarter AI model so better smoothness
    https://www.svp-team.com/forum/viewtopi … 301#p84301
6. Search "rife_sc" in settings https://gyazo.com/f4966e81c9c0453f82c5c3de86de0b88

elocai wrote:

it works fine when I manually select to use the profile

Make sure only VapourSynth Filter has the "Prefer" checkbox
https://gyazo.com/ebc04ca3f970e73414afff14f1f9bbb2

117

(7 replies, posted in Using SVP)

reconhell wrote:

Any idea how to prevent this?

Latest RIFE says it fixes live action movies interference artifacts:
https://www.svp-team.com/forum/viewtopi … 347#p84347
Try to see if it fixes your issue by getting it from here:
https://github.com/AmusementClub/vs-mlr … nal-models

SHTH34D wrote:

TensorRT does not natively support INT64. Attempting to cast down to INT32

Probably just some information of what it's trying to do, that we have no control off.
Just ignore it, as long as it works.

unreality wrote:

Is there no solution for this?

As aloola said, the GPU doesn't have enough power yet for 24x3
We can only bypass it by reducing how many pixels we send to RIFE by using a resize setting lower than 4K resolution:
https://www.svp-team.com/forum/viewtopi … 264#p84264

unreality wrote:

but the TV does 50hz

Try to search "target" in the Application Settings and specify the exact value of your monitor:
https://gyazo.com/e9ccf345121d821d3180a40625c49bb4

SHTH34D wrote:

The command prompt also says resolution of 3840x2400 when I'm running at 3800x2160. I looked for a way to change that setting but I haven't found it anywhere.

https://gyazo.com/0128486aa19a32c7a565693fb0e84234

SHTH34D wrote:

I'm using MPC-HC with Vapousynth as that is what was recommended on the SVP instructions and by Chanik to me here in the forum for DV at 4k HDR.

Consider exploring MPV as an alternative.
In my experiments, I found that while MPC-HC struggles, MPV seamlessly drops frames and continues.
Additionally, aloola's analysis suggests that newer models demand more from your system, yet they offer substantial enhancements in interpolation. MPV supports the addition of shaders which can significantly improve image quality and sharpness. A clever workaround involves resizing a 4K image to 1080p for swift interpolation with RIFE on newer models, and then applying shaders to emulate the appearance of the original 4K quality.
Although the result won't exactly match the original source, it ensures a smooth viewing experience. Moreover, your RTX 4090 will handle it effortlessly, as upscaling is far less resource-intensive than interpolating a 4K HDR10 image.
Feel free to experiment with these techniques yourself:
MPV upscaling config: https://drive.google.com/drive/folders/ … MSSZq0jJGj

122

(3 replies, posted in Using SVP)

badhomaks wrote:

The video at least seems to run.

Good to know u fixed it.
Always try to run RIFE with "Performance Boost" Enabled so it will reuse the generated cache file. They probably improved something and it takes less and less time to generate.
Never use the ensemble onnx cause it takes an overwhelming amount of processing power compared to the others.

Try latest RIFE 4.15 too because

dawkinscm wrote:

It is a clear improvement over previous models for reducing double images in fast movement.

SVP allows u to fill the gaps between their source frames

Sagan wrote:

For example, Work It Out, Wombats has the characters animate at ~15fps and the video is rendered at 30fps.

but if the animators were cost cutting trolls then not even AI will be able to smooth out their trash animations.

124

(3 replies, posted in Using SVP)

badhomaks wrote:

Internal Error (input: for dimension number 1 in profile 0 does not match network definition (got min=11, opt=11, max=11), expected min=opt=max=7).)

https://www.svp-team.com/forum/viewtopi … 125#p84125
https://www.svp-team.com/forum/viewtopi … 126#p84126

SHTH34D wrote:

I was having the stuttering performance at 50fps, but only 70% GPU usage at x2 (48fps). I have been using 4.9 but will look into 4.15.

I'm getting smooth 300 fps with these settings.
https://gyazo.com/a457e8297485eba27e2596f21d08c399
Try to play around with resize maybe?
https://www.svp-team.com/wiki/Manual:All_settings