madVR - high quality video renderer (GPU assisted)

[brazen1]

Thank you huhn. Direct link working. Can you look it over and tell me if I'm out of my mind?
This is the Sony 'Camp' video. You can d/l it here: http://4kmedia.org/sony-camping-in-nature-4k-demo/

https://i.imgur.com/QuV5CVT.jpg

[huhn]

you are sending 10 bit to the GPU driver.
it's using NV HDR.
the decoder should be lavfilter.
the file is maybe faulty no HDR meta data.

what i'm supposed to see here?
sending 10 bit to the GPU driver at UHD 60 hz us something i would never with HDMI 2.0 do but do as you please...

[brazen1]

I use LAV Filters otherwise it wouldn't decode HDR in MPC-HC without them afaik.
Maybe the file is faulty. I just played a different 60fps UHD HDR.
This one shows meta data, BT 2020 upstream and downstream, HDR 1000 nits BT2020->DCI-P3 which tells me what it was mastered in.
What is wrong with sending 10bit UHD 60Hz with HDMI 2.0? That is the native rate and I always match them. My display is native 120Hz fwiw. I have others that I send at their native rates at 23Hz too.

We were having a discussion about how it's impossible to play 60Hz titles at 10bit due to the HDMI 2.0 limitation spec. Does that OSD reading confirm or deny that I'm indeed playing 60Hz at 10bit or is it not relevant at all?

[huhn]

like said before you can't send UHD 60 hz10 bit RGB with HDMI 2.0 and madVR OSD has nothing todo with that.


you are just sending stuff the GPU driver. if you like to MPDN can do 16 bit and if madshi wants to he could add that too(the last time i heard something about this is pretty broken) but that has little to nothing todo what the GPU send the display.

so not sure why you comapre the OSD to what is send to the display device.

[brazen1]

Thank you. Now I understand. madVR OSD only shows what is being input from the GPU and shows nothing about output to the display. I don't know everything about deciphering the madVR OSD like most of you. I'm learning. Thanks again.

[takenori]

I just installed the new Nvidia drivers for my GTX 1080 without using DDU or Clean Install. I created a restore point first, just in case.

Once again, the madVR custom refresh rate entries were still there, but not working. For each one, I clicked Optimize, ran the test and saved the change (no change, actually), then rebooted. Played a test movie, and the refresh rate changed as it should have.

I did this for each entry that I use (only three), and all is working normally now. So basically a new Nvidia driver includes a 3-reboot penalty for my setup, but I can install over the old version and keep my Nvidia and OS settings.
this happened to me to after latest driver.
but a simply checking all custom resolution within nvidiacp do the work

[FDisk80]

It's not converted to DCI-P3. It just lets you know that the content was mastered to DCI-P3 using a BT-2020 container. So you are correct to use a BT2020 calibration.

I suggested to Madshi to change the sign he uses to convey this information, as I think it is confusing to many users, but for some reason he didn't think it was confusing so it's stayed like that because he is the boss :).



It would be nice if people could refrain from making blanket statements such as this. Yes, new drivers often break things for some. Yes, sometimes they break things for the majority.

But as far as I'm concerned, the latest 390.x drivers work fine, at least in 4K. I'm set to 4K23p with a custom refresh mode created by MadVR giving me a frame drop every 1-2 hours, and I use RGB 12bits 4:4:4. When I play 4K60p, the driver swaps automatically to 8bits 4:4:4. That survives a reboot and works fine here, as it has always done.

There are two limitations that I am aware of:

1) Like all the drivers after 285.28, you have to select 12bits from a non custom refresh mode. Once a custom refresh mode is selected, the resolution is greyed out and can't be changed, but it's still 12bits in 23p and 8bits in 60p if 12bits was selected from a non-custom refresh mode (at 30p max).

2) Compatibility is broken with Asio4all and most Asio drivers. Thanks to a kind member, I was able to find Flexasio, which works fine with some limitations.

So instead of making blanket statements simply because it doesn't work for you, please post details about your rig (OS version and build, GPU model, driver version) so that we can see if there is a common link between those for whom 390.x works fine, and those for whom 390.x doesn't work.

My rig is detailed in my sig.

By the way, 391.24 was just released today, I'm about to try it.

I posted details of the issue a bunch of times, anyway, it's GTX970 connected to a 1080P HDTV via HDMI running on Latest Windows 10 and with latest nvidia drivers, same issue with 391.24.

