226 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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...?

Go to forum: Using SVP

227 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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.

Go to forum: Using SVP

228 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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

Go to forum: Using SVP

229 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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.

Go to forum: Using SVP

230 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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.

Go to forum: Using SVP

231 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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".

Go to forum: Using SVP

232 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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?

Go to forum: Using SVP

233 Reply by dawkinscm

(4 replies, posted in Using SVP)

fakel wrote:

@vulcan78
May be useful https://kokomins.wordpress.com/2019/10/ … fig-guide/

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.

Go to forum: Using SVP

234 Reply by dawkinscm

(4 replies, posted in Using SVP)

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

Go to forum: Using SVP

235 Topic by dawkinscm

(0 replies, posted in Using SVP)

Sorted. Script issue.

Go to forum: Using SVP

236 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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+

Go to forum: Using SVP

237 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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.

Go to forum: Using SVP

238 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

Blackfyre wrote:
Chainik wrote:

> And please update MPV to the latest stable v0.38.0

nope, it crashes playing DoVi

Oh wow, that sucks, why would they push that out as a "stable" release. Crazy.

The way mpv is built and in particular its reliance on other large libraries means that "stable" is relative. So even without the DoVI issue I agree that they shouldn't upgrade. If anything they should be one version behind the latest version to ensure stability.

If you wish to use 0.38 then SVP will still find mpv as long as you put the files in the mp64 folder. Just make sure you stop SVP from installing mpv. This is what I do because I use my own mpv builds.

Go to forum: Using SVP

239 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

The bottom line with this is that we are all just trying out stuff and reporting back. We are all learning together.

Go to forum: Using SVP

240 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

Xenocyde wrote:
dawkinscm wrote:

Exactly smile Especially since I can see minor but perceptible differences between v4.15 and v4.15v2 that I don't remember seeing in other models.

So V4.15 is better than V4.15V2 now? Didn't you say that V2 is better?

I would be surprised if I ever said that Rife v2 has better picture quality, but if I did say that then was incorrect. But there definitely was a time when v2 was better/quicker at FF/REW a video, but that is no longer the case. 


Xenocyde wrote:

I tried both and couldn't see any visual difference.

I said the difference was "minor" but "perceptible" and I'm watching on a very large VR Cinema screen so I'm going to see things that others don't. That's why I wouldn't use anything below Rife v4.9.  Over the development time of Rife from v4.6 to v4.15 I've seen artefacts improve to the point where they either disappear or have been reduced.  Vertical fast movement artefacts are still an issue but v4.15/v2 handles those the best.

Go to forum: Using SVP

241 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

flowreen91 wrote:
dawkinscm wrote:

But after downscaling is it still necessary to use v2?

Nope, we can use v1 just fine and never see the visual bug.

Exactly smile Especially since I can see minor but perceptible differences between v4.15 and v4.15v2 that I don't remember seeing in other models.

Go to forum: Using SVP

242 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

flowreen91 wrote:

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

Thanks for the extra testing and I remember now that you also said this in January when I asked why I should upgrade to TRT9. But after downscaling is it still necessary to use v2?

Go to forum: Using SVP

243 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

pensioner600 wrote:
Chainik wrote:

> How can I change the TRT version? And how can I find out the current version? I really don’t like the scene change on any model at any 6%-100% values.

this isn't related to the TRT version at all
TRT version can only affect build time, memory usage and overall performance

Are there any other settings besides rife_sc that affect scene changes? I really don’t like how it works, I’ve already tried many options. It's as if the algorithm in the next scene is confused and momentarily doesn't know what to do. Everything is perfect, smooth as butter, except for this trouble with the scene change.

You're just going to have to experiment and see what works best for you. Most of my movies work well with almost any SC or even turning it off. But I've got a couple that need SC to be set to I had to find a balance.

Go to forum: Using SVP

244 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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"

Noted thanks. I'm currently using v4.15 but if I go back to a v2 model then I will update TRT. Cheers smile

Go to forum: Using SVP

245 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

If you have to use Rife v2 and have picture shaking issues then updating vslmrt makes sense.  I reset everything back to default (minus some script changes) then updated to TRT8.6. Not going beyond that unless someone can show me how TRT9 improves things*. Not sure why anyone would update to TRT 10.

Update:
*TRT9 is required if you are using Rife v2 and have the picture shaking issue.

Go to forum: Using SVP

246 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

Xenocyde wrote:

I've been using V2 or V2 lite models for some time now (maybe 6+ months) and never noticed any shakiness. My vslmrt version is 3.18.16, says it was last modified in December 2023. Does that mean it includes the shake fix?

Yes.


flowreen91 wrote:
pensioner600 wrote:

How can I change the TRT version?

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

No. As @Chainik stated above, this is nothing to do with TRT version.

Go to forum: Using SVP

247 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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?

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. Before I started to use downscaling, I was regularly hitting 100% GPU, but the v2 models would bring that down to 90% or less depending on the model.

But @Chainik thanks for the reminder because it's been a while since I used a non v2 model and unlike previous models, v4.15 seems to handle artefacts a "touch" better than the v2 version.

Go to forum: Using SVP

248 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

flowreen91 wrote:
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)

lazy is harsh lol. But if the issue is vslmrt and you want to upgrade then I would recommend upgrading to the November 2023 script and not later because later vslmrt scripts made changes that require mods to the helper script too.

Go to forum: Using SVP

249 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

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.


RAGEdemon wrote:

Each iteration after 4.4 causes a massive performance hit @~16% for minimal artefact improvement.

I know you are not replying to me but I think your comments are interesting so I hope you don't mind me responding directly to you. As you say, there is a massive performance hit. But you have been very lucky if you haven't come across the horrible artefacts that appear below 4.9.

RAGEdemon wrote:

Above 4.9 is trained mostly on Anime.

Being "trained on Anime" or not doesn't matter if it still results in improved live action motion. Rife v4.9 and above are all smoother and have much less visible artefacts than below 4.9.

RAGEdemon wrote:

What you say doesn't make sense to me. You say you don't use 4.4 because "too much artefacts (not critical but noticeable)", but then you are happy to force downscale all 4K and 1080p content to 1280x720p?! And you don't notice the huge degradation in quality?

I am guessing you don't have a 4K display, or else you wouldn't be saying something so seemingly bizarre smile

To each their own, I guess...

Resolution is important but only up to a point. Although I personally would not downscale to 720p I do now downscale my 1920x2160 3D blu-rays to 1080p.   On a near IMAX VR screen, I've tried both upscaling to 4K and downscaling to 1080p and found no "visible" difference between the two. For actual 4K content there is a difference, but it will only be a problem on very large of screens. For most people watching on a TV, there will be little visible difference unless you decide to stand in directly in front of the screen.

Go to forum: Using SVP

250 Reply by dawkinscm

(2,448 replies, posted in Using SVP)

Done some more testing and I've learned or at least confirmed a few things. Not sure I see any real benefits with Tensor 9 and Tensor 10 seems to be moving further away from us. So I'm sticking with the last non LLM Tensor 8.6.1 along with the latest vslmrt to have the most up to date build defaults. Using BO=5 but I see no obvious difference to the default. 72fps seems to be the sweet spot for me which might be because the thrown away frames reduces the effect of certain fast movement artefacts. There's more but that about summarises it.

Go to forum: Using SVP