madVR Options Explained

[huhn]

So you are saying a color space conversion from RGB to YCbCr is a necessary part of image doubling? This is what I questioned based on that post.

yes of cause you can't scale luma from RGB.
i wonder if a RGB -> YCbCr conversation is used when chroma and luma is doubled at the same time.

[Asmodian]

yes of cause you can't scale luma from RGB.
i wonder if a RGB -> YCbCr conversation is used when chroma and luma is doubled at the same time.

Madshi has confirmed that it is, around when doubling was first added. There is no special case that skips coversion to YCbCr for doubling both luma and chroma with the same number of neurons. it would be odd (rare) to use the same number of neurons for both anyway.

So you are saying a color space conversion from RGB to YCbCr is a necessary part of image doubling? This is what I questioned based on that post.

Luma is Y and chroma is Cb and Cr.

[Warner306]

Madshi has confirmed that it is, around when doubling was first added. There is no special case that skips coversion to YCbCr for doubling both luma and chroma with the same number of neurons. it would be odd (rare) to use the same number of neurons for both anyway.



Luma is Y and chroma is Cb and Cr.

Ok, I understand. Now that chroma doubling has returned, your chart will still have to be updated, or reverted back to its previous state.

[Asmodian]

Updated for v0.88.7

Ok, I understand. Now that chroma doubling has returned, your chart will still have to be updated, or reverted back to its previous state.

Yes, more modifications needed. I should have listened to huhn. ;)

Thanks for the feedback, I hope this new chart makes sense. Like any other feature, chroma doubling doesn't do anything if it isn't enabled so I felt the explicit path for chroma doubling disabled wasn't helpful.

[Warner306]

Updated for v0.88.7



Yes, more modifications needed. I should have listened to huhn. ;)

Thanks for the feedback, I hope this new chart makes sense. Like any other feature, chroma doubling doesn't do anything if it isn't enabled so I felt the explicit path for chroma doubling disabled wasn't helpful.

Not meaning to be a pest, but have you considered factoring in NEDI image doubling? It appears to double with RGB values because you can only scale both luma and chroma together.

[Asmodian]

Not meaning to be a pest, but have you considered factoring in NEDI image doubling? It appears to double with RGB values because you can only scale both luma and chroma together.

I added a note about it to the NEDI description but I don't think I will include it in the diagram. It would simply replace the entire "image doubling" box and I leave out a lot of details in the diagram already. I am also not sure how to add it in a way that makes sense.

If I did include it I suppose I would simply add NEDI image doubling to the black "image upscaling or downscaling" box and call the current "image doubling" box "NNEDI3 image doubling". :o

[Asmodian]

Small updates for 88.10.

still more to do.

[Neeto]

Good write up - thanks.
Any chance of adding in the registry entries - particularly the ones to turn off driver dithering in AMD

[Asmodian]

Good write up - thanks.
Any chance of adding in the registry entries - particularly the ones to turn off driver dithering in AMD

I am actually at the character limit already. :(

I also don't know those AMD registry entries. :o

Don't you only want to use them when testing if a display is really 10-bit? The drivers dithering any conversion they do seems good.

[Asmodian]

Updated for madVR v0.88.11.

I also moved Known Limitations or Complication out of the first post for space. Most of these are somewhat obscure so hopefully not much is lost.

Known Limitations or Complications:
-madVR can't do frame packed 3D
-When using a 3DLUT madVR can generate out of gamut values when displaying WtW unless it is emulating the GPU LUT when using 'enable windowed overlay'.
-Native DXVA decoding has some negative ramifications such as it is impossible to use force film (IVTC) or xy/vsfilter for subtitles.
-madVR cannot handle p010 (10-bit) input from DXVA native.
-madVR IVTC can detect a lot of cadences but can "only" handle some of them correctly. For example the rare cadence 3:2:3:2:2 (25 fps in 30i 60 fields) does not work well.
-madVR currently always switches to 23Hz when having forced film mode on while playing 59i content.

[RainyDog]

Updated for madVR v0.88.11.

I also moved Known Limitations or Complication out of the first post for space. Most of these are somewhat obscure so hopefully not much is lost.

Known Limitations or Complications:
-Native DXVA decoding has some negative ramifications such as it is impossible to use force film (IVTC) or xy/vsfilter for subtitles.
-madVR cannot handle p010 (10-bit) from DXVA native.

So we shouldn't use DXVA native in LAV if using madVR in 10bit output mode?

I don't see any issues with it at my end (though I don't have any material that needs IVTC nor do I use xy/vsfilter) and DXVA native seems to have a lower overhead than copyback or Cuvid.

