View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000605||madVR||bug||public||2019-03-17 10:40||2019-03-25 09:45|
|Platform||PC, MPC-HC + MadVR||OS||Windows 10 x64||OS Version||10.0.17763.379|
|Summary||0000605: Incorrect HDR nits reported|
Windows 10 x64 on the latest patches
MadVR v0.92.17 or madVRhdrMeasure78
NVIDIA GTX 1060 6GB, drivers v417.75
LG C8 TV
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
|Steps To Reproduce|
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
which leads me to believe the files themselves are fine, and the issue lies somewhere in the Windows -> Madvr -> NV drivers chain
|Tags||No tags attached.|
|madVR Version||MadVR v0.92.17 or madVRhdrMeasure78|
|Media Player (with version info)||MPC-HC v1.84|
|Splitter (with version info)||LAV v0.73.1|
|Decoder (with version info)||LAV v0.73.1|
|DXVA2 Scaling Active||no|
|Aero / Desktop Composition||On|
|Problem occurs with mode||windowed mode|
|GPU Model||GTX 1060 6GB|
|GPU Driver Version||417.75|
||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.|
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.
||What do you mean with "madVR stats" exactly?|
03. 900-4000nits.mp4 on PC with Madvr.jpg (1,825,202 bytes)
03. 900-4000nits.mp4 on PC with Madvr with debug OSD enabled.jpg (2,185,878 bytes)
03. 900-4000nits.mp4 on TV directly via USB.jpg (1,767,167 bytes)
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
||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?|
->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?
Yup, LAV 0.73.1, also tried 0.74 that was released yesterday.
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:
I'm actually right now on http://madshi.net/madVRhdrMeasure78.zip, 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
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?
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
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.
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.
||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.|
Might very well be the case, I've made a post there on the creator's thread, hope he could share some ideas:
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)
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.
|2019-03-17 10:40||kryptonite||New Issue|
|2019-03-17 11:48||madshi||Note Added: 0002501|
|2019-03-17 14:33||kryptonite||Note Added: 0002502|
|2019-03-17 14:41||kryptonite||Note Edited: 0002502|
|2019-03-17 15:38||madshi||Note Added: 0002503|
|2019-03-17 15:57||kryptonite||File Added: 03. 900-4000nits.mp4 on PC with Madvr.jpg|
|2019-03-17 15:58||kryptonite||File Added: 03. 900-4000nits.mp4 on PC with Madvr with debug OSD enabled.jpg|
|2019-03-17 15:58||kryptonite||File Added: 03. 900-4000nits.mp4 on TV directly via USB.jpg|
|2019-03-17 15:59||kryptonite||Note Added: 0002504|
|2019-03-17 16:06||madshi||Note Added: 0002505|
|2019-03-17 16:10||kryptonite||Note Added: 0002506|
|2019-03-17 16:51||madshi||Note Added: 0002507|
|2019-03-17 17:06||kryptonite||Note Added: 0002508|
|2019-03-17 17:19||madshi||Note Added: 0002509|
|2019-03-17 17:26||kryptonite||Note Added: 0002510|
|2019-03-17 17:27||kryptonite||Note Edited: 0002510|
|2019-03-17 17:35||madshi||Note Added: 0002511|
|2019-03-17 17:56||kryptonite||Note Added: 0002512|
|2019-03-17 17:59||kryptonite||Note Edited: 0002512|
|2019-03-17 18:00||kryptonite||Note Edited: 0002512|
|2019-03-17 18:55||madshi||Note Added: 0002513|
|2019-03-18 12:42||kryptonite||Note Added: 0002514|
|2019-03-20 12:54||kryptonite||Note Added: 0002515|
|2019-03-25 09:45||madshi||Note Added: 0002516|