madVR - high quality video renderer (GPU assisted)

[madshi]

Originally Posted by turbojet

Found an issue with FinalDither builds and turning on overlay between files in queue results in a blank screen, it never happened with 87.4. To reproduce you can set profiles of 2 different files to toggle overlay, queue them in a player and jump between them.

This is an example of my setup with a 60hz display, force film, display mode changer disabled, and a profile for rendering>general settings to: if (srcFps>24) and (deintFps<24) and (refreshrate<61) "overlay" else "window", window is windowed mode, overlay is overlay mode. Queue this file and any 24 or 25 fps file in a player. Jump between them within a few jumps to the 'overlay file' it'll show an offcolor (blue in mpc, green in potplayer) screen without a picture.

Sounds weird. Can you please create a bug tracker entry for this? Thanks.

Originally Posted by leeperry

All this said, I'll play around with the green fix color option

The green fix is only for ordered dithering, though.

Originally Posted by Asmodian

Ah I see. I am very happy the way it works now, except needing to remove the linear ramps manually and that isn't hard.

The part about removing the linear ramps still kinda confuses me, though. Are you saying that madVR copies the linear ramps (which are attached to the 3dlut) to the GPU ramps, so that the whole Windows desktop is affected, *even when using overlay mode*? If so, I don't think that is as intended. In overlay mode madVR should be clever enough to let the GPU ramps alone because they don't affect madVR, anyway.

Originally Posted by 6233638

I have been meaning to ask for a while now; does this option simply clear the LUT, or is it restored when playback is stopped?

The LUT is restored at some point, though it might not be directly at playback stop. IIRC it's a few seconds after the last madVR instance was destroyed.

Originally Posted by James Freeman

I think you miss understood me, madshi.
I never recommended turning off dithering, EVER.
What I meant is his MONITOR is fine (that what he was fearing), if he does not see the difference between 7 & 8 bit without MadVR dithering enabled, in a heavy dithered hollywood Movie (dithered by the studios).

Ok, then it's all good.

Originally Posted by iSunrise

Is this like it´s supposed to work madshi? Didn´t know this either.

Yes. In windowes/FSE mode the only (reliable) way to disable the GPU gamma ramps is to disable them globally.

Originally Posted by Ver Greeneyes

madshi, could you share the equations you use to convert from YCbCr to RGB and back? After the whole discussion above I'd like to try encoding my gradients from raw planar YUV444 instead to see if it makes a difference, but I found the wikipedia article extremely confusing (they say that the constants k1 and k2 are used, then never use them?!). The Rec.709 spec was also confusingly written. I'm sure there are other sources that might be clearer, but most of what I found only seemed to be concerned with YCbCr -> RGB using 8-bit integers.

I'm currently looking into this myself. Unfortunately it's not as straightforward as copying some constants out of madVR's source code. I'm building the color conversion matrixes by doing some math on some constants, and it depends on several factors which constants are used, and then I also have a multiplication and an addition, which I apply in an unusual order (to improve shader performance). At one point I had all of this figured out in my head and double and triple checked. But it's been a long time, so right now my own code is somewhat confusing to me.

After some research, looking into this topic again, I think the following matrixes should work for converting RGB <-> YCbCr for BT.709. However, please note that these matrixes expect luma to be in the 0..1 range and chroma to be in the -0.5..+0.5 range:

YCbCr -> RGB
 1.0000000000000000,  0.0000000000000000,  1.5748000000000000
 1.0000000000000000, -0.1873242729306488, -0.4681242729306488
 1.0000000000000000,  1.8556000000000000,  0.0000000000000000

RGB -> YCbCr
 0.212600,  0.715200,  0.072200
-0.114572, -0.385428,  0.500000
 0.500000, -0.454153, -0.045847

Originally Posted by Ver Greeneyes

Using the D3D9 API for setting a video LUT

FWIW, some earlier madVR versions tried using that D3D9 API, but it didn't work reliably. If it worked at all, it was only in FSE mode, and even that depended on the GPU drivers. Because of that I've switched over to using the normal win32 gamma ramps API, which works reliably, but of course also affects the whole desktop.

Originally Posted by sneaker_ger

