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

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

Out of the box svp with rife model 4.9 v2 with tree wiggle present:
https://gyazo.com/67445b08ae0aa2a214e8cb054e051b1b
Out of the box svp with rife model 4.9 v2 with tree wiggle fixed:
https://gyazo.com/61d5906c4bbbe4887171fd5724c6d4ed

If u override vsmlrt-cuda and vstrt.dll from rife folder with:
https://github.com/AmusementClub/vs-mlr … 4.test2.7z
Issue gets fixed.
If u downgrade back to:
https://github.com/AmusementClub/vs-mlr … 14.test.7z
wiggle issue will reappear.

You can check the example here:
https://drive.google.com/drive/folders/ … sSi1Kl8tSn

Please compare the differences and address this Rife v2 issue when u have time.
Thanks a lot @Chainik!

Thank you for this by the way!

Fixed the small flickering that was happening on static objects such as the mountain in the background at the start of Shang Chi and the Legend of the Ten Rings, or the embedded text in shows like Shogun for example.

Both issues fixed and also 4.16 Lite drops hundreds of frames for me at 4K, while 4.16 Lite (v2) works flawlessly without any dropped frames at 4K x2 with my RTX 3090 and my configuration.

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.

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.

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

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

Out of the box svp with rife model 4.9 v2 with tree wiggle present:
https://gyazo.com/67445b08ae0aa2a214e8cb054e051b1b
Out of the box svp with rife model 4.9 v2 with tree wiggle fixed:
https://gyazo.com/61d5906c4bbbe4887171fd5724c6d4ed

If u override vsmlrt-cuda and vstrt.dll from rife folder with:
https://github.com/AmusementClub/vs-mlr … 4.test2.7z
Issue gets fixed.
If u downgrade back to:
https://github.com/AmusementClub/vs-mlr … 14.test.7z
wiggle issue will reappear.

You can check the example here:
https://drive.google.com/drive/folders/ … sSi1Kl8tSn

Please compare the differences and address this Rife v2 issue when u have time.
Thanks a lot @Chainik!

Would be good if the above is added as an update for those that need it @Chainik

And please update MPV to the latest stable v0.38.0 from 2 weeks ago.

Thank you.

Drakko01 wrote:

I honestly dont remenber what I changed in the old vs-mlrt. Because I run into this problem before

All I done was disable hardware-accelerated GPU scheduling. Restarted the PC, and it built after.

Didn't help though, none of 4.15 versions or 4.16 work at 4K without dropped frames on my RTX 3090

EDIT: This was a 'me issue', performance fixed.

Deleting old comment, fixed the issue.

56

(2 replies, posted in Using SVP)

You should be able to delete the old "Desktop" (your username should be there) from the manager and just install SVP on the new PC

So just scroll down and delete the old PC in the license manager, when you use the new PC that should become the new default.

dawkinscm wrote:
aloola wrote:

4.16 lite has fewer artifacts and about the same performance as 4.9, so if you are using 4.9, time to switch to 4.16 lite

Looking at your screenshots I assume you are talking about animation because they've been trying to improve that since 4.13 (I think). But for live action I doubt there's much difference between the two.

There will always be scenes where differences will be noticeable, even in live action. Improvement at no extra cost is great, that is amazing for anyone that had 4.9 working fine but not later versions, they can now upgrade to 4.16 Lite and use that instead with improved quality.

SHTH34D wrote:

I'm going for Dolby Vision at 60fps

RIFE + Dolby Vision do not work together from the last time I tested. Did something change?

Depending on the mpv configuration, you either get weird flickering, or inaccurate colours.

dawkinscm wrote:

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.

My RTX 3090 was sent for RMA a few weeks ago. Praying a 4090 comes in its place, but either way I will have to wait to test out 4.15

Good to hear there have been further improvements.

60

(4 replies, posted in Using SVP)

OlegYch wrote:

Thanks, Blackfyre

"HDR 10 and 10+ both work fine for me. There is no visible difference between them" - that sounds unfortunate... What's your display model? Could it be that RIFE actually doesn't really support HDR10+ ?

