madVR - high quality video renderer (GPU assisted)

[madshi]

So here's a new test build:

http://madshi.net/madVRanotherTestBuild1.rar (overwrite the official build with the files from this rar)

Here's a list of changes compared to the last deband test build:

(1) some calibration related fixes and improvements
(2) madVR doesn't dither, anymore, when a pixel doesn't need dithering
(3) fade in/out detection should have less false positives now
(4) fade in/out rerendering shouldn't result in dropped frames, anymore

(Please note that the included madHcNet64.dll is only for calibration purposes. It is *not* a sign of upcoming 64bit support. 64bit support is still not planned any time soon.)

[James Freeman]

Originally Posted by madshi

So here's a new test build:

Here's a list of changes compared to the last deband test build:

(2) madVR doesn't dither, anymore, when a pixel doesn't need dithering

A marvelous core behavior change.
Neeto!

Thanks.

"cnvrgc"

What is that?

[madshi]

Convergence correction. AKA panel alignment correction. For front/back projection users.

[shimaflarex]

With the new test build I get a "creating shader file failed" when opening any video (but the video works fine).

I also get a corrupted and green component only image when using DXVA for downscaling (did not test upscaling).

Using Intel HD 4000 with driver version 10.18.10.3316. Everything was working fine with the previous (deband) test build.

[michkrol]

Originally Posted by shimaflarex

With the new test build I get a "creating shader file failed" when opening any video (but the video works fine)

Can confirm here.
EDIT: The OSD needs to be open for this to happen. Also happens when opening the OSD (CTRL+J) with the file already playing.

Originally Posted by shimaflarex

I also get a corrupted and green component only image when using DXVA for downscaling (did not test upscaling).

Also happens here on Intel HD 4000 with newest drivers (10.18.10.3345). To further narrow it down, DXVA scaling doesn't work with 8bit 4:2:0 color formats (NV12 and YV12), but works with probably everything else.
Worked while tested with 4:2:2/4:4:4 8bit, 4:2:0 10bit and RGB output from LAVFilters.

[madshi]

Sorry, my fault. Here's a fixed build:

http://madshi.net/madVRanotherTestBuild2.rar

[bacondither]

Originally Posted by madshi

(2) madVR doesn't dither, anymore, when a pixel doesn't need dithering

Please explain in more depth please, doesn't madvr use triangular dither and isn't it applied to all pixels and how would you do that selective?

[madshi]

Yes, madVR uses triangular dither, but it's applied pixel by pixel without looking at neighbors. So basically every pixel is handled totally separately. The new algorithm still applies dither the same way as before. However, before applying dither it now checks whether the final 8bit output value happens to be a simple cardinal number with no fractional part. If that is the case, dithering doesn't really help because the pixel is already perfectly reproducing the needed value even without dither. So in that situation dither for that pixel is simply not applied, any longer.

[MSL_DK]

Originally Posted by madshi

Sorry, my fault. Here's a fixed build:

http://madshi.net/madVRanotherTestBuild2.rar

Hi ... With the latest test builds, I experience dropped frames. It is not only with the latest version, it is also with the other you have uploaded. I did not have problems with dropped frames before now. What can I contribute in connection with troubleshooting?

12 minutes in the movie:
18 presentation glitches
121 dropped frames

[madshi]

You can contribute a much more detailed description. When. Where. Under which circumstances. With all videos or some. Which OS. Which GPU. Are any queues (near) empty in the madVR debug OSD (Ctrl+J) when the frame drops occur etc...

[MSL_DK]

With all movies. Windows 7 x64, ATI HD 4800 (1080p, 60 Hz), Intel E8500, 8 GB of RAM. Yes .. render queue 0-6, pressent queue 0-1. I can not manage to see if it's right before I experience dropped frames, or after.

FSE: Yes
Smooth motion: Yes, always

I have not made any changes. But experience a lot of dropped frames with the latest test build.

EDIT:

I have gone back to version 0.86.11 and did not experience a single dropped frame after 40 minutes playback vs 121 dropped frames after 12 minutes playback with the test version.

[leeperry]

First, for the new build!

Originally Posted by madshi

in that situation dither for that pixel is simply not applied

And that would improve PQ? Or simply lower the GPU load?

[ryrynz]

Originally Posted by leeperry

And that would improve PQ? Or simply lower the GPU load?

Technically yes with PQ, but even with dithering disabled I never saw any differences, the color changes are so subtle that I don't think anyone would really notice it. As far as lower GPU usage goes, I'm not seeing a difference with full HD content, maybe 4K might show something. I'm all for efficiency and PQ improvement even if I can't measure it and see it, I know it's there, one step closer to perfection I guess.