[nevcairiel]

IMHO, You shouldn't use DXVA native with madVR at all really, using DXVA2-CopyBack is probably a better combination.

[Qaq]

So we shouldn't use DXVA native in LAV if using madVR in 10bit output mode?
Nope. Asmodian meant madVR's input, not output. 10 bit from madVR's output works just fine for me with DXVA native.
IMHO, You shouldn't use DXVA native with madVR at all really, using DXVA2-CopyBack is probably a better combination.CopyBack shares GPU bus with madVR, right? Sometimes GPU is too busy with madVR to route additional LAV's decoding traffic there.

[nevcairiel]

At least if you're using NVIDIA (and maybe on Intel? I forget), madVR will perform a "copy-back" anyway as thats the only way to preserve full chroma quality. So in that case, its better to just use Copy-Back from the get-go and avoid any limitations in madVR.

madVR used to have a trade quality option to disable this copy-back and risk bluring chroma a bit, but I think madshi removed it recently. Not sure if he worked-around the chroma limitation differently without costing much performance, or just decided to not offer the trade option anymore...

[Qaq]

I have Intel g1830 on workstation and AMD 7750 on HTPC. After upgrading from 5450 (64 bit bus) to 7750 (128 bit bus) I started with DXVA CB and had no issues untill I tried full 1920x1080 (with no borders) video. It looked stuttering with perfect madVR OSD stats in same time. I switched LAV from DXVA CB to DXVA native and playback turned to smooth again.
You see now why I'm very carefull with DXVA CB. Though CB is still the best solution for havy bitrate telecined videos.

Asmodian, sorry if it looks like off-topic, lets just aware AMD users do not use havy madVR settings with LAV DXVA copy-back )

[huhn]

I have Intel g1830 on workstation and AMD 7750 on HTPC. After upgrading from 5450 (64 bit bus) to 7750 (128 bit bus) I started with DXVA CB and had no issues untill I tried full 1920x1080 (with no borders) video. It looked stuttering with perfect madVR OSD stats in same time. I switched LAV from DXVA CB to DXVA native and playback turned to smooth again.
You see now why I'm very carefull with DXVA CB. Though CB is still the best solution for havy bitrate telecined videos.

Asmodian, sorry if it looks like off-topic, lets just aware AMD users do not use havy madVR settings with LAV DXVA copy-back )

do you have a sample of this issue? this doesn't make any sense.

[Qaq]

No, I don't have that movie anymore. And whats the point anyway? You don't want to test it totally different environment and say "everything is alright", do you?
My point is that DXVA copy-back puts additional load on GPU (GPU bus at least), which BTW is already too busy with madVR. Do you agree or not?

[huhn]

no i don't agree at all.
the copyback load is nothing at all. we have CB-D now on top of it.

why would madVR stutter with totally fine OSD stats that means it is a clear bug.

[Qaq]

Bug or not, it was ages ago. Next, not everyone has SSE4 capable CPU for CB direct. I don't.
Also, it would be nice to see GPU-Z screenshots for DXVA N and DXVA CB.

[huhn]

i tried that but with no really findings.

the load difference is so small it's hard to measure. but i don't have a weak GPU currently the weakest i have is a HD 4000 and a HD 4400 both a IGPU with ddr3 speed and not with gddr5 which is worlds faster.