Tried, DDU in safe mode, clean installed nvidia drivers, same issue.
Last 3 driver releases cannot save tweaked custom resolution when set to 1080P23. Same for madVR, it throws driver error in your face if you try to apply a tweaked refresh rate setup.

And it's obviously a driver issue since the 390.77 works fine while 391.01, 391.05 and 391.24 do not.

[Manni]

Thank you huhn. Direct link working. Can you look it over and tell me if I'm out of my mind?
This is the Sony 'Camp' video. You can d/l it here: http://4kmedia.org/sony-camping-in-nature-4k-demo/

https://i.imgur.com/QuV5CVT.jpg

This screenshot shows that content is 4K60 4:2:0 10bits and you’re asking MadVR to dither to 10bits, which is wrong because the GPU can’t output 4K60p in 10bits over HDMI 2.0 in RGB 4:4:4. This doesn’t tell you anything about what is actually sent by the GPU to the display. Most likely, if using RGB 4:4:4 as you should be, the GPU is sending 4K60p 8bits, dithering behind MadVR’s back.

You should ask MadVR to dither to 8bits with 4K60p (using profiles to do this automatically) so that there is no dithering from the GPU driver done behind MadVR’s back. That or use 8bits dithering in MadVR all the time.

If you use YCB 4:2:2 then you can send 4K60p 10 or 12bits at 4K60p, but it’s not recommended as the worse chroma upscaling is probably wiping out any (very marginal) benefit of dithering to 10bits vs 8bits.

[jkauff]

this happened to me to after latest driver.
but a simply checking all custom resolution within nvidiacp do the work
I only use madVR custom refresh rates so I can use madshi's optimization data. I don't have any custom resolutions in Nvidia CP.

[Manni]

I use LAV Filters otherwise it wouldn't decode HDR in MPC-HC without them afaik.
Maybe the file is faulty. I just played a different 60fps UHD HDR.
This one shows meta data, BT 2020 upstream and downstream, HDR 1000 nits BT2020->DCI-P3 which tells me what it was mastered in.
What is wrong with sending 10bit UHD 60Hz with HDMI 2.0? That is the native rate and I always match them. My display is native 120Hz fwiw. I have others that I send at their native rates at 23Hz too.

We were having a discussion about how it's impossible to play 60Hz titles at 10bit due to the HDMI 2.0 limitation spec. Does that OSD reading confirm or deny that I'm indeed playing 60Hz at 10bit or is it not relevant at all?

Not relevant at all as explained earlier on a few occasions. 18gb/s is the max bandwidth for HDMI 2.0. That's a hardware limitation and a best case scenario (some older devices can only do 10Gb/s). 4K60p RGB 4:4:4 8bits requires 17.62Gb/s. So as you can see, it's simply impossible to send anything higher than 8bits unless you lower chroma or frame rate.

I posted details of the issue a bunch of times, anyway, it's GTX970 connected to a 1080P HDTV via HDMI running on Latest Windows 10 and with latest nvidia drivers, same issue with 391.24.

Tried, DDU in safe mode, clean installed nvidia drivers, same issue.
Last 3 driver releases cannot save tweaked custom resolution when set to 1080P23. Same for madVR, it throws driver error in your face if you try to apply a tweaked refresh rate setup.

And it's obviously a driver issue since the 390.77 works fine while 391.01, 391.05 and 391.24 do not.

I am not doubting you have an issue, I am only asking you to stop saying it is an issue for everyone, as you keep posting, because it's misleading and not true.

Saying "390.x drivers are broken" doesn't help anyone.

Saying that in 1080p23 you can't save tweaked custom resolution with a GTX970 on Windows 10 since 390.77 becomes more useful, because from there we can see who else has the same issue and whether they use the same GPU model or default resolution.

So thanks for posting the additional details, I hope that others with the issue will post detailed info as well, and others for whom it works fine (like myself) will do too, so we can gather more data and see if there are common points between those for whom it still works exactly the same and those for whom it's broken.

[NoTechi]

Hi all,

since I am using a JVC 7900 I am interested in the dynamic HDR of madVR.
My question is how much GPU power a system for madVR would need if I just go for dynamic HDR.

I am struggeling to decide if I should wait for the new upcoming NUC Hades Canyon or start a HTPC from scratch.
I know with a HTPC from scratch I could go for all optimizations in madvr but the system would be louder and more expensive.
The new NUC is reported to have a similiar performance as a nvidia 1060 and if it could handle dynamic HDR my requirement would be met.

NoTechi

[Warner306]

Hi all,

since I am using a JVC 7900 I am interested in the dynamic HDR of madVR.
My question is how much GPU power a system for madVR would need if I just go for dynamic HDR.

