madVR - high quality video renderer (GPU assisted)

[James Freeman]

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

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]

A4 static is the one for me too as the impression of depth & sharpness is amazing
Yeah, A4 from a distance is sheer fun :cool:

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... :o 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*]

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]

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. :D :helpful:

[cyberbeing]

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.

there was a bug in madVR's handling of fullrange YCbCr content... :o 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]

@sneaker_ger, @mzso,

there was a bug in madVR's handling of fullrange YCbCr content... :o 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]

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.

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]

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. :o
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.

@sneaker_ger, @mzso,

there was a bug in madVR's handling of fullrange YCbCr content... :o 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.

[leeperry]

Neither ED11 or AD4 would I consider neutral.
Fully agreed but can you expect cutting down half the resolution from 16 to 8 and getting away with it without any drawback? This is a genuine question, not being sarcastic here.

[mzso]

@sneaker_ger, @mzso,

there was a bug in madVR's handling of fullrange YCbCr content... :o 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.)

Okay I tested. I can verify that it's okay now. As a matter of fact it's visually indistinguishable from MPV-s output, for my eyes at least. (small differences data wise)

(It also tells me that ffmpeg encodes are also wrong in their on regard too, madvr just made them wronger)

[Mangix]

hmmm. I see a difference with the test patterns but not with actual content. Rather interesting...

[Ver Greeneyes]

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.045847Thanks! I assume R, G and B should be in the 0.0-1.0 range? Oh, and these convert from and to gamma light RGB, right?

[cyberbeing]

@aufkrawall

Have you tried enabling "use separated device for presentation" and "use separated device for dxva" along with everything set to "don't flush"?

Fully agreed but can you expect cutting down half the [bitdepth] from 16 to 8 and getting away with it without any drawback?

Probably not, it's all about how much you can minimize the drawbacks. In madVR's case, it also needs to be faster than realtime video playback.

[madshi]

Thanks! I assume R, G and B should be in the 0.0-1.0 range? Oh, and these convert from and to gamma light RGB, right?
Yes, RGB 0-1, too. These are for gamma light. But I think they can also be used for linear light. At least I don't know any different matrixes for linear light.

Okay I tested. I can verify if that it's okay now.
Good, thanks for the heads-up.

hmmm. I see a difference with the test patterns but not with actual content. Rather interesting...
There will be scenes in actual content which are somewhat similar to those test patterns. In any case, I strongly recommend leaving dithering enabled. The default option shouldn't cost that much performance, anyway.

[Damien147]

Can smallramp.ytp be used as a reference point?Got a 6-bit panel(u2412)with afrc and I get the smoothest result by setting madvr in 8-bit,to see the difference with dithering off though I got to stick my face on the screen.

[cyberbeing]

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

So rather, what you've posted there is RGB <-> YPbPr (analog) according to Poynton, rather than YCbCr (digital).

Does that mean YPbPr is equivalent to full-range YCbCr, or rather that this matrix can only be used if full-range YCbCr is first converted to YPbPr?

[Shiandow]

Hi madshi, I just tested the fix for the green tint and it seems to work! This is how the distribution of green/magenta pixels looks now: link (http://i.imgur.com/BQKoBWs.jpg).

[The 8472]

Interesting, 3bit + dynamic causes some significant pulsing. It becomes less perceivable with 4bit.

Is that some effect of not doing dithering it in perceptually uniform colors and thus the different perturbations created by dynamic actually not being interchangeable? I guess at higher bit-depths it works fine because the differences can be approximated as locally linear, especially if neighboring pixels have similar colors.

[Asmodian]

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.

Yes, the attached gamma ramps are applied to the GPU ramps even when using overlay mode. It would be very cool if madVR did leave the GPU ramps alone when in overlay mode. :)

[turbojet]

madshi: You want bug reports about dither only builds in the bug tracker? It's not an issue in 87.4. It might be limited to non dx11 gpu's though can those that have older gpus reproduce this? I'll try testing a 650 soon.

Also another issue has popped up with overlay, there is no screen in mpc-be or potplayer when the window is not maximized. I was able to fix potplayer by changing skins. The only way I've found to fix mpc-be is to delete the configuration and start over. This affected all overlay builds but didn't start until finaldither builds were being used.

There's also always been video artifacts maximizing with overlay mode. It places the non-maximized window inside of the maximized window at the upper-left part of the screen for about 500ms. I can't figure out a way to show the issue, print screen and screen capping result in a blank overlay window.

[jkauff]

Yeah, A4 from a distance is sheer fun :cool:
It's a lot of fun a couple feet from a 23" IPS panel, too. :)

[*Touche*]

Is it normal that activating colored noise increases black levels or should that have been fixed?

[truexfan81]

Is it normal that activating colored noise increases black levels or should that have been fixed?

i tried turning it off and back on, i see no difference in black level, but then i already have it set to triple expanded :D

[*Touche*]

I don't know if it is because of my TV's native dithering, but it is very obvious. I took some screenshots in 6bit to make it more visible. I can't see it on my smaller LCDs, but it is visible in images too when I put them on TV.

