madVR - high quality video renderer (GPU assisted)

[sneaker_ger]

I hope that after reading that thread you'll have more trust in madVR than in swscale... :D
You didn't understand my post, swscale was not involved in any way.

[iSunrise]

ED (option 2) + Dynamic and use NNEDI3 x16 for Chroma upscaling

OR

Ordered Dithering and use NNEDI3 x32 for Chroma upscaling
That´s a very hard question to answer, indeed. Since I´m using a GTX580, there´s also not too much headroom when we´re talking about 720p at anything higher than 30fps, so personally, I love that there are now profiles to make the best out of it.

Since I´m so impressed with ED2+dynamic (it´s unbelievable how high the bit difference can be and how much headroom for processing it gives you without making any sacrifices in quality), personally I would use profiles to always go with ED2+dynamic and the highest affordable NNEDI3 on stuff <720p. Always keep in mind though, that NNEDI3 image doubling on luma is the most contributing factor to improve your upscaling, so that should also be enabled at anything lower than 720p at least.

On anything higher than 720p and if your display is 1080p/1200p, there´s not much need for chroma upscaling with NNEDI3, since you will find it very hard to see the differences anyway (just use a reasonably sharp chroma upscaler, which should be enough).

[madshi]

You didn't understand my post, swscale was not involved in any way.
It was not? The original source was RGB, your encode is YCbCr. Which algorithm was used to convert RGB to YCbCr? Was it not swscale? And then in AviSynth you used "Dither_convert_yuv_to_rgb". Does that not use swscale, too?

[sneaker_ger]

It doesn't matter what the original source was or how the conversion to the lossless sample was done, my screenshots are all taken from the lossless sample ("output_ll.mkv") itself, not from any original source.

And then in AviSynth you used "Dither_convert_yuv_to_rgb". Does that not use swscale, too?
Not to my knowledge. If it actually does use swscale then my statement was wrong. Anyways a link to an old swscale bug doesn't prove anything. I'm not saying madVR is at fault here but it can't be ruled out until the cause of the mismatch is fully understood.

[QBhd]

@ madshi,

Wow... you're quick on the draw right now! I had edited the above post, so I wanted to say this again:

ED option 2 + mono dynamic is awesome!

All these new features kick the crap out my card, but it's so worth it! :)

for those interested here are my settings for 1280x720p30==>1024x768p60 that are pushing my 1120MHz R9 270x to the max:

artifact removal: both set to medium
chroma upscaling: NNEDI3 x16
image doubling: Luma resolution always NNEDI3 x64, Chroma resolution unchecked
image upscaling: Jinc 3 AR
image downscaling: Lanczos 4 AR
smooth motion: OFF (I use ReClock and refresh rates of 60 & 72)
dithering: Error Diffusion - option 2 + mono color + dynamic
trade quality...: ALL unchecked

I have other profiles for other content, but all of them had clear winners and losers within my GPU's capabilities, only this profile pushes right to the edge

Anyway, I am rambling now...


Keep up the AWESOME work!!!

QB

[iSunrise]

...for those interested here are my settings for 1280x720p30==>1024x768p60 that are pushing my 1120MHz R9 270x to the max:

artifact removal: both set to medium
chroma upscaling: NNEDI3 x16
image doubling: Luma resolution always NNEDI3 x64, Chroma resolution unchecked
image upscaling: Jinc 3 AR
image downscaling: Lanczos 4 AR
smooth motion: OFF (I use ReClock and refresh rates of 60 & 72)
dithering: Error Diffusion - option 2 + mono color + dynamic
trade quality...: ALL unchecked...
Have you tried/compared Catmull-Rom with linear light downscaling instead of Lanczos 4 AR, yet?

That would save you the increased cost (load) of Lanczos 4 vs. Catmull-Rom and also the AR processing step, so when you´re only on 768p, you would have more GPU headroom and a more accurate representation of any content that is natively higher or upscaled than 720p on your display.

Personally, I would only use Lanczos 4 AR for upscaling.

[nevcairiel]

Chrome Upscaling with NNEDI is also a rather miniscule gain, if you're running into performance troubles thats the first thing I would get rid of.