I am struggeling to decide if I should wait for the new upcoming NUC Hades Canyon or start a HTPC from scratch.
I know with a HTPC from scratch I could go for all optimizations in madvr but the system would be louder and more expensive.
The new NUC is reported to have a similiar performance as a nvidia 1060 and if it could handle dynamic HDR my requirement would be met.

NoTechi

Intel doesn't support dynamic HDR switching (yet) in madVR. You need a Nvidia or AMD GPU. Otherwise, you will have to manually toggle the HDR switch when watching HDR files.

[NoTechi]

Intel doesn't support dynamic HDR switching (yet) in madVR. You need a Nvidia or AMD GPU. Otherwise, you will have to manually toggle the HDR switch when watching HDR files.

Warner,

the upcoming NUC Hades Canyon has a AMD GPU (Radeon RX Vega M GH) paired with a Intel CPU.
The 7900 projector switches to the HDR preset as Long as the HDR flag is set.
However my question was in regards to GPU power required for dynamic HDR while watching a movie. My understanding was that madVR analysis the currently playing video and adjusts e.g. gamma to get the best HDR settings depending on the movie scene.

NoTechi

[brazen1]

Hi Manni. Thank you. TBH, this whole 4K60p was just a test bed and I've learned plenty from you guys as always. I've yet to run across a real world example of 4K60p other than those test files as my rips are 4K23p but in the event they manifest, this knowledge is good to better understand how to deal with them and if it's ok with you I'll hit you up for profile codes when/if applicable. Actually I think there was that Billy Lynn title but I don't own it. I assume these profiles for dithering are based on resolution and would be created in Display connected to AVR tab?

In the mean time I assume leaving madVR setting to dither at 10bit or higher for 4K23p including (540p through 1080p 8bit at resolution from 23Hz to 60Hz) etc. when using RGB 4:4:4 remains the correct config or should I be using additional profiles since 1080p etc. are 8bit? In short, leave madVR at 10bit or higher for everything except 4k above 30Hz? Furthermore, I'm thinking the GPU is not doing dithering ahead of madVR and madVR will dither them down in these examples? Still foggy in this area. Btw, did new driver present any problems? Considering what I'm learning recently, no reason I shouldn't be using one of the newer drivers if not the latest.

[Manni]

In short, leave madVR at 10bit or higher for everything except 4k above 30Hz?

That.

I haven't spent enough time with the drivers to note any new issues. I only was able to confirm that they were working fine here after checking the usual possible issues.

[Warner306]

Hi Manni. Thank you. TBH, this whole 4K60p was just a test bed and I've learned plenty from you guys as always. I've yet to run across a real world example of 4K60p other than those test files as my rips are 4K23p but in the event they manifest, this knowledge is good to better understand how to deal with them and if it's ok with you I'll hit you up for profile codes when/if applicable. Actually I think there was that Billy Lynn title but I don't own it. I assume these profiles for dithering are based on resolution and would be created in Display connected to AVR tab?

In the mean time I assume leaving madVR setting to dither at 10bit or higher for 4K23p including (540p through 1080p 8bit at resolution from 23Hz to 60Hz) etc. when using RGB 4:4:4 remains the correct config or should I be using additional profiles since 1080p etc. are 8bit? In short, leave madVR at 10bit or higher for everything except 4k above 30Hz? Furthermore, I'm thinking the GPU is not doing dithering ahead of madVR and madVR will dither them down in these examples? Still foggy in this area. Btw, did new driver present any problems? Considering what I'm learning recently, no reason I shouldn't be using one of the newer drivers if not the latest.

Remember, madVR processing starts at a bit depth higher than 10-bits to avoid color conversion errors. It simply dithers the result down to the output bit depth set. So this choice is irrelevant, as you will not be changing the color space, just the number of steps between each color. Outputting an 8-bit source at 10-bits means less dithering is added creating less noise in the image. The gradient gets smoother as the bit depth is increased. So think of the image in terms of a gradient with fixed top and bottom values. The choice of bit depth impacts what is in between the top and bottom values. More steps = a smoother, less noisy image.

[Warner306]

Warner,

the upcoming NUC Hades Canyon has a AMD GPU (Radeon RX Vega M GH) paired with a Intel CPU.
The 7900 projector switches to the HDR preset as Long as the HDR flag is set.
However my question was in regards to GPU power required for dynamic HDR while watching a movie. My understanding was that madVR analysis the currently playing video and adjusts e.g. gamma to get the best HDR settings depending on the movie scene.

