madshi bug tracker - madVR
View Issue Details
0000605madVRbugpublic2019-03-17 10:402019-03-25 09:45
PC, MPC-HC + MadVR Windows 10 x6410.0.17763.379
MadVR v0.92.17 or madVRhdrMeasure78
MPC-HC v1.84
LAV v0.73.1
LAV v0.73.1
DXVA2 Native
none (progressive)
windowed mode
GTX 1060 6GB
0000605: Incorrect HDR nits reported
Windows 10 x64 on the latest patches
MPC-HC v1.84
MadVR v0.92.17 or madVRhdrMeasure78
NVIDIA GTX 1060 6GB, drivers v417.75

Download files from here: [^]

You'll that some of these files are mastered at higher than 1000 nits, but I don't see that reflecting in the madvr stats

Play 01. 240-1000nits.mp4 on MPC-HC + MadVR:
-when you press Ctrl+J on madvr, 1000 nits is correctly reported

Play 03. 900-4000nits.mp4 (or) 05. 700-10Knits.mp4 (or) 07. 3600-10Knits.mp4 or on MPC-HC + MadVR
-you'll still continue to see 100 nits reported
-Expected to see 4000 nits / 10,000 / 10,000 nits respectively

Since the max nits is being reported incorrectly, my TV tone maps accordingly only upto 1000 nits, and everything above >1000 nits is being clipped

If you however copy these files on usb drive and play them from the LG C8 TV directly, I see the TV tone map all these files very well upto 3800~4000 nits
03. 900-4000nits.mp4
05. 700-10Knits.mp4
07. 3600-10Knits.mp4

which leads me to believe the files themselves are fine, and the issue lies somewhere in the Windows -> Madvr -> NV drivers chain
No tags attached.
jpg 03. 900-4000nits.mp4 on PC with Madvr.jpg (1,825,202) 2019-03-17 15:57
jpg 03. 900-4000nits.mp4 on PC with Madvr with debug OSD enabled.jpg (2,185,878) 2019-03-17 15:58
jpg 03. 900-4000nits.mp4 on TV directly via USB.jpg (1,767,167) 2019-03-17 15:58
Issue History
2019-03-17 10:40kryptoniteNew Issue
2019-03-17 11:48madshiNote Added: 0002501
2019-03-17 14:33kryptoniteNote Added: 0002502
2019-03-17 14:41kryptoniteNote Edited: 0002502bug_revision_view_page.php?bugnote_id=2502#r560
2019-03-17 15:38madshiNote Added: 0002503
2019-03-17 15:57kryptoniteFile Added: 03. 900-4000nits.mp4 on PC with Madvr.jpg
2019-03-17 15:58kryptoniteFile Added: 03. 900-4000nits.mp4 on PC with Madvr with debug OSD enabled.jpg
2019-03-17 15:58kryptoniteFile Added: 03. 900-4000nits.mp4 on TV directly via USB.jpg
2019-03-17 15:59kryptoniteNote Added: 0002504
2019-03-17 16:06madshiNote Added: 0002505
2019-03-17 16:10kryptoniteNote Added: 0002506
2019-03-17 16:51madshiNote Added: 0002507
2019-03-17 17:06kryptoniteNote Added: 0002508
2019-03-17 17:19madshiNote Added: 0002509
2019-03-17 17:26kryptoniteNote Added: 0002510
2019-03-17 17:27kryptoniteNote Edited: 0002510bug_revision_view_page.php?bugnote_id=2510#r562
2019-03-17 17:35madshiNote Added: 0002511
2019-03-17 17:56kryptoniteNote Added: 0002512
2019-03-17 17:59kryptoniteNote Edited: 0002512bug_revision_view_page.php?bugnote_id=2512#r564
2019-03-17 18:00kryptoniteNote Edited: 0002512bug_revision_view_page.php?bugnote_id=2512#r565
2019-03-17 18:55madshiNote Added: 0002513
2019-03-18 12:42kryptoniteNote Added: 0002514
2019-03-20 12:54kryptoniteNote Added: 0002515
2019-03-25 09:45madshiNote Added: 0002516

2019-03-17 11:48   
It's a known issue with the newer Nvidia drivers. I've already reported this to Nvidia, but they've not fixed it yet. I hope it will be fixed in a future driver version. For now you can downgrade to an older driver version. I think the last one that sent correct metadata to the display was 397.93.
2019-03-17 14:33   
(edited on: 2019-03-17 14:41)
I just tried drivers 385.25 through 398.11, and with the same files, I still see HDR 1000 nits in the madVR stats for these clipping tests, so something is still off.

I should have mentioned this before, there are other videos/movies in my collection @ 4000 nits and # 10,000 nits and madVr shows the rights stats for these, irrespective of whether I use driver 385.25 or 417.75, so I guess my issue is specific to these files. And these files themselves seem to be fine because they cleanly tone map on my TV upto 4000 nits if played directly from the TV via USB, but only upto 1000 nits when played through madvr.

Would be great if you could please take a look.


2019-03-17 15:38   
What do you mean with "madVR stats" exactly?
2019-03-17 15:59   
I'm referring to the debug OSD - the CTRL + J shortcut.
Also attaching 3 pictures

1) 03. 900-4000nits.mp4 on PC with Madvr.jpg
-where I'm playing the "03. 900-4000nits.mp4" file on my PC with Madvr on my LG C8 and you can see the blocks upto 1000 nits are lit, others are clipped

2) 03. 900-4000nits.mp4 on PC with Madvr with debug OSD enabled.jpg
-where I'm playing the "03. 900-4000nits.mp4" file on my PC with Madvr on my LG C8 with the debug OSD enabled and you can see HDR 1000 nits being reported, which also explains why everything above 1000 nits is being clipped as seen in (1). I think this file is at 4000 nits.