To be clear with this regard, I meant HDR10+ vs Dolby Vision. Whenever I have tested content, there is no difference between them, at least on my calibrated LG C2 and my configuration for MPV. They both look absolutely amazing.

HDR 10 is of course slightly inferior, but with HDR Compute Peak enabled for MPV, it performs pretty well too.

framo wrote:

are there any better models available? smile

Better than RIFE? Nope, nothing that I know of is better right now.

62

(4 replies, posted in Using SVP)

OlegYch wrote:

I see that Dolby Vision support is unavailable with RIFE, is that still true? Does HDR10+ work with RIFE?

Yes, Dolby Vision still has flickering issues with RIFE. HDR 10 and 10+ both work fine for me. There is no visible difference between them when watching on my OLED display using MPV and my configuration setting. So don't worry about no DV support too much.

OlegYch wrote:

Is RIFE required for 4k60fps?

My RTX 3090 can barely do 2x video, so 48FPS at 100% GPU usage

So unless you're getting an RTX 4090, don't expect to do 4K at 60FPS or higher (not sure if the 4080 Super can or not, but you can ask in the RIFE thread).

OlegYch wrote:

Or is it just better quality than regular svp?

Significantly better quality preservation, likes miles ahead of anything else. RIFE is a game changer.

---

The first time you run a different aspect ratio video with any GPU driver update it will take time to build RIFE Cache that takes a while to build, this only happens the first time you run a new aspect ratio though, after that videos play instantly with the same aspect ratio on the same driver versions.

63

(9 replies, posted in Using SVP)

anders.nilsson wrote:

If i get new motherboard in the future that hade Pci E 4.0 insted of 3, if will be a boost to,

With that card, you will get 0 boost going from PCIe 3 to 4

Don't waste money on a motherboard.

antonhavree wrote:

My main priority is to minimize artifacts as much as possible and then make sure it feels smooth and not choppy.

From my settings what would you consider to change for less artifacts?

Looks mostly good. I think it's similar to my settings before I started using RIFE, but honestly I don't remember them exactly as it has been a long time. RIFE through SVP, is a huge upgrade over traditional SVP, but if you watch 4K content at 4K, then I don't think the 2080 is strong enough, I have a 3090 and it's barely enough.

Consider changing Motion Vectors Grid to 28 or 32, the larger it is, the less visible artifacts from what I remember.

Motion vectors precision to One pixel, instead of half.

Artifact masking to 400 instead of 200 (strong is 200, strongest is 1000). Check the image below for how to do that, scroll down all the way until you find your TITLE name there, then go up to fi_masking and change it from 200 to custom value.

Strongest (1000) causes smoothness issues from what I remember, but between 400 and 700 was a great testing place for me.

Here's an image to show you all my settings, based on memory though, as I don't use them anymore.

https://i.imgur.com/tQSh1Vs.jpeg

zxcvbnm821 wrote:

What happens if you use hwdec=no ?

Next time I install a new driver, I'll turn on GSync again and test it.

EDIT:

Also, this goes for everyone, instead of quoting a huge block of text, please just quote the section you want to reply to, or only the important part, and remove everything else.

It makes reading the forum a lot easier.

aloola wrote:

VRR (GSync and Freesync Premium) enabled in the Display and NVCP = Crushed blacks and banding with d3d11va-copy running at 24FPS (even outside the VRR range, so VRR is not even working).

have you tried to turn on "G-sync compatible indicator" in Nvidia control panel?

because I tested with various mpv options, and g-sync always turn on in full screen for me. I also LG C2 48''

the green text on top right is a proof that G-sync is active
https://cdn.discordapp.com/attachments/ … 7ab4d&

ah, I forgot.  press the green button 7 times on your TV remote will show you VRR information. check if the fps there sync with your video fps

You can visually see the difference in smoothness when GSync is working vs when it's not.

But also, you can check using the “Game Optimiser” settings with the LG Remote. When GSync is working, the frame rate corresponds with the refresh rate shown in the Game Optimiser, but when GSync is not working, it shows the highest refresh rate.

That's how I check it.