NoTechi

HDR -> SDR conversion requires GPU power. HDR passthrough does not (or maybe it takes a little; I don't know. But not as much). A setting of passthrough lets the display decide how the content is mapped rather than madVR. So you can't use madVR to improve HDR presentation on a HDR-compatible display. That is up to the format used and the quality of the display.

So any GPU with at least 4GB of VRAM and HEVC decoding will do. GPUs with greater power will be more capable of using madVR processing features such as artifact removal and image upscaling. madVR is very good at the image upscaling of 1080p Blu-rays to 4K. So consider this feature when buying a GPU for madVR. A GTX 1060, at minimum, is required to push madVR to higher settings. But a 1050 Ti will allow for basic madVR settings and no limitations on features. It all depends on how much money you want to spend. GPU prices are terrible right now. So there is no hurry to upgrade to 4K.

[brazen1]

Thanks Warner for the further details...
I'm sorry guys. I just can't get my head wrapped around all of this. Here's what I'm struggling to understand:

Installed new driver. RGB 4:4:4 and set it to my native 2160p 8bit 60Hz. Then I switched to 2160p 12bit 23Hz and 24Hz. Then set back to 2160p 8bit 60Hz. Next I played a 2160p 23Hz HDR 10bit title no FSE. Looked in NCP during playback and it is showing 8bit at 23Hz as if it ignored my previous command to play 23Hz at 12bit. My display does not show detailed info so I check info from my Denon AVR. It shows RGB 4:4:4 8bit. To me, I don't think this is correct and why I ask you guys. So, during playback I select 12bit in the NCP. I go back to info from AVR and it shows RGB 4:4:4 12bit now. I know title is 10bit so AVR info means nothing I guess? True? Either does bit set depth setting in NCP? True? And madVR does not report anything beyond what the GPU is sending it? True? So how do I know if my display is outputting 8bit or taking advantage of the higher 10bit depth of an HDR title? Sorry I am so naïve!

To make understanding more difficult, after reboot that 12bit setting no longer appears in NCP or my AVR even though I manually changed during playback before I rebooted. It's back to 8bit as if I never set it.

[NoTechi]

HDR -> SDR conversion requires GPU power. HDR passthrough does not (or maybe it takes a little; I don't know. But not as much). A setting of passthrough lets the display decide how the content is mapped rather than madVR. So you can't use madVR to improve HDR presentation on a HDR-compatible display. That is up to the format used and the quality of the display.

So any GPU with at least 4GB of VRAM and HEVC decoding will do. GPUs with greater power will be more capable of using madVR processing features such as artifact removal and image upscaling. madVR is very good at the image upscaling of 1080p Blu-rays to 4K. So consider this feature when buying a GPU for madVR. A GTX 1060, at minimum, is required to push madVR to higher settings. But a 1050 Ti will allow for basic madVR settings and no limitations on features. It all depends on how much money you want to spend. GPU prices are terrible right now. So there is no hurry to upgrade to 4K.

Warner many thanks I start to understand now! :)

So it looks like those who are using a projector and are playing HDR content they convert it to SDR BUT let madVR improve the picture including dynamic improvements depending on the movie scene. Most likely they remove the HDR flag so the projector stays in some non HDR but BT2020 setting instead of auto switching to HDR. Especially on projectors with limited lumen output compared to TVs this "fake HDR/pimped SDR" might bring better HDR like results then having HDR passthrough or not using madVR at all.
As I get you right this conversion to SDR plus madVR improvements will need lots of power where this new NUC might come to its limits.

Thanks for clarification Warner and yes gpu prices are insane atm :/

NoTechi

[Warner306]

Warner many thanks I start to understand now! :)

So it looks like those who are using a projector and are playing HDR content they convert it to SDR BUT let madVR improve the picture including dynamic improvements depending on the movie scene. Most likely they remove the HDR flag so the projector stays in some non HDR but BT2020 setting instead of auto switching to HDR. Especially on projectors with limited lumen output compared to TVs this "fake HDR/pimped SDR" might bring better HDR like results then having HDR passthrough or not using madVR at all.
As I get you right this conversion to SDR plus madVR improvements will need lots of power where this new NUC might come to its limits.

Thanks for clarification Warner and yes gpu prices are insane atm :/

NoTechi

I think passthrough is the higher-quality method. Your display knows itself best, so it should be calibrated to maximize HDR content. Every display is designed to map using its own methods. It is not a universal algorithm.

[Warner306]

