madVR - high quality video renderer (GPU assisted)

[ashlar42]

the recommended levels are still full full full.
https://www.avsforum.com/threads/madvr-argyllcms.1471169/page-19#post-23457822
Quoting from here: https://www.avsforum.com/threads/colourspace-cms-next-generation-calibration-thread.3049142/post-60916211

LGs are consumer's TVs, and everything in the consumer area works in the legal video signal (64-940) but without clipping WTW (according to SDR standards).

Internal LUT is working in video legal extended (64-1023), so it's covering/calibrating even the WTW.

WTW = headroom = above 100% Reference White, until 109% SuperWhite.

So this could be specific to LG OLEDs internal 3D lut, I don't know, but Ted knows his calibration stuff.

[SamuriHL]

It is an LG quirk, yes. Sorry was out today and just now saw that you quoted my post. This information ONLY applies to LG OLED (or possibly other displays but in this case and what was quoted I was talking about LG specifically). Ideally FULL, FULL, FULL is what you want. But LG does NOT handle FULL correctly. They aren't really expecting consumer devices to send it so I don't think they put a lot of effort around its support. I mean, it works, but, it doesn't look correct. That's why I recommend limited, full, limited (madvr, gpu, LG) to get the cleanest picture from these OLEDs. That being said, if you are using YCbCr, that's going to be limited on the GPU so you'd likely want madvr set to full in that case. That's currently how I'm running mine, as well. It's wildly wrong but these OLED panels don't give us great options.

[huhn]