[Qaq]

Well, for IGPUs/APUs it may be a totally different story of course. Different architectures, different traffic routing. I use myself CBd with madVR on G1830 just fine for almost any video now.
Let alone GPU-Z for AMD without screenshots. GPU-Z doesn't show much for my 7750 anyway. With AMD we have to "copyback" OpenCL data and here comes PCIe bottleneck. Lets route there DXVA CB traffic as well?

[huhn]

Well, for IGPUs/APUs it may be a totally different story of course. Different architectures, different traffic routing. I use myself CBd with madVR on G1830 just fine for almost any video now.
Let alone GPU-Z for AMD without screenshots. GPU-Z doesn't show much for my 7750 anyway. With AMD we have to "copyback" OpenCL data and here comes PCIe bottleneck. Lets route there DXVA CB traffic as well?


the openCL copyback issue use the same bandwidth yes. but do you notice a difference in speed there?

AMD d3d <-> openCL intreop looks like a terrible inefficient copyback while DXVA CP/D is very efficient.

[Telion]

Do AMD APUs suffer from this d3d <-> openCL copyback issue? Isn't hUMA supposed to overcome exactly this kind of problems? Should madVR explicitly implement some kind of hUMA support, or it is a driver's task? If it's the former, would madVR implement it some day?

[huhn]

madVR uses openCL cl_khr_dx9_media_sharing and it looks like it is designed to copyback.

AMD APU usually have a to weak iGPU anyway so the buttleneck is not the bandwidth and in the end they don't use PCIe for copyback in the first place

[Soul]

hi.. what is the best option for GPU queue size and CPU queue size? I have GTX750 NVidia.

Thanks

[huhn]

default is usually optimal.

[XMonarchY]

Is there truly no benefit to using Chroma Upscaling and/or Image Doubling/Quadrupling on TV's that are set to use 0-255 range, RGB, but limited to 4:2:2. In my case, 4:4:4 simply looks really bad (too dim) on my TV, leaving 4:2:2 as the only real choice.

[Asmodian]

The high cost Chroma Upscaling and Chroma Image Doubling options will not provide as much benefit (and their benefit is already minor) when using 4:2:2 but they do still provide a benefit. Luma Image Doubling is still very helpful.

However, I have never seen a TV that changes brightness or contrast due to 4:4:4 or 4:2:2, are you sure you are not confusing limited range (16-235) with color sub-sampling? Usually 4:4:4 or 4:2:2 is not something you can easily change unless your TV has a PC Mode. Also the difference is somewhat subtle, hence the need for an image to test for 4:2:2 or 4:4:4.

[vivan]

However, I have never seen a TV that changes brightness or contrast due to 4:4:4 or 4:2:2, are you sure you are not confusing limited range (16-235) with color sub-sampling? Usually 4:4:4 or 4:2:2 is not something you can easily change unless your TV has a PC Mode. Also the difference is somewhat subtle, hence the need for an image to test for 4:2:2 or 4:4:4.No, he is just used to LSD colors of his Samsung and that extreme postprocessing is disabled in PC mode or something.

[pirlouy]

I have a 2009 Samsung TV and indeed, when using PC mode, you lose all post-processing, and image looks insipid.
In fact, image is surely normal, but when you compare to Samsung post-processing, it looks insipid.
My solution has been to increase saturation in madVR, and I manage to have the same result.
I don't know if I should blame Samsung for that, but I prefer a saturated image now. xD

[XMonarchY]

No, he is just used to LSD colors of his Samsung and that extreme postprocessing is disabled in PC mode or something.

Might want to think before you post or at least ask. ALL post-processing is completely turned off and I calibrated each mode using both manual settings and 3DLUT with i1Display Pro. I could calibrate 4:2:2 mode color gamut, but not 4:4:4 PC mode because color gamut calibration does not apply to PC mode. This, however, should make no difference since I applied 3DLUT on top of each calibration and the results were very accurate.

