Xenocyde wrote:

So the headset would introduce more lag theoretically? Not sure why that matters. Anyway, what options do you have enabled/disabled in the NV 3D control panel?

It's interesting because I used to make changes to NV3D panel and have exotic configurations but it looks like I've gone full circle everything because is back to default. No changes made to NV3D panel. I've made some (very) low level driver tweaks by disabling Multiplane Overlay and enabling Message Signalled Interrupts but I doubt they would make a huge difference. Yes the headset does create more load on the GPU.

The occasional micro-stutter doesn't bother me at all when compared to what it was like before Rife.

Xenocyde wrote:
dawkinscm wrote:

Nope I stop using v2 a while back.

Then not sure how you're getting that performance difference. Different components? OC-ed GPU? Some config tweaks? You're getting same readings in task manager too?

 
My CPU and RAM have minor OC tweaks but I stopped OC'in my GPU a long time ago. Yes those readings are from the Task Manager.  BTW my GPU is also transmitting the SVP+MPV processed video back to my headset.

Xenocyde wrote:

Are you on V2 then? I took readings from 4.15 non-V2. With 4.15 V2 or 4.17 V2 @1080p, utilization varies wildly between 40 and 60%, seems like non-V2 is more intensive but at least it stays at 60 something all the time.

Nope. I stop using v2 a while back.

Xenocyde wrote:
dawkinscm wrote:

The occasional micro-stutter isn't a major issue of course, but it's surprising that your GPU is hitting 67% with downscaling. For me it's around 30% with the same GPU. I use mpv player.

Haven't actually checked the 4K downscale performance since I don't have a 4K HDR TV and I only get a 4K movie when I can't find the 1080p version. 67% is for native 1080p. I don't have HAGS enabled btw.

HAGS should be off so that is OK. But my previous GPU readings was FHD3D downscaled. With 4K downscaled and playing full ATMOS (which also uses the GPU) my GPU hits 55%.

Xenocyde wrote:

I have an RTX 4080 and I only play 1080p TV series or 4K downscaled to 1080p @2.5X fps with RIFE 4.15. Maximum GPU utilization I see is around 67%. Microstutters are not too often, maybe once every 15 minutes at most.
...
There was a time when microstutters did not occur at all, but who even knows what version of RIFE or what drivers I was using back then.

The occasional micro-stutter isn't a major issue of course, but it's surprising that your GPU is hitting 67% with downscaling. For me it's around 30% with the same GPU. I use mpv player.

Xenocyde wrote:

I had TRT 9.1.2 and decided to give 9.2 a try because I was noticing some microstuttering at times. From what I can see, fast movement might be somewhat improved with 9.2, but microstuttering gets worse. Should I update to latest TRT version or is there really nothing I can do to get rid of microstuttering?

The latest TRT version is noted to have 4x worse performance with Rife. So unlike with other version I haven't even bothered trying.

132

(1 replies, posted in Using SVP)

timharvey wrote:

Hi all, I use RTX 3080 and it works fine with Rife 4.6 but not with Ensemble. Can anyone with experience running with Ensemble give me advice? Or what else does the installation need to do? Thank.

Advice? Don't use it. You would struggle to get it working on a 3090ti never mind a 3080 and from personal experience of using it, I saw zero improvements or benefits.

flowreen91 wrote:
oriento wrote:

4.17 - 2024.05.24 | Google Drive | 百度网盘 : Add gram loss from FILM, need to fully assess the impact.

Gram loss is a type of loss function used in style transfer tasks to capture and preserve the texture and style of an image.
In the context of neural networks and machine learning, FILM stands for Frame Interpolation for Large Motion. It refers to a specific model or algorithm designed to perform frame interpolation, which is the process of generating intermediate frames between existing ones to create smooth transitions, typically in video sequences.
So i think it improves this type of scenarios where the character is hidden temporarily behind an object:
https://github.com/hzwer/Practical-RIFE/pull/23

I have scenes to test this and if v4.17 was an improvement it wasn't very noticeable. But they are still concentrating on Anime so maybe it works better for that.

Xenocyde wrote:

RIFE 4.17 is out with no lite version. Testing now.

L.E.: Not sure what this new version is supposed to improve... I'm getting quite a bit more fast movement artifacts compared to 4.15 and 4.16.

The author says that he is not sure it will improve anything. I tried it first thing and found zero improvements. YMMV.

Chainik wrote:

the file attached there was updated 4 times already
the last time - yesterday

I see now. That was not clear to me which is why I asked. You might want to make it clearer.

But this is great! ASM vertical artefacts are still an issue but it's about as good as I have ever got it to look but now without the stutters. Definite improvements all round.