Originally Posted by michkrol

Works flawlessly for me

Maybe something was corrupt or there were incompatible versions of things mixed together, I've updated to the new build and I no longer experience the crashes. It was happening on both my machines, oh well. Fixed.

[MistahBonzai]

Ran a quick HW Performance Scan (CPU useage) with 56.11 & 56.11 w/patch. I'm not seeing any appreciable difference in performance...

[madshi]

Originally Posted by MSL_DK

With all movies. Windows 7 x64, ATI HD 4800 (1080p, 60 Hz), Intel E8500, 8 GB of RAM. Yes .. render queue 0-6, pressent queue 0-1. I can not manage to see if it's right before I experience dropped frames, or after.

If you read the queues from top to bottom, is the render queue the first one which is empty all the time? Or do the queues above the render queue also have a problem? The queue which is causing all the trouble is the top most queue which is getting empty all the time. Which is the fill state of the queue directly above the render queue?

Originally Posted by leeperry

And that would improve PQ? Or simply lower the GPU load?

It should actually ever so slightly *increase* the GPU load because I had to add a check for whether dithering is needed or not. The GPU load increase is probably rather small, though.

The disabling of dithering for pixels which don't need it is has 3 potential benefits:

(1) With full black or white video areas, dithering ever so slightly increased the black level and decreased peak white brightness. This also meant that some displays didn't "recognize" full black video areas, due to dithering, and thus they didn't turn off the local dimming LEDs etc. With the new test build, hopefully this problem should be solved.
(2) The LightSpace CMS calibration developer told me that he prefers dithering to be off during display profiling. So I made this possible this way now.
(3) Having dithering disabled if it's not needed might slightly decrease the overall noise floor, but this is not a planned benefit, just a side effect, and the difference might be nearly invisible in most situations.

[iSunrise]

Originally Posted by madshi

(2) madVR doesn't dither, anymore, when a pixel doesn't need dithering

Wow, that sounds like a nice change, however, I keep on asking myself, how exactly do you determine that? Do you base that decision on neighbouring pixels? Also, I am extremely surprised that this only leads to minimal increases in GPU load, because it actually sounds like a lot of if-processing going on (which would increase with the resolution).

What I am also wondering about is that I always thought that dithering is basically applied to better represent the source as a whole (by adding noise), while still living with the limits of the actual bitdepth. Now, if madVR selectively decides that based on individual pixels on real content (not talking about just pure black or pure white here), wouldn´t that lead to "uneven" areas inside the actual picture itself? Or is that effect almost neglectable, because madVR is processing at a lot higher bitdepth, before dithering gets applied at the very last stage before sending it out to the display?

Thanks a lot for still adding such important core functionality even this late into development.

[madshi]

The pixel shader simply checks for each pixel if the final 8bit value has a fractional part or not, without looking at neighbor pixels. Yes, it's some sort of "if" processing, and due to the way HLSL works, dithering is still calculated for all pixels but then simply discarded for some, so GPU load increases instead of decreasing. However, madVR is mostly memory bandwidth limited, so some extra code in the shaders which doesn't consume additional memory bandwidth usually doesn't harm all that much. GPUs don't like dynamic branching a lot, but simple "if" statements which result in using either value A or value B can be implemented without dynamic branching, so they're not too expensive.

[michkrol]

Originally Posted by madshi

Sorry, my fault. Here's a fixed build:

http://madshi.net/madVRanotherTestBuild2.rar

Thanks for the quick fix. Works perfectly (DXVA scaling and everything else).

[iSunrise]

Originally Posted by madshi

The pixel shader simply checks for each pixel if the final 8bit value has a fractional part or not, without looking at neighbor pixels. Yes, it's some sort of "if" processing, and due to the way HLSL works, dithering is still calculated for all pixels but then simply discarded for some, so GPU load increases instead of decreasing. However, madVR is mostly memory bandwidth limited, so some extra code in the shaders which doesn't consume additional memory bandwidth usually doesn't harm all that much. GPUs don't like dynamic branching a lot, but simple "if" statements which result in using either value A or value B can be implemented without dynamic branching, so they're not too expensive.

Thanks for the detailed explanation. Didn´t even think about the fractional part of a pixel value as the condition. Yes, that makes a lot of sense, indeed. Quite clever, actually.

[Marin85]

Quick question, can somebody recommend a list of settings how to maximize madVR performance for older hardware (Win 7, no aero)? The main reason is that only with madVR I don't get any tearing on that machine.