I use Standard mode (with all post-processing disabled in User Menu and in Service Menu) + Game mode (4:2:2), which reduces input lag by further bypassing post-processing. It looks identical to fully calibrated Movie mode, but Standard + Game mode simply provides better/lower input lag.

4:4:4 PC mode looks bland, pale and kind of dim, even with 3DLUT. Its not just me - other Samsung VA owners reported similar findings. I also own Samsung PNF5350 Plasma TV and PC mode (4:4:4) looks perfectly fine, better than 4:2:2 modes. It seems like the problem is with specific Samsung VA screens.

[Asmodian]

Obviously all post-processing is not off if it looks very different? All post-processing you can turn off is off. It sounds like Samsung has a correction/calibration tied to a post-processing chip that operates in 4:2:2 and changes the way the panel runs outside the 0-255 RGB input values (if a 3DLUT cannot fix it).

Have you tried creating a 3DLUT with a saturation intent when in PC mode?

[XMonarchY]

Obviously all post-processing is not off if it looks very different? All post-processing you can turn off is off. It sounds like Samsung has a correction/calibration tied to a post-processing chip that operates in 4:2:2 and changes the way the panel runs outside the 0-255 RGB input values (if a 3DLUT cannot fix it).

Have you tried creating a 3DLUT with a saturation intent when in PC mode?

What do you mean 3DLUT cannot fix it? In both 4:2:2 mode and 4:4:4 mode 3DLUT accuracy is just as high. Everything is within dE 1 with proper Rec.709 gamut (not wide gamut or anything). I even had it re-checked with i1Pro. Post-processing in Movie mode 4:2:2 is completely turned off by default, but it looks the same as Standard mode, which requires manual turning off of all post-processing. I am saying that all 4:2:2 modes look better than 4:4:4 mode, which to me looks dimmer and duller. I wonder if the difference is in luminance. Colors depends on saturation, hue, and luminance. There are controls for saturation and hue, but not luminance. I mean I even visited the hidden Service Menu and made asbsolutely sure no post-processing was used. Again, Game mode by itself further removes post-processing. When I switch to PC 4:4:4 mode, the same post-processing options are grayed out as the ones I manually turned off.

Let's say I calibrate 4:2:2 color gamut to read exactly as 4:4:4 color gamut for some specific color (fullscreen pattern). Then I can toggle between 4:4:4 PC mode and 4:2:2 non-PC mode (be it Standard or Movie). i1Display Pro and i1Pro will read it as the same color in both modes within the same dE, but 4:2:2 will look brighter/more vivid/vibrant (luminance)? Yet, if it was some post-processing affecting the color, then i1Display Pro or i1Pro would pick it up, wouldn't they? More vibrant or vivid or brighter color than the other color = different dE reading, but such is not the case. It also baffles me! I mean what kind of post-processing could this be?

Maybe it is possible that contrast ratio plays a role because the max I can squeeze out of 4:2:2 modes is 2600:1 and out of 4:4:4 only about 2200:1. Don't worry - all dynamic contrast and such junk is turned off in all modes, but contrast ratio's differ by about 400:1. However, would such a small difference in contrast ratio have any effect on a fullscreen color pattern looking different? The reason why PC mode has lower contrast ratio is because it is impossible for me to max out white balance gains due to locked controls. I am quite certain if I could max out white balance gains in PC mode, then I could get identical contrast ratio.

Bah, it could be simply because PC 4:$:4 mode is set at 90cd/m^2 and 4:2:2 modes are set at 110cd/m^2 using identical brightness and backlight settings.

[huhn]

by calibration you should first set white 255 to 100-120 cm² before 3d lut calibration.

a colorimeter is reading the all over color not from some pixel so post processing can still be used.

[Asmodian]