No, my test involved zero RGB to YUV conversions, I have a YUV source ("output_ll.mkv") and converted it to RGB using two different chains that should yield the same result yet don't. One of them is wrong.

If our only goal is to check if something is wrong, then the test you did was sufficient. There obviously is something wrong. But is that the only thing you are interested in?

My comments where not aimed at figuring out whether something is wrong. I was one step ahead, thinking about how to figure out whether the problem is caused by madVR or by the color conversion used when encoding the output_ll.mkv file.

Originally Posted by kasper93

I can write a lib which will do completely wrong RGB->YUV conversion, but when I use this lib to do conversion RGB->YUV->RGB it will be proper RGB. It's just math.

Exactly.

[YxP]

Originally Posted by *Touche*

minute pixel differences

I think it's safe to say that from average Joe's point of view whole MadVR is little more than minute pixel difference None of my friends see, or care to see any "real" PQ difference between mpc+mvr and VLC when we watch movies at my house. Yes, some people here do seem to possess almost superhuman eyesight when it comes to PQ, but hey, isn't this the place to go crazy with it?

[*Touche*]

Originally Posted by YxP

I think it's safe to say that from average Joe's point of view whole MadVR is little more than minute pixel difference None of my friends see, or care to see any "real" PQ difference between mpc+mvr and VLC when we watch movies at my house. Yes, some people here do seem to possess almost superhuman eyesight when it comes to PQ, but hey, isn't this the place to go crazy with it?

I was very specific about the settings in question, not the whole madVR processing.

Originally Posted by leeperry

Minute pixel differences I'd suggest you'd open to the idea that there's more to it than slow-blinking Plasma. Anyway, let's agree to disagree as neither of us could care less about the outcome. Point is, the difference is anything but "minute pixel differences" on a BFI LCD but I'm entirely willing to believe that it'd take a lot of imagination to see much change at all on a Plasma.

Actually, I also have a 27" LCD with a glossy screen to double check various settings. The math and science of seeing something as these 8 bit dither differences from such a distance where your sight has a resolution to see only relatively huge group of pixels apart just doesn't add up.

[sneaker_ger]

Originally Posted by madshi

My comments where not aimed at figuring out whether something is wrong. I was one step ahead, thinking about how to figure out whether the problem is caused by madVR or by the color conversion used when encoding the output_ll.mkv file.

Well, the RGB source is available for anyone to test and it doesn't look like madVR's output. What do we gain from this knowledge? Supposedly nothing, since it could indeed just be a case of two wrong conversions canceling each other out - it didn't bring us any step further to the solution. That's why I went in the opposite direction and eliminated any RGB->YUV conversion from the test. In the end you'll have to check your code for errors* or someone has to come up with samples that are guaranteed to be correct and can be used for reference.

(or so. has to check AviSynth/dither code)

[madshi]

FWIW, after checking the whole RGB -> YCbCr -> RGB pipeline, using the original source, and the "lossless" encode, it seems that the encode is probably correct and there might be a bug in madVR, probably in the fullrange handling, but I'm not totally sure yet.

[nevcairiel]

I am pretty sure LAVs handling of YUV->RGB is correct in full range, so you could also compare LAV in full-range RGB32 output with LAV in YUV output mode.

[jmonier]

Originally Posted by madshi

The LUT is restored at some point, though it might not be directly at playback stop. IIRC it's a few seconds after the last madVR instance was destroyed.

My LUT does enough of a correction that it's obvious when it's restored and that occurs 1-2 sec after playback stop.

[James Freeman]

About 3DLUTs,

Here's a tip for you: Profile the monitor (and create 3DLUT) without Calibrating it first.
Profile the display using MadPTG with at least 128 gray patches (targen -g128).
Read the display (dispread) without -k or -K, then create a 3DLUT (colprof).

The result a an absolutely smooth and even greyscale without banding or and visible coloration.


P.S
What about the problem of the blacks being dithered (green dots) in lower bit depths, is it fixable (or going to be)?

[yok833]

Originally Posted by leeperry

-When I'm 3m away from the TV, Static ED11 looks too polite, Dynamic ED11 makes the picture more "alive" but Static A4 really shines in that scenario as its "impression of depth" is as impressive as ever.

