madVR - high quality video renderer (GPU assisted)

[AngelGraves13]

Are you limiting your frames to 3 or less in your AMD control panel? Does it ONLY affect FSE?

[har3inger]

Only affects FSE. It's not possible to limit frames to anything in AMD control panel. This problem with weird queues is the entire reason madshi rolled out a new fix for the d3d11 render code.

[madshi]

Originally Posted by Werewolfy

Sure, here you go

Original

Thanks!

Originally Posted by har3inger

The A/V delay is probably on the order of 25-75 ms. It's slight, but it's there. Has anyone else noticed this problem? Only exists when you use very high present queues in FSE.

Weird. If the queue only fills to 4 frames with the "old" D3D11 mode, then a desync of maybe 15-4 = 11 frames would have been logical.

Originally Posted by har3inger

Radeonpro doesn't actually work on my computer. It can't find the ATI card.

There are a bunch of ATI tweak tools, this was just one which had a nice picture to it, showing the flip queue size GUI element. I suppose most/all of them will have the setting, so you could try a different tool. But if the desync is that small, I've kinda changed my mind and doesn't really expect this tweak to produce a difference. If you had a delay of ~11 frames then it would be a different situation.

Originally Posted by har3inger

For now, I might just go back to using a 3 frame queue for present queue. Honestly, I don't really see any difference between 3 and something huge like 12, and FRC behavior doesn't seem to change based on the queue size. I've read before that you need more frames in present queue for FRC, but haven't actually found this to be the case. What would I be looking for, if it's not working properly at low queue sizes?

If you neither get frame drops nor presentation glitches, and if everything looks smooth to your eyes, too, then all is fine and you can just continue using the small queue size.

Originally Posted by har3inger

This problem with weird queues is the entire reason madshi rolled out a new fix for the d3d11 render code.

The original reason I implemented that was to fix shaky 3D playback. But after I implemented it, I thought it might help with non-filling presentation queues, too.

[Werewolfy]

I've found a really weird issue, I don't know if it has been reported.

The queues are not filling (all of them) when I upscale a video in 2160p using D3D11 exclusive mode (10 bit).
It's the only situation when this issue happens. I have no issues with D3D11 windowed mode or with D3D11 exclusive mode (8bit) or when I select 1080p for the desktop (whatever the resolution of the movie).

I was using Windows 7 x64 and never saw this issue. I've noticed it since I installed Windows 8.1 x64.

[madshi]

Originally Posted by Werewolfy

I've found a really weird issue, I don't know if it has been reported.

The queues are not filling (all of them) when I upscale a video in 2160p using D3D11 exclusive mode (10 bit).
It's the only situation when this issue happens. I have no issues with D3D11 windowed mode or with D3D11 exclusive mode (8bit) or when I select 1080p for the desktop (whatever the resolution of the movie).

I was using Windows 7 x64 and never saw this issue. I've noticed it since I installed Windows 8.1 x64.

That has been reported a couple of times. The usual workaround in the past has been to reduce the number of prepresented frames to 3 or 4 frames. But please try the new "alternative glitch handling mode", maybe that fixes the issue for you? If it does, please double check that you don't get audio/video desync issues. I don't think you should, but since it's a brand new feature, double checking that might make sense.

[6233638]

Originally Posted by madshi

That has been reported a couple of times. The usual workaround in the past has been to reduce the number of prepresented frames to 3 or 4 frames. But please try the new "alternative glitch handling mode", maybe that fixes the issue for you? If it does, please double check that you don't get audio/video desync issues. I don't think you should, but since it's a brand new feature, double checking that might make sense.

For what it's worth, the new glitch handling mode didn't help for me with a GTX 960. I still have to keep my present queue set to 6.

[Werewolfy]

Originally Posted by madshi

That has been reported a couple of times. The usual workaround in the past has been to reduce the number of prepresented frames to 3 or 4 frames. But please try the new "alternative glitch handling mode", maybe that fixes the issue for you? If it does, please double check that you don't get audio/video desync issues. I don't think you should, but since it's a brand new feature, double checking that might make sense.

I tried the "alternative glitch handling mode" but it didn't really help. Sometimes when I move forward or backward (I don't mean when displyaing the seekbar) into the video the queues filled but it's pretty rare.

If I reduce the prepresented frames to 4 frames, the queues fill correctly but I don't really want to modify that... The only combination that doesn't give me dropped frames with interlaced DVD are :
- CPU queue size : 23
- GPU queue size : 14
- Frames presented in advance : 6

Deinterlacing seems to be pretty erratic most of the time.

Originally Posted by 6233638

For what it's worth, the new glitch handling mode didn't help for me with a GTX 960. I still have to keep my present queue set to 6.

Strange, 6 doesn't work for me. I have to use 4.

[har3inger]

Okay, this is weird. I tried turning off FSE and just using windowed FS for longer queues, and D3D11 windowed full screen has a delay, but windowed (downsized 1080p-> 1080p plus window frames) has no delay.

Whatever. Back to tiny queue sizes it is :P

[GCRaistlin]