[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 (http://www.mediafire.com/download/mntpfnsgaalms97/cadence.mpg) 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.

nevcairiel: Have you had a chance to test madvr's nnedi and ED on your 750?

[madshi]

It doesn't matter what the original source was or how the conversion to the lossless sample was done, my screenshots are all taken from the lossless sample ("output_ll.mkv") itself, not from any original source.

Not to my knowledge. If it actually does use swscale then my statement was wrong. Anyways a link to an old swscale bug doesn't prove anything. I'm not saying madVR is at fault here but it can't be ruled out until the cause of the mismatch is fully understood.
It does matter how the conversion to the lossless sample was done. Because if both the RGB -> YCbCr and later the YCbCr -> RGB conversions are performed by using the same algorithm, the final result is likely to look correct, regardless of whether the actual conversion algorithm is following the standards or not.

In the open source programming world algorithms are very often reused. So if the most basic underlying library/routine (swscale) is buggy, the bug can very easily spread to many other routines and projects. In contrast to that madVR was written completely new from ground up, so there are no bugs I copied from other projects. Practically this means that if you use swscale to encode the content and then use swscale to play it back, you'll probably get good results. Even if what swscale does is not correct. So it's important to know which algorithm was used for *both* the RGB -> YCbCr and YCbCr -> RGB conversions in your screenshots.

But I do agree with you that we can't rule out anything until we know the exact cause of the problem. I think the best way to figure out the exact cause is one of the following two approaches:

(1) Either we check the source code of the original RGB -> YCbCr conversion and double check if the math is really correct.
(2) Or we look at one pixel in the original RGB file, and compare it to the YCbCr pixel encoded in the lossless encode and double check whether the YCbCr pixel value is correct.

Either way would allow us to verify if the lossless encode is correct or not. If it's correct then it follows that madVR is most probably doing something wrong.

(BTW, the encode process itself might be lossless, but your encoded video file is certainly *not* lossless, unless you have encoded it in floating point. Converting RGB to integer YCbCr can not possibly be lossless.)

[leeperry]

So which algorithm do you like most now?
Well, I either use my 32" TV as a computer monitor from a 80cm distance or sitting on the couch from a 3 meters distance(I like a small punchy picture so my brain can also focus on audio) and I've been running more tests yesterday:

-As this quote clearly sumps up:
static dithering has the same amount of error except it becomes harder to detect since it doesn't change.
I really don't see the point of going dynamic as the noise is easier to spot due to the fact that it's constantly moving around.......I don't quite understand how that could be good to anything, there's a high price for trying to hide patterns to my eyes and it's not worth it.

-When I'm 80cm from the TV and watching crisp 30fps 1080p content, I like static ED11 as it's the cleanest by far...all other options give a "dirty window" effect to my eyes, Static A4 is hard to look at due to the EE....OTOH its EE is the shiznit on blurry/utterly grainy/low-bitrate stuff and most upscaling jobs, http://forum-images.hardware.fr/images/perso/loomy.gif it!

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

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

[Asmodian]

Overlay mode makes a BIG difference because Overlay mode totally ignores the GPU gamma ramps. madVR has to do extra work to manually apply GPU gamma ramps in Overlay mode. Yeah, ok, I guess madVR could make use of this Overlay specialty by letting the GPU gamma ramps alone, when using Overlay mode. I'm not sure if madVR currently does that or not.

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.

Some quick testing confirms overlay only, of course. With "disable GPU gamma ramps" checked; unchecking "enable windowed overlay" loads a linear LUT and Windows goes uncalibrated. If I re-enable overlay Windows goes back to calibrated. The video in madVR doesn't change, impressive.

An option or feature to not load attached gamma ramps into the video card if using windowed overlay might be a bit too specific (and really hard to explain :p) but I think it would be ok as the normal behavior. You could only load them into what you use to manually apply GPU gamma ramps in Overlay mode.

All pretty specific but it is really nice not having Windows changing colors when launching/closing madVR. Please do not change "disable GPU gamma ramps" to really linearize the GPU ramps when in Overlay mode. :)

Maybe this is also why I stopped noticing banding? I thought it was because of a better calibration or monitor but it turns out I wasn't actually using the video card's LUT to do that part of the calibration after all - madVR was doing it; probably at a higher bit-depth and before dithering. :D

[6233638]

Not right now. Let's keep all the options for a while and then after a couple of weeks or so we can revisit who likes which algorithm the most and which algorithm might not be used at all, anymore, and then maybe drop some options based on that.If the performance of ordered dither is faster on all systems, it does seem like there's very little reason to keep random dithering around as it adds a huge amount of noise relative to the other options.

From doing some testing, I think I prefer to use ED1 if colored dither is enabled, and ED2 if it's disabled.
Now that it's fixed, I do think I prefer using the colored dither option with ordered dither, though it looks pretty good either way - as long as it's changing every frame.

When viewing in 8-bit rather than bit-reduced modes for testing, I think I will stick to ordered dither for now.
Any difference between dynamic ordered and dynamic error diffusion is extremely small at 8-bit, and switching from ED to OD drops my render times by 10ms, which has a direct effect on what scaling algorithms I can use with 60fps videos. (16.67ms)

Scientifically, your eyes should be able to differentiate about 11-12 bits of brightness information in a smooth gray ramp. So if you set madVR to 7 bit without dithering, you're throwing away TONS of potential brightness steps for no good reason. Maybe current content is often not good enough to show a clear benefit, but as I said, that depends on the exact movie/scene. And we'll hopefully soon get 4K content with higher native bitdepths.I must say it's very impressive that ArgyllCMS is reporting the effective number of bits as 11-12 considering that the output is 8-bit.

I think someone reported the ENOB as ~10 bit back when random dither was being used, so it's a big improvement.

I wonder if there's a difference between what ArgyllCMS reports with the different dither algorithms.

From a technical point of view there is no way to "disable the GPU gamma ramps". Basically they are always used. So disabling them practically means filling them with linear values. So disable=linear.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?

I really don't see the point of going dynamic as the noise is easier to spot due to the fact that it's constantly moving around.......I don't quite understand how that could be good to anything, there's a high price for trying to hide patterns to my eyes and it's not worth it.The noise is easier to spot, but the dither pattern is more difficult to see.

Static looks like a lower bit-depth image in my tests with actual video content.

[James Freeman]

If you are watching a movie (which is already dithered by the studios), then everything is fine.
Please don't *ever* recommend or support disabling dithering. It's a bad bad bad idea. The hair on my neck is standing up. Seriously.

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).

