SHTH34D wrote:

Uhhh my virus software is saying this straight up has a trojan in it...

I've been downloading these file for months with not alerts and no one else is reporting this. Which AV are you using?

Rife v4.15 is out. It is a clear improvement over previous models for reducing double images in fast movement. I need to do some testing but I think it uses a little more GPU than previous models because even with v2 my GPU never drops below 100%. Packet drops sometimes happen when starting or when FF/REW but settles down quickly with no further drops during playback. No obvious regressions from previous tests.

anders.nilsson wrote:

I changed the graphics card from gtx 1070 to rtx 4060 and experience much more artifacts especially when it is fence shaped materials, elements, railings, is there any setting in svp I could change to counteract this? or in Nvida control panels 3d settings for the software players?

Maybe with the 4060 you are now trying and watching new things because it is a more powerful card? Are you sure that you are using the exact same settings with the two cards?

RickyAstle98 wrote:

Lets say about RTX per equivalent model performance >
RTX 2070 > v4.4
RTX 3070 > v4.9
RTX 4070 > v4.11

     RTX 4080 > 4.14 (lite) smile

aloola wrote:
dawkinscm wrote:
aloola wrote:

because of this bug https://github.com/AmusementClub/vs-mlrt/issues/72

if you use model v4.7+ you need to turn performance boost on else you will get the error.

Isn't this a separate issue to the TensorRT bug you refer to?  I don't think the use of dynamic shapes reduces the memory footprint enough to help @oriento who is literally running out of memory. Using performance mode reduces the amount of memory being used. Lower number Rife models also use less memory. Maybe for a 20 series card a user should do both by using the SVP default Rife 4.9 which works almost as well as later Rife models but is less taxing on the GPU.

it's the same
performance boost off = dynamic shape
performance boost on = static shape

you can test it yourself with performance boost off + model v2 4.7+

Oh right, good to know. After all this time still learning new things. Thanks smile

flowreen91 wrote:

What i imagine when people enable interpolation from mpv config on top of the movie already being fully interpolated by RIFE:
https://gyazo.com/8ce62ce348609112c567448cb406a223

lol But as I said yesterday, I don't need interpolation to be enabled and it probably doesn't have room to do much. I now use it because it needs to be active in order to set up motion-blur.

flowreen91 wrote:

Please share your mpv.conf solution, other VR users might be interested.

Not unless they have OLED lenses because OLED has an issue with smooth movement. I'm not particularly susceptible to it myself but even I can see that the extra config reduces the OLED micro-stutters. LED doesn't have the same issues. The rest is mostly standard stuff from my Plex mpv config.

#start
input-ipc-server=mpvpipe
hwdec=no
vo=gpu-next
profile=high-quality

#This is standard stuff most of which is not needed because it's the default but I like to play around with them smile
gpu-api=auto
gpu-context=auto
linear-downscaling=yes
correct-downscaling=yes
dither=ordered
dither-depth=8
temporal-dither=yes
deband=yes
pause="no"
no-hidpi-window-scale

#This is config specific to my situation and as some have already seen, it can cause problems even for other VR users because they all use LED lenses.
video-sync=display-resample
interpolation=yes
tscale=sphinx
tscale-blur=0.65
swapchain-depth=1

#standard shader stuff
glsl-shaders="~~/shaders/CfL_Prediction.glsl"
glsl-shaders-append="~~/shaders/adaptive-sharpen.glsl"

After that there's shader stuff that won't work because they aren't designed to work the way I use them because I modified the code. So I haven't included them here because they are only used for special circumstances. I also haven't included any color settings because every display is different.

So after more testing I pretty much have a fixed mpv/SVP configuration for VR. Although knowing me, it won't stop me from tinkering. None of this is strictly necessary because SVP works pretty well out of the box.

For SVP I use Rife 4.13v2 with 12% SCT at 60fps fixed. I'm also using a later version of vsmlrt which has some extra code for playback buffering but this is not compatible with the default SVP helper scripts so I modified it to work.

For mpv the difference betwen using hwdec and not using it is about 1-2% in favor of not using it. YMMV. I also use interpolation with some motion blur. Overall motion was smooth enough before, but fast motion is now almost perfectly fluid so I am very happy with the results. Looking at the SVP manual, is it still the case that SVP runs after decoding but before rendering meaning that mpv is interpolating the output of SVP?

aloola wrote:

because of this bug https://github.com/AmusementClub/vs-mlrt/issues/72

if you use model v4.7+ you need to turn performance boost on else you will get the error.

Isn't this a separate issue to the TensorRT bug you refer to?  I don't think the use of dynamic shapes reduces the memory footprint enough to help @oriento who is literally running out of memory. Using performance mode reduces the amount of memory being used. Lower number Rife models also use less memory. Maybe for a 20 series card a user should do both by using the SVP default Rife 4.9 which works almost as well as later Rife models but is less taxing on the GPU.