Thanks Warner for the further details...
I'm sorry guys. I just can't get my head wrapped around all of this. Here's what I'm struggling to understand:

Installed new driver. RGB 4:4:4 and set it to my native 2160p 8bit 60Hz. Then I switched to 2160p 12bit 23Hz and 24Hz. Then set back to 2160p 8bit 60Hz. Next I played a 2160p 23Hz HDR 10bit title no FSE. Looked in NCP during playback and it is showing 8bit at 23Hz as if it ignored my previous command to play 23Hz at 12bit. My display does not show detailed info so I check info from my Denon AVR. It shows RGB 4:4:4 8bit. To me, I don't think this is correct and why I ask you guys. So, during playback I select 12bit in the NCP. I go back to info from AVR and it shows RGB 4:4:4 12bit now. I know title is 10bit so AVR info means nothing I guess? True? Either does bit set depth setting in NCP? True? And madVR does not report anything beyond what the GPU is sending it? True? So how do I know if my display is outputting 8bit or taking advantage of the higher 10bit depth of an HDR title? Sorry I am so naïve!

To make understanding more difficult, after reboot that 12bit setting no longer appears in NCP or my AVR even though I manually changed during playback before I rebooted. It's back to 8bit as if I never set it.

I'm not technical enough to answer all of your questions, but I can start. The first scenario where your AVR is reporting 8-bit sounds like a driver error if you selected 12-bit in the NCP. This would be confirmed by the fact you were able to correct this during playback by changing the bit depth in the NCP. Did this change stick?

Second, you are not taking advantage of the 10-bits of the source. It could be output at 8-bits with dithering without most users noticining much of a difference. The color space is not clipped. It is all about smoothing gradients, and high-quality dithering makes various bit depths look smooth. But, of course, you want 10-bit output if your display can support this. Just remember, madVR is processing everything at very high bit depths (16-bits); higher than the highest output bit depth (10-bits). Errors will not occur when going to any bit depth below madVR's processing.

As far as the GPU output is concerned, I don't know what Nvidia sends to display. I thought it passed-through 10-bit, but it might actually be upconverted to 12-bits. That is beyond my technical acumen.

[NoTechi]

I think passthrough is the higher-quality method. Your display knows itself best, so it should be calibrated to maximize HDR content.

My projector is calibrated and HDR looks great ... but you know there is always still room for improvement and playing with new techi gadgets is fun as well ;)
There are some discussions going on atm on projector boards where it is discussed which method is best for the HDR effect and using madvr is one of them.

NoTechi

[Warner306]

And the madVR OSD shows what it receives from the source and what conversions are done by madVR. It is placed between the source and the GPU, so it has no idea what the GPU is doing to the image after it has handed it off.

[Warner306]

My projector is calibrated and HDR looks great ... but you know there is always still room for improvement and playing with new techi gadgets is fun as well ;)
There are some discussions going on atm on projector boards where it is discussed which method is best for the HDR effect and using madvr is one of them.

NoTechi

As I said in my edit to the first post, every display is designed to map using its own methods taking into account the limitations of its output. It is not a universal algorithm.

[brazen1]

Yes the change stuck until I rebooted. Yes my display supports 10bit. Using my old driver, these settings would apply when I opened a title first time, every time, and they would apply and stick after a reboot . As I understand it now, none of this sticking matters? By sending 8bit from the GPU to madVR, evidently to prevent the GPU from dithering instead of madVR is correct if I understood replies correctly. I don't understand how madVR can dither 8bit it is receiving up to 10bit when playing 2160p 23Hz HDR 10bit? My AVR can't either nor NCP? What am I not understanding here?

[huhn]

https://forum.doom9.org/showthread.php?p=1271418#post1271418

[brazen1]

Are we in agreement that newer drivers do not retain a 12bit setting after reboot and reverts to 8bit? If no, has anyone established why it sticks for some and not for others? If yes, are you all playing 10bit sources at 8bit even though your hardware is all 10 bit compatible?

huhn, is there something specific I should concentrate on there? If your simply pointing me to page one, well.......

[Warner306]

Yes the change stuck until I rebooted. Yes my display supports 10bit. Using my old driver, these settings would apply when I opened a title first time, every time, and they would apply and stick after a reboot . As I understand it now, none of this sticking matters? By sending 8bit from the GPU to madVR, evidently to prevent the GPU from dithering instead of madVR is correct if I understood replies correctly. I don't understand how madVR can dither 8bit it is receiving up to 10bit when playing 2160p HDR 10bit? My AVR can't either nor NCP? What am I not understanding here?

