You are not logged in. Please login or register.
SmoothVideo Project → Posts by dawkinscm
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?
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 
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...?
%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.
%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?
I just switched off the computer damn you Switching it back on now 
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.
> 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 choppythat 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.
"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".
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?
@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.
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 
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 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
Sorted. Script issue.
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.
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+
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.
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.
The bottom line with this is that we are all just trying out stuff and reporting back. We are all learning together.
dawkinscm wrote:Exactly
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.
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.
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 Especially since I can see minor but perceptible differences between v4.15 and v4.15v2 that I don't remember seeing in other models.
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?
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 performanceAre 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.
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
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.
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.
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.
one more time, what is the exact point of "v2"?
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.
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.
SmoothVideo Project → Posts by dawkinscm
Powered by PunBB, supported by Informer Technologies, Inc.