Regardless, the visual differences when HDR is enabled in Windows between d3d11va-copy and d3d11va occur whether running SVP or not as I wrote in the last post on the last page. So running at 24FPS default, which is outside the VRR range. When VRR is enabled, even when not triggered, it is causing crushed blacks and banding with d3d11va-copy. At least for me with the configuration I posted.

You can test these if you enable HDR under Display Settings in Windows Settings. Assuming you have GSync enabled in NVCP and the TV.

Test it with Ahsoka Episode 1 in HDR if you have that as the beginning sequence in space and the intro itself will show both. The logo's at the start will show banding with hwdec=d3d11va-copy below, and the dark scene after that has crushed blacks. But when you change to hwdec=d3d11va, both issues will resolve as VRR breaks.

ontop
fullscreen=yes
d3d11-exclusive-fs=yes

vo=gpu-next
gpu-api=d3d11
hwdec=d3d11va-copy
video-sync=audio
gpu-context=d3d11
fbo-format=rgba16hf

target-peak=800
target-contrast=inf
target-colorspace-hint=yes

End of above.

NM64 wrote:

I don't suppose this works with the newly open-sourced ZLUDA for running CUDA software on AMD GPUs?

https://github.com/vosen/ZLUDA
https://www.phoronix.com/review/radeon-cuda-zluda

One particularly key interesting point from the Phoronix review on page 3 is that Blender actually ran faster with CUDA + ZLUDA than its native HIP codepath, so it's within reason that ZLUDA could also be faster than Vulkan for AMD GPUs.

^ This comment should be interesting for @Chainik and the devs.

67

(9 replies, posted in Using SVP)

anders.nilsson wrote:

Do i need to register account on nvida and download TensorRT  dev kit?

For RIFE? No, just install the latest drivers. Everything else comes with SVP.

aloola wrote:

have you tried
hwdec=dxva2 and dxva2-copy ?

Without VRR everything works fine, no problems. With VRR I am pretty sure I tried them both the other day as well, and it was the same issues.

I'll test them again next time I update the driver and enable GSync/Freesync

Chainik wrote:

Blackfyre

you'd better ask about the differences between d3d11va and d3d11va-copy in relation to VRR and black levels in mpv's Github.

Thanks for the recommendation, yeah, I'll try to write something later tonight.

EDIT:

Just to narrow it down even further, I just done a lot of testing before I write and report the issue later today.

First, I decreased the code to this:

ontop
fullscreen=yes
d3d11-exclusive-fs=yes

vo=gpu-next
gpu-api=d3d11
hwdec=d3d11va-copy
video-sync=audio
gpu-context=d3d11
fbo-format=rgba16hf

target-peak=800
target-contrast=inf
target-colorspace-hint=yes

HDR Enabled:

No SVP running in the background.

VRR (GSync and Freesync Premium) enabled in the Display and NVCP = Crushed blacks and banding with d3d11va-copy running at 24FPS (even outside the VRR range, so VRR is not even working).

Changing to d3d11va solves the problem. No crushed blacks or banding.

DDU uninstall nVidia drivers. Shut down the PC. Turn off GSync and Freesync from the display. Turn the PC on and install NVidia drivers.

Run again with both d3d11va-copy and d3d11va, no problems at all with both. No crushed blacks, and no banding. Everything running smoothly.

All of this without SVP.

Conclusion:

Just enabling VRR causes d3d11va-copy to crush black levels and introduce banding, even when the video playing is outside the VRR range (my range is 40Hz to 120Hz), with the HDR video playing at 24 FPS.

EDIT 2:

What's with all the crazy details they want. I just want to report an issue that is very clearly written without the need to go into so much detail they are requesting.

I click on Report a Windows Issue and it's full of so much details they want, including a LOG. Also if this is the wrong section, the post will be deleted.

So I got to the Ask a Question section, and it says if you report an issue in the ask a question section, your post will be deleted.

Wtf lol

EDIT 3:

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

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

Chainik wrote:

SVP does nothing

^ SVP Developer btw haha ❤️