I don't know if this is exact or not but...

The source starts as 10-bit. This is great because there is no knowing if the studio used dithering or not and this helps ensure there is no banding in the SOURCE.

madVR takes this information and blows it up to 16-bits. This is all math designed to avoid rounding errors and other mistakes that can lead to inaccurate color values. Then, the result is dithered in the highest-quality possible. So the end result is a 10-bit source upconverted and then downconverted for display.

madVR is designed, in almost every way, to avoid inaccurate color conversions, no matter what it is doing, so it should never introduce banding if the bit depth is 8-bits or higher. This all depends on the quality of the source and whether it had banding to begin with.

Like I said a couple of times now, the color space has fixed top and bottom values. You can manipulate the bit depth all you want without screwing up the colors you started with. You just get more shades of each color when the bit depth is increased; everything in between becomes smoother, not more colorful. This is mitigated in madVR by the use of dithering.

Check out these two images, which show the impact of dithering with a bit depth as low as 2-bits.

Dithering to 2-bits:
2 bit Ordered Dithering (http://madshi.net/2bitOrderedDithering.png)
2 bit No Dithering (http://madshi.net/2bitNoDithering.png)

Pretty impressive?

[Warner306]

And, 10-bit RGB > 8-bit RGB > 10-bit YCbCr 4:2:2 > 10-bit YCbCr 4:2:0.

You only want to send 8-bit RGB when HDMI bandwidth is a problem (at 60 Hz), or when the display does not support 10-bits or has trouble display 10-bits without banding.

[huhn]

Actually YCbCr -> RGB conversion gives us floating point data! And not even HDMI 1.4 can transport that. So we have to convert the data down to some integer bitdepth, e.g. 16bit or 10bit or 8bit.

is this part not clear enough.

and literal nearly every TV supports 12 bit input that doesn't mean they are even 8 bit.

it's very simple, can you easily see a difference between 8 bit madVR output or 10 bit?

yes bother with it. no don't bother with it.

[Warner306]

Are we in agreement that newer drivers do not retain a 12bit setting after reboot and reverts to 8bit? If no, has anyone established why it sticks for some and not for others? If yes, are you all playing 10bit sources at 8bit even though your hardware is all 10 bit compatible?

huhn, is there something specific I should concentrate on there? If your simply pointing me to page one, well.......

The driver appears to work for some people and not for others. I don't know how to get in touch with the people in the know to fix it.

[Warner306]

is this part not clear enough.

and literal nearly every TV supports 12 bit input that doesn't mean they are even 8 bit.

it's very simple, can you easily see a difference between 8 bit madVR output or 10 bit?

yes bother with it. no don't bother with it.

Send 10-bits unless you know your display can't support this, or if you notice banding is introduced by the display (or GPU), or if you want to simplify your set-up until HDMI 2.1 increases the available bandwidth. You won't cripple yourself by going to 8-bits, but this is not the highest possible quality.

My fingers are tired of typing about this topic, so I hope we're clear?

Someone else can confirm what bit depth the GPU is sending to the display; I don't know for sure.

[huhn]

so why should i bother with sending 10 bit if i know for sure my TV is 8 bit FRC (like nearly every Tv out there, except what LG claism for the OLEDs but there is no screen with more banding problems...). why should i send 10 bit if i know for sure it doesn't matter for image quality? so i send 10 bit because the number is higher? is 10 bit even better if it gets dithered again?

seriously why can't people simply use there eyes to judge it.

if you want to know what an GPU send it easy with an AMD card it will always send what you select be default it is 10 bit if the device supports it. by nvidia well not that easy. in the past the bitdeep option was ignored(generally not a totally bad idea if you ask me) and was based on what was used for presentation.

[Warner306]

so why should i bother with sending 10 bit if i know for sure my TV is 8 bit FRC (like nearly every Tv out there, except what LG claism for the OLEDs but there is no screen with more banding problems...). why should i send 10 bit if i know for sure it doesn't matter for image quality? so i send 10 bit because the number is higher? is 10 bit even better if it gets dithered again?

seriously why can't people simply use there eyes to judge it.

if you want to know what an GPU send it easy with an AMD card it will always send what you select be default it is 10 bit if the device supports it. by nvidia well not that easy. in the past the bitdeep option was ignored(generally not a totally bad idea if you ask me) and was based on what was used for presentation.

I outlined why you should not use 10-bits. It covers all of that.

And, 10-bit RGB > 8-bit RGB > 10-bit YCbCr 4:2:2 > 10-bit YCbCr 4:2:0. That is a direct quote from madshi. He didn't clarify the quality difference between each setting.

[Manni]

Send 10-bits unless you know your display can't support this, or if you notice banding is introduced by the display (or GPU), or if you want to simplify your set-up until HDMI 2.1 increases the available bandwidth. You won't cripple yourself by going to 8-bits, but this is not the highest possible quality.

My fingers are tired of typing about this topic, so I hope we're clear?

Someone else can confirm what bit depth the GPU is sending to the display; I don't know for sure.

I have already confirmed that. When set to 12bits, the GPU sends 12bits, at least here. Whether these 12bits are simply padded with trailing zero from the 10bits dithered output of MadVR (most likely) or “true” 12bits, I have no idea.

[brazen1]

Sorry for bugging you guys. I'm just going to use the new driver and let it do its thing at 8bit. Fwiw, my 'go to' movie for checking this discussion is Allied 2016. Scene 2:15 through 3:00 shows a dessert slow pan with a cloudy sky. That sky shows banding using 12bit settings in NCP. Using the 8bit settings (that it's going to revert to after a reboot anyway), there is no banding. I don't know what higher quality I will miss by using 8bit but I won't miss that banding. Thanks for all the input. If I make further progress somewhere down the line, I'll share.

[Warner306]

Sorry for bugging you guys. I'm just going to use the new driver and let it do its thing at 8bit. Fwiw, my 'go to' movie for checking this discussion is Allied 2016. Scene 2:15 through 3:00 shows a dessert slow pan with a cloudy sky. That sky shows banding using 12bit settings in NCP. Using the 8bit settings (that it's going to revert to after a reboot anyway), there is no banding. I don't know what higher quality I will miss by using 8bit but I won't miss that banding. Thanks for all the input. If I make further progress somewhere down the line, I'll share.