After a little more testing with v4.15, SC=8% with nvof is generally as good as turning off SC plus it helps with certain vertical fast motion artefacts. But  I'm hoping the next Rife model can improve here because nvof causes problems for another one of my other SC torture files. So back to setting SC higher than 10 or turning it off.

Chainik wrote:

https://www.svp-team.com/forum/viewtopi … 672#p84672
updated svpflow2_vs.dll, default value for scene.limits.blocks set to 40 for RIFE

Is this an official SVP update? When will it become available?

Chainik wrote:

https://www.svp-team.com/forum/viewtopi … 672#p84672
updated svpflow2_vs.dll, default value for scene.limits.blocks set to 40 for RIFE

You're welcome wink

OK another update. My previous tests were all with blend which is how I left it from previous testing. With duplicate frames 8% works better with Spidey and as well as 6% does with dumb algo. None of them are great but I think this is an issue with the model. From previous testing a few months back, setting SC at below 6% with the dumb algo will fix this issue while causing stuttering everywhere else. It's almost as if it turns of SC for that scene.

I hope some of this helps. 8% with nvof and duplicate frames might end up being my default from now on. But then I can find at least one other scene where the best option is SC=100 and the square is solid blue so...?

Chainik wrote:

%APPDATA%\SVP4\override.js

smooth.scene.limits.blocks = 40;

default value is 20
with 40 at least the Hugo intro - the fly over the city and through the train station - is better (almost no scene changes)

btw

smooth.debug.qmode = true;

will draw a color square in the frame corner, when it's red it's a scene change

APOLOGIES I MESSED THIS UP A LITTLE BEFORE. FIXED NOW!
Definite improvements at 8%

- 8% with nvof - Solid green square when Spidey descends.
Still doesn't fix the horizontal fast motion issue (see Amazing Spiderman at 1:52:48). But is otherwise the best overall and smooth with Hugo.

6% with dumb algo best for Spidey.

The others are all better than dumb algo at 6% and 8% respectively. But not as smooth as 8% with nvof or 10%+ with dumb algo.
- 6% with SVP - Flashing yellow/green square when Spidey descends.
- 6% with nvof - Solid green square when he descends.
- 8% with svp - Solid green square when he descends.

Chainik wrote:

%APPDATA%\SVP4\override.js

smooth.scene.limits.blocks = 40;

default value is 20
with 40 at least the Hugo intro - the fly over the city and through the train station - is better (almost no scene changes)

btw

smooth.debug.qmode = true;

will draw a color square in the frame corner, when it's red it's a scene change

how is this easier than choosing "6%" in the gui? hmm

I just switched off the computer damn you wink Switching it back on now big_smile

flowreen91 wrote:
dawkinscm wrote:

Thanks. I've tried various combinations

I think it's easier to test if u go to line 222 from generate.js and delete the following:
    if(profile.rife)
    {
    if(profile.rife_sc==6) rife_sc_algo = 1;
    else if(profile.rife_sc==8) rife_sc_algo = 2;
    else rife_sc_algo = 0;
    }
    else rife_sc_algo = -1;
then replace with following line for "scene change based on SVP's motion vectors"
    rife_sc_algo = 1;
or replace with following line for "scene change based on Nvidia Optical Flow's motion vectors"
    rife_sc_algo = 2;
or replace with following line for "scene change based on dumb frame comparison"
    rife_sc_algo = 0;

Yes that's fine, but it's just a simple conditional so I didn't bother adding code. It was simple enough just to make changes and test.

Chainik wrote:

> NVOF algo fixes vertical motion artefacts but causes problems elsewhere.

It just can't "cause problems". It can only:
a. (_very_ unlikely!) miss the scene change that is actually a scene change --> which shows RIFE's artifacts at this frame
b. mark a scene change where there's no scene change --> makes it choppy where it could be not choppy

that Hugo?

Sorry I was sloppy with my language but at 6% it's 'b' and at '8%' it seems to be a combination of the two.

Yes that Hugo at the intro when the night sky starts to appear. The choppyness sometimes starts earlier but always happens from when the night sky appears onwards.

Chainik wrote:

"6%" or "8%" mean nothing here
IF "6%" THEN USE "scene change based on SVP's motion vectors"
IF "8%" THEN USE "scene change based on NVOF's motion vectors"
ELSE USE "dumb frame comparison"

Thanks. I've tried various combinations including setting SC=100 (turn off?). 6% is a no go. The issues I saw initially with NVOF motion vectors are amplified by the intro to Hugo which is a torture test for SC. The dumb frame comparison is the only algorithm that works for Hugo and works the best all round.