scb wrote:
flowreen91 wrote:

We should either use "video-sync=audio" like Blackfyre's configs or nothing at all.

Referring to https://mpv.io/manual/master/

I believe video-sync=audio is the mpv default behaviour.

Yes it is.


flowreen91 wrote:
dawkinscm wrote:

but it still has issues with horizontal slow pans.

If i'm using the mpv setting "video-sync=display-resample" this scene has massive stutters:
https://youtu.be/jZvFEtR8RH0?si=59TEOOJ … m&t=18
We should either use "video-sync=audio" like Blackfyre's configs or nothing at all.

Most configs for mpv on the Internet are out of date at best. But people will copy them verbatim without understanding. Blackfyre's config is his own and in previous comments I noted some unnecessary settings. This is another one, but I only started using "video-sync" myself in the last few days so I'm still learning.

As for the "display-resample" option, I don't need it to be on, but for me it seems to work well in smoothing out some of the remaining micro-stutters even without interpolation=on. But I watch stuff on a large VR screen so I will see micro-stutters that many wont. Because of that, my SVP setup including scripts will be different to most. Everyone's situation is different.

The remaining issue I have with RIFE is the double images for fast motion. What I found is that the higher the frame-rate the less the issue occurs. At x3 frame-rate from the issue is reduced but then I get stutters. But turning on interpolation in mpv removes those stutters and I get the smooth motion back and better fast motion handling, but it still has issues with horizontal slow pans. I like it, but the issue with slow pans annoys me. Maybe if you have a 4090 this might be useful.

211

(9 replies, posted in Using SVP)

MAG79 wrote:

I've checked with my RTX 3060 Ti.
It has 152 Tensor cores instead of 136 in RTX 4060 Ti.
and it has 38 streaming multi-processors instead of 34 in RTX 4060 Ti.
and it has 4864 cuda cores intead of 4352 in RTX 4060 Ti.

So, my RTX 3060 Ti must be faster than RTX 4060 Ti

Not exactly. If you have a 3060ti you probably shouldn't upgrade to the 4060ti for SVP because they have similar performance. The 3060ti has a wider memory bus, but the 4060ti is using the latest generation Tensor cores, SMPs and Cuda cores which makes a difference. For example, an RTX 4080 is equivalent to the previous gen 3090ti so is much faster than a 3080. But the 4080 has less actual Tensor cores than a 3080.

Blackfyre wrote:

Ended up asking it in the Questions Section, so hopefully it wont get removed @Chainik

https://github.com/mpv-player/mpv/issues/13467

If you don't follow the format then they will usually tell you but sometimes the question will just get ignored. It's structured in a way to stop random questions filling up the list.

Interesting. I guess we were all wrong lol But I did ask for a clarification and all I got was answers from everyone except @Chainik hence my assumption. But at least now we know what's actually happening. It is still all good smile

Blackfyre wrote:

You can see in the SVP logs as @Chainik already showed the SVP is active and working with d3d11va. I mean you can test it yourself, switch to d3d11va and test it with RIFE + SVP + MPV

I see now that SVP is doing the copy. But to clarify, I had previously tested copy vs no copy a few times. When using copy I saw was a decrease in performance and the copy buffers not being used which made sense when taken with the default mpv.conf using copy. The default mpv.conf is a little out of date, but I still couldn't see why they would supply a config with a poor performing option like copy. Especially when the manual says the same thing.


Blackfyre wrote:

The whole point of the pictures was to show the difference...

I simply missed it. I didn't see any difference when I looked at it. I do now.


Blackfyre wrote:

the only reason I mentioned colour once at the start then edited it out was because the crushed blacks results in a visible difference in the entire image,

I only focussed on what you wrote. What was edited out afterwards I don't know.

But it's all good smile

Two things.
First is @Chainik saying that I no longer need to use copy? The manual still says use "copy-back".
Second, I thought @Blackfyre said that there was no difference between d3d11va and copy and I didn't see those differences in pictures. To me that made sense because it the mechanism should have nothing to do with color. But I see there is a massive difference in the two pictures which I must have somehow missed. But a possible explanation for the difference would be that it is being affected by SVP which brings me back to my first point.
So still confused.

Chainik wrote:

no magic here, mpv is doing copying automatically in this case:

[   0.245][v][vo/gpu-next] Loading hwdec driver 'd3d11va'
...
[   1.787][][autoconvert] HW-downloading from d3d11
[   1.787][][autoconvert] Converting p010 -> yuv420p10

Now I'm just confused.

Blackfyre wrote:
dawkinscm wrote:

There's working, then there's working properly.

Okay, but what is there to working properly? The interpolation is happening, and it appears as smooth as copy.

So I'm not sure what more can “properly” do in this case. RIFE is doing its job and the frame rate is doubling as I am requesting it to do.

What happens to your performance when you use copy? I assume it goes down?


dawkinscm wrote:

But unless the devs come on here and tells us that the manual is wrong then I'm sticking with "copy".

Blackfyre wrote:

Wouldn't mind some clarification on this too tbh

Hopefully @Chainik can clarify perhaps.

My guess is that the manual just has old information which was perhaps resolved, maybe with gpu-next

Not gpu-next. That has nothing to do with this.

scb wrote:

So should I be using auto-copy rather than auto? SVP appears to work either setting.

Blackfyre wrote:

https://i.imgur.com/XCPunEf.png

There's working, then there's working properly. From the SVP manual:
Only "copy-back" hardware video decoders are compatible with Vapoursynth filters, use hwdec=auto-copy

If the SVP manual is wrong then great we get more performance!!! But unless the devs come on here and tells us that the manual is wrong then I'm sticking with "copy".

Blackfyre wrote:
dawkinscm wrote:

If you are using d3d11va then SVP doesn't work properly because it doesn't have full access to all frames.

Never had such an issue with RIFE + SVP + MPV

Unless a dev comes on and tells me that the way SVP has always works has now changed, then whether you recognise it or not, using d3d11va and not d3d11va-copy means that SVP is not working properly.


Blackfyre wrote:
dawkinscm wrote:

Also hwdec has very little to do with colours which is why you see no differences. But it might have some impact on banding depending on what card you are using.

Pictures look exaggerated, captured with ExpertRAW on my phone. But you can understand what I mean by banding, and the blacks are not perfect blacks, they become very very dark grey, but not perfect black levels.

You're kind of mixing up colour with banding but I get what you mean. I did say that hwdec can affect banding depending on the card and parameters used. What happens if you set hwdec=no? If you still have the same banding then the issue is definitely not the card or hwdec but is probably your display and its setup. If the banding disappears then you need to check your card settings.

Blackfyre wrote:

Testing only with:

hwdec=d3d11va *Prevents VRR but black levels are good, and no banding.

Changed to d3d11va-copy *VRR works but same problem as above crushed blacks & banding

nvdec, cuda, etc all same thing, do not work properly.

hwdec=d3d11va provides the best black levels and no banding, but breaks VRR.

It's weird that people are using d3d11va when the base mpv.conf uses d3d11va-copy. If you are using d3d11va then SVP doesn't work properly because it doesn't have full access to all frames. Also hwdec has very little to do with colours which is why you see no differences. But it might have some impact on banding depending on what card you are using.

221

(5 replies, posted in Using SVP)

Chainik wrote:

> But also mpc-hc is very old

wat? hmm

One of the reasons mpc-be came out was because HC was a dead project. But I forgot that it has been restarted. I've updated my original post.

222

(5 replies, posted in Using SVP)

SHTH34D wrote:

I have an I7-8086K and a RTX 4090. I watch movies on MPC-HC with Vapoursynth, MPC internal renderer, and Internal LAV filter. My performance is very odd, with huge spikes then dropping to zero. It is making movies unwatchable. It is not an issue when SVP is not running. Any help would be greatly appreciated!

You may have to use mpv instead. If you still have issues, even with mpv then there's something wrong and as @flowreen91 says you can try re-installing SVP.

RickyAstle98 wrote:

Im already use mpv player since SVP4 Pro buy, I custom mpv for my preferences, so I cant get extra performance at all? I test d3d11va and RTX 4070 dies at 720@24>144 realtime playback, but d3d11va-copy didnt smile

The reason you get better performance with d3d11va over d3d11va-copy is because with d3d11va SVP can't properly process the frames. d3d11va-copy copies frams to system ram where SVP has full access to them. So unless SVP has changed and somehow has direct access to GPU memory, you need to use copy. But you probably already know this and you were just joking.

Gippy wrote:

I deleted mpv after one day. Horrible GUI and doesn't work with the MadVR renderer.

What made you think that it should work with MadVR?  Running mpv is equivalent to running mpc-be+MadVR and with that flexibility there is a learning curve. Yes it is text based but you can also download gui's for it. There are also gui based players that use mpv as a display engine.

But SVP comes with baseline mpv.conf file so unlike mpc-be, it will just work with zero extra configuration.


Gippy wrote:

VLC is the "for dummies" media player and doesn't have much customization. mpv goes too far extreme in the other direction and is for those who think FFmpeg command line is the greatest encoder. MPC-HC/BE is in the middle and that's good enough for me.

mpc-be is a great media player and a nice middle ground, but mpv just works more efficiently with SVP.   mpv is open source and uses code from other oepn source projects including ffmpeg and even VLC "for dummies".

Xenocyde wrote:

Is MPC-HC better for GPUs like RTX 4080? I'm on MPV but screen is 1080p so don't think it really matters right now. I'm thinking of getting a 4K screen soon, though, so maybe MPC-HC is better for 4K?

No. One of the reasons I switched from mpc to mpv is that it works better with SVP at any resolution.