One other thing...I read you were having trouble with MPC-BE in the Kodi forums. This only occurred when launching the player from Kodi.

Have you tried programming Stop and Exit to the same key on your remote instead of using the automatically close after playback setting? That is what I used to do and it never failed with either player.

I try and stay out of your set up guide. And I don't know anything about ISO's or BDMV's or batch files. Sorry to the other users, but Brazen posts a lot of set up information for new users to madVR that want to use Kodi.

Edit: Probably shouldn't have posted that here, but I did.

[huhn]

bit deep is about banding and noise and that's.
the higher the bit deep the lower the noise floor.
even 6 bit can create a banding free image but most people will see the added noise to hide the banding.

and that'S why blindly using 10 bit is not a good idea there is a reason it is not default and no sending 8 bit with 10 bit madVR is not that bad... it's clearly not optimal to say it friendly.

[brazen1]

And I shouldn't answer you and this will be the end of it. Yes, my remote is programmed exactly like that. For MPC-HC too yet each behaves differently. To get technical beyond my understanding, it depends if stereoscopic is engaged or not. Don't ask me why but that is exactly what it boils down to. I also map alt + f4 to force them to close if the auto function didn't. I prefer the auto close because the less interaction the better. You are welcome in my guide anytime. I appreciate you. You know that. Half of what I know is because of your guides and because of the diverse crowd here. Good folks all of you. Much nicer guide than mine for sure:o

[brazen1]

Yes huhn. I've finally grasped what you are trying convey all this time. 8 bit vs 10 bit is just a couple of numbers. Because one is higher does not mean it is better especially when you consider hardware being used. In the end, what our eyes see should be our final deciding factor. You've been correct all along. Thank you for finally beating it into my head.

[Asmodian]

I have already confirmed that. When set to 12bits, the GPU sends 12bits, at least here. Whether these 12bits are simply padded with trailing zero from the 10bits dithered output of MadVR (most likely) or “true” 12bits, I have no idea.

Starting with madVR's dithered 10-bit output, what would be the difference between 10 bit with trailing zero and "true" 12 bit? The way you perfectly convert 10 bit to 12 bit is to add two zeros. This is a 2D image, we do not have new samples or anything to interpolate between. The best thing to do is simply add zeros, any further processing would generate some non-zero bits in the least two significant positions, reducing the effective bit depth loss from that processing step, but the source would simply have nothing but zero in those positions. :confused:

[ryrynz]

Simple MadVR options..

"Should I enable X?"
"Can you see a difference enabling X?"

Repeat ad nauseam.

Think we've covered this about half a dozen times already.

[Manni]