A4 static is the one for me too as the impression of depth & sharpness is amazing... Maybe is it because we both watch on a plasma TV? ED11 static is my 2nd choice as the noise is really low but the result is too clean and less <alive> IMO

Anyway the both are really good so great work and thank you Madshi !!


"Envoyé depuis mon GT-I9300 avec Tapatalk"

[fairchild]

Originally Posted by yok833

A4 static is the one for me too as the impression of depth & sharpness is amazing... Maybe is it because we both watch on a plasma TV? ED11 static is my 2nd choice as the noise is really low but the result is too clean and less <alive> IMO

Can you clear up some of this for me as I haven't been following this thread closely with all the dithering stuff. The latest posted build he has a new dithering section under rendering. There you have the different algorithms (none, random, ordered, error 1, error 2) along with 2 options (colored noise, change dither for every frame)

I'm assuming Error 1 is A4/ED4 and Error 2 is ED11? Also what is all this static and dynamic talk? Is that referring to the 2 extra options? Thanks!

[James Freeman]

Heh..
I think it will be hard to vote out any of the Dithering options, because they all seem to be loved equally.

Originally Posted by fairchild

Can you clear up some of this for me as I haven't been following this thread closely with all the dithering stuff.

None = Rounding.
Random Dithering = Random Dithering.
Ordered Dithering = OD32
ED Option 1 = Adaptive 4
ED Option 2 = ED11

Colored noise = OppositeColor (MultiColor only for Random Dithering), (MonoColor when Off).
Change dither for every frame = Enable Dynamic (Static when Off).

You can also change to any bit depth in Devices -> Device-> Properties without creating a "4bit" folder on the desktop.

[leeperry]

Originally Posted by yok833

A4 static is the one for me too as the impression of depth & sharpness is amazing

Yeah, A4 from a distance is sheer fun

Originally Posted by *Touche*

I also have a 27" LCD

Oh, that changes everything then. PWM 6bit TN hopefully.

Anyway I can confirm that your message has full gotten through by now and I'm afraid you might start boring the readers of this thread who have more interesting matters to attend to than listening to your sciencetification knowledge, but I'll give you that it's most impressivistic and I humbly bow down to your wisdomness again.

[madshi]

@sneaker_ger, @mzso,

there was a bug in madVR's handling of fullrange YCbCr content... Thanks for bringing that to my attention. Here's a test build with a fix:

http://madshi.net/madVRyuvFullrange.rar

FWIW, some pixels are still different in the "lossless" decoding compared to the original RGB file due to colorspace conversion rounding errors. (And yes, nevcairiel, LAV seems to do this correctly.)

[*Touche*]

Originally Posted by leeperry

Oh, that changes everything then. PWM 6bit TN hopefully.

8bit non-PWM IPS, actually.

Anyway I can confirm that your message has full gotten through by now and I'm afraid you might start boring the readers of this thread who have more interesting matters to attend to than listening to your sciencetification knowledge, but I'll give you that it's most impressivistic and I humbly bow down to your wisdomness again.

I would just like to base the decisions about further development on less esoteric grounds. No need to throw a tantrum.

[YxP]

Originally Posted by *Touche*

I would just like to base the decisions about further development on less esoteric grounds.

What a weird thing to say. I sure hope madshi has at least one or two ideas of his own how to continue the development so that it's not just us amateurs telling him what to do. /sarcasm.

[cyberbeing]

Originally Posted by madshi

Please let me know about your final preferences, thanks.

I've come to the conclusion that ED11 mono dynamic blurs fine details slightly, and losing low-contrast edge definition compared to the source. The dynamic quality enhances this effect, behaving as a minor denoising effect. Unfortunately, I can still sometimes see checkerboard patterns with ED11 static, so if I were to use ED11 it would need to be dynamic to help hide them. AD4 mono static by comparison slightly enhances low-contrast edge-definition compared to the source. Neither ED11 or AD4 would I consider neutral.