Thanks for the FinalDithering4 build.

[leeperry]

I must say it's very impressive that ArgyllCMS is reporting the effective number of bits as 11-12 considering that the output is 8-bit.
FWIW Argyll also claims to measure 9bit LUT accuracy over a 8bit TMDS connection IME, but indeed at least 10bit sounds fantastic :)

The noise is easier to spot, but the dither pattern is more difficult to see.

Static looks like a lower bit-depth image in my tests with actual video content.
Right but the constantly moving grain is a deal breaker to my eyes and I've only been using 24/30fps movies, no test patterns.

[iSunrise]

I really don't see the point of going dynamic as the noise is easier to spot due to the fact that it's constantly moving around.......I don't quite understand how that could be good to anything, there's a high price for trying to hide patterns to my eyes and it's not worth it.

-When I'm 80cm from the TV and watching crisp 30fps 1080p content, I like static ED11 as it's the cleanest by far...all other options give a "dirty window" effect to my eyes, Static A4 is hard to look at due to the EE....OTOH its EE is the shiznit on blurry/utterly grainy/low-bitrate stuff and most upscaling jobs, http://forum-images.hardware.fr/images/perso/loomy.gif it!

-When I'm 4m 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.

All this said, I'll play around with the green fix color option :)
I would say your description perfectly matches our artifical tests.

A4 = sharper edges, less smooth, makes details stand out more, no patterns
ED11 = mild-low sharpening, very smooth, doesn´t make anything stand out, mild patterns