Starting with madVR's dithered 10-bit output, what would be the difference between 10 bit with trailing zero and "true" 12 bit? The way you perfectly convert 10 bit to 12 bit is to add two zeros. This is a 2D image, we do not have new samples or anything to interpolate between. The best thing to do is simply add zeros, any further processing would generate some non-zero bits in the least two significant positions, reducing the effective bit depth loss from that processing step, but the source would simply have nothing but zero in those positions. :confused:

I didn't say one would be better than the other, I just said that I have no idea what the driver does. So I don't know if it pads the 10bits handed by MadVR with 00 (which I indicated is more likely and I agree would be preferred) or if the driver does some kind of interpolation resulting in "true" 12bits. This is why I put quotes around the true, to make it clear that it would be "true" in name but not necessarily better. I clearly failed.

Now my fingers are tired too, so I'm off :)

[Asmodian]

There is nothing to interpolate through, I just don't understand what you imagine it could be doing. Making up non-zero values? There is only one value, nothing to interpolate between.

[huhn]

there is a way to fill it up with something else than 00. but we don't know and we can't change it anyway.

[mclingo]

Simple MadVR options..

"Should I enable X?"
"Can you see a difference enabling X?"

Repeat ad nauseam.

Think we've covered this about half a dozen times already.

I think what some people want is objective answers and with MADVR there should be some objective advice that can be given. However with everyone having different eyesight, TV's, lighting conditions and setups in general most of the processing done in MADVR can now really on be subjectively different / better / worse in most cases.

I am aware there is a clear objective difference between 444 rgb and 420 ybcr but I personally choose to run everything in 10 bit 4:2:0, I get hammered for this everywhere but I genuinely see no difference at all between 8 bit 444 full RGB dithered and 10 bit 420, or maybe I should say I see no difference in real world viewing. I do however see a difference between madvr and standard EVR renderer.

set this way you dont have to worry about bit depth switching, bandwidth or anything, everything just works as it should.

I did try using 4:2:2 but I get small picture dropouts, a couple every evening, I see my receivers DIGI icon disappear when it happens so its losing connection, something in my setup cant handle that extra bandwidth, i've given up trying to find out what after 3 sets of HDMI cables. I'm sure its bandwidth as it doesnt do it at 422 4k 24hz, only 422 4k 60hz.

[Manni]

There is nothing to interpolate through, I just don't understand what you imagine it could be doing. Making up non-zero values? There is only one value, nothing to interpolate between.

I'm not saying there is something to interpolate. I'm only saying that I didn't look with an analyzer at the bits coming out of the GPU to be able to say for sure what the driver does. I've seen Sony bluray players "creating" data instead of padding with zeros when enabling "deep color", so I'm not going to say that this is what it is when I have no evidence. What makes you so sure that a driver might not do the wrong thing and "interpolate"?

If you are 100% sure that the driver pads with zeros because you've looked at the stream coming out of the nVidia GPU set to 12bits when MadVR sends 10bits dithered, by all means say so, otherwise please allow me to not state something that I am not sure of.

The only thing I can guarantee is that the driver does output 12bits when set to 12bits, because I can see that with the Vertex. What's in the last two bits, I can't say for sure, even if chances are that it's padded zeros (fingers crossed).

[huhn]

because 8 bit 11111111 is not the same as 10 bit 1111111100 in term of top brightness 1111111111 has the same brightness.

[Asmodian]

I simply don't understand what you imagine it might be doing? Making up non-zero values? There is only one data point, you cannot interpolate with one point. I suppose the driver could add noise? :p

Edit: Ah, true huhn. So maybe they strech the range 000000000000-111111111100 to 000000000000-111111111111, with dithering, which would be odd but possible. :(

[nevcairiel]

There is actually a bit of a trick when extending the bitdepth of a full range signal, you fill the new bits with the leading bits of the pixel, ie. like this for 8 to 10-bit:

- You shift to 10-bit first, which adds two empty bits.
- Then you fill those empty bits with the top bits from the original signal


1111111100
+ 11111111
= 1111111111


This has several good properties, namely:
- All 1 also remains all 1, ie. maximum 8-bit (255) remains maximum 10-bit (1023)
- Zero also remains zero
- Its easy and fast

I can't say that this is what its doing, but it is generally regarded as producing a more faithful signal when increasing bitdepth then plain zero padding, and a full stretch from 0-255 to 0-1023 is computationally rather expensive.

Note that this does not apply when you are dealing with limited range (ie. 16-235), because 16 and 235 map to the limited-range 10-bit values exactly when you simply shift them up (ie. 64 to 940)
But when handling full-range signals like RGB, plain zero padding is not entirely accurate.