Overall I'd lean towards AD4 mono static as being more accurate and visually pleasing than ED11 mono dynamic, as my final preference. ED11 mono dynamic isn't bad though, so I'm pondering if it would fit well in a certain profile. I think it may be useful if you added the display 'Device Name' which madVR is currently active on as a variable for profiles switches, no rush on that though.

Originally Posted by madshi

there was a bug in madVR's handling of fullrange YCbCr content... Thanks for bringing that to my attention. Here's a test build with a fix:
http://madshi.net/madVRyuvFullrange.rar

Did you forget to enable compiler optimizations again? I wouldn't have expected such a change to grow by ~0.4MB, unless the fix required adding an additional codepath.

[mzso]

Originally Posted by madshi

@sneaker_ger, @mzso,

there was a bug in madVR's handling of fullrange YCbCr content... Thanks for bringing that to my attention. Here's a test build with a fix:

http://madshi.net/madVRyuvFullrange.rar

FWIW, some pixels are still different in the "lossless" decoding compared to the original RGB file due to colorspace conversion rounding errors. (And yes, nevcairiel, LAV seems to do this correctly.)

Cool. I'll have a look.

[madshi]

Originally Posted by cyberbeing

I've come to the conclusion that ED11 mono dynamic blurs fine details slightly, and losing low-contrast edge definition compared to the source. The dynamic quality enhances this effect, behaving as a minor denoising effect. Unfortunately, I can still sometimes see checkerboard patterns with ED11 static, so if I were to use ED11 it would need to be dynamic to help hide them. AD4 mono static by comparison slightly enhances low-contrast edge-definition compared to the source. Neither ED11 or AD4 would I consider neutral.

Overall I'd lean towards AD4 mono static as being more accurate and visually pleasing than ED11 mono dynamic, as my final preference.

Ok.

Originally Posted by cyberbeing

Did you forget to enable compiler optimizations again? I wouldn't have expected such a change to grow by ~0.4MB, unless the fix required adding an additional codepath.

Yes, the build is without optimization.

[aufkrawall]

Originally Posted by madshi

It's not *that* odd. Without that trade option, madVR rerenders the past 5 frames every time a fade is detected. The fade detection only detects a fade as a fade after 5 frames were faded in a row. So in the moment when the fade is detected, madVR has to go back, throw away the past 5 frames rendering and rerender them. That will immediately cut the render queue down from 7-8/8 to 2-3/8. This *can* maybe produce dropped frames once in a while if your GPU has a lot to do and circumstances are bad. Generally it might be a good idea to increase the GPU queue size if you want to use debanding with full fade functionality. E.g. with 12 GPU frames, the fade rerendering will only lower the GPU queue from 11-12/12 to 6-7/12, which should not be a problem.


And you don't have any such glitches without debanding enabled at all? In the moment when those glitches occur (with the trade quality option activated) which state to the queues have? Are they all full? In any case, I'd suggest increasing the GPU queue size to 12, if your GPU has enough RAM for that. There isn't really any downside to using a higher GPU queue size, as far as I'm aware, except that "delay playback start until all queues are full" will delay a bit longer. In order to avoid presentation glitches you could also try increasing the number of "frames that shall be presented in advance".

Seems like there can be also presentation glitches without debanding (it's a mystery to me why...). They disappear when I set up "flush & wait after intermediate render steps" instead of just default flush.
I have to set GPU queue to 16 frames to avoid the glitches with debanding in the particular Crysis 3 video.
But then my GTX 670 is too slow for 4k content.
Time for a r9 290x... The AMD drivers also seemed to be less vulnerable for presentation glitches. I hadn't to alter flush settings with the r9 290.

Originally Posted by madshi

@sneaker_ger, @mzso,

there was a bug in madVR's handling of fullrange YCbCr content... Thanks for bringing that to my attention. Here's a test build with a fix:

http://madshi.net/madVRyuvFullrange.rar

Confirmed. Nice find, mzso. In the past I always used limited range with YUV (haven't found a test picture that shows any difference towards full range yet). The Trine 2 pictures of mine above were with full range, but maybe the difference is too subtle to recognize it well with that complex content.

[madshi]

FWIW, presentation glitches are mostly outside of my control. It's a problem somewhere between Direct3D and the GPU driver.