mono (http://i.imgur.com/UjlLBqR.png)
color (http://i1.someimage.com/ivnRxjj.png)

Here are histograms. I don't know if they are representative of the increased blacks or is the difference between them expected due to mono/color dithering:

monohist (http://i.imgur.com/nrLAhVG.png)
colorhist (http://i.imgur.com/VlMHOZ0.png)

EDIT: fixed the color image link.

[cyberbeing]

There is something wrong with your "color" image beyond the elevated black level, as it is only showing noiseless 16x16 color blocks (http://i1.someimage.com/AImHHqM.png).

Which dither algorithm and madVR build was that?

[*Touche*]

I think this was ED2 static, but it shows elevated blacks in all of them. I have no explanation for the blocks. Could it be IrfanView's PNG compression? Though that should be losless.

[XMonarchY]

There is a slight issue with LAV Video decoder in that it doesn't clip WTW levels, so when you use 0-255 setting in madVR with a 16-235 ArgyllCMS 3DLUT to run white clipping pattern - you get yellow flashing bars. To fix that, you can either:
1. Use a different video decoder, like FFDshow
OR
2. Create a 0-255 3DLUT, but set madVR to 16-235. That way, you will not get crushed blacks and flashing WTW bars even when using LAV video.

But...what if you have a real 0-255 source when using method #2? What will happen then?

BTW, is it me or does sending PMs not leave a copy in the "Sent" box???

[Nevilne]

He's certainly using a 58kb jpg image

[cyberbeing]

Ah, good point.

[*Touche*]

He's certainly using a 58kb jpg image

Huh, it seems Imgur converted that one to jpg. Have no idea why. Tried again and it did it again. I'll try another hosting.

[cyberbeing]

Recently I've been using SomeImage (http://someimage.com/), as it allows images up to 15MB in size and hotlinking.

[*Touche*]

Thank you, finally a hosting that doesn't butcher it.

Here is the proper color (http://i1.someimage.com/ivnRxjj.png) version.

[cyberbeing]

I do not see anything abnormal about that color dithering screenshot. The black level does not appear to be elevated, and all colors average to the same as the mono screenshot.

Any difference you see, must just be a quirk of how your Panasonic 55ST60 performs plasma dithering and post-processing near-black. With your mono screenshot, less pixels would be active, but those that are (should) have a higher intensity. With the color screenshot, more pixels would be active, but those that are (should) have a lower intensity.

[James Freeman]

What is the purpose of Windowed Overlay Mode?

[cyberbeing]

Overlay should be faster, particularly on low-end hardware. As the name implies, it utilizes GPU hardware overlay. It has some limitations like being unable to take screenshots with PrtSrn, movement quirks, and bypassing your GPU LUT (madVR 0.86.7+ will instead apply your GPU LUT to Overlay via shaders).

[turbojet]

Overlay is useful for multiple displays with different refresh rates or when aero is disabled but it's clunky. FSE also works well in these situations.

[Mangix]

I use it on my PC as I also use fl.ux. Overlay bypasses fl.ux's color modifications and allows me to properly view content. I also prefer it to FSE mode as it tends to be a little more stable.

[James Freeman]

So basically Overlay bypasses all the "layers" of processing done by other Software & OS and gets directly to the screen.
Correct?

[Mangix]

That assumes that there actually is processing being done. In most cases, there is not.

But otherwise, yes.

[James Freeman]

Thanks.

I also noticed that in Overlay mode enabling "disable GPU gamma ramps" only has effect on the MPC window and leaves the VideoLUT (OS) alone.
On the other hand when not in Overlay mode, enabling "disable GPU gamma ramps" disables VideoLUT completely.
Which is very useful behavior.

[*Touche*]

I do not see anything abnormal about that color dithering screenshot. The black level does not appear to be elevated, and all colors average to the same as the mono screenshot.

Any difference you see, must just be a quirk of how your Panasonic 55ST60 performs plasma dithering and post-processing near-black. With your mono screenshot, less pixels would be active, but those that are (should) have a higher intensity. With the color screenshot, more pixels would be active, but those that are (should) have a lower intensity.

Yes, it's not that the whole black tones get uniformly lighter, but many more pixels become active. I guess the panel somehow amplifies the effect in that particular scene. It would interesting to see other if people's plasmas show a difference.

Histograms are as expected? If I look at index 2, for instance, I see that there are 33.494 pixels active in mono, but 307.833 in color.

[ryrynz]

Yes, it's not that the whole black tones get uniformly lighter, but many more pixels become active. I guess the panel somehow amplifies the effect in that particular scene. It would interesting to see other if people's plasmas show a difference.


I just spent the last 5 minutes staring up close at my VT50 and I can't see any change in plasma noise using ordered dithering with colored noise enabled and disabled.

[*Touche*]

Have you looked at fullscreen screenshots I've posted and changed between them on the VT?

[cyberbeing]

Did you specifically test near-black (0-2%) like his screenshot, or rather displaying his dithered screenshots as-is with madVR dither disabled? I'm now curious myself, so I'll check it out on my GT50 plasma tomorrow night.

[aufkrawall]

@aufkrawall

Have you tried enabling "use separated device for presentation" and "use separated device for dxva" along with everything set to "don't flush"?

This is procuding a lot of glitches here.

Btw: Error diffusion in general is causing dropped frames and presentation glitches with 1080p60 video in FSE. GPU is not well utilized.

[cyberbeing]

Strange, I literally never have presentation glitches on my GT440 DDR5 (Fermi) or GTX770 (Kepler). Check your DPC latency maybe?

[aufkrawall]

According to LatencyMon (Win 8.1), it's below 100μs.
Which driver are you using?

[ryrynz]

Have you looked at fullscreen screenshots I've posted and changed between them on the VT?

I downloaded your images and checked again comparing using xnview and yes I can see the colored dithering screenshot has the VT50 delivering darker blacks in the darkest areas (the corners) of the image.

Most of it the image looks exactly the same but what must be that 0-2 black range like cyberbeing said certainly has less plasma noise.
I guess the colored dithering could be offering a nice bonus for plasma owners yeah? It wouldn't be much though I imagine 8 bit will probably drop at least half of what I saw.