View Full Version : madVR - high quality video renderer (GPU assisted)
Asmodian
21st May 2017, 21:30
Maybe, it's better to choose relative colorimetric then?
Well, I was addressing those artifacts in your test pattern.
I prefer perceptual myself, accuracy is not affected very much and the image looks better. I spent years using an absolute or relative (or luminescence axis) intent but once I got over my accuracy > all fixation I much prefer the image when using perceptual. And you never get clipping artifacts.
If the display's gamut is not very close to the source gamut then perceptual is not a good choice but when your display is already close to the source gamut then perceptual is my preferred choice.
I suggest testing the various intents and picking the one that looks best to you.
I would like to understand when I should use it. If I change the refresh to 24hz instead of 23hz I could use it? Who would win?
If you want to use 24Hz with Windows 10 or 8.1 you probably need to use it, otherwise no. I never need to use 24 or 60 Hz so I do not enable it. Nothing wins if you don't need 24 Hz. I understand there are some 24 Hz blurays but I don't think I have any. Personally, enabling smooth motion and not worrying about any of these refresh rate issues is my preferred technique.
Sideeffect
21st May 2017, 21:30
So you're saying your display still stays in SDR mode, even when you enable the "HDR and advanced color" switch in display settings? Your display only switches to HDR mode for the exact duration in which madVR is in fullscreen exclusive mode?
When I enable "HDR and advanced color" the display shows HDR enabled and the display enters HDR mode. If I open up a HDR video in windowed mode the colours are washed out.
Once I go to full screen the display shows HDR again like it detects it again and the colours display properly the same as if I would run them from a USB stick on TV.
I guessed this was because HDR is only working in directx 11 mode and even though the windows desktop is sending a HDR enabled signal to the display it still is actually only working in a directx 11 fullscreen aplication.
Some people are reporting that the Microsoft films and tv app is working with HDR in windowed mode but I disagree as I think it looks different more like HDR to SDR conversion and not as good as USB playback or madvr exclusive playback.
So madVR behaves the same way as HDR games, is that correct?
Yes MadVR behaves the same as Mass effect Andromeda and Shadow Warrior 2. But this is not a good thing as it's a pain to keep changing colour settings. I leave the Display in Nvidia colour 8-bit RGB Full for everything else. Enabling the Microsoft colours sets either RGB limited or 422 you can't really see the setting but either way it looks crap for general PC usage.
Are you using 382.19? For me this is no longer the case on this driver.
No I am still using 382.05 as the Prey hotfix didn't apply to me. What changed with HDR?
Oguignant
21st May 2017, 21:37
If you want to use 24Hz with Windows 10 or 8.1 you probably need to use it, otherwise no. I never need to use 24 or 60 Hz so I do not enable it. Nothing wins if you don't need 24 Hz. I understand there are some 24 Hz blurays but I don't think I have any. Personally, enabling smooth motion and not worrying about any of these refresh rate issues is my preferred technique.
Now I understand. I use 23hz (99% of the movies I have are 23,976 fps) and de-judder/de-blur options from the Tv. looks great.
cyber201
21st May 2017, 21:39
@madshi
Same issue of imhh11,
GTX1070, Win10 CU, latest nvidia driver, latest madvr, latest Lav Filter.
I use Kodi DSlayer v17.1. TV Samsung KS8000
If I turn on HDR slide in Windows 10, all videos are play in HDR mode.
If I turn off HDR slide in Windows 10, madvr don't turn on my TV into HDR mode. The only way is to turn on HDR slide manually when I need to play an HDR video.
Thanks madshi for your work.
Well, I was addressing those artifacts in your test pattern.
I prefer perceptual myself, accuracy is not affected very much and the image looks better. I spent years using an absolute or relative (or luminescence axis) intent but once I got over my accuracy > all fixation I much prefer the image when using perceptual. And you never get clipping artifacts.
If the display's gamut is not very close to the source gamut then perceptual is not a good choice but when your display is already close to the source gamut then perceptual is my preferred choice.
I suggest testing the various intents and picking the one that looks best to you.
Ok, I tried both relative colorimetric and perceptual.
Switched to D3D9 windowed, and both give these saturated color blotches on video.
I have wide gamut display, and certainly need to use 3dlut.
As far as I understand the problem, it's due to the fact that values 236-255 are not expected on input and simply not translated on output.
Is it correct? Or is there a way still to map them to the nearest color value that is in gamut for sRGB?
Sideeffect
21st May 2017, 21:46
So you're saying your display still stays in SDR mode, even when you enable the "HDR and advanced color" switch in display settings? Your display only switches to HDR mode for the exact duration in which madVR is in fullscreen exclusive mode?
When I enable "HDR and advanced color" the display shows HDR enabled and the display enters HDR mode. If I open up a HDR video in windowed mode the colours are washed out.
Once I go to full screen the display shows HDR again like it detects it again and the colours display properly the same as if I would run them from a USB stick on TV.
I guessed this was because HDR is only working in directx 11 mode and even though the windows desktop is sending a HDR enabled signal to the display it still is actually only working in a directx 11 fullscreen aplication.
Some people are reporting that the Microsoft films and tv app is working with HDR in windowed mode but I disagree as I think it looks different more like HDR to SDR conversion and not as good as USB playback or madvr exclusive playback.
So madVR behaves the same way as HDR games, is that correct?
Yes MadVR behaves the same as Mass effect Andromeda and Shadow Warrior 2. But this is not a good thing as it's a pain to keep changing colour settings. I leave the Display in Nvidia colour 8-bit RGB Full for everything else. Enabling the Microsoft colours sets either RGB limited or 422 you can't really see the setting but either way it looks crap for general PC usage.
Are you using 382.19? For me this is no longer the case on this driver.
No I am still using 382.05 as the Prey hotfix didn't apply to me. What changed with HDR?
Asmodian
21st May 2017, 22:22
If it is simply that you have full range input then the source needs to say it is full range. If it doesn't you can use Crtl-Alt-Shift-I to toggle through the input levels, PC is full range where 255 is mapped to 100% instead of 235. With limited range content you cannot map 236-255 to in-gamut colors; they are, by definition, out of gamut.
Sorry, I am confused as to what you want and why you are looking at this test image. :o
Please continue to ask calibration questions in the Display Calibration thread (https://forum.doom9.org/showthread.php?t=172783) so we don't clog up madshi's thread with calibration.
If it is simply that you have full range input then the source needs to say it is full range. If it doesn't you can use Crtl-Alt-Shift-I to toggle through the input levels, PC is full range where 255 is mapped to 100% instead of 235. With limited range content you cannot map 236-255 to in-gamut colors; they are, by definition, out of gamut
Ok, possibly the source is wrong and it is full range, but not providing this.
Strange that in this case madVR doesn't clip these values, and it leads to wrong colors.
Seems that I need to manually switch this source encoding for each video in this case.
Sorry, I am confused as to what you want and why you are looking at this test image. :o
This is a screenshot from video, not an image actually. There are many examples of such wrong colors in several videos.
Please continue to ask calibration questions in the Display Calibration thread (https://forum.doom9.org/showthread.php?t=172783) so we don't clog up madshi's thread with calibration.
Didn't think that it was display calibration related question, just what madVR does with 3dlut mappings.
But ok, possibly it's bordering with calibration much.
P.S. Forgot to ask: does madVR support 3D LUT for full range content?
Because there is no way to select input or output encoding "RGB 0-255" when creating 3dlut for madVR.
Damien147
21st May 2017, 22:49
Questions:
3) If HDR switch does NOT work for you: Which GPU are you using? Does the OS show the "HDR and Advanced color" switch to you? Have you tried with the switch on and off? Does your display switch into HDR with the switch on or off? Or neither?
RX470.Yes,it shows the switch.I tried it on and off but it gets disabled all the time.The only time I've seen it enabled was with the installation of new drivers but it didn't last long.With previous madvr version I've seen it getting enabled at random times when opening a video(non hdr) but if I remember well it gets disabled when going fullscreen.Haven't tested a lot with v0.91.10 but the behavior seems like the past.Washed out image and hdr stays disabled.
Also did you change anything else?I think I found an occasion that I have dropped frames when in the past things seemed more stable.Not completely sure though.
hannes69
21st May 2017, 23:05
That sounds good. That's not the case for my Kaby Lake GPU, though. Maybe it's a driver issue, once more?
Seems like that, yes. Bad driver implementations and OS quirks like Creators Update may keep us all busy for the next decades:devil:
I recently made a clean OS install directly with Win 10 Creators Update included and didnīt have any major problems though like others reported... Some small things like a taskbar that didnīt like to disappear in FSE and things like that but nothing too critical.
BTW: Recently I had several use cases for 24.000 Hz. I often watch movies with Amazon Video and there are several with this frame rate (some months/years ago they were mainly 23.976fps, in the meantime the number of 24.000fps ones is growing). And of course I watch them with madVR (Kodi with MPC HC as external player). So the 23.976fps vs. 24.000fps topic has indeed some relevance (when using corresponding refresh rates and not smoothmotion of course).
kolak
21st May 2017, 23:42
If I have h265 files with HDR info in headers (added with --master-display option) will these be fully passed over HDMI?
mrcorbo
22nd May 2017, 00:25
Wow, that's weird. Totally different behaviour to what Sideeffect and oldpainlesskodi are reporting!
You're saying your display immediately switches into HDR mode when you flip the "use HDR and Advanced color" display settings switch on, even if no video is playing and no game is running?
Weird indeed! And that's correct, yes. And when the HDR switch is activated both madVR in windowed mode and the Win 10 Movies & TV app render the video correctly.
Strange. With these settings, how does fullscreen exclusive mode look?
With the HDR slider on or off videos in FSE look exactly the same and also look identical to what I get when I choose EVR as the renderer in MPC-HC.
Just to be sure I am being totally clear. In windowed mode with the Win 10 API HDR metadata is always being passed whether HDR mode is activated via the switch or not, but is only displayed correctly when the HDR switch is active. In FSE mode HDR metadata is never being passed regardless of the state of the HDR switch and, additionally, when FSE mode is activated it will take me out of HDR mode on my TV if it has been activated by the switch. As soon as I leave fullscreen, if HDR had been activated by the switch my TV will return to HDR mode and HDR metadata is passed again.
P.S. Forgot to ask: does madVR support 3D LUT for full range content?
Because there is no way to select input or output encoding "RGB 0-255" when creating 3dlut for madVR.
it doesn't matter for the 3D LUT if the source is limited or full range.
it will always get a limited range signal as an input and outputs this in limited range.
changing the output/input encoding to something other than 16-235 will results in wrong colors.
if a file is full range but not flagged for full range it is broken!
and you should contact the creator to fix it because he made a huge mistake here.
it doesn't matter for the 3D LUT if the source is limited or full range.
it will always get a limited range signal as an input and outputs this in limited range.
changing the output/input encoding to something other than 16-235 will results in wrong colors.
As far as I understand this, it's madVR feature, because it more tuned to movie playback, and these have limited range?
Won't it be better to just clip input BtB and WtW values to 16 and 235 respectively?
if a file is full range but not flagged for full range it is broken!
and you should contact the creator to fix it because he made a huge mistake here.
In my example it's video from Youtube, but I saw other video files with this problem.
As far as I understand this, it's madVR feature, because it more tuned to movie playback, and these have limited range?
Won't it be better to just clip input BtB and WtW values to 16 and 235 respectively?
if this would be done it would be impossible to watch properly flagged full range content.
and i don't know why you think madVR more tuned for limited range. madVR is perfectly made for full range content
unlike other renderer that treat everything as limited range madVR is aware of full range videos and handles them correctly.
In my example it's video from Youtube, but I saw other video files with this problem.
that makes it easier to contact the creator. doesn't it?
if this would be done it would be impossible to watch properly flagged full range content.
and i don't know why you think madVR more tuned for limited range. madVR is perfectly made for full range content
unlike other renderer that treat everything as limited range madVR is aware of full range videos and handles them correctly.
I mean - if the video is detected as limited range (even erroneously), why not clip WtW values?
And if it's full range - use range 0-255 and not clip.
The current implementation leaves colors of WtW wrong, and it has no sense to me.
As for contacting the author - is there a good and technical way to make sure that the video uses full range, even when tagged as limited?
Except for guessing looking at miscoloration?
some videos have some informations in the WTWor BTB parts so no there is no easy technical way to check this.
i'm mean you have to check ALL frames in a video to be 100% sure.
it could even switch all the time.
maybe the creator wants it too look terrible clipped on top of it.
this video here is full range: https://www.youtube.com/watch?v=bzJDimvPW1Y but YT think it is limited range so blacks are clipped. even with a correct flag you should not upload full range to YT.
are you even sure full range is the source of your issues?
i talked about BTB WTW handling of 3D LUT before and well it is still as it is: http://bugs.madshi.net/view.php?id=424
Oguignant
22nd May 2017, 02:04
I think I posted everything relevant in that post. I ran the tests on a i7-6700 at 4.7 GHz. Those are the individual times for NGU, not the total average rendering time. If you put an empty file called "ShowRenderSteps" in the madVR directory it will show you the rendering times for each filter individually in the OSD.
I just tried it. My times are similar to yours. NGU Sharp very high: 14.1 ms
oldpainlesskodi
22nd May 2017, 07:13
Re HDR....further digging...
With my GTX 1080 using driver 378.92, pass-through with nvidia api or win 10 api does nothing in dx 11 FSE. If using windowed dx11, nvidia api does nothing, but, if i select win10 api in non-fse dx11, it passes through the metadata, but does not switch the display into hdr mode.
Can anyone else confirm?
K
Update - tried the above on drivers past 378.92, and it doesn't work. From reading the nvidia forums, post this driver, nvidia handed over an important part of the render chain to the OS. So, to confirm, using nvidia driver 378.92, madvr set to hdr pass-through using win10 api and madvr set to non-fse dx11 passes through the metadata perfectly (no washed out colours and perfect blacks), but, the 8bit output is imposed, and the display doesnt switch to hdr mode (although it looks like hdr mode).
Madshi - hope this helps.
Update 2 -hmmmm. Even though madvr is in fullscreen window 8 bit mode, my receiver reports a 36bit (12x3) ouput with 10bit and 8bit 23.976 files (nv control panel set to 12bit for 23,24,25 and 30hz full range through the chain, apart from Lav set as untouched).
some videos have some informations in the WTWor BTB parts so no there is no easy technical way to check this.
i'm mean you have to check ALL frames in a video to be 100% sure.
it could even switch all the time.
Provided there is a tool to check the color values of all the frames. Or should I convert every frame to image and check manually every pixel?
maybe the creator wants it too look terrible clipped on top of it.
The video looks ok when played without applying 3D LUT, just more saturated on the wide gamut monitor.
Also, there are no artifacts with 3D LUT when I switch input encoding to full range, it's just more washed out.
this video here is full range: https://www.youtube.com/watch?v=bzJDimvPW1Y but YT think it is limited range so blacks are clipped. even with a correct flag you should not upload full range to YT.
are you even sure full range is the source of your issues?
That was actually a question from the very beginning.
And the best guess I could come to.
i talked about BTB WTW handling of 3D LUT before and well it is still as it is: http://bugs.madshi.net/view.php?id=424
ryrynz
22nd May 2017, 10:05
but YT think it is limited range so blacks are clipped. even with a correct flag you should not upload full range to YT.
YT has a lot of PC content.. so it's all wrong? Why is it not fixed?
ph123uk
22nd May 2017, 10:59
Re HDR....further digging...
With my GTX 1080 using driver 378.92, pass-through with nvidia api or win 10 api does nothing in dx 11 FSE. If using windowed dx11, nvidia api does nothing, but, if i select win10 api in non-fse dx11, it passes through the metadata, but does not switch the display into hdr mode.
Can anyone else confirm?
K
Update - tried the above on drivers past 378.92, and it doesn't work. From reading the nvidia forums, post this driver, nvidia handed over an important part of the render chain to the OS. So, to confirm, using nvidia driver 378.92, madvr set to hdr pass-through using win10 api and madvr set to non-fse dx11 passes through the metadata perfectly (no washed out colours and perfect blacks), but, the 8bit output is imposed, and the display doesnt switch to hdr mode (although it looks like hdr mode).
Madshi - hope this helps.
Update 2 -hmmmm. Even though madvr is in fullscreen window 8 bit mode, my receiver reports a 36bit (12x3) ouput with 10bit and 8bit 23.976 files (nv control panel set to 12bit for 23,24,25 and 30hz.
I get exactly this.
In windowed mode using the windows 10 API I get HDR colours and representation, looks fantastic.
As soon as I double click for fullscreen I get washed out colours.
In either windowed or fullscreen it does not activate the "HDR" mode on my TV - but again, windowed mode looks correct!
So close!
ph123uk
22nd May 2017, 11:19
A quick video of what I am experiencing in MADVR HDR - windowed and fullscreen windowed.
Using Windows 10 API, fullscreen exclusive disabled, doesn't seem to make much difference what settings I change.
This is WITHOUT the HDR colour tab slider switched to "ON" in windows.
very strange indeed haha!
https://youtu.be/adx8KVVBH5M
heiseikiseki
22nd May 2017, 11:25
Hey Madshi,
In previous build I have to limit the buffer and set to D3D9 mode, but In madVR v0.91.10 All Optimus Problem has gone here!!
Thanks a lot!!
YT has a lot of PC content.. so it's all wrong? Why is it not fixed?
nothing wrong with PC content.
doing a proper RGB -> YCbCr conversation (to limited range 4:2:0) is not that hard and done by default by program like OSB.
@igvk
plz provide and sample and the 3D LUT i will have a closer look.
@igvk
plz provide and sample and the 3D LUT i will have a closer look.
Here you are:
https://www.mediafire.com/folder/lnusmyaz3dlv6/madVR
Video sample in mkv format and rar-compressed 3dlut for madVR.
EDIT: the clipping shader works perfectly i just had to untick "run custom video shaders in video levels instead of PC levels" and it works wonders on your 3D LUT fixing it completely. the ringing is fixed too.
shader:
sampler s0 : register(s0);
float4 main(float2 tex : TEXCOORD0) : COLOR
{
return clamp(tex2D(s0, tex), 0.0, 1.0);
}
so this is the same out of gamut handling issue i reported before. nothing else.
worthless old post:this is >not< a video range problem.
the issue should be the 3D LUT in general and but...
my 3D LUT creates similar ringing and some banding artefacts.
kind of the same as issue 424: http://bugs.madshi.net/view.php?id=424
the clipping shader doesn't help here in this case. which is strange.
the ringing is there with both 3d lut mine and yours but yours goes crazy with saturated colors. could be the render intent not sure.
so here you go: http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms-153.html
i reported the ringing issue before. but well... nothing changed.
Ver Greeneyes
22nd May 2017, 12:42
I used to have problems with highly saturated colors too. Out of curiosity, are you creating the 3DLUTs using the flags "-eT -Et"? That makes it clip invalid input values. I was using "-et -Et" before that (note the lower case "t"), which doesn't do any clipping.
oldpainlesskodi
22nd May 2017, 12:59
A quick video of what I am experiencing in MADVR HDR - windowed and fullscreen windowed.
Using Windows 10 API, fullscreen exclusive disabled, doesn't seem to make much difference what settings I change.
This is WITHOUT the HDR colour tab slider switched to "ON" in windows.
very strange indeed haha!
https://youtu.be/adx8KVVBH5M
AMD or Nvidia?
If you are using Nvidia, have you tried driver 378.92?
K
EDIT: the clipping shader works perfectly i just had to untick "run custom video shaders in video levels instead of PC levels" and it works wonders on your 3D LUT fixing it completely. the ringing is fixed too.
shader:
sampler s0 : register(s0);
float4 main(float2 tex : TEXCOORD0) : COLOR
{
return clamp(tex2D(s0, tex), 0.0, 1.0);
}
so this is the same out of gamut handling issue i reported before. nothing else.
worthless old post:
So, is it indeed the way madVR handles WtW values when using 3dlut?
And the video is really full range (but interpreted as limited)?
I used to have problems with highly saturated colors too. Out of curiosity, are you creating the 3DLUTs using the flags "-eT -Et"? That makes it clip invalid input values. I was using "-et -Et" before that (note the lower case "t"), which doesn't do any clipping.
I tried both: "-eT" and "-et", the situation didn't change.
Actually, it was GUI frontend, the options are called "Input encoding: TV RGB 16-235" with and without "(clip WTW)".
ph123uk
22nd May 2017, 13:41
AMD or Nvidia?
If you are using Nvidia, have you tried driver 378.92?
K
Nvidia for me, using the latest 382.05, haven't tried 378.92 - will it make a difference? I'm not using the colour options in the NVidia control panel, I'm using "system controlled" option.
using the windows 10 API option.
So, is it indeed the way madVR handles WtW values when using 3dlut?
And the video is really full range (but interpreted as limited)?
nope.
the 3D LUT can't handle out of gamut information properly.
out of gamut information can be easily be created by scaling (and you are "always" scaling chroma).
now you can argue if madVR should never ouput out of gamut information input a 3D LUT (there are good reasons NOT to clip out of gamut information BTW.). or you can argue the 3D LUT should properly clip them. even with WTW clip this is not the case at least the last time i tested it.
at the end nothing changed.
you can try -eT but as far as i know this doesn't fix it. atleast not the ringing.
input encoding TV range 16-235 (clip WTW) is -eT AFAIK i think maybe...
the first think you should do know is making sure that the clipping script is fixing your issue.
the first think you should do know is making sure that the clipping script is fixing your issue.
Yes, the clipping script fixes the problem.
I understand that 3D LUT cannot handle the out-of-gamut values. Perhaps, they can be extrapolated? But maybe it's more work than needed.
As for the range of the original video - I couldn't understand your answer on whether it's limited or not.
mrcorbo
22nd May 2017, 14:10
A quick video of what I am experiencing in MADVR HDR - windowed and fullscreen windowed.
Using Windows 10 API, fullscreen exclusive disabled, doesn't seem to make much difference what settings I change.
This is WITHOUT the HDR colour tab slider switched to "ON" in windows.
very strange indeed haha!
https://youtu.be/adx8KVVBH5M
So when GUI elements are being rendered, either by moving to the bottom of the window or exiting fullscreen, HDR metadata starts being passed?
Maybe I'll try rolling back to v 382.05 from the 382.19 hotfix driver and see if that fixes my fullscreen reboot issue when not in FSE. If it does, then I can see if I get the same behavior as you.
ph123uk
22nd May 2017, 14:11
Ok, by selecting
Convert HDR to SDR using pixel shader math
instead of passthrough
Seems to keep the HDR colours.
It still doesn't trigger the HDR flag on the TV but the colours certiainly look correct.
ph123uk
22nd May 2017, 14:22
So when GUI elements are being rendered, either by moving to the bottom of the window or exiting fullscreen, HDR metadata starts being passed?
Maybe I'll try rolling back to v 382.05 from the 382.19 hotfix driver and see if that fixes my fullscreen reboot issue when not in FSE. If it does, then I can see if I get the same behavior as you.
Certainly seems that way, as I just put, if you click convert hdr to sdr using pixel shader maths, instead of passthrogh it keeps the HDR colour.
I understand that 3D LUT cannot handle the out-of-gamut values. Perhaps, they can be extrapolated? But maybe it's more work than needed.
it could be clipped.
there are for sure mathematical ways to ignore 0-16 and 236-255 or they could be mapped to 16/235.
of cause i have no clue how much work that is.
[qoute]As for the range of the original video - I couldn't understand your answer on whether it's limited or not.[/QUOTE]
should be limited(a normal video). it is not worth to check it with a histogram and the issue has nothing to do with the range anyway.
should be limited(a normal video). it is not worth to check it with a histogram and the issue has nothing to do with the range anyway.
If it's limited and still produces values that are out of range 16-235, then I think the problem should be fixed.
For now, thank you very much for the shader script!
But really, I would prefer this built in - because the way it works now leads to highly oversaturated colors on wide gamut monitor.
Instead of clipping, it would be better to have information on these out of gamut values in 3dlut, or extrapolate them - if it's possible.
But not keep the original values - they are plain wrong, as far as I see.
imhh11
22nd May 2017, 15:26
A quick video of what I am experiencing in MADVR HDR - windowed and fullscreen windowed.
Using Windows 10 API, fullscreen exclusive disabled, doesn't seem to make much difference what settings I change.
This is WITHOUT the HDR colour tab slider switched to "ON" in windows.
very strange indeed haha!
https://youtu.be/adx8KVVBH5M
Thats weird, on my setup just moving the mouse to the search bar doesnt kick me out of FSE.
And I'm experiencing the exact opposite of you, but i'm setting the hdr slidder to ON... i dont know why you dont.
Windowed give me black screen
FSE give me proper playback
https://s17.postimg.org/amanj78bz/2017-05-22_10.23.04.jpg
moving my mouse to the search bar give me this
https://s12.postimg.org/u476s5qbx/2017-05-22_10.23.28.jpg
XMonarchY
22nd May 2017, 15:45
Just FYI, I could not solve my madVR Creator's Update problem with madVR no matter how I tried, even with the latest version - 23.976Hz refresh rate still produced problems. The latest LTSB version of the OS or just updated Anniversary Edition of - a whole different story (in a good way!).
Sideeffect
22nd May 2017, 17:39
@madshi
I reinstalled display drivers and MadVR and now I am getting behavour like mrcorbo.
The send HDR metadata has an effect as in showing what looks like HDR colors using Windows 10 API but it doesn't toggle HDR mode for my display.
I still need to enable HDR and advanced color in order for the display to go into HDR mode.
The send metadata does seem to work in both Nvidia or default colour settings when in windowed mode but colours become washed out when I enter FSE mode.
If default color settings and the HDR and advanced color is enabled then it works in FSE mode.
ph123uk
22nd May 2017, 17:43
Thats weird, on my setup just moving the mouse to the search bar doesnt kick me out of FSE.
And I'm experiencing the exact opposite of you, but i'm setting the hdr slidder to ON... i dont know why you dont.
Windowed give me black screen
FSE give me proper playback
https://s17.postimg.org/amanj78bz/2017-05-22_10.23.04.jpg
moving my mouse to the search bar give me this
https://s12.postimg.org/u476s5qbx/2017-05-22_10.23.28.jpg
When I click the HDR slider in windows it messes with the colour and makes it almost fluorescent, it does indeed play correctly as you state, but I don't want to have to go and click the slider everytime I want to watch a HDR movie and turn it off when it's finished.
Using the "convert hdr to sdr using pixel math" works flawlessly for me now, it is however not triggering the HDR "mode" on my TV, but the colours are spot on the same as when I plug an external hdd into my TV and play from there.
Will do for now :)
imhh11
22nd May 2017, 18:15
When I click the HDR slider in windows it messes with the colour and makes it almost fluorescent, it does indeed play correctly as you state, but I don't want to have to go and click the slider everytime I want to watch a HDR movie and turn it off when it's finished.
Using the "convert hdr to sdr using pixel math" works flawlessly for me now, it is however not triggering the HDR "mode" on my TV, but the colours are spot on the same as when I plug an external hdd into my TV and play from there.
Will do for now :)
for me there is black crush using '' convert hdr to sdr using pixel math ''.
picture look a lot better on real hdr passthrough even if i have to manually activate the OS slider.
mitchmalibu
22nd May 2017, 20:57
@madshi
Here are my findings. Interesting thing : the HDR switching behaviour differs if I use a 32 or 64bit player using the Nvidia API (still using reclock ...).
Setup :
LG 2016 OLED
GTX 1070
Nvidia drivers : 382.05
MPC-BE : 1.5.1 (build 2548) (32 and 64bit)
LAV Filters : 0.69
madVR : 0.91.10
The OK / KO results reflects the state of the ouput in fullscreen mode.
32 bit mpc
Nvidia HDR API fullscreen exclusive d3d9 : KO (switch out from hdr when I go fullscreen)
Nvidia HDR API fullscreen exclusive d3d11 : KO (switch out from hdr when I go fullscreen)
Nvidia HDR API windowed d3d9 : OK (TV switches to HDR, output looks ok)
Nvidia HDR API windowed d3d11 : OK (TV switches to HDR, output looks ok)
Windows 10 HDR API fullscreen exclusive d3d11 : OK but have to manually switch to HDR in the display settings
Windows 10 HDR API windowed d3d11 : KO (black screen when I switch to fullscreen)
64 bit mpc
Nvidia HDR API fullscreen exclusive d3d9 : KO (TV never switches to HDR)
Nvidia HDR API fullscreen exclusive d3d11 : KO (TV never switches to HDR)
Nvidia HDR API windowed d3d9 : KO (TV never switches to HDR)
Nvidia HDR API windowed d3d11 : KO (TV never switches to HDR)
Windows 10 HDR API fullscreen exclusive d3d11 : OK but have to manually switch to HDR in the display settings
Windows 10 HDR API windowed d3d11 : KO (black screen when I switch to fullscreen)
Hope this helps !
@imhh11
I see that you're using the Sony 4K HDR demo. Any luck decoding those efficiently on your system ? Mine struggles and can't keep up with the framerate (GPU and CPU decoding alike).
mrcorbo
23rd May 2017, 01:47
So when GUI elements are being rendered, either by moving to the bottom of the window or exiting fullscreen, HDR metadata starts being passed?
Maybe I'll try rolling back to v 382.05 from the 382.19 hotfix driver and see if that fixes my fullscreen reboot issue when not in FSE. If it does, then I can see if I get the same behavior as you.
Still crashes on 382.05. And for me, choosing system-managed vs. Nvidia color settings has no effect on FSE being able to put or keep my TV in HDR mode or on HDR metadata being transferred in FSE mode.
mrcorbo
23rd May 2017, 01:55
Thats weird, on my setup just moving the mouse to the search bar doesnt kick me out of FSE.
ph123uk has FSE disabled, so is never in FSE mode during any part of that video. Didn't say if they're using windowed overlay or not.
GTX 1060 via nvidia api hdr passthrough work on .9. I just open up hdr video(windowed player) and tv go into hdr mode. didnt test windows 10 api.
Samsung TV set up for 444RGB to work as monitor daily.
I believe the creator update was not installed.
Can someone help me set this up please...
I have all my ripped BDs set to play back at 4K upscaling via JR and madvr using the 1080Ti card.
As I have only a handful of BDs that are 50Hz and DVDs that are 50 and 60, when they switch across at 4K they drop frames etc etc...
As most of my 900 ripped BDs are 23.97 I have my settings fairy high on madvr since I have the 1080Ti card...
Can I make just the ripped DVDs and BDs that are 50Hz just playback in 1080P rather than 4K so the madvr settings can remain high?
Many thanks...
ph123uk
23rd May 2017, 10:59
ph123uk has FSE disabled, so is never in FSE mode during any part of that video. Didn't say if they're using windowed overlay or not.
Yea, apologies, I'm NOT using windowed overlay, this is my basic renderer settings.
Have MADVR setup to switch to the native Hz at 2160p upscaling, but that's about it (and NGU AA med / High dependant on source)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.