Search options (Page 2 of 17)

Chainik wrote:

BTW: if you just replace vsmlrt.py with the latest git, then it will use V1 models instead of V2

Yes, cause in december 2023 the dev updated the signature of the RIFE method:
https://gyazo.com/bde7edb2b4deb80294dbbaf71b757cc2
but he didn't add it as last element of the method so please fix it by updating helpers.py to send video_player True or False as 10th parameter:

return RIFE(clip,multi,1.0,None,None,None,model_num,backend,ensemble,False,implementation)
or
return RIFE(clip,multi,1.0,None,None,None,model_num,backend,ensemble,True,implementation)
(not sure which one is best for SVP)

Chainik wrote:

I'd say this's because of color space converted back and forth, noticeable in a very high contrast areas only.
Probably
...and your "shaking" is not like Blackfyre's V2 shaking, which is quite obvious not only on those lines but in a whole frame

Yes, i think you're right. I tried to simplify the base.py and generate.js and ended up with this:
https://gyazo.com/5f8efd7ead2c79d6a3afeaa852161184
but micro shaking still persists. Which confirms that it's caused by the color space conversion required for Vapoursynth.
Easiest way to fix it would be to allow Vaporsynth to also apply the same conversion process on the source frame too.
This way all outputed frames should line up and 100% fix the micro-shaking.
Is this possible? (even if it will increase the computational processing needed)

Blackfyre's V2 whole-frame obvious shaking takes priority, though.
Thanks again for putting the time and effort to look through the magnifying glass.

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.

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)

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.

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)

the onnx file is available now

just a bug fix for a rare situation RIFE + HDR + SVP's tone mapping

new release

4.25beta - 21M - 2024.09.19 | [Google Drive](https://drive.google.com/file/d/10RhXyy … share_link) | I am trying using more flow blocks, so the scale_list will change accordingly.

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.

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.