madVR - high quality video renderer (GPU assisted)

[Xaurus]

Originally Posted by Messiah

I'm trying to calibrate my LG 50PK550 using AVS HD 709 patterns.

I've fired up Black Clipping sample, ahd have a very strange problem.

I set Black level to high on my LG(0-255).
But if I tell madVR that my display expects 0-255, i only see bars 18-25 flashing.
If I set to 16-235 then I see bars 2-25 flashing.
Should that be other way around?

Of course, if I set LG black level to low, I see only bars 18-25 flashing...

My LG is connected through Marantz SR5004 receiver(maybe this causes problems), and HTPC is Zacate (AMD E-350 Fusion).

I have the same set as you do (only 60" version) and if you set the LG to "high" and madvr to 0-255 it will be OK.

I am using Nvidia though, so I am not sure how that would be compared to your Fusion (I assume it has integrated graphics).

edit:
By the way, if you don't have calibration tools for your TV (like me) and have tried many different settings for your set, you can look at this post:
http://www.avforums.com/forums/14947541-post43.html

It basically made my day after trying X number of expert 1/2 settings and never being completely happy.

[Messiah]

Originally Posted by Xaurus

I have the same set as you do (only 60" version) and if you set the LG to "high" and madvr to 0-255 it will be OK. Gamma on "medium" and brightness at 50 on the LG.

I am using Nvidia though, so I am not sure how that would be compared to your Fusion (I assume it has integrated graphics).

edit:
By the way, if you don't have calibration tools for your TV (like me) and have tried many different settings for your set, you can look at this post:
http://www.avforums.com/forums/14947541-post43.html

I have Eye One display 2 so I wan't to calibrate my TV properly.

But when I choose 0-255 in madVR, I only see 18-255 flashing, and when I choose 16-235, I see 2-25 flashing.

Should RGB Limited clip all values under 16?

EDIT: Zacate uses integrated 6310, in AMD Vision I set up pixel format 4:4:4 Full RGB PC Levels.

[Mark_A_W]

Originally Posted by dansrfe

I have a question about screen savers and blanking one of the screens in a dual monitor setup if only one of the monitors are being used to watch a clip in windowed or exclusive mode.

For example: I have a dual monitor setup in which I am watching a movie in exclusive mode on Monitor #2 and I am using Monitor #1 sometimes or not using it at all for long periods of time in which the screen still remains on. Normally if I don't move the mouse or touch the keyboard for 2 minutes then I have set the screen to "shut-off signal" and both monitors go blank. Is there a way to apply this same rule on Monitor #1 or Monitor #2 if only the other is being used with madVR? In other words, is it possible for Monitor #1 to shut-off signal and go blank if Monitor #2 is displaying a movie in exclusive mode?

I have a similar setup, and I, umm.....turn the other monitor off...you know with my finger, on the button, so to speak..

Sorry....but everything doesn't *have* to be automated.

[nand chan]

Originally Posted by Mark_A_W

I have a similar setup, and I, umm.....turn the other monitor off...you know with my finger, on the button, so to speak..

Sorry....but everything doesn't *have* to be automated.

Haha wow, yes, this. I think most of use / many of us have more than one monitor. They have a power button for a reason.

[silverking93]

Dear Madshi,
There is a problem that I've been having for quite a long time. It's the same problem that 3ngel had back on page 209, but to my knowledge, he never got it resolved. I've had to resort to watching low quality videos on the default renderer (using MPC-HC), which is irritating to say the least.

Whenever I open a video, shown in the upper left-hand corner is this message:

madVR reports:
-creating Direct3D device failed (8876086c)

This is extremely frustrating, because no amount of option-tweaking will fix it. I'm running a Dell Latitude d620 with an Intel 945gm Mobile Chipset. It has 224.0 MB of memory, and supports Dx9 Direct3D. I'm running windows XP. As far as I know, I meet the minimum hardware requirements. What can I do to resolve this problem?

Thank you for your time.

P.S. I tried to do the debug routine using the madVR[debug].ax file and switching the name and all that, but it didn't put a text file on the desktop. Otherwise, I would post a link to the log right now. If you would like to send me a personal message, I can give you an email address by which you can contact me, if that makes things easier for you. Thanks again.

[nand chan]

Originally Posted by cyberbeing

The madVR/3DLUT workflow has been odd, or rather complex, ever since 0.62 when madshi moved to RGB and offloaded various operations to shaders.

It looks something like the following with BT.709 input:

madVR:
(1) input = 8bit Y'CbCr, 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(2) convert -> 32bit float R'G'B', 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(3) convert -> 32bit float RGB, 709 primaries/gamut, linear light, WTW/BTB, D65 White Point
(4) convert -> 32bit float RGB, Display primaries/gamut, linear light, WTW/BTB, D65 White Point
(5) convert -> 32bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma, WTW/BTB, D65 White Point
3dlut:
(6) input = 8bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma (with trilinear interpolation), WTW/BTB, D65 White Point
(7) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, D65 White Point
(8) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, Display White Point
(9) convert -> 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
madVR:
(10) input = 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
(11) dither down to 8bit R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point

You'll need to use madVR <=0.61 if you want the old behavior of the 3DLUT doing everything (YUV->RGB, Gamut Correction, Gamma Correction, White Point Correction, Levels Expansion) with no shaders. I still like the old way better, for the added flexibility you get with 3DLUT creation.

I'm experimenting around with gamma adjustment and gamut mapping.

As far as I can tell, when my value hits the .3dlut in step (6), it's expected to be encoded using a pure power of 2.2, correct? So the first thing I do is decode it back to rgb (or linear RGB) by raising it to a power of 2.2.

Then I do whatever I wish with the value (eg. nothing), and I convert it back to the display's expected gamma level by raising it to, say, 1/2.2 - which will, assuming an ideal 2.2 gamma display, give me a linear intensity again.

I was under the impression, however, that adjusting the encoded for display gamma to /higher/ values (eg. 2.35) will make the image appear slightly darker as a result - however, if I plug those values in (decode using 2.2, encode using 1/2.35), the image appears brighter than before.

Where exactly am I going wrong here? Wouldn't encoding with 1/2.35 make the encoded R'G'B' signal match that of a 2.35 monitor (and since my monitor only has a 2.2 input to luminosity exponent, it /should/ appear darker than intended)?

[cyberbeing]

It's brighter since the 1/2.35 encoding is linearized to 1.0, and afterwards it's returned to the decode gamma of 2.2.

Have you tried enabling gamma correction in madVR and setting it to 2.35? IIRC, that should return 1/2.35 data which was linearized, back to a gamma to 2.35. Step (9) is actually a madVR shader step, where madVR does any gamma correction needed to the 2.2 gamma 3dlut based on the information in 3dlut header and user settings.

Since I've never used or asked specifically about how gamma correction works in madVR, I'm only half-certain the above is correct. Madshi or yesgrey, please correct me if I'm way off.

[nand chan]

Originally Posted by cyberbeing

It's brighter since the 1/2.35 encoding is linearized to 1.0, and afterwards it's returned to the decode gamma of 2.2.

But that contradicts your earlier statement - according to the steps posted earlier, madVR would linearize + encode it to 2.2 before it touches the .3dlut, not afterwards. So any processing I do in the .3dlut would directly affect the output.

Have you tried enabling gamma correction in madVR and setting it to 2.35? IIRC, that should return 1/2.35 data which was linearized, back to a gamma to 2.35.

At which step does the madVR gamma correction apply? Before the .3dlut or after it?

What I'm basically trying to do is simulate the effects of the madVR gamma correction using a .3dlut, so using the actual tool would defeat the purpose.

Step (9) is actually a madVR shader step, where madVR does gamma correction with the 2.2 gamma 3dlut based on the information in 3dlut header and user settings.

1. madVR does not read gamma information out of the .3dlut header.
2. If you were referring to the gamut correction which madVR performs, it does that before the values enter the .3dlut - it reads out the input primaries information from the .3dlut and scales the colors into that color space. To my knowledge, madVR shouldn't be touching the output of the .3dlut, other than dithering it down to screen depth (+ rendering subtitles).

I'll probably have to ask madshi about this.

Edit: Never mind, I approached the problem visually (as I love to do), and the solution began to become clear to me.



I was mixing up the two curves. The red line is a 2.2 display, the light blue line is a 2.2 signal for that display. The two, when applied in succession, result in the purple line in the center which is the linear light output.

However, if I use a 2.35 display (darker), I need to encode a /brighter/ curve (1/2.35, shown in dark blue) to compensate. As a result, a brighter curve on the same display appears brighter.

Edit 2: Also, thinking about it this way, made me realize how to achieve the result I want.

In essence, I want to compute the value which would be equal to a (1/2.2) encoded value being rendered on a 2.35 screen - which would appear slightly darker.

Or, in other words, I want my x₂ = (x₁∧(1/2.2))∧2.35. Now, we know that our original input x₁' = x₁∧(1/2.2) since madVR adjusts to 2.2 PPC already before it hits the .3dlut, so we can pop that right into the formula: x₂ = x₁'∧2.35. And, of course, since we know our display is x₂=x₂'∧2.2, we just need to compensate for that: x₂' = x₂∧(1/2.2) = (x₁'∧2.35)∧(1/2.2).

And there we have our formula:

1. Exponentiate to the new desired gamma curve
2. Exponentiate to the inverse of the old gamma curve

[cyberbeing]

Edit: After reading your edit, my reply isn't needed? If I completely misunderstood what you were trying to figure out, disregard the below.

Originally Posted by nand chan

But that contradicts your earlier statement - according to the steps posted earlier, madVR would linearize + encode it to 2.2 before it touches the .3dlut, not afterwards. So any processing I do in the .3dlut would directly affect the output.

As of step (6), the video has been converted to gamma of 2.2.
In step (7) the video which has a gamma of 2.2 is converted to linear light.
If you use 1/2.35 as the encoding for the 3dlut, everything will get brighter in step (7) since the video isn't 2.35, it's 2.2.

IIRC, madVR does read the 3dlut header to decide how to convert to linear light for step (7), but madshi would need to confirm. The longer I go on trying the explain things, the more likely I'm going to get something wrong.

Encoding gamma (3dlut) = madVR gamma (gamma correction setting) is equivalent to no gamma correction. In other words, the 3dlut set with an encoding of 1/2.35 and madVR set to 2.35, it means no gamma correction is performed by madVR shaders.

Originally Posted by nand chan

At which step does the madVR gamma correction apply? Before the .3dlut or after it?

I guess you could consider it 'after', but it's really 'during'. In step (9), madVR shaders manipulate the 3dlut data to perform gamma correction as needed. Take a look at how the headers of 3DLUTs created within madVR look when gamma correction is enabled and set to 2.35, to get an idea how this is signaled.

Originally Posted by nand chan

What I'm basically trying to do is simulate the effects of the madVR gamma correction using a .3dlut, so using the actual tool would defeat the purpose.

yesgrey would be your man for questions such as these. This is the limits of my knowledge on the subject, since I stay the hell away from gamma correction done by yCMS+madVR in my setup.

Edit2: madshi, I hope you can push out a new version of madVR soon which fixes the problem of it holding onto decoder references when a new video is opened. It causes a new instance of CoreAVC 3.x to be created each time, resulting in what is basically a memory leak.

[G_M_C]

I must say i'm getting a bit annoyed getting MadVR to work.

I'm on Win7-64, using 32 bit version of MPC-HT (current).
I downloaded madVR 074 and put it in C:\MadVR. I'm logged in as admin and runned install.bat, even tried activating the administrator account with the 'net user ...' command.

When i want to open madVR's setting page, it keeps complaining that the instance cannot be found, and to make sure the firewall isnt blocking madvr. But even if i disable the firewall it wont work.

What to do ?

[nand chan]

Originally Posted by cyberbeing

Edit: After reading your edit, my reply isn't needed?

Indeed so.

As of step (6), the video has been converted to gamma of 2.2.
In step (7) the video which has a gamma of 2.2 is converted to linear light.
If you use 1/2.35 as the encoding for the 3dlut, everything will get brighter in step (7) since the video isn't 2.35, it's 2.2.

Don't forget that steps (6) through (9) are *not* done by madVR - they are contained within the .3dlut. But I'm cutting out all of those steps (performed by yCMS) and doing my *own* calculations in place of them. So the conversion to linear light never happens in my version of things (or, well, it does if I want it to).

The .3dlut encompasses the entire process from 8 bit to 16 bit, madVR never uses 64 bit values.

The only things madVR does after the .3dlut output are the steps below the second “madVR:”, aka dither down to screen depth.

IIRC, madVR does read the 3dlut header to decide how to convert to linear light for step (7), but madshi would need to confirm. The longer I go on trying the explain things, the more likely I'm going to get something wrong.

It does not (for reasons described above) - the only things madVR reads is the Input_Primaries information, and it makes sure the strings “0 255”, “RGB_PC” and “YCbCr” are not present - that's all; I know this because I work closely with .3dluts myself and generate madVR-compatible headers, also the information is taken from an earlier post of madshi in this thread.

Encoding gamma (3dlut) = madVR gamma (gamma correction setting) is equivalent to no gamma correction. In other words, the 3dlut set with an encoding of 1/2.35 and madVR set to 2.35, it means no gamma correction is performed by madVR shaders.

I guess you could consider it 'after', but it's really 'during'. In step (9), madVR shaders manipulate the 3dlut data to perform gamma correction if needed. Take a look at how the headers of 3DLUTs created within madVR look when gamma correction is enabled and set to 2.35, to get an idea how this is signaled

Actually, there's no need for guesswork - I forgot I already had a special .3dlut which would change the output color based on the input luminosity (blue = 0, red = 1; all other color information is discarded). madVR does in fact adjust the gamma /before/ it enters the .3dlut. So if gamma correction is /disabled/, the input values will be x'=x^(1/2.2), if gamma correction is /enabled/, the input values will be x'=((x^(1/2.2))^(y))^(1/2.2). where y is the simulated gamma, eg. 2.35.

As such, no matter what gamma the user desires, the input value will always be on the scale ^(1/2.2) which is what the monitor has to work with, and all of my edits should be transferred back to such.

Btw, what is referred to as “Display corrected gamma” in step (9) means yCMS fixes the gamma to account for any display inaccuracies - eg. it “simulates” a true 2.2 display - this has /nothing/ to do with the madVR “enable gamma processing” feature.

yesgrey would be your man for questions such as these. This is the limits of my knowledge on the subject, since I stay the hell away from gamma correction done by yCMS+madVR in my setup.

Unfortunately yesgrey is terribly busy. Nonetheless, your earlier post has been extremely helpful as I was able to guess the exact workings with my knowledge + yours.

Ps. I'd also like to correct step (4) - madVR does in fact adapt the white point to the display's as well.

[nand chan]

Having done some experimenting, it seems like the usage of ICC profiles and .ti3 files and yCMS and all of that fancy stuff is, at least partially, completely unnecessary! I'm doing some experiments with madVR's built in chromatic adaption - it's basically just as precise as gamut mapping with ICC profiles or yCMS, even white point adaption.

Since ArgyllCMS's .cal files take care gamma fixing as well (making sure that if a perfect 2.2 enters the .cal, a perfect 2.2 leaves the screen), all we have to do is 1. tag the input primaries of the monitor profile and 2. load the calfile!

A simple madVR-compatible .3ls for gamut and gamma fixing could look something like this:

# Set the properties properly
!Filetype(3DLUT)
!Input_Range(Limited)
!Output_Range(Limited)
!Input_Primaries(0.6821358317, 0.303858037, 0.19746212, 0.70357813, 0.14572444, 0.0486, 0.31289517, 0.33084743)

!Pixel(CalFile("standard.ti3"))

No more yCMS, no more LittleCMS - just madVR + my CalFile loader.

Of course, this isn't a real 3D LUT implementation - it's just a 3x1D LUT, no better than the graphics card's CLUTs will provide (except maybe with 64 bit interpolation) - but that can be easily fixed from there.

Given a known input gamma (1/2.2), one can construct a virtual RGB profile with the exact same primaries as the output profile and the (1/2.2) gamma, eg. using LittleCMS, and then just use the ICC to fix all inconsistencies. One could even then encode the difference only and LZO compress it, which will result in a remarkably small .3dl2 since all of the complex gamut mapping code will be abstracted away within the madVR's GPU chain. As such, we could expect much faster load times as well.

I will be experimenting around with this solution. With the addition of the video card's CLUTs, we might not even need the .3dlut at all (except for a “blank” .3dlut that tags the primaries - madshi, consider allowing us to set the primaries without using a .3dlut?)

Edit: The only skepticism I have right now is what happens if the monitor's gamut is /smaller/ than BT.709. Does madVR simply clip values, or does it properly convert them to L*Ch (polar coordinates of L*ab) and reduce the chromaticity? (I'm guessing it doesn't, or does linear pulling, or some other cheap trick)

I'll have to ask madshi about this: How does madVR behave if the .3dlut's input primaries are smaller than the BT.709 primaries?

[QBhd]

Originally Posted by G_M_C

I must say i'm getting a bit annoyed getting MadVR to work.

I'm on Win7-64, using 32 bit version of MPC-HT (current).
I downloaded madVR 074 and put it in C:\MadVR. I'm logged in as admin and runned install.bat, even tried activating the administrator account with the 'net user ...' command.

When i want to open madVR's setting page, it keeps complaining that the instance cannot be found, and to make sure the firewall isnt blocking madvr. But even if i disable the firewall it wont work.

What to do ?

Are you trying to access the settings whilst playing a video? madVR needs to be running to use the settings.

QB

[G_M_C]

Originally Posted by QBhd

Are you trying to access the settings whilst playing a video? madVR needs to be running to use the settings.

QB

Thx, that was one of the problems
I also used the install manager to reset te register to the state it was before running install.bat. It's running now.

[cyberbeing]

Originally Posted by nand chan

don't forget that steps (6) through (9) are *not* done by madvr - they are contained within the .3dlut. But i'm cutting out all of those steps (performed by ycms) and doing my *own* calculations in place of them. So the conversion to linear light never happens in my version of things (or, well, it does if i want it to).

The .3dlut encompasses the entire process from 8 bit to 16 bit, madvr never uses 64 bit values.

Hmm... Thanks for the info, it sounds completely different than what madshi and yesgrey told me, but is probably correct. I always had the feeling that yesgrey must have coded all the new 3dlut related stuff in 0.62 by the way madshi explained things.

madshi, when you come back around, can you clarify the above for me? Once again, how does madVR interact with the 3DLUT during steps (6) through (9) in >=0.62 compared to <=0.61? What does the 64bit refer to in the steps you listed? It's beginning to seem that many of my complaints about the new 3dlut limitations introduced in 0.62 from the 'dumb' 3dlut behavior in 0.61, were all just yCMS limitations imposed by yesgrey???

[Budtz]

I found a setup that works. running videos at 25p and then having 50hz at the tv. but now i get glitches. i did not at 24p60 or 24p24. are there any settings that work better in 50hz? It seems the glitches are not rerlated to 25p playback. only when i switch the resolution to 50hz

Edit: seems to work to enable the glitch hacks.
Is it a bug maybe that madvr dosnt work as well with 50hz as 60hz or 24hz?

[6233638]

Originally Posted by Budtz

I found a setup that works. running videos at 25p and then having 50hz at the tv. but now i get glitches. i did not at 24p60 or 24p24. are there any settings that work better in 50hz? It seems the glitches are not rerlated to 25p playback. only when i switch the resolution to 50hz

Edit: seems to work to enable the glitch hacks.
Is it a bug maybe that madvr dosnt work as well with 50hz as 60hz or 24hz?

A while back, around the time when the new rendering path was introduced, videos running at multiples of the refresh rate started having presentation glitches for me.

24/25p@24/60 was fine, but 25@50 or 30@60 did not work correctly.


If your card supports it, use D3D11 presentation, and enable the "limit rendering times to avoid glitches" option.

Everything else as far as rendering is concerned should be left at the defaults. (though you may want to increase the buffer sizes)


It would be interesting to know if the "limit rendering times to avoid glitches" option causes problems for anyone, regardless of whether or not they are experiencing this issue. It seems like it could maybe be enabled by default.

[Defiler]

madVR is the best thing. Sorry if that doesn't add much to the conversation.

[G_M_C]

Originally Posted by 6233638

A while back, around the time when the new rendering path was introduced, videos running at multiples of the refresh rate started having presentation glitches for me.

[...]

Hope that is looked at. Cause here in PAL-land (yes, the NTSC/PAL regions still excist) multiples of 25 are seen often.
ex: 1080i50 -> deinterlaced to 1080p25 and displayed on 1080p50.

[e-t172]

@madshi: I don't know if you're actively following the thread about the 3dlut processing tools from nand chan, but I think you should take a look at the the discussion with Graeme Gill (the author of ArgyllCMS, no less), who doesn't seem convinced that using 256x256x256 lookup tables is the best idea ever. Maybe you could tell him your side of the story