Search options (Page 1 of 15)
Blackfyre wrote:@jdg4dfv7
Thanks for all the info, I'll read all of it in detail later, but I skimmed through it and wanted to note that the 4.26 model definitely showed heavy artifacts in certain scenes I tested that were not present in 4.18 and 4.25. I gave the No Time to Die example before, but I noticed it elsewhere too. Maybe I will test again and see how it goes.
Another thing I wanted to note is 3840x1600 is what I call 4K letterbox, but there are a lot of IMAX releases too for the past few years, which are actual full scale 4K (or switch to it in many scenes), this also applies to some TV shows that are full scale 4K and not limited to 1600 vertical pixels.
This is why I use 4.25 v2 for 3840x1600 or lower at x2, and I use 4.16 v2 for full 4K at x2
3090 is only capable of pushing x2 and v2 models perform better than v1
The 5080 news sucks, but I am hoping the 5090 is not ridiculously priced in Australia (but it looks like it will, and I might just stick with the 3090 until it dies out now if the performance difference to the 4090 is not substantial).
If the rumours are true then the 5080 doesn't suck because it will be at least as powerful as the current most powerful consumer GPU on the planet and that would be good enough for me. But if the rumours are true then the 5090 will be so far ahead of it in performance that it will feel like the 5080 sucks.
Blackfyre wrote:This below is basically the reason why the RTX 3090 outperforms the 4080 and 4080 Super with RIFE, someone can correct me if I am wrong:
The RTX 3090 boasts an additional 8GB of VRAM and features a broader 384-bit data bus, surpassing the 256-bit memory of the RTX 4080. Furthermore, its impressive 936.2 GB/s memory bandwidth is a 30.6% advantage over the RTX 4080’s 716.8 GB/s.
That definitely applies to v4.16. But for other models, the 4080's overall performance improvement (also massive efficiency improvement but not relevant here) will probably make up the difference.
RickyAstle98 wrote:dawkinscm wrote:RickyAstle98 wrote:Whats the default align/valign values for SVP4 Pro? I forgot that I used 2x2 all the time, maybe thats why all models starting 4.16 looks fragmentary smooth!
Fragmentary smooth - when a small parts of one large object can be interpolated differently, even being a same large object! For example: faces, 4.4 to 4.16 faces looks buttery smooth, from 4.17 to 4.26 small parts like lips, cheeks, ears and other objects can be separated from the frame! There were cases when the lips moved apart alone, never happens for 4.4 to 4.16 before, also happens when the main object in the frame is interpolated correctly, but all the background moving both axis, looks like one step forward-two steps back frame!
The 4.26 new model is worse than 4.15 lite in Matrix rooftop 3 agents opening the doors, pattern errors on door textures, no door errors in 4.15v2 (both mod32 and mod64 input)!
Too noticeable door errors 4.4 (worst)
Less noticeable door errors 4.9 (okay)
No door errors 4.11 to 4.16 (perfect)
Are you talking about 4.26 lite only because the lite models do behave differently to the normal ones.
I'm not exactly right or wrong. I was just suggesting that there is a difference between a lite model. But yes you are
The 4.26 lite? I dont see 4.26 lite model, where is it? Youre wrong!
I've seen this happen before but if there is no lite model then this is not the case here.
RickyAstle98 wrote:Whats the default align/valign values for SVP4 Pro? I forgot that I used 2x2 all the time, maybe thats why all models starting 4.16 looks fragmentary smooth!
Fragmentary smooth - when a small parts of one large object can be interpolated differently, even being a same large object! For example: faces, 4.4 to 4.16 faces looks buttery smooth, from 4.17 to 4.26 small parts like lips, cheeks, ears and other objects can be separated from the frame! There were cases when the lips moved apart alone, never happens for 4.4 to 4.16 before, also happens when the main object in the frame is interpolated correctly, but all the background moving both axis, looks like one step forward-two steps back frame!
The 4.26 new model is worse than 4.15 lite in Matrix rooftop 3 agents opening the doors, pattern errors on door textures, no door errors in 4.15v2 (both mod32 and mod64 input)!
Too noticeable door errors 4.4 (worst)
Less noticeable door errors 4.9 (okay)
No door errors 4.11 to 4.16 (perfect)
Are you talking about 4.26 lite only because the lite models do behave differently to the normal ones.
From the vsmlrt script dev about the issue with SVP using v4.26:
It's not a problem with the official RIFE repository. I chose 32 to be the minimum requirement for the RIFE wrapper in vs-mlrt, and then the SVP developer adapted this requirement. The v4.26 model now requires mod64 input, and I have updated the code to explicit notify the change, and therefore it is the SVP developer that should update the code.
(this will only affect the "v1" variants, the "v2" variants handle this kinds of resolution requirement automatically
The artefacts I saw before v4.26 are still there but improved to the same level as v4.25. But when I tested DR Strange 2 with v4.26 with the new code, it makes IC behave identically to SVP and NVOF with intermediate Rife frames being created.
Updates:
So far using SVP motion detection for SC seems to work very well with v4.26 and the mod code. NVOF is very similar. What is a little annoying is that you can run the same scene multiple times and see varying degrees of the same artefact.
I can also forward and reverse some scenes when using SVP that previous got stuck.
flowreen91 wrote:dawkinscm wrote:Nope. Still crashes out. I've got the TRT error log and it says that broadcast dimensions must be comformable.
It seems 4.26 also crashes when the width or height of the resized video is not divisible by 64 with:
Attaching files that load both v1 and v2 correctly below.
Just a quick update. I don't like the way v4.26 and the new code is performing. v4.25 with the old code works better. I'm just double checking to make sure.
flowreen91 wrote:dawkinscm wrote:Nope. Still crashes out. I've got the TRT error log and it says that broadcast dimensions must be comformable.
It seems 4.26 also crashes when the width or height of the resized video is not divisible by 64 with:
...
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.
I got nowhere close in figuring this out lol. I will have to take a look at the changes but in the mean time: Damn good job buddy 
dlr5668 wrote:dawkinscm wrote:How does 4.26 work for you with no changes?
I didnt update yet
If the engine was created in less than 15 seconds then it crashed. It looks like it's working. SVP will tell you that it's working. But it is not coz there's an error log generated. When it works, no error logs are generated. BTW I did update but it makes no difference because the version number doesn't change.
oriento wrote:dawkinscm wrote:oriento wrote:the onnx file is available now
Yep. But it does not work properly with SVP. It might look like it is working but the engine parse crashes. Looking at the new vsmlrt script there are a lot of changes and I'm not sure which ones are relevant. Especially since SVP moved some functionality into helpers.py.
i suppose you must change 32 into 64
multiple_frac = 32 / Fraction(scale)
Nope. Still crashes out. I've got the TRT error log and it says that broadcast dimensions must be comformable.
How does 4.26 work for you with no changes?
oriento wrote:the onnx file is available now
Yep. But it does not work properly with SVP. It might look like it is working but the engine parse crashes. Looking at the new vsmlrt script there are a lot of changes and I'm not sure which ones are relevant. Especially since SVP moved some functionality into helpers.py.
oriento wrote:another update (no changelog)
4.26 - 21M - 2024.09.21 | Google Drive 百度网盘
v4.26 is supposed to be the completion of v4.25 training from what I remember so it should hopefully be even better.
Blackfyre wrote:Link not there above, where is everyone getting the Google Drive links for beta and alpha versions? I can't see on github a link to them.
That's because it is not there. The Google Drive link is the Rife model. But it needs to be converted into and onnx engine file before we can use it in SVP. Hopefully it will get done before Monday. If not then it will almost certainly be done by then.
Chainik wrote:just a bug fix for a rare situation RIFE + HDR + SVP's tone mapping
Any fixes coming for SVP/NVOF scene detection? IC works well and is working even better with the latest models.But it would be nice to have a choice.
The v4.25 model is not complete and yet it is still a little better than v4.18. The next version will be the complete model and hopefully be even better
oriento wrote:new release
I've been testing for a bit. So far it might be an improvement and a possible replacement candidate for v4.18 As with the last tested model it works best with a lower SC threshold. But when I do that, Hugo is then negatively impacted.
narkohol wrote:Is there any way to improve the Scene Change detection beyond the default options?
I tried all options available in the interface, but even at the lowest Image Comparision % Threshold I still get a lot of wrong interpolations between scene changes.
Before the recent SVP update, 12% was about right for me. But 10% works best for me after the update. But what you might be seeing is lots of stuttering because 6% is way too low. Unless of course you are watching Anime then I have no idea. If you are watching Anime then 4.18 may not be the best model but I'm not sure.
flowreen91 wrote:Blackfyre wrote:I will put back v1 models and test performance difference now between v1 and v2 properly.
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 478 (mpv or RIFE crashes at 479)
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.
Thanks for the link. It reminded me of the name of the Akarin plugin which makes V1 seek performance similar to V2. V2 is still better if you have a GPU with limited memory bandwidth. Your testing shows that V2 still a little faster overall.
Blackfyre wrote:This explains why I was seeing equal performance before.
To confirm the discussion above, I went to the rife folder and deleted all the models inside rife, and only kept the ones inside rife_v2
RIFE is not working without the v1 models, so basically it means it was just using v1 models even when v2 was selected?
flowreen91 wrote:Attaching sending video_player False to RIFE as dawkinscm suggests in helpers.py
Tested with these above and also rife v2 is not working.
To test properly, remove all the models inside v1, so SVP doesn't fall back to them. That's what I am doing.
Now I need to find a way to make v2 work.
I think I remember Chainik saying that v2 models have become pointless. Especially after the change (can't remember the name, it's a Windows dll) that made it work better. But if you wish to process v2 files then maybe you should compare the helper files from before and after the latest update. From memory, the v2 processing is technically in the vslmt script, but I think the SVP devs essentially moved that functionality to the helper script. But as I said this is from memory.
dawkinscm wrote:flowreen91 wrote:Chainik wrote:I believe that all "fixes" the latest vsmlrt.py contains are included in SVP's one
The v2 shake issue seems to get fixed if u add this on line 1027:
video_player: bool = False,
https://gyazo.com/d7798e1ee97ecfa658d8587466561630
Please take a look.
I think that should be on by default because from what I have read, it might be duplicating some SVP functionality which may explain why the shaking bug occurs.
To clarify, Setting to "True" might duplicate some SVP functionality. I meant' that video_player: bool = False should be the default setting.
flowreen91 wrote:Chainik wrote:I believe that all "fixes" the latest vsmlrt.py contains are included in SVP's one
The v2 shake issue seems to get fixed if u add this on line 1027:
video_player: bool = False,
https://gyazo.com/d7798e1ee97ecfa658d8587466561630
Please take a look.
I think that should be on by default because from what I have read, it might be duplicating some SVP functionality which may explain why the shaking bug occurs.
Chainik wrote:SVP packages updated: TensortRT 10.4.0, vsmlrt 15.4
Thank you. I probably wasn't going to update to 10.4,. But I'm glad that Cuda 12.6 the officially part of SVP. Thanks again
Chainik wrote:4.9 is like 4.xx_lite, 1.5 times slower than 4.6
...and quite a few on here are using "lite" models which suggests that v4.9 might be usable for many. Again, Rife v4.6 makes sense, but I do wonder if seeing some of the major artefacts it creates might turn people off. I know I was having second thoughts until v4.9 came out. Not only did it reduce or remove some of the more obvious artefacts. But it also gave me hope that a better model would arrive some day. Which they did, and if downscaling is used then many users can use the better models too. I don't even need to use downscaling, but for blu-rays I'm getting identical picture quality while using around 25% GPU. So why not?
Chainik wrote:ok, 4.18 is also two times slower, and it's also recommended by the model creator
is it two times better?
> I'm sure this is a rhetorical question
mmm.... yes and no 
trying to figure the best default model now
and it looks like 4.6 is still the best default choice
in fact, every newer release gets slower and slower and slower...
Yes but as you know that is because the models get more complicated. Also Rife v4.18 is recommended based on quality, not performance.
Rife v4.6 makes sense as the default model, but maybe have a look at v4.9. It gets rid of some of the worst artefacts from v4.6 but doesn't use as much resources as v4.1x models. Rife v4.18 is my default but it definitely should NOT be the SVP default because it uses too much GPU.
I don't want to complicate matters, but downscaling enables more people to use Rife v4.1x models. Just a thought
Chainik wrote:btw, 4.24 is two times slower than 4.6
is it two times better? 
I'm sure this is a rhetorical question but the answer is obviously "no" Rife v4.24 is as maybe a bad as v4.6 for artefacts. Being two times slower makes it even worse. However, as I said, even though the onnx files are available, the model creator has removed both v4.23 and v4.24 from view. The last official version is v4.22.
Posts found: 1 to 25 of 375