I´m not sure what you mean with more "alive". Is that a negative thing? Do you mean the dithering noise itself or do you mean more alive in the sense of a "more natural appearance"? Because when something is more alive, it´s usually a good thing when you´re watching a movie.

Also, static in my tests will lower the bit-headroom a lot compared to dynamic. If that gives you the impression of a veil, though, that´s certainly not a good thing, but I still am not sure why are are even able to see that in 8bit in the first place. It´s still monoColored noise after all. It should be undetectable or else, your TV for some reason makes it stand out a lot.

Your description is also the reason why the dithering algorithms are always some kind of trade-off, because there are so many factors coming into play that it´s very hard to recommend something for everyone, any use case, different user setups and viewing distances.

[Qaq]

I've no idea where the noise comes from, but madVR got pretty much nothing to do with the audio side of things. So whether there's noise or not is outside of my control, from what I can see.
Not really, IMO. I guess its high CPU load (by madVR) on startup that causes audio noise or something. With last test builds I have sound glitches as well, but find them no big deal. Some delay in the madVR might help maybe.

[Asmodian]

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?

It is restored when playback is stopped but there is a slight delay.

Not really, IMO. I guess its high CPU load (by madVR) on startup that causes audio noise or something. With last test builds I have sound glitches as well, but find them no big deal. Some delay in the madVR might help maybe.

Have you tried "delay playback start until render queue is full"?

[6233638]

Overlay mode makes a BIG difference because Overlay mode totally ignores the GPU gamma ramps. madVR has to do extra work to manually apply GPU gamma ramps in Overlay mode. Yeah, ok, I guess madVR could make use of this Overlay specialty by letting the GPU gamma ramps alone, when using Overlay mode. I'm not sure if madVR currently does that or not.All the discussion on this has got me to do some testing, and I wish I had known about this "feature" sooner - it seems that the behavior in Windowed Overlay with "disable GPU gamma ramps" is different from regular FSW or FSE modes, and is exactly what I was looking for:

When Windowed Overlay is disabled, the "disable GPU gamma ramps" clears the profile currently loaded in Windows, and all applications are affected.

When Windowed Overlay is enabled, the "disable GPU gamma ramps" option only affects the video being played in madVR. All other applications are unaffected.


It's annoying that I won't be able to use PrtScn to take screenshots any more (overlay prevents this) but it now means that I don't have to worry about anything else affecting the madVR video output.

I've been testing f.lux (http://justgetflux.com/) again recently for example, and I liked what it was doing on text, but not what it was doing to videos.
The combination of Windowed Overlay and "disable GPU gamma ramps" works perfectly with it.

[iSunrise]

When Windowed Overlay is disabled, the "disable GPU gamma ramps" clears the profile currently loaded in Windows, and all applications are affected.
Is this like it´s supposed to work madshi? Didn´t know this either.

[6233638]

Is this like it´s supposed to work madshi? Didn´t know this either.That's what I would have expected in all cases. It's just that Windowed Overlay seems to be an exception to this.

[iSunrise]