I wonder if the difference is in luminance. Colors depends on saturation, hue, and luminance. There are controls for saturation and hue, but not luminance. I mean I even visited the hidden Service Menu and made asbsolutely sure no post-processing was used.

Bah, it could be simply because PC 4:$:4 mode is set at 90cd/m^2 and 4:2:2 modes are set at 110cd/m^2 using identical brightness and backlight settings.

luminance = brightness. It looks like you found your answer. :)

[XMonarchY]

by calibration you should first set white 255 to 100-120 cm² before 3d lut calibration.

a colorimeter is reading the all over color not from some pixel so post processing can still be used.

So what kind of processing can affect the way pixels look or how vibrant or bright they look without affecting the actual color properties? I just can't imagine something like that.

[huhn]

first check if both modes have a white point of d65 at 120 cm².

[XMonarchY]

first check if both modes have a white point of d65 at 120 cm².

They do (all 3) have D65 white point, but cd/m^2 for each mode differs slightly. Movie mode is darker than Standard mode with identical values for brightness, contrast, and backlight. PC mode is dimmer than Standard mode, but brighter than Movie mode using those same identical settings and appropriate 1DLUT (each mode needs its own 1DLUT for games and 3DLUT for films). Again, this happens due to lack of RGB White Balance controls in PC mode.

ANYWAY, it doesn't really matter because all I wanted to know is whether there is still some benefit from upscaling chroma for 4:2:0 content to 4:2:2 mode and the answer is YES, but it is mild.

[huhn]

numbers please...

[XMonarchY]

OK, I verified - white point cd/m^2 are the same just like contrast ratio.

Here's a thought - can a slight bit of sharpness affect colors, as in full-screen single-color patterns? I disabled sharpness everywhere in User Menu, but also dug deep into Service Menu and loosened sharpness there, Edge Enhancement was also disabled. There is a SLIGHT big of sharpness compared to Movie or PC mode, but it is there. Can sharpness somehow affect pixel vibrance or color? I am talking about PURE single-color fullscreen patterns here, not some complex-color image.

[huhn]

on a full screen it shouldn't have an effect.
just ask your colorimeter it's a fullscreen effect so easy to read.

the YCbCr <-> RGB conversation may do that.

[XMonarchY]

on a full screen it shouldn't have an effect.
just ask your colorimeter it's a fullscreen effect so easy to read.

the YCbCr <-> RGB conversation may do that.

Colorimeter reads both colors as being identical. Both modes are set to RGB.

I decided to stick to PC Mode 4:4:4 this time because you can now use ReShade 3DLUT's with dispcalGUI which allow full grayscale and colorspace calibration with extreme accuracy to be applied in games without the need for CPKeeper or using Borderless Window modes AND you can apply 3DLUT's to madVR of course.

I figured 4:4:4 PC mode is just a SAFER bet of seeing proper colors (& have lower input lag) than using Standard mode with some kind of post-processing.

[XMonarchY]

the YCbCr <-> RGB conversation may do that.

So the conversion itself can create colors that colorimeters read as identical, but people perceive as different?

[huhn]

So the conversion itself can create colors that colorimeters read as identical, but people perceive as different?

no your meter must be broken.

[XMonarchY]

no your meter must be broken.

It isn't. I verify everything with i1Pro.

[huhn]

if your meter doesn't see the difference between two colors it is broken.

[XMonarchY]

if your meter doesn't see the difference between two colors it is broken.

i1Pro also broken?

[huhn]

if it doesn't see the difference between two colors what else?

[XMonarchY]

if it doesn't see the difference between two colors what else?

I think it may be perception because the chances of both i1Display Pro and i1Pro both going bad at the same time is slimmer than the problem being with something else, maybe even in my head...

[Akeno]

This is being discussed in the madVR thread but I thought it would be better to ask here: What exactly does overlay mode do? Also, is it fine to use gamma processing to something that looks pleasing to me even though I haven't calibrated my display or am I deviating too far from the source?