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.
You are not logged in. Please login or register.
SmoothVideo Project → Posts by dawkinscm
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
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.
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.
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.
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/66Example 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.
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.
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.
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.
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
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?
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
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.
I use MPV to watch content and here are my current MPV Config:
ontop
fullscreen=yes
d3d11-exclusive-fs=yesvolume=100
volume-max=100vo=gpu-next
gpu-api=d3d11
hwdec=auto-copy
hwdec-codecs=all
gpu-context=d3d11
fbo-format=rgba16hfhdr-compute-peak=no
tone-mapping=st2094-40
target-colorspace-hint=yesscale=ewa_lanczos
cscale=ewa_lanczos
dscale=ewa_lanczos
tscale=ewa_lanczosglsl-shader="C:\Users\USERNAME\AppData\Roaming\mpv\Shaders\FSRCNNX_x2_8-0-4-1.glsl"
glsl-shader="C:\Users\USERNAME\AppData\Roaming\mpv\Shaders\KrigBilateral.glsl"
glsl-shader="C:\Users\USERNAME\AppData\Roaming\mpv\Shaders\SSimDownscaler.glsl"
This is strange because I'm pretty sure I saw this config when I looked at your previous code before I apologized. Anyway the mpv devs removed fbo-format from gpu-next some time ago. Other than that, it's interesting that you are using a HDR10+ tone mapping curve. Are you using a Samsung HDR10+ TV?
Lol, we skipped over 4.23, guys. Is that any good?
The onnx files for v4.23 and v4.24 are still available but links to the actual models used to create the onnx files have been removed by the model creator.
4.24 is out, anyone tried it?
Yep and and my advice is don't bother. v4.18 is still the best for live action and even the dev has updated the README to agree.
Just an FYI that v4.23 came out yesterday as a fix for v4.22 but it is still not better than v4.18 for artefacts.
GGGG wrote:Hi all, I am new to this forum, can you please tell me which version of rife is the performance?
https://github.com/AmusementClub/vs-mlr … nal-models
The rife models with "lite" in their name consume way less power.
Be careful. I can't remember which one it is, but one of the "lite" models uses more GPU resources than some non "lite" models.
vs-mlrt 15.3 includes beta libraries for MiGraphX (similar to TensorRT, but for AMD). Those of you with AMD GPUs might want to encourage SVP devs to incorporate MIGraphX. The list of supported GPUs is below:
gfx1030: Radeon RX 6950 XT, Radeon RX 6900 XT, Radeon RX 6800 XT, Radeon RX 6800, ...
gfx1100: Radeon RX 7900 XTX, Radeon RX 7900 XT, ...
gfx1101: Radeon RX 7700 XT, ...
gfx1102: Radeon RX 7600
dawkinscm wrote:Others are saying it is not as good as v4.15. v4.15 is close but not quite as good as v4.18 so it will interesting to hear what happens after further testing.
Yeah exactly, sometimes more demanding translate to worse performance so more negative comment on the hardware/setup more prone to it , sometimes there it's not the case at all , like 4.21 that i think everyone hates. I tweak here and there make so much difference, for example i don't know what change in my setting, for i'm sure that almost all my main options are the same, and somehow my movies improve , the reason maybe stability after the 0x129 microcode, Who Knows.
The dev made no changes to features for v4.22 lite over v4.22 which means that v4.15 and v4.18 are still better. But you may be right that your hardware is benefiting from a less demanding model.
dawkinscm wrote:It came out very early this morning. But v4.22 is not a good model so the lite model will be at best the same but probably worse.
I think this it's not the same for every setup, for me it's very similar than 4.18 and I'll say that I'm some movies my experience was better. Later I will test the new model and see how it performes
Others are saying it is not as good as v4.15. v4.15 is close but not quite as good as v4.18 so it will interesting to hear what happens after further testing.
It came out very early this morning. But v4.22 is not a good model so the lite model will be at best the same but probably worse.
Unless you have a very weak GPU then you are not loosing anything by using copy-back. Plus I'm not sure that "all" of the processing is done in GPU. I use software decoding by default anyway. There was some confusion recently but it looks like you can get away with not using copy-back and mpv (or I think actually ffmpeg) will do it for you anyway. So again, I'm not sure you are gaining anything because it looks like some sort of copy-back process still takes place. Hopefully a dev will have a more definitive answer.
dawkinscm wrote:RickyAstle98 wrote:My actual scenarios
v14test3 320fps / v15.2 310fps (4.4v2 with 1.78 dynamic shape and 320 fps with 2.35 dynamic shape)
Starting models 4.16 everything gets worse, just a performance drops variables from 6 to 12% respectively, the movie dynamic shapes always faster (even when the targeted resolution is slightly higher)So it works better with Performance Boost disabled? Am I understanding this correctly?
Yes and no! Easier explanation - depending on the aspect ratio of the sources, depending on the resolution and the model used, performance can be either increased to 2% or degraded to 12% with or without TRT boost option! Seek performance is night and day with boost enabled! I did not regret that I switched to a new library!
So - with 15.2 you gets maximum 12% performance degradation, but practically is just 6% of that!
OK thanks. So this is basically restating my point about @aloola's stats:
..on average he got around an 8 fps improvement. But this stat should be taken in the context of dev notes that suggest there might be be specific situations where the performance might be slightly worse.
dawkinscm wrote:flowreen91 wrote:Looking forward to @aloola benchmarks for the new TensorRT like he did before:
https://www.svp-team.com/forum/viewtopi … 324#p84324As he said above, on average he got around an 8 fps improvement. But this stat should be taken in the context of dev notes that suggest there might be be specific situations where the performance might be slightly worse.
My actual scenarios
v14test3 320fps / v15.2 310fps (4.4v2 with 1.78 dynamic shape and 320 fps with 2.35 dynamic shape)
Starting models 4.16 everything gets worse, just a performance drops variables from 6 to 12% respectively, the movie dynamic shapes always faster (even when the targeted resolution is slightly higher)
So it works better with Performance Boost disabled? Am I understanding this correctly?
aloola wrote:v15.2 gives me a tiny FPS boost
v14test3 ~150fps vs ~ v15.2 ~158fps, also fixed dynamic shape (Performance boost: off) bug15.2 changelog:
Upgraded to TensorRT 10.3.0.
Fixed performance regression of RIFE and SAFA models starting with vs-mlrt v14.test4. This version may still be slightly slower than vs-mlrt v14.test3 under some conditions, however.
Looking forward to @aloola benchmarks for the new TensorRT like he did before:
https://www.svp-team.com/forum/viewtopi … 324#p84324
As he said above, on average he got around an 8 fps improvement. But this stat should be taken in the context of dev notes that suggest there might be be specific situations where the performance might be slightly worse.
Xenocyde wrote:RickyAstle98 wrote:New TensorRT library!
https://github.com/AmusementClub/vs-mlr … a.v15.2.7zWorth installing over 9.2?
According to my realtime tests and encoding tests, the difference is starting to increase from 4.16 models!
The old models like 4.4 (v1/v2) encoding speed with 2% performance difference and maximum to 12% for newest models!
Fixed my issues? Nope, but now models look smoother a little bit! Seek performance? Variable!
Worth? If you want, you can test, for me new models looks smoother, what happens to you - who knows?!
@aloola already mentioned TRT 15.2 a couple of days ago and as I said at the time, on initial testing, I didn't see anything obviously better when 9.2. But I like finally having libraries that are closer to those used in the latest Nvidia drivers.
SmoothVideo Project → Posts by dawkinscm
Powered by PunBB, supported by Informer Technologies, Inc.