that's a very specific topic to a display not a general statement which kodi wiki got wrong.
first of all OLED does not technically lose CR when you make WTW visible.
so you could use a full range signal with madVR set to custom white at 235 so a range of 0-235 without loosing a single bit of CR (in theory) and still getting wtw which has content in it (but there shouldn't be).

at least on my CX auto levels are bugged so i can't switch between a full range signal and a limited range signal. next issue is a device may create banding in full range RGB mode but not in YCbCr or RGB limited mode that doesn't make RGB full worse in general but the TV is just buggy. and this seems to reflect on the fact that LG processes WTW and you can calibrate it. you can just clip it and never have to deal with it again.

the spec for conversation are clear and they are watched at full range RGB that's just how a display works.

what so ever i need to first read through context of this post and the specific flaws of LG OLEDS.
and i'm not willing to do that i simply don't care enough and it's not enough to invalided a general statement.

TVs not clipping WTW is very common and it's also very common to make it visible with some setting combination which on LCD destroy CR.

[ashlar42]

Thanks guys, did not want to derail the conversation. I initially simply asked if what I was seeing in desktop programs was normal. It is and all is good. Cheers!

[SamuriHL]

Without a doubt the general statement of full, full, full being the correct path absolutely stands. I never disputed that nor would I. It's just the LG's and their stupid quirks that cause us to tread off the beaten path. I said very clearly what I do is NOT correct from a general perspective. I do it to avoid banding and other stupid problems that I see when I try to send RGB to my C8. So, anyone looking at my comments and sitting there with a "wtf" expression on their face, please understand I'm NOT talking about generally. LG specific.

[Asmodian]

I am back to limited on my CX as well, it simply isn't possible to calibrate full range on these LG OLED's as well as limited range (banding, especially near black). :(

At least PC mode (444 chroma) is pretty good now.

But I also agree, Full - Full - Full is preferred, assuming the display handles full range properly.

[oldpainlesskodi]

Yep, that's why I have chosen to stick my set in PC mode permanently, with a full range chain and just have done with it.

[QBhd]

I have just given up on PC mode entirely... HDR Banding is just too much of a deal breaker.

So for my C8, I just leave the HDMI on normal and run a Full-Full-Full setup. I did extensive testing and it is the simplest set-it-and-forget-it option.

Game of Thrones "The Long Night" is a great HDR banding test... the first scenes where Dani rides in on the Dragon and the fire on the inky black night... then shortly after that, when Jon rides away and looks back... If needed I can find the actually timestamps...

QB

[ashlar42]

That being said, if you are using YCbCr, that's going to be limited on the GPU so you'd likely want madvr set to full in that case. That's currently how I'm running mine, as well.
I don't understand your setup. I think I am going with madVR limited, Nvidia RGB full, OLED limited.

Where does YCbCr enter the picture and why?

[chros]

if it is the same issue i may not be affected at all.
...
edit: my current 3D LUT does not seem to expose the issue. it's hard to judge with the coating of this TV...

It should be trivial to see (assuming brightness/contrast are at their bypass default settings on the TV):
- full-full-full: only 234 is blinking
- limited-full-limited: 254 is also blinking

BTW. the 3D LUT doesn't at all it's always limited range as input and just to stop the confusion this is irrelevant for output ranges.
Good point, but this is how it works here.

Game of Thrones "The Long Night" is a great HDR banding test... the first scenes where Dani rides in on the Dragon and the fire on the inky black night... then shortly after that, when Jon rides away and looks back... If needed I can find the actually timestamps...
I understand your point of course, but GoT UHD is DoVi, so ... :)
CX and C1 should be way better than our old 2018 models, we're still waiting for the new owners to test couple of scenarios :)

[ashlar42]

CX and C1 should be way better than our old 2018 models, we're still waiting for the new owners to test couple of scenarios :)
Right. PM me here with what you would like to see tested. I'm in the middle of calibration, setup, whatever... but the TV has now already 350 hours on it, so it should ok to test stuff.

[SamuriHL]

I don't understand your setup. I think I am going with madVR limited, Nvidia RGB full, OLED limited.



Where does YCbCr enter the picture and why?You'll be fine with that most likely. I wouldn't go looking for issues though. My c8 has issues with rgb input which is why I use YCbCr instead of rgb. This gives me the cleanest picture on my c8. But because YCbCr is limited, madvr gets set to full. As I've said, this setup is crazy wrong and not really the way it's supposed to be. If I ever upgrade my c8 I can get off this ride. Lol

Sent from my SM-G998U1 using Tapatalk

[nevcairiel]

CX and C1 should be way better than our old 2018 models, we're still waiting for the new owners to test couple of scenarios :)

I got the G1 with the Evo panel, but I haven't had much time yet to do detail comparisons.

If typical problem scenarios were documented somewhere, I could also check at some point

[Sunspark]

You'll be fine with that most likely. I wouldn't go looking for issues though. My c8 has issues with rgb input which is why I use YCbCr instead of rgb. This gives me the cleanest picture on my c8. But because YCbCr is limited, madvr gets set to full. As I've said, this setup is crazy wrong and not really the way it's supposed to be. If I ever upgrade my c8 I can get off this ride. Lol

I use YCbCr 4:4:4 in the Intel driver settings to my monitor. The reason is because I find using RGB on this PC a little more straining on the eyes (maybe too many layers of dithering?). I have a displayport to hdmi active adapter between the PC and monitor as well. The difference is subtle but it is there. One thing I can observe when set to ycbcr in the driver is that 10-16 bit greyscale gradients in a regular image viewer will show slight subtle bands onscreen that RGB mode doesn't which tells me that the Intel driver dithers when set to RGB mode before sending it out to the monitor which then applies temporal dithering on top of it. Having MadVR's dithering options active does smooth these bands out so I am not sold that images need to be dithered 3 times in a more standard processing chain (madvr, windows driver, monitor panel).

Now I am wondering something.. source material is YUV for video. MadVR converts from YUV to RGB to do its processing, and then in my case, the Intel driver converts it back to YUV (YCbCr). I wonder if there is a way to tell MadVR to stay in the YCbCr space instead of RGB? Then the whole chain to the monitor (which displays YPbPr oddly enough) could stay YCC all the way through.

There is a special madvr filename flag you can set, "YCbCr: Outputs YCbCr data instead of RGB, as if it was RGB." I tried it once, and all it did was make the video pink and green so it's not what I expected. I wonder under what circumstances it is used, it must have been made for some display somewhere. My assumption is that the reason it looks pink and green like that is because Windows then converts the MadVR output to RGB and then the driver is converting it back to YUV which is why the colors look wrong. Pity that the OS itself can't be told to function in 4:4:4 YCbCr instead of RGB in the middle.

[SamuriHL]

There is a way to tell madvr to process in YcbCr but it's definitely not recommended even if you're outputting YCbCr from the GPU. The reason is that the driver is expecting RGB and will do even more conversions internally from what I understand. There's no way to control this behavior in the driver. At least this is how I understand it and have seen it explained. The Envy can process everything in YCbCr.

[huhn]

the YCbCr option is for debugging not for use.

setting the driver to YCbCr adds morte conversation unlike with RGB.

"no" display can do YPbPr it only accepts it and does the RGB conversation itself.

LCD, plasma and even OLED have all RGB pixel so they need RGB data.

[SamuriHL]

While you are technically correct about it being converted to RBG internally, with the LG OLEDs that conversion is done as a final step. All the processing is done internally on the YCbCr signal that it expects to receive. It's very likely why we see issues when sending it an RGB signal...it's very likely skipping some of that processing.

[chros]

Right. PM me here with what you would like to see tested. I'm in the middle of calibration, setup, whatever... but the TV has now already 350 hours on it, so it should ok to test stuff.

I got the G1 with the Evo panel, but I haven't had much time yet to do detail comparisons.
If typical problem scenarios were documented somewhere, I could also check at some point
Thanks guys, here it is (https://forum.doom9.org/showthread.php?p=1948898#post1948898), only 3 test cases in it for now, I'll update it in the future if it will be necessary.

[huhn]

While you are technically correct about it being converted to RBG internally, with the LG OLEDs that conversion is done as a final step. All the processing is done internally on the YCbCr signal that it expects to receive. It's very likely why we see issues when sending it an RGB signal...it's very likely skipping some of that processing.

is not about oled is at Sunspark.
i never claimed when and where RGB conversation is used only that it is.

[ashlar42]

is not about oled is at Sunspark.
i never claimed when and where RGB conversation is used only that it is.
What?!?

[el Filou]

huhn meant his comment was not specifically about OLEDs, but was directed at Sunspark who asked how to keep video in YCC inside madVR's pipeline and said TVs display in YCC (which is not true even if they process in YCC before displaying in RGB).

[Sunspark]

In the end, I feel it comes down to which part of the chain does the best job of converting from YUV to RGB. It's also an unknown what processing criteria is in the code in the display when it receives a signal. Are all display processing paths agnostic and the output is the same whether it receives a YUV 4:4:4 signal or RGB? I think the answer to that is it depends on what the manufacturer implemented since displays are now computers in their own right and we are generally not dealing with hardwired logic circuits anymore.

YUV-RGB(MadVR)-RGB(OS)-RGB(Video Drivers)-Display(RGB)
YUV-RGB(MadVR)-RGB(OS)-YUV(Video Drivers)-Display(RGB)

The video drivers portion matters as well because I am aware of the fact that for a long time Intel insisted that if you used the HDMI port to a "display television" (which is how my monitor is recognized by the drivers) it would change the level to 16-235 for you unless you glitched that with a registry setting or much later, new driver options to not do that. If you had your output traveling over displayport or dvi there was no forced level conversion. This is in addition to any software processing they may have been doing regarding dithering or image optimizations.

Intel also has an "IT Content" setting which is supposed to change something involving HDMI which was hard for me to get more information about because it's not well documented, but my understanding of it, the hdmi spec has different modes text, video, etc. and it content is a way of processing something differently involving those modes and the display. I was able to see a subtle rendering difference on my monitor with text and pictures changing the setting between on or off (I have it off on my setup). I am not sure if the difference came from the display processing it based on metadata received in the signal, or if the driver itself processed it.

I would be curious to know how this IT content flag affects the OLED displays discussed here.

[VBB]

I would be curious to know how this IT content flag affects the OLED displays discussed here.

HDMI content type set in the video driver only triggers on LG 2021 models. Previous series simply ignore the setting. I only have experience with Nvidia's implementation, and with the LGs you can select either "Desktop programs" or "Full-screen videos". The TV will switch between PC mode and normal HDMI mode, depending on what is set. Other display brands have more/different options. The default when set to "Auto-select (recommended)" is "Desktop programs", by the way, which means that if you want to use normal HDMI mode on a 2021 model, you'll have to set this manually to "Full-screen videos".

[el Filou]

The IT content flag is just that, a flag, and it's the display that (optionally) changes its picture processing when it sees it.
It has been discussed before, you can find those discussions by searching for "content type nvidia" on here.

[DMU]

There is a way to tell madvr to process in YcbCr but it's definitely not recommended even if you're outputting YCbCr from the GPU. The reason is that the driver is expecting RGB and will do even more conversions internally from what I understand. There's no way to control this behavior in the driver. At least this is how I understand it and have seen it explained. The Envy can process everything in YCbCr.

The driver will expect the format specified (https://docs.microsoft.com/en-us/windows/win32/api/dxgiformat/ne-dxgiformat-dxgi_format) by the application developer.

[DMU]

In the end, I feel it comes down to which part of the chain does the best job of converting from YUV to RGB. It's also an unknown what processing criteria is in the code in the display when it receives a signal. Are all display processing paths agnostic and the output is the same whether it receives a YUV 4:4:4 signal or RGB? I think the answer to that is it depends on what the manufacturer implemented since displays are now computers in their own right and we are generally not dealing with hardwired logic circuits anymore.

I would trust to madVR. As practice shows, TV manufacturers are not worried about the passthrough of the RGB signal to the pixel matrix.
But if you really care about this, then you should output the RGB@60Hz from the PC, and set the HDMI TV input in the PC mode.


Intel also has an "IT Content" setting which is supposed to change something involving HDMI which was hard for me to get more information about because it's not well documented, but my understanding of it, the hdmi spec has different modes text, video, etc. and it content is a way of processing something differently involving those modes and the display. I was able to see a subtle rendering difference on my monitor with text and pictures changing the setting between on or off (I have it off on my setup). I am not sure if the difference came from the display processing it based on metadata received in the signal, or if the driver itself processed it.

I would be curious to know how this IT content flag affects the OLED displays discussed here.
About the IT content (https://drive.google.com/file/d/1XbZV-A_BLmFS7nzKe1v7mllUW8q2Omqu/view?usp=sharing)

[ashlar42]

HDMI content type set in the video driver only triggers on LG 2021 models. Previous series simply ignore the setting. I only have experience with Nvidia's implementation, and with the LGs you can select either "Desktop programs" or "Full-screen videos". The TV will switch between PC mode and normal HDMI mode, depending on what is set. Other display brands have more/different options. The default when set to "Auto-select (recommended)" is "Desktop programs", by the way, which means that if you want to use normal HDMI mode on a 2021 model, you'll have to set this manually to "Full-screen videos".
Not in my experience. But I will recheck.
Unless this is true after having set the input to PC mode. Gonna try and report back.

Edit: nope. Chroma remains at 4:2:2, no matter what content the driver reports. Unless you set the input as PC.

[Stereodude]

What Windows 10 build is recommended for MadVR? I'm still rocking Windows 8.1 on the HTPC, but the 3070 Ti I have on the way won't work under Windows 8.x even though there are Windows 7 drivers for it. :rolleyes:

[SamuriHL]

I'm running the latest W10 build and I've no issues.

[Stereodude]

I'm running the latest W10 build and I've no issues.
Okay, thanks. :thanks:

[brazen1]

Is it best to apply crispen edges and thin edges in scaling/upscaling refinement or processing/image enhancements?

[chros]

Depends on what you want, scaling/upscaling refinement is not applied if there's no scaling is required, the other one is always applied (not sure at which point, before or after scaling). That's how I use them (https://www.avsforum.com/threads/guide-building-a-4k-htpc-for-madvr.2364113/page-259#post-60096583).
I don't think there should be a difference between them quality wise, otherwise.

[chros]

Guys, do you know what the best way is to test double/tripple (level) expansion? (Like the madvr feature) E.g. with grayscale ramps? If so, which one?
(It's about Firestick 4k device.)

[brazen1]

Depends on what you want, scaling/upscaling refinement is not applied if there's no scaling is required, the other one is always applied (not sure at which point, before or after scaling). That's how I use them (https://www.avsforum.com/threads/guide-building-a-4k-htpc-for-madvr.2364113/page-259#post-60096583).
I don't think there should be a difference between them quality wise, otherwise.

I like to add a tiny bit of crisp and thin edges to all 540p, 720p, and 1080p. I don't want to add any to 2160p. I already have profiles for all these resolutions so I have control.

The resolutions I want to apply them will be scaled. I simply won't use them for 2160p that won't be scaled. I just need to understand better when I crisp and thin, is it best to do it in processing or scaling? I assume scaling after reading your feedback. (thank you) Do you agree or am I still not grasping why crisp and thin can be adjusted in two different tabs?

[oldpainlesskodi]

From my understanding, you get the biggest bang for the buck with pre-processing, as it takes minimal overhead...however, I always use (apart from my 2160p profile) post-processing, as I find it less extreme and easier to dial-in/fine tune.....YMMV.

[Asmodian]

Right, after scaling is higher quality but before scaling takes less GPU power to do. Before scaling will also have a stronger effect at the same settings.

[brazen1]

Thank you guys. So, it comes down to saving GPU resources by setting in the processing tab or.. using more resources but having finer tune increments in the scaling tab.

[artins90]

MPC-HC has begun to crash on video loading after the last W11 beta update.
Setting the output to Enhanced Video Renderer avoids the crash so I think the cause might be MadVR.

Faulting application name: mpc-hc64.exe, version: 1.9.14.0, time stamp: 0x60de5700
Faulting module name: KERNELBASE.dll, version: 10.0.22000.120, time stamp: 0xbe15c822
Exception code: 0xc0000005
Fault offset: 0x0000000000033ddb

I would like to know if there are other users experiencing this crash on W11 22000.120 before trying to troubleshoot my system for other causes.

[Ripmann]

MPC-HC has begun to crash on video loading after the last W11 beta update.

I can't address your question directly (not switching to Win11 any time soon), but in case you hit the wall and turn to troubleshooting, try testing with MPC-BE first. MPC-HC hasn't been updated since 2017, so there's a good chance MPC-BE will have fewer compatibility issues here. I waited years before I switched myself, but after I set up everything correctly, literally the only thing I miss from MPC-HC is quickly deleting files with DEL. Other than that, it's pretty much the same Media Player Classic we all know and love.

[Stereodude]

MPC-HC hasn't been updated since 2017, so there's a good chance MPC-BE will have fewer compatibility issues here. I waited years before I switched myself, but after I set up everything correctly, literally the only thing I miss from MPC-HC is quickly deleting files with DEL. Other than that, it's pretty much the same Media Player Classic we all know and love.
Huh? clsid is updating it all the time. https://github.com/clsid2/mpc-hc/releases

[Ripmann]

Huh? clsid is updating it all the time. https://github.com/clsid2/mpc-hc/releases

Whoa, thanks. I was not aware of this fork. Will take a look at it ASAP. The official page hasn't been updated since 2017, though:

v1.7.13 is released and farewell
https://mpc-hc.org/2017/07/16/1.7.13-released-and-farewell/

[huhn]

it's open source because the person in charge of the github page said farewell doesn't mean anything.

why the project was not directly given to someone that clearly wants to continue is beyond me.

[artins90]

Update on the W11 crash situation:
Today the OS has been updated to ver. 22000.132.
After the update, MadVR is working again.
I didn't change any setting, so I think it was indeed an OS incompatibility or bug that caused the crash.

[SirMaster]

it's open source because the person in charge of the github page said farewell doesn't mean anything.

why the project was not directly given to someone that clearly wants to continue is beyond me.

While his branch is technically a fork, he was contributing to the original project long before that as well. So IMO it's a direct continuation.

[creatine]

I'm setting up MadVR for the 1st time. I am trying to understand the scaling options and how they apply to source material and video levels. I am running a dedicated Win10 HTPC connected to a 2013 Panasonic 1080p plasma. The TV has been calibrated to REC.709, 2.2 gamma, RGB limited. I read through the MadVR guide and setup the video levels as follows.

(madVR) TV levels (16-235) -> (media front-end) Use limited color range (16-235) -> (GPU) Full Range RGB 0-255 -> (Display) Output as RGB 16-235 ( MadVR native display bit depth 8bit)

I am mostly playing 1080p bluray rips, occasional HDR videos and some 4k\720p rips but will focus my question on 1080p rips. The rips are 8bit 4:2:0

Considering the video levels, resolution and encoding of the rips, is there any advantage\visual improvement upscaling the chroma using NGU AA high or should I leave the Madvr settings at default for 1080p ?

[gfxnow]

Considering the video levels, resolution and encoding of the rips, is there any advantage\visual improvement upscaling the chroma using NGU AA high or should I leave the Madvr settings at default for 1080p ?

Video is always encoded and stored as 4:2:0 (chroma subsampling, as opposed to non-subsampled 4:4:4) but MadVR runs its algorithms and processes on RGB (which implicitly does not have any chroma subsampling) because internally a PC GPU works in RGB only.

Therefore there is always chroma upscaling when using MadVR (even if you are playing a 1080p video on a 1080p screen. The word scaling confuses people, maybe it should be called chroma upsampling or chroma extrapolation or something) and it happens before any of the other processes in the pipeline (because those all work on RGB, not subsampled 4:2:0 chroma). The output of chroma upscaling is the input for the rest of the MadVR processing. So why not provide the best input for Image Upscaling/downscaling algorithms, provided that you have a powerful GPU and enough headroom?

Edit: I could be wrong about the video is always encoded part but I mean most commercial formats/standards such as blu-ray.

[ryrynz]

Considering the video levels, resolution and encoding of the rips, is there any advantage\visual improvement upscaling the chroma using NGU AA high or should I leave the Madvr settings at default for 1080p ?

I recently switched off Pure Direct mode on my set to test motion handling which is improved when off and as a result of that 4:4:4 is disabled. I compared chroma upscalers briefly, my take away is that even if I wasnt using 4:4:4 I would still prefer NGU AA for my chroma. Low is fine, medium is good. YMMV depending on ur viewing distance and hardware. I decided to switch Pure Direct back on and use Smooth Motion as panning shots looked better with that enabled rather than without and using the TVs own motion handling processes in 4:2:0. For the majority of scenes and viewers chroma upscaling differences between upscalers won't be noticeable and depending on your hardware you may prefer to keep this area dialed back to spend on luma processing or post.

[tp4tissue]

There's not a huge difference to the chroma upscalers.

Some color cast may show up in test patterns, but in real world, it's almost impossible to notice.

Zoomed in 3x-4x you can maybe see a little hair that's slightly sharper sometimes, impossible to notice in motion. :rolleyes:

[tp4tissue]

The TV has been calibrated to REC.709, 2.2 gamma, RGB limited. I read through the MadVR guide and setup the video levels as follows.

(madVR) TV levels (16-235) -> (media front-end) Use limited color range (16-235) -> (GPU) Full Range RGB 0-255 -> (Display) Output as RGB 16-235 ( MadVR native display bit depth 8bit)


You always want to use NATIVE color gamut and rgb 444 (0-255)

For calibration, NEVER use the TV's CMS features except for gamma-tracking. The TV's cms is not nearly as good as MADVR's processing, you want madvr to do most of the work.

IN FACT, double check if the gamma tracking causes trouble on its own, because it might.

[tp4tissue]

I use YCbCr 4:4:4 in the Intel driver settings to my monitor. The reason is because I find using RGB on this PC a little more straining on the eyes (maybe too many layers of dithering?). I have a displayport to hdmi active adapter between the PC and monitor as well. The difference is subtle but it is there. One thing I can observe when set to ycbcr in the driver is that 10-16 bit greyscale gradients in a regular image viewer will show slight subtle bands onscreen that RGB mode doesn't

The problem is you guys are still eyeballing what's going on.

i1studio probe, measure it, then you know EXACTLY what's going on.

Alot of things with format conversion/ mismatch are not obvious and fundamentally uncorrectable without a measurement probe.

3DLUT fixes just about everything SDR side of things short of extreme gamut clipping.

the displayport to hdmi adapter is not good. you shouldn't use these things because they can be unpredictable.

I have tried several disp to hdmi 2.0 adapters, and they cause crush, because they do different internal processing DEPENDING on what flags the TV gives it, NOT the gpu.