3) 03. 900-4000nits.mp4 on TV directly via USB.jpg
-where I'm playing the "03. 900-4000nits.mp4" file on my LG C8 TV directly via USB, and you can see the TV is tone mapping to almost 4000 nits, beyond which it's clipped
2019-03-17 16:06   
You mean the "HDR 1000 nits" information in the OSD? That's information madVR receives from the splitter/decoder. Which decoder are you using? LAV Video Decoder?
2019-03-17 16:10   
->You mean the "HDR 1000 nits" information in the OSD?
Yes, correct

->That's information madVR receives from the splitter/decoder. Which decoder are you using? LAV Video Decoder?
Yup, LAV 0.73.1, also tried 0.74 that was released yesterday.
2019-03-17 16:51   
Ok, I've checked file "900-4000nits.mp4". It has the following metadata:

Mastering Display Peak: 1000 nits
MaxCLL: 4000 nits
MaxFALL: 1600 nits

All of this data is incorrect, though. madVR actually measures more than 6000 nits.

Anyway, the latest madVR test build should forward the proper metadata to the display, when using a proper Nvidia driver version. I'm not sure right now if the official madVR build also does that. You can try the latest test build here: [^]
2019-03-17 17:06   
I'm actually right now on, [^] and I've set it to pass through to display

With this madvr build, I tried 385.25 through 398.11 and also the latest 417.x and 419.x drivers, but nothing helps tone map to 4000 nits really.

With 385.25 & 398.11, I see peak white tone map to 1000 nits, I see one or 2 colours extend to about 1500 nits maybe, but cyan for example doesn't even tonemap to 700 nits, clips way before that

With 417.x & 419.x, I see peak white and all colours tone map very well to 1000 nits, but nothing beyond.

And everything is very different when natively played on the TV, where peak white and colour all tone map well upto 3000 nits+.

So, I'm not sure where the issue is
2019-03-17 17:19   
I don't really know. Of course the video is going through very different processing paths when playing with the internal TV player vs when being fed via HDMI. So it's possible the TV doesn't handle HDR input via RGB very well.

I suppose you've already set your GPU and madVR and your TV all to RGB Full (0-255), right?
2019-03-17 17:26   
(edited on: 2019-03-17 17:27)
MadVR and NVIDIA Video player settings are at 0-255
Display is at 3840x2160, YCBCR 4:2:2, 12bit, 60Hz, which will be 16-235, can't do RGB 10/12bit over HDMI 2.0b
HDMI Deep colour is enabled on TV to switch to HDR on demand

If I set display to 3840x2160, RGB Full (0-255), 8bit, 60Hz, then the TV tone maps to 600-650 nits with these files, and clips everything after that, which is even worse

2019-03-17 17:35   
I've no idea what happens if you send YCbCr to the TV. The Nvidia driver will convert my RGB rendered pixels to 4:2:2, using an unknown color matrix, an unknown chroma downscaling algorithm, and possibly no dithering. It's really really bad. RGB 8bit should be *much* better. Have you tried that with a proper driver, e.g. 397.93 or older?

People worry too much about bitdepth, to be honest. 8bit RGB is perfectly fine, if you use lossless high quality dithering. We do need as high as possible bitdepth for lossy content encoding. But during lossless HDMI transport, dithered 8bit is plenty good enough.
2019-03-17 17:56   
(edited on: 2019-03-17 18:00)
Appreciate your quick responses mate, I hadn't tried, but just did.

Driver = 397.93
Madvr set to pass through
RGB 8-bit Full 0-255 set in NV display settings
MadVR settings, NVIDIA video color settings, LAV settings set to 0-255

And I got exactly the same thing as

Driver = 417.75
Madvr set to pass through
YCBCR 12bit Limited 16-235 set in NV display settings
MadVR settings, NVIDIA video color settings, LAV settings set to 0-255

Both tone map up to 1000 nits (whites & all the colours), that's it. They're identical.

2019-03-17 18:55   
Maybe the LG ignores MaxCLL when receiving RGB via HDMI? The Mastering Monitor Metadata is only 1000 nits, maybe the LG uses that in this situation? I'm only guessing, of course.
2019-03-18 12:42   
Might very well be the case, I've made a post there on the creator's thread, hope he could share some ideas: [^]
2019-03-20 12:54   
Hope you had a chance to follow the discussion here: [^]

I think we've provided that Mastering display level has an effect on the TV's tonemapping when using MPC-HC + MadVR, but if the same file is played through the TV's internal player via USB, it responds to MaxCLL instead.

While the author of the files has offered to re-encode the files using matching MDL/maxCLL values, I was wondering if there is anything we should do on the madvr front to help the TV respond to maxCLL instead of MDL while using MPC-HC + madVR (we know the TV does repond to maxCLL when using it's internal player via USB)
2019-03-25 09:45   
What are you suggesting? That I set MDL to maxCLL? The problem with this approach is that maxCLL doesn't have to be accurate. So if I set MDL to the same value as maxCLL, this might make things worse for some movies/display combinations. E.g. there are several movies which have these values set to some standard values which can be far too low, which would result in clipping, if the display actually made use of those values.

Actually these test patterns don't have accurate maxCLL values, either. madVR detects that by looking at whether the numbers are rounded to xxx50/xxx00. If both maxCLL and madFALL are rounded that way, there's a 99.96% chance that they were manually set and not properly calculated. In that case madVR completely ignores the maxCLL and maxFALL data.