https://media1.tenor.com/m/zqHbKTg9NxEAAAAC/ray-liotta-laughing.gif

dawkinscm wrote:

Two things.
First is @Chainik saying that I no longer need to use copy? The manual still says use "copy-back".

I've been using non-Copy (Cuda, Vulkan, and d3d11va) for a couple of years without issues, I've also used them with copy in the past too.

But I know right now there is definitely no issue with SVP doing its thing.

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

dawkinscm wrote:

Second, I thought @Blackfyre said that there was no difference between d3d11va and copy and I didn't see those differences in pictures.

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

dawkinscm wrote:

To me that made sense because it the mechanism should have nothing to do with color.

It's banding and crushed blacks that are the issue. Forget about colour, I don't know why you're so focused on colour, 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, so it impacts colour because black levels are crushed on the video as a whole.

dawkinscm wrote:

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.

RickyAstle98 wrote:

Maybe its SVP issue? Because SVP do some things with HDR contents, converting, recoloring, etc

I don't think it's SVP. It could just be my display as LG C Series are known to have a VRR flickering issue which could be impacting on the picture quality when VRR is being triggered.

So when d3d11va-copy works and the refresh rate drops to 48Hz, it might be causing a VRR issue with the TV where the black levels become raised perhaps.

With d3d11va VRR is broken, so there is no problem with crushed blacks and banding and image appears fine, but not as SMOOTH as with VRR enabled. Because the FPS and Refresh Rate (Hz) are not matching.

RickyAstle98 wrote:

I really dont see a difference, I dont watch HDR content because my panel is fakeHDR sad

I don't mean this to be rude because you were trying to help, but I said the issue is ONLY present in HDR and in SDR there is no visible difference between either of them from my limited testing.

RickyAstle98 wrote:

Do you force video-output-levels to full? Because SVP uses limited color levels by default, and can ignore full levels from NVCP params, my case I dont see any difference in colors/banding...

It's set to full and 10bit from NVCP, but I did not have:

video-output-levels=full

... in MPV config. I added it, but it did not fix the hwdec=d3d11va-copy problem with crushed blacks and banding.

Another thing to note, when in full screen banding is crushed, when I double-click to windowed mode, the black levels are not crushed. So, black levels are crushed only in full screen mode (which is the mode where VRR works).

EDIT:

with the above in mind, I disabled full-screen exclusive by removing:

ontop
fullscreen=yes
d3d11-exclusive-fs=yes

I enabled GSync in both Full-screen and Windowed mode from NVCP.

Opened a video, and when I double-click to enter full-screen (without exclusive mode), black levels still crush.

So it leads me to believe, it's something about VRR with this panel that I have that causes black levels to crush and banding to occur with d3d11va-copy.

The only reason d3d11va works properly, is because VRR is broken with that one.

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.

dawkinscm wrote:

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

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

flowreen91 wrote:
Blackfyre wrote:

Pictures look exaggerated

Nice issue, can you please link us where we can find this specific scene so we can test it too?

The example above in the pictures is Ahsoka Episode 1 with HDR and VRR (Gsync) enabled. The start of the episode sequence is a good dark environment test.

On the LG C2 42"

I don't think this is an issue for VRR monitors or QD-OLED displays though, so I don't think it applies to most people.

It's just a me issue I guess trying to get VRR to work with the C2 + RIFE + SVP + MPV

Also to note d3d11va-copy work fine without HDR enabled, no banding or crushed blacks. With HDR enabled only d3d11va works correctly, but VRR breaks.

EDIT:

dawkinscm wrote:

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.

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

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

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.

hwdec=d3d11va

https://i.imgur.com/5PmmjAB.jpeg

hwdec=d3d11va-copy

https://i.imgur.com/TwPlkb7.jpeg

As to this:

RickyAstle98 wrote:

Anyway if you have GSync monitor with physical module, this issue isnt happen, because renderer now doesnt request backup memory through VRR option!

It's an LG C2 42" which I use as a desktop monitor. It has both GSync and Freesync Premium.

Either way, I am still looking for a solution. Maybe someone else can chime in if they know of a workaround or different rendering method perhaps.