Bottom line:
- 6% no go any algo.
- SC below 10% with the dumb algo fixes the vertical fast motion artefacts at the expense of smoothness.
- NVOF algo fixes vertical motion artefacts but causes problems elsewhere. Hugo just makes those problems more obvious.
- SVP algo doesn't seem to help much.
- Dumb algo works best overall. Smooth with Hugo and everything with exception of "some" vertical fast motion scenes.


I do used fixed 60 fps though, not "To Screen".

Chainik wrote:

Testing RIFE update with SVP's scene change detection added.
Replace script\generate.js, script\base.py and plugins64\svpflow2_vs.dll, restart SVP.

Now THREE different modes are possible, controlled by the "Scene change threshold" profile option:
1. default - old behavior with "dumb" scene change
2. scene change based on SVP's motion vectors - when "scene change threshold" is "6%"
3. scene change based on NVOF's motion vectors - when "scene change threshold" is "8%"

Scene change-related params from override.js should also work, such as smooth.scene.limits.zero, .blocks, .scene (see a short description there - https://www.svp-team.com/wiki/Manual:SVPflow)

UPDATE: svpflow2_vs.dll updated, also supporting blending on scene changes instead of frame repeating.
There's no "processing of scene changes" option in the RIFE profile so you have to set it via 'All settings' - find the profile and set 'fi_scene_changes' to 0 (blend) or 1 (repeat)

I was hoping someone would make a change for below 10% because this is what I was using to fix the vertical fast motion issues I saw but the choppiness it introduced elsewhere wasn't worth it.. 8% works well on fixing those issues, but maybe not quite as smooth on one or two other scene changes above 10%. Still testing. 6% is too choppy no matter what.  Blending/repeat doesn't seem to make much difference.

Update: Did my ultimate test (introduction to Hugo) and below 10% is way too choppy even at 8%. If a similar SC algorithm fix could be applied to 10 or even 12% that would work. But maybe that's not possible because of how it works?

If you don't know where to start with mpv then I'm not sure this site is the best site because it's still a little complicated for a newbie, unless of course you just copy the stuff blind. But you really should find out how each command works because while some of mpv config is knowledge, a lot of it is based on personal preference.

vulcan78 wrote:

would switch to MPV but I can't stand that it's completely barebones with zero UI, zero built in menu, I have no idea what the hotkeys are and I can't configure anything.

I started with SMPlayer for similar reasons smile but you have to set it up to use mpv. The GUI makes things easier, but I remember having weird issues once I started to get a little advanced. I also remember that the manual felt incomplete and to get the best out of it I still needed to Google a lot. Just like MPV smile So I ended up learning enough to start using mpv by itself without SMPlayer.

Here is a page with links to a few GUI based players based on mpv: https://github.com/stax76/awesome-mpv?t … dia-player

But unless you are using SVP to play HDR content then the best case might be to just use the default mpv.conf from SVP which has the bare minimum config you need to work and the picture quality will be decent enough to start with. If you do want to play HDR content then it gets complicated smile

148

(0 replies, posted in Using SVP)

Sorted. Script issue.

Blackfyre wrote:

The purpose of 4K HDR is to maintain that quality, otherwise it is not worth it to downscale imo

You are conflating 4K resolution with the  important technologies of HDR and WCG. Marketers knew that these technologies wouldn't "sell" to the average joe without significant explanation.  But everyone "thinks" they understand resolution so that's the easy sell.


Blackfyre wrote:

What is the purpose of down-scaling? Sure you gain performance, but you lose the quality of 4K, so why not get your content in 1080p and do native 1080p and you can push 3X for example or 4x with RIFE

When I watch 4K HDR content on my PC, I don't see any detail loss at all, even on a very large screen. So whatever loss there is, isn't significant or obvious without pixel peeping. I can also download 1080p HDR rips that look as good as many 4K discs. That's why I decided to re-encode most of my non Dolby Vision 4K discs down from 60GB+ to half or less, saving disc space while keeping 99% of picture quality.

As for my blu-ray collection, I literally can't see any quality loss at all, and for blu-ray, as long as you are using a decent player then you shouldn't either. 4K HDR playback on a PC is a little trickier, not because of the resolution, but because of HDR. Especially Dolby Vision and HDR10+

Blackfyre wrote:

So v2 in some instances definitely performs better, at least with my RTX 3090, I can even downclock and undervolt it and run a completely silent system that does not distract me at all now.

That's why I used v2 for so long. Half the GPU usage, half the noise. But I no longer need v2 now that I'm downscaling.