That's what I would have expected in all cases. It's just that Windowed Overlay seems to be an exception to this.
There was some talk about this here (http://forum.doom9.org/showthread.php?t=146228&page=703).

What is confusing to me is that you wrote "It's annoying that I won't be able to use PrtScn to take screenshots any more (overlay prevents this) but it now means that I don't have to worry about anything else affecting the madVR video output."

Wasn´t the "disable GPU gamma ramps" option introduced, because mainly 3DLUT and madVR calibration made it necessary? So you´re saying that you need this option always enabled (because you´re using a 3DLUT)?

How would this effect external hardware calibration tools and monitors that still kinda rely on the windows profiles as well as other applications that are relying on the profiles, which are running with madVR at the same time.

Are the profiles restored after you quit madVR?

[Qaq]

Have you tried "delay playback start until render queue is full"?
That might fix audio issues, thanks. Don't really remember if I have it enabled.

[Ver Greeneyes]

All the discussion on this has got me to do some testing, and I wish I had known about this "feature" sooner - it seems that the behavior in Windowed Overlay with "disable GPU gamma ramps" is different from regular FSW or FSE modes, and is exactly what I was looking for:

When Windowed Overlay is disabled, the "disable GPU gamma ramps" clears the profile currently loaded in Windows, and all applications are affected.

When Windowed Overlay is enabled, the "disable GPU gamma ramps" option only affects the video being played in madVR. All other applications are unaffected.


It's annoying that I won't be able to use PrtScn to take screenshots any more (overlay prevents this) but it now means that I don't have to worry about anything else affecting the madVR video output.Indeed, this is great! I've been profiling with the calibration loaded into my 8-bit videoLUT because I can't stand turning the calibration off for other programs, but I'd much rather use the full 16-bit results for the 3DLUT and it sounds like overlay should let me do this (assuming it works the same way in Windows 7).

I have had hanging issues with it like that other user posted though - didn't want to interrupt the discussion for it when I tried it a while back. From what I recall, switching the overlay on required a restart of the media player before anything showed up, and transitioning from one video to the next in a playlist sometimes caused a hang.

[sneaker_ger]

[text]
No, you still don't understand. I am not comparing madVR output to the source I used to encode the "output_ll.mkv" from but I am comparing decoding of "output_ll.mkv" between l-smash/dither and madvr.

I created the l-smash/dither screenshot with this exact script:
lwlibavvideosource("output_ll.mkv")
Dither_convert_yuv_to_rgb(matrix="709", tv_range=false, output="rgb24")
ImageWriter("", 112, 112, "ebmp")
(Afterwards convert ebmp to png with irfanview.)

Then I opened the very same "output_ll.mkv" in MPC-HC, skipped to frame #112 and used MPC-HC's screenshot function to create the shot.

[*Touche*]

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


I have a hard time believing you actually see these differences in 8 bit at 3 meters away from a 32" TV.

[6233638]

Wasn´t the "disable GPU gamma ramps" option introduced, because mainly 3DLUT and madVR calibration made it necessary? So you´re saying that you need this option always enabled (because you´re using a 3DLUT)? It is not necessary, and some people may want to use their regular display profile with madVR.
It should be higher quality to bypass the display profile and calibrate purely using a 3DLUT though, and when you combine Windowed Overlay with the "disable GPU gamma ramps" option, it means you can do this without affecting other applications.

I have had hanging issues with it like that other user posted though - didn't want to interrupt the discussion for it when I tried it a while back. From what I recall, switching the overlay on required a restart of the media player before anything showed up, and transitioning from one video to the next in a playlist sometimes caused a hang.That's only the first time you enable the setting, if I recall correctly. I haven't had any problems with the player hanging when changing to a new file or anything like that.

The only thing is that because it's using Overlay, anything transparent in the Media Player looks bad. (and as previously mentioned, breaking PrtScn functionality) But those are minor issues.

[Vyral]

When Windowed Overlay is disabled, the "disable GPU gamma ramps" clears the profile currently loaded in Windows, and all applications are affected.


"disable GPU gamma ramps" only "bypass" the ICC profile loaded in Windows, is that what you mean ?
Then it should only be used when an ICC profile is loaded, right ?

[James Freeman]

If the performance of ordered dither is faster on all systems, it does seem like there's very little reason to keep random dithering around as it adds a huge amount of noise relative to the other options.
There are some people who would strongly disagree with this comment.
I too wrote that RD was obsolete when madshi introduced the first "Final" build, and got some harsh feedback.

When viewing in 8-bit rather than bit-reduced modes for testing, I think I will stick to ordered dither for now.
Any difference between dynamic ordered and dynamic error diffusion is extremely small at 8-bit,
This is what I do too.
I also lower both of the queues to 4 to spare the memories, as the CPU & GPU are powerful enough to not empty the queues.
I minimize the load when the effect is not seen (or measured), despite system capabilities.

I must say it's very impressive that ArgyllCMS is reporting the effective number of bits as 11-12 considering that the output is 8-bit.
Agreed.
I hope it directly translates to what the human eye sees.

[Ver Greeneyes]

"disable GPU gamma ramps" only "bypass" the ICC profile loaded in Windows, is that what you mean ?
Then it should only be used when an ICC profile is loaded, right ?Sort of? madVR is always unaffected by the profile in the ICC profile, however if the ICC profile has a videoLUT appended to it and those are loaded into your GPU, it will affect madVR as well - except when it's using the windowed overlay, apparently.

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.

[iSunrise]

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.
There´s a detailed FAQ linked on this page, which seems to cover it:
http://www.fourcc.org/fccyvrgb.php

You need to scroll to the bottom of the page, where it says: The Thorny Issue of HD Video

This particular description has caught my eye:
Just when you thought things were quietening down, Richard Salmon correctly points out that the YCrCb colour space used for HD video (ITU.BT-709) is actually different from SD (ITU.BT-601).
...
In addition to the YUV/RGB equations relating to Rec.601 (which are used for Standard Definition TV) there are another completely different set adopted for HDTV (ITU Rec.709). This change of equation was entirely pointless, but unfortunately we have to live with it, since it is the internationally agreed standard.

[Asmodian]

Sort of? madVR is always unaffected by the profile in the ICC profile, however if the ICC profile has a videoLUT appended to it and those are loaded into your GPU, it will affect madVR as well - except when it's using the windowed overlay, apparently.

Even in windowed overlay mode without the setting "disable GPU gamma ramps" madVR will copy the videoLUT data and use it to mimic the videoLUT calibration. The feature is that in windowed overlay the "disable GPU gamma ramps" option does not disable (set to linear) the hardware LUT.

[Ver Greeneyes]

Even in windowed overlay mode without the setting "disable GPU gamma ramps" madVR will copy the videoLUT data and use it to mimic the videoLUT calibration. The feature is that in windowed overlay the "disable GPU gamma ramps" option does not disable (set to linear) the hardware LUT.Ah right, good point. I don't have a calibration suitable for trying it out right now, so I was going by memory.

One thing I am wondering: Using the D3D9 API for setting a video LUT, only fullscreen applications are allowed to set it (and Windows will automatically restore the old LUT when the application exits fullscreen). So what I think we're seeing is that madVR tries to set the videoLUT to linear, assumes it worked, then doesn't take it into account when applying the 3DLUT. Except you're saying the overlay isn't affected by the videoLUT in the first place, so this is actually (accidentally) correct?

[kasper93]

No, you still don't understand. I am not comparing madVR output to the source I used to encode the "output_ll.mkv" from but I am comparing decoding of "output_ll.mkv" between l-smash/dither and madvr.

I created the l-smash/dither screenshot with this exact script:
lwlibavvideosource("output_ll.mkv")
Dither_convert_yuv_to_rgb(matrix="709", tv_range=false, output="rgb24")
ImageWriter("", 112, 112, "ebmp")
(Afterwards convert ebmp to png with irfanview.)

Then I opened the very same "output_ll.mkv" in MPC-HC, skipped to frame #112 and used MPC-HC's screenshot function to create the shot.

Hmm, I think madshi explained this very well. You have "output_ll.mkv" which was converted RGB->YUV and if you convert it back to RGB with the very same buggy math it will be "good". But if you convert it back to RGB with madVR, you will get different results, because math used by madVR isn't the same. And I'm not judging where it's miscalculated, but madshi explained it well. And actually you need to check if "output_ll.mkv" file was correctly converted to YUV...

[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.

[kasper93]

No, my test involved zero RGB to YUV conversions

It was converted once recording this sample.

One of them is wrong.

Exactly, so what is the problem? Do you have reference RGB screenshot/sample to compare which is wrong and check if ("output_ll.mkv") was correctly converted to YUV?

[leeperry]

I´m not sure what you mean with more "alive". Is that a negative thing? Do you mean the dithering noise itself or do you mean more alive in the sense of a "more natural appearance"? Because when something is more alive, it´s usually a good thing when you´re watching a movie.
Static ED11 looks too quiet from a distance and making it dynamic does help making it more realistic but the noise is more dancing around than being as extremely useful as it with static A4. Less noise, less wow factor and when I'm watching a movie from the couch I expect to be constantly entertained :)

Also, static in my tests will lower the bit-headroom a lot compared to dynamic. If that gives you the impression of a veil, though, that´s certainly not a good thing, but I still am not sure why are are even able to see that in 8bit in the first place. It´s still monoColored noise after all. It should be undetectable or else, your TV for some reason makes it stand out a lot.
Well the noise is randomly dancing around and it does veil the picture to my eyes. I still firmy believe that BFI is a game-changer as motion blur is drastically decreased, to the point that every frame looks "fresh" and not some artistic blur from the previous one...we also perceive colors differently as I see slightly less red than you do basically. Anyway, better have too many options than not enough and I'm very pleased that ED11 & A4 made it through, as I thoroughly and equally enjoy both.

I have a hard time believing you actually see these differences in 8 bit at 3 meters away from a 32" TV.
Well tbh I have a hard time believing that you can bear watching a Plasma as those nasty things look like a 15Hz CRT to my brain...and I've watched a whole bunch of LG, Sammy and even a Pana GT30. As I previously showed you, I'm far from being the only one....I also see RBE's on DLP when the CW runs at less than 200Hz(50Hz*4) (http://archive.is/g7Za) but some ppl seem completely immune to RBE, even with a sluggish 2X CW. We all see and hear differently.

There's so much dithering/color blinking trickery going on with Plasma that I fully agree on the fact that nitpicking about mVR's dithering on those things is kinda bound to fail....which again means more time for more fruitful activities :cool:

[sneaker_ger]

It was converted once recording this sample.
Yes, but that isn't part of the test. If I work on a Blu-Ray sample you wouldn't ask me how the mastering process in the authoring house was because it's irrelevant.

Exactly, so what is the problem?
Two chains delivering different results is the problem.

Do you have reference RGB screenshot/sample to compare which is wrong and check if ("output_ll.mkv") was correctly converted to YUV?
Here:
http://abload.de/img/112_rgb_source_y2s59.png
It's not relevant for this specific test so don't try to nail me down to it.

[*Touche*]

Well tbh I have a hard time believing that you can bear watching a Plasma as those nasty things look like a 15Hz CRT to my brain...and I've watched a whole bunch of LG, Sammy and even a Pana GT30. As I previously showed you, I'm far from being the only one....I also see RBE's on DLP when the CW runs at less than 200Hz(50Hz*4) (http://archive.is/g7Za) but some ppl seem completely immune to RBE, even with a sluggish 2X CW. We all see and hear differently.

There's so much dithering/color blinking trickery going on with Plasma that I fully agree on the fact that nitpicking about mVR's dithering on those things is kinda bound to fail....which again means more time for more fruitful activities :cool:

I can't believe you can stand gray blacks :D

Plasma flicker and RBE are something different and there is an objective reason some are bothered by them. But you are talking about minute pixel differences from 3 meteres away on a tiny 32" screen. I believe that you believe you see differences, as I often think I do too, but I bet you would fail a blind test. I guess this is getting too OT, so I'll put it to rest.

[kasper93]

Yes, but that isn't part of the test. If I work on a Blu-Ray sample you wouldn't ask me how the mastering process in the authoring house was because it's irrelevant.

Yes, but you can assume that Blu-Ray is standard compliant. With such recording as your sample, you can't be sure.

Two chains delivering different results is the problem.

Indeed, but unless you can prove that madVR is doing it wrong I see no point in discussing it here. Madshi already said that he wrote the code from scratch and he didn't copy bugs from open source libs.

One of two chains is wrong, but you can't know which unless you do proper RGB->YUV conversion. You said that this is not part of your test, but it certainly should if you are going to blame madVR for doing something wrong.

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.

That say, I don't see a bug here, I just see two different results which doesn't mean anything.

[leeperry]

you are talking about minute pixel differences
Minute pixel differences :confused: 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.

[madshi]

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 (http://www.mediafire.com/download/mntpfnsgaalms97/cadence.mpg) 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.

All this said, I'll play around with the green fix color option :)
The green fix is only for ordered dithering, though.

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.

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.

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.

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.

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

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.

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.

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]

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*]

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.


Minute pixel differences :confused: 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]

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]

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]

-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]

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!