Jump to time (by clicking on the time scale in MPC-HC) is broken since 0.90.4 (WinXP). To be precise, the first click works but the second one is not and the player may hang after it.
Sample: http://mir.cr/2XNEHWTK

[CarlosCaco]

with d3d11 "old" my queues don´t fill, with the new alternate now my queues fill and the a/v are perfect synced, but i have a slight perfomance loss because the present a frame for every vsync option

i don´t output 10 bit and 3d, so there any advantage for me to use d3d11 ? or should i stay on d3d9?

i´m usinf FSE with the standard settings:

- CPU queue size : 16
- GPU queue size : 8
- Frames presented in advance :8

theres any advantage if i increase my queues? i have the trade quality option don´t render frames when fade... checked

[ryrynz]

Originally Posted by 6233638

For what it's worth, the new glitch handling mode didn't help for me with a GTX 960. I still have to keep my present queue set to 6.

I have a 960 also. For what content and settings? Upscaling to 4k using d3d11 10-bit?

[Dlget]

something wrong with fullscreen scaling.
http://screenshotcomparison.com/comparison/164548

Tested with Zoom control disabled & Only move subtitle to inactive video area.
Video is not cropped.I can decrease width with "Num4" & it looks perfect then.
Why in fullscreen width is increased????hence some content in both side is lost.
How to fix this.

I'm using MadVR 0.9.12 with MPC-BE

[huhn]

can you make a screen with the osd (control+j)?

[Dlget]

Originally Posted by huhn

can you make a screen with the osd (control+j)?

ahh.forgot basic setting.
Anyway solved now.
Thanks

[Aikibana]

A more general question: Does anyone know how to fix the display number ID's?

I'd like my pc monitor to be number one, so it's ID number will STAY UNCHANGED when my second display (tv) is turned on for movie viewing.
My tv is connected via HDMI to the graphics card and always hijacks the ID number one spot when turned on.

The problem, however small, is that I always have to reconfigure the fullscreen options in MPC-HC because the display numbers have changed.

PS: This has no negative impact on my desktop positioning or icons, because I set my pc monitor as the primary default screen in win 10.

Any help would be greatly appreciated

[jmonier]

Originally Posted by Aikibana

A more general question: Does anyone know how to fix the display number ID's?

Windows seems to be a power on to itself for display ID's. I've had occasional problems with this and I've never been able to find a solution other than to have all monitors on all the time.

[aufkrawall]

madshi, have you already taken a look at the latest super-xbr update? Seems like a big deal to me.
There are new versions of Adaptive Sharpen and SuperRes too.

Edit: Latest version on Github is from February:
https://github.com/bacondither/Adaptive-sharpen/

[Sunset1982]

madshi, have you already taken a look at the latest super-xbr update? Seems like a big deal to me.

https://github.com/libretro/common-s...-multipass.cgp

You're right. It looks nice. Maybe Madshi could use it in madVR...

[Hyllian]

Originally Posted by Sunset1982

https://github.com/libretro/common-s...-multipass.cgp

You're right. It looks nice. Maybe Madshi could use it in madVR...

I think you two are a bit mistaken. Those updates are for the xBR shaders, not for the super-xbr ones. They're very different shaders.

Though the new color distance code I'm using on standard xbr might some way improve other filters (including sxbr).

Instead using just luma, I found a source that presents a different way to calc distance between colors. See the source here (thanks to Sp00kyfox): http://www.compuphase.com/cmetric.htm

I played a bit with that formula and modified it a bit for my needs. So, the new xBR shaders are using that and it improves color, specially in sharp red/blue transitions. I don't know if these sharp color transitions are critical in movies as they are for games, maybe cartoons could benefit.

My color distance (a bit different from that source):

// Originally, these are the values
//#define XBR_RED_COEF  2.0
//#define XBR_GREEN_COEF 4.0
//#define XBR_BLUE_COEF  3.0

// These are better for my tastes. Other good combination is (3, 6, 1).
#define XBR_RED_COEF  17.0
#define XBR_GREEN_COEF 20.0
#define XBR_BLUE_COEF  3.0

float df(float3 A, float3 B)
{
	float rmean = (A.r+B.r)/2.0;
	float3 diff = A - B;
	float3 K = float3(XBR_RED_COEF+rmean, XBR_GREEN_COEF, XBR_BLUE_COEF-rmean);

	return sqrt(dot(K*diff, diff));
}

I have a CIECAM02-UCS shader implementation, which are considered the best way to calc color distances. It's just too much calculations for my needs. The results with that new color distance algo are very comparable with this ciecam02-ucs, at least on my tests. I think it's very good performance for much less computation.

Here's a comparison where it's easy to see how the new color distance algo fixes red/blue sharp transitions when compared to the standard color distance algo based only on luma: http://screenshotcomparison.com/comp...4239/picture:0

[aufkrawall]

I think with the reduced ringing, super-xbr is almost as good as NNEDI3, but with much lower performance impact. NNEDI3 is still a bit better regarding aliasing (however, it also seems to remove some of the source on the other hand).
Kudos for your work!