View Full Version : madVR - high quality video renderer (GPU assisted)
dvd1
21st August 2017, 17:56
https://s30.postimg.org/yyuq4iecx/Immagine.png (https://postimg.org/image/697u7vact/)
Here there is no video jumps.Is it a good result?
https://s30.postimg.org/o33c95tf5/Immaginettt.png (https://postimg.org/image/7fbu6nynh/)
How can I fix the problem?
thank you so much
huhn
21st August 2017, 18:11
madVR is deinterlancing using DXVA so if deinterlancing is needed you need DXVA and deinterlancing is doubling the frame rate which means the GPU load is a lot higher.
by default madVR is using DXVa chroma scaler for interlanced source which is pretty cheap.
try ngu low change the downscaling algo to bicubic 60 and or get a better video card.
dvd1
21st August 2017, 18:48
So the first source is interlaced and can I also put filters in chrome upscaling?
Is the source securely interlaced and I have to lower the filter in image upscaling?
How do i create two different profiles for the 576 dvd?
huhn
21st August 2017, 19:15
you can put filters in chroma too even with interlancing but do your self a favour and leave it at DXVA.
the second image is interlanced the first not.
"all" pal DVDs should be interlaced but that doesn't mean they need to be deinterlanced. but looks like i'm wrong.
i'm pretty sure you can create rules for FPS and check if the source is interlanced but i don't know them. so you should create onefor 25 FPS and one for 50.
el Filou
21st August 2017, 20:43
I use this:if (deintFps < 26) "24-25 fps"
else if (deintFps < 31) "30 fps"
else if (deintFps < 51) "50 fps"
else "60 fps"that way madVR always evaluates the final frame rate after deinterlacing if there is any.
@dvd1 : if you get dropped frames, try something lower than NGU for luma, like Jinc or Lanczos 4 tap. It's still better quality than basic DXVA scaling.
You can also combine deintFps with srcWidth and srcHeight in your rules if you play material of varying definition.
RenderGuy2
21st August 2017, 20:54
The timings optimization feature is really great! I am getting much better results using this feature than I was before by manually adjusting. Sorry if this has been asked before: Would it be possible for MadVR to optimize the timings for 3D mode as well? Mine is off (23.971) and I can't seem to find a way to optimize through MadVR or even adjust it manually in the GPU control panel.
Thanks
pankov
21st August 2017, 21:09
Good question! Will have to add this to my to-do list. I suppose subtitles should probably never be brighter than 100 nits. So maybe I need to post process the subtitles to enforce them to not be too bright... :(
madshi,
when you reach to this task in your to-do list please consider also limiting madVR's OSD also to 100 nits and it will be great if you can make the elements of the player's UI drawn via madVR's API look SDR unless the player explicitly asks for HDR UI ... which I don't even think there is a way to do now ... because right now the UI elements look oversaturated and too bright.
Talking about UI elements I'm wondering if the player can instruct madVR to turn off HDR (if it's quick enough) while it draws it's standard UI (popup menu or other UI elements not drawn via the API but rather as standard windows ... as Zoom Player does with it's navigation interfaces like the media library one) and restore it back on after the navigation interface is closed and the movie is back on top.
dvd1
21st August 2017, 21:10
It is better to do it the other way around (easier to think through):
If (srcWidth <= 1024) AND (srcHeight <= 576) "SD-DVD"
Else If (srcWidth <= 1280) AND (srcHeight <= 720) "720p"
Else If (srcWidth <= 1920) AND (srcHeight <= 1088) "1080p"
Else "Fast"
You might also make a "fast" profile for the else statement, for everything above 1920x1088, but if you never watch anything UHD then it is not important. Without an else statement, and not matching an if statement, madVR picks the first profile ("1080p" in your case).
These are the profiles I'm using now
I'm not able to add more.
@ Asmodian and @ Filou
help my
thank you very much
aufkrawall
21st August 2017, 21:48
Colors are wrong for HEVC with native DXVA2 decoding + DXVA2 downscaling:
https://abload.de/thumb/13cshu.png (http://abload.de/image.php?img=13cshu.png)
Happens only with HEVC (probably because of P010 surface?). Turning off either DXVA2 decoding or DXVA2 downscaling both help.
Edit: Happens only with HEVC 10 bit, to be more specific.
D3D11VA scaling could really get interesting for weak GPUs.
The last time I checked DXVA2 scaling on Nvidia, it looked like bicubic. If it would be cheaper than bicubic via shaders and won't have the DXVA2 drawbacks, at least it'd be much more interesting.
egandt
22nd August 2017, 00:32
First off I have a 7700K at 4.8GHZ, 32GB Ram and a 1080TI (OC'ed to do 14TFLOPS). I have the latest Nvidia 382 drivers (8/13)
I have MadVR 0.92.1 and LAV 0.70.2.35-git Using CUVID for decompression (and everything select except for mpeg4), attached.
In madVR I have a profile using Jinc for all image processing (so as light weight, as is reasonable).
I have an Integral in-line so I can actually monitor the HDMI for HDR headers, (which is very nice, I can also force HDR if needed, such as for calibrating the TV a Samsung K8000).
First issue:
So everything should handle HDR, but first and foremost madVR never see's any HDR data from LAV, and hence will not use the HDR profile I have setup for the montior, and second that obviously means there is no HDR header passed through to the TV. Now it does read the Rec.2020 color space, but not HDR10 headers.
I've tested the Sony 4K HDR Camp, LG's Chess and Samsung's Q.Dot Demo in HDR all play back as SDR.
Now I'd like to provide a screenshot of what the madVR displays when rendering, but Zoomplayer does not like to take them of any of these sources, as I get an erro message "can not take screen shot of this format", or if it does it does not include madVR stats.
Second:
4K 60FPS is unplayable it skips frames avg render times are over 22.3ms but in 30 seconds I have 486 dropped and 150 repeated frames, not in now in 30 seconds I should have had 1800 frames so that means about 35% of all frames are either dropped or repeated. Again with the specs above I do not see how this can be the case and it is driving me crazy.
GPU-Z shows that which the Video card is running full out (2Hgz) and it is only 50% utilized, so it is not as if there is not processing power to spare, I do not see why rendering times are 22+ms (which explains some of the the dropped frames as that only would all 45 frames a second max to be displayed).
The problem:
So basically I can not get either HDR nor, 60FPS playback to work with MadVR and LAV, yet I have processing power to spare, it is just unused, if the system above can not handle 4K HDR 60FPS what ever could?
I've upgraded the entire PC over the last 6 months and still can not play back 60FPS/HDR at all, in fact I've made no progress with HDR or 4k60, in months and have hit a wall, as it makes no sense, so it is something I'm doing wrong, my question is what and how to fix it, without breaking 1080P playback as obviously that is used 99% of the time.
Thanks,
ERIC
nevcairiel
22nd August 2017, 00:37
Using CUVID for decompression
Don't use CUVID, ever, for anything anymore. It doesn't export the HDR metadata. Use software, DXVA2 or the new D3D11 mode.
Also while we're at things not to use, don't use the Sony Camp HDR demo, its broken.
egandt
22nd August 2017, 00:59
Don't use CUVID, ever, for anything anymore. It doesn't export the HDR metadata. Use software, DXVA2 or the new D3D11 mode.
Also while we're at things not to use, don't use the Sony Camp HDR demo, its broken.
Thanks, that fixed the issue, moved to D3D11.
Also good to know not to use the Sony Demo.
Manni
22nd August 2017, 01:10
A quick update:
- I don't know if it's installing the latest LAV nightly, but like others I can now play 3D in windowed mode. So bye bye FSE! :)
- I also tested the automatic switch to HDR/SDR in windowed mode, and it works fine with 385.28 here.
- HDR Metadata is passed-through, except the part related to the mastering display primaries and white point, which doesn't seem to ever make it out of the GPU. Please can you check it is included in the metadata when MadVR is set to pass-through? All the other metadata is present and correct.
oddball
22nd August 2017, 09:10
On the latest MadVR HDR is still not working correctly on my setup. If I leave HDR disabled in Win10 display properties I get no HDR logo appear on my LG OLED55B6. If I enable it HDR is *ALWAYS* set to HDR on my TV (Not desirable for SDR viewing). Plus I have to disable FSE and click on the MadVR system tray icon to get it to send correct HDR metada. Otherwise it just looks washed out.
sauma144
22nd August 2017, 15:38
@madshi
- Are you going to add a D3D11VA upscaler?
- Are you going to add a way to import/export/re-apply custom resolutions?
huhn
22nd August 2017, 15:53
what is a d3d11 upscaler?
clsid
22nd August 2017, 16:09
I think he means DXVA2 scaling.
XMonarchY
22nd August 2017, 20:00
Wow and another huge thanks to mashi! The 92.xx madVR's custom display feature is awesome! I haven't even done the "Optimize" part and my playback audio/video desync % is super-epic-level-low already! That means no more ReClock and no more MPC-HC x86! Now everything in my playback chain is x64 and D3D11 after LAV Filter's latest nightly update!
imhh11
22nd August 2017, 20:16
Should i keep using DXVA2 copy back or the new D3D11 is better? I have a high-end PC. (7700k + gtx1070)
chros
22nd August 2017, 20:19
madshi, what about adding 47p and 48p modes to the custom modes util? Lot of monitors can't handle 23/24/25p, but they might do 47/48/50p (like my ancient Samsung 24" does).
Thanks for all your effort!
PS: and yes, I tried out on my optimus (see my signature), with this intel chipset I can't do anything now :)
aufkrawall
22nd August 2017, 20:46
Funny: The banding issues with DXVA2 native decoding are entirely gone now, even for HEVC 10 bit HDR Rec.2020 content.
"Just" the chroma blur remains, however it's not there with DXVA2 chroma scaling.
So, it may be actually not too bad for slow GPUs, until we have D3D11VA scaling and deinterlacing.
Klaus1189
22nd August 2017, 21:10
devices>identification>dynamic metadata <- What is that?
JarrettH
22nd August 2017, 21:18
madshi, what about adding 47p and 48p modes to the custom modes util? Lot of monitors can't handle 23/24/25p, but they might do 47/48/50p (like my ancient Samsung 24" does).
Thanks for all your effort!
PS: and yes, I tried out on my optimus (see my signature), with this intel chipset I can't do anything now :)
I think you can add 50 hz yourself, but what it won't allow is a decimal place.
@madshi: Do I need to add 72 hz and experiment from there to reach 71.928?
dvd1
22nd August 2017, 21:21
I use this:if (deintFps < 26) "24-25 fps"
else if (deintFps < 31) "30 fps"
else if (deintFps < 51) "50 fps"
else "60 fps"that way madVR always evaluates the final frame rate after deinterlacing if there is any.
@dvd1 : if you get dropped frames, try something lower than NGU for luma, like Jinc or Lanczos 4 tap. It's still better quality than basic DXVA scaling.
You can also combine deintFps with srcWidth and srcHeight in your rules if you play material of varying definition.
These are the profiles I'm using now
I'm not able to add more.
@ Asmodian and @ Filou
help my
thank you very much
Help me to create complete profiles and rules
thank you
aufkrawall
22nd August 2017, 23:08
madVR shows corruption with D3D11VA + SDR conversion (default setting) of Sony HDR Camp video:
https://abload.de/thumb/hdrx5s39.png (http://abload.de/image.php?img=hdrx5s39.png)
https://mega.nz/#!0VMWhRoD!6hR2-lRoYKqO1Dpf7ylHNna6z1MIuNO4ByySxUIp-E4
Copyback works.
nevcairiel
22nd August 2017, 23:09
The Sony sample is broken. Its HDR metadata says "1 nit", which is clearly wrong, as you can see in the OSD (yes, that value is stored in the file like that).
*Please* stop using it.
madVR has a hack to ignore the metadata of that sample (its the only one I have ever seen with that "issue"), but the hack doesn't work with D3D11. madshi will likely fix the "hack", but still, stop using that broken thing! :)
aufkrawall
22nd August 2017, 23:37
Alright, sorry. :o
I've just given it a try since I am looking for a sample with realistic colors, which doesn't seem to be found so easily between all that PR material with LSD amplified colors.
mbordas
23rd August 2017, 04:42
Will it be possible ever to adjust the visible and total pixels separately? The Nvidia Control Panel lets you do this when you create a custom resolution and set the timings manually.
The reason I ask is because I've always had an issue with a strange distorted line at the bottom of my screen and I always worked around it by setting the active pixels in the Nvidia Control to one pixel greater (ie 1081 instead of 1080). It's the only thing preventing me from switching fully to use the new madVR custom modes. I can't get rid of that annoying line :)
I tried adding a custom mode of 1920x1081, but that doesn't work. I get an error that says "The GPU driver rejected this mode for unknown reasons", even though I copied the front/back porch and sync settings exactly.
I also noticed the Nvidia Control Panel allows four decimal places for the refresh rate (aka pixel clock) while madVR uses only two. Rounding up seems to work fine, but I wondered if this might change at some point?
cork_OS
23rd August 2017, 07:53
@madshi: Do I need to add 72 hz and experiment from there to reach 71.928?
I've already tried, you need to set 71 hz to get 71.928.
chros
23rd August 2017, 08:52
I think you can add 50 hz yourself, but what it won't allow is a decimal place.
@madshi: Do I need to add 72 hz and experiment from there to reach 71.928?
Oh, I see, thanks.
I quickly tried out to "add" 71/47 modes to my monitor (not the TV):
- they won't show up in OS at all
I tried to modify 59Hz (it's available by default), madVR says that 60Hz is modded, but when I switch to it (or 59p) OSD reports the original timings.
So, conclusion (as madshi stated in the tutorial): it's not usable at all with this "ancient" hardware/driver and the sh***y optimus :)
70MM
23rd August 2017, 09:52
Can someone help me please...
Tonight my Windows 10 crashed or died on me.
I tried to change the 1080Ti card from 8bit to 12bit and thats how it happened.
A recovery page popped up for windows, stating did I want to re start or do the recovery bit...
Or call someone I trust to help...
I clicked restart, the Asus page started to load then the screen went black again.
What do I do, just leave it on overnight and wait, is it in a recovery mode or something?
nevcairiel
23rd August 2017, 10:01
This isn't general PC help, sorry.
FDisk80
23rd August 2017, 10:11
Can someone help me please...
?
Ask here
https://forums.geforce.com/default/board/33/geforce-drivers/
Or here
https://forums.geforce.com/default/board/172/geforce-1000-series/
madshi
23rd August 2017, 10:36
I already have a near perfect rate for 99% of my content, so don't spend any time on this if you have better things to do. I'm happy to help, but the EDID timings are good enough for me from a practical point of view. I can live with 1-2 frame drops per film (in 2D). :)
Ok, then let's leave it at that for now.
I'm not sure this is correct. When I tested the direct connection to the JVC earlier, I'm almost 100% sure that when I added the 4K23 custom mode, it appeared with data available. It shouldn't be the case as technically it was a different display (AVR vs JVC). In any case, when we delete the custom mode, it might be a good idea to also delete the corresponding recorded data, to make sure we can start afresh if we decide to re-create the mode, without having to do a clean install of the drivers.
I'm storing the measurements under the "ID" of the monitor/identification. So it should be specific to the display. Right now from the top of my head I don't recall if I tied it to the display device or to the identification card, though. But anyway, you're right that when deleting a custom mode, it would make sense to also delete the measurement data.
2) The EDID values do not work for 1080p23 (the refresh is weird, some kind of double picture as if two different refresh rates were applied simultaneously, I know it's not possible, only trying to describe the effect). In that case, it's difficult to run the optimization.
Strange. It should be official EDID values, just maybe an ever so slightly modified pixel clock. I don't think the pixel clock digital value is actually transferred to the display, it's just how the pixel clock is driven. So this is confusing to me.
3) I already asked but don't think I've seen a reply. I don't think the 1080p23 mode would be applied for 1080p23FP. Is there a way to optimize that mode?
Unfortunately neither Nvidia, nor AMD nor Intel support custom resolutions specific to 3D... :( I'm not sure right now whether this is something that could be done through an EDID override. But I have my doubts whether that would be possible, either. Not 100% sure right now, though.
Of course you could always contact Nvidia customer support and ask for custom modes to also effect 3D, or for the ability to create separate custom modes for 3D.
Thanks for such an amazing update. I got good results with Custom Resolution: 1 frame drop every 1.18 days for a 59p custom mode on a 60Hz monitor.
Good to hear!
1. madHcCtrl.exe stops responding when I change the refresh rate through display adapter properties in OS control panel and come back to access madVR settings.
Does this happen every time? Does it happen only if you're on the display modes or custom modes tab, or only if you're not on either of those 2 tabs, or regardless of which tabs you're on?
2. madVR measurements for timings optimization do not happen if video is played in JRiver Media Center. In MPC-HC, it works perfectly.
Did you update the madVR version used in JRiver MC?
3. How do I create a custom mode for resolutions like 48Hz or 72Hz? Do I have to find some standard timings to begin with on the net first?
Just give it a try. The GUI will guide you through it.
10 bit output in fullscreen windowed mode is really cool and works perfectly, however on my system with AMD card, FSE is more stable.
In which way is it more stable? You've not installed Creator's Update yet?
Let say we did optimization, but still don't have exact rate (and have drop/repeat in one or two hours). But instead of exact dropping/repeating can we do some kind of SmoothMotion (blending) but not always - only in(near) the point where repeat/drop actually will take place without this blending?
I'm not sure how near frame blending would have to be done, it might require dozens of frames to be blended to be totally invisible. I think a better idea might be to try to detect two frames where motion is minimal and then drop one of those. But this is relatively hard to implement. So not planned any time soon.
I can use Monitor Asset Manager and it shows the edid for the monitor so I guess it does send it.
Interesting. Can you please double check the following:
madVR tries to get the EDID from the registry. The path is retrieved like this:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\DISPLAY\xxxxx\Device Parameters\EDID
The "xxxxx" is coming from the string that the madVR settings dialog shows for your monitor as the "Windows device path". It starts with "\\?\DISPLAY". I think on your PC it should be:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\DISPLAY\Default_Monitor\5&6dedc66&0&UID2097424\Device Parameters\EDID
Does this registry path exist and is there an "EDID" entry there?
when I do virtual crop in mkvtoolnix madshi render playing it in wrong way. Iam using potplayer. All other renderers like opengl, build in direct 3d 11 videorenderer etc. shows it propertly. It is in form of left, up, right, down. So f.e. if I use 0,140,0,140 then picture in Madshi renderer looks, that up crop is ignored and down crop is 2x140. So up crop and down crop is added to down side of picture. Similary to if I do in mkvtoolnix 0,0,280,0.
Sorry again if that was discussed earlier or if I did something wrong.
I even dont know if problem is related to madshi renderer or potplayer itself. But it seems to me that it is renderer issue.
Bernix
Edit:it seems that up croping is added instead of substracted or other way round.
Can you please upload a small MKV sample?
The timings optimization feature is really great! I am getting much better results using this feature than I was before by manually adjusting.
:)
Sorry if this has been asked before: Would it be possible for MadVR to optimize the timings for 3D mode as well?
See my reply to Manni earlier.
Talking about UI elements I'm wondering if the player can instruct madVR to turn off HDR (if it's quick enough) while it draws it's standard UI (popup menu or other UI elements not drawn via the API but rather as standard windows ... as Zoom Player does with it's navigation interfaces like the media library one) and restore it back on after the navigation interface is closed and the movie is back on top.
In theory it would be possible, but I'm not sure if it makes sense. I'll double check when I get around to it.
Colors are wrong for HEVC with native DXVA2 decoding + DXVA2 downscaling:
https://abload.de/thumb/13cshu.png (http://abload.de/image.php?img=13cshu.png)
Happens only with HEVC (probably because of P010 surface?). Turning off either DXVA2 decoding or DXVA2 downscaling both help.
Edit: Happens only with HEVC 10 bit, to be more specific.
Which GPU?
- I don't know if it's installing the latest LAV nightly, but like others I can now play 3D in windowed mode. So bye bye FSE! :)
- I also tested the automatic switch to HDR/SDR in windowed mode, and it works fine with 385.28 here.
- HDR Metadata is passed-through, except the part related to the mastering display primaries and white point, which doesn't seem to ever make it out of the GPU. Please can you check it is included in the metadata when MadVR is set to pass-through? All the other metadata is present and correct.
Good to hear on 3D and HDR/SDR switch.
I'm feeding the HDR gamut data to the Nvidia HDR API. You say it isn't passed through to the display? What metadata does the HTPC send out instead? This is something I can report to Nvidia, if it's 100% reliable information.
Can you double check both HDR methods:
1) "HDR and Advanced Color" turned on. This way I'm reporting the mastering display primaries to D3D11, which then has the duty to report it to the display. This might only work in non-exclusive fullscreen mode, though.
2) "HDR and Advanced Color" turned off, using Nvidia's direct HDR switching instead.
Would be good to know which mastering display gamut the HTPC sends out in both cases. Ideally it would be great if you could test with different HDR demo files with different gamuts, so we can see if the HTPC mastering display gamut metadata output changes at all when using different video files, or not.
On the latest MadVR HDR is still not working correctly on my setup. If I leave HDR disabled in Win10 display properties I get no HDR logo appear on my LG OLED55B6. If I enable it HDR is *ALWAYS* set to HDR on my TV (Not desirable for SDR viewing). Plus I have to disable FSE and click on the MadVR system tray icon to get it to send correct HDR metada. Otherwise it just looks washed out.
Which GPU?
- Are you going to add a D3D11VA upscaler?
See v0.92.0 release notes.
- Are you going to add a way to import/export/re-apply custom resolutions?
I've thought about it. Maybe.
Wow and another huge thanks to mashi! The 92.xx madVR's custom display feature is awesome! I haven't even done the "Optimize" part and my playback audio/video desync % is super-epic-level-low already! That means no more ReClock and no more MPC-HC x86! Now everything in my playback chain is x64 and D3D11 after LAV Filter's latest nightly update!
:)
Should i keep using DXVA2 copy back or the new D3D11 is better? I have a high-end PC. (7700k + gtx1070)
Both have advantages and disadvantages. D3D11 is faster, but doesn't support DXVA deinterlacing + DXVA scaling atm, and it doesn't work with forced film mode and "zoom control" settings. If your PC is fast enough for DXVA2 copyback, there's no need to switch.
madshi, what about adding 47p and 48p modes to the custom modes util?
You can already do that yourself. Just click on the "Add" button while no mode is active and you can add custom modes with any refresh rate you like.
Funny: The banding issues with DXVA2 native decoding are entirely gone now, even for HEVC 10 bit HDR Rec.2020 content.
I think I did a change recently for handling native 10bit DXVA2 decoding which might explain this.
devices>identification>dynamic metadata <- What is that?
The home theater and consumer electronics companies are working on adding dynamic metadata support to UHD Blu-Ray. It's not there yet, but might come soon. It requires HDMI 2.1. madVR can already detect if your display supports it.
@madshi: Do I need to add 72 hz and experiment from there to reach 71.928?
You can directly add 71, if that's what you want.
Will it be possible ever to adjust the visible and total pixels separately? The Nvidia Control Panel lets you do this when you create a custom resolution and set the timings manually.
The reason I ask is because I've always had an issue with a strange distorted line at the bottom of my screen and I always worked around it by setting the active pixels in the Nvidia Control to one pixel greater (ie 1081 instead of 1080). It's the only thing preventing me from switching fully to use the new madVR custom modes. I can't get rid of that annoying line :)
I tried adding a custom mode of 1920x1081, but that doesn't work. I get an error that says "The GPU driver rejected this mode for unknown reasons", even though I copied the front/back porch and sync settings exactly.
I would have to change quite a noticable amount of code to make that work. I did not anticipate the need for ever using an "active" pixels number that is different from the real screen resolution. Of course it would be possible to add, but considering the amount of time it would cost me, atm I think it's unlikely, unfortunately... :( Of course you could try to use the madVR optimization procedure to find an ideal mode, and then delete it again and recreate it with the Nvidia control panel, increasing the active pixels by 1, and keeping total the same, or something like that.
I also noticed the Nvidia Control Panel allows four decimal places for the refresh rate (aka pixel clock) while madVR uses only two. Rounding up seems to work fine, but I wondered if this might change at some point?
Refresh rate and pixel clock are 2 different things. The GPU control panel does show 4 digits for the pixel clock, but I can tell you that the Nvidia API that is used by both madVR *and* the Nvidia custom resolution control panel works with a 10kHz pixel clock. So only 2 digits are supported by the API. Which means the Nvidia custom resolution control panel must be rounding it to 10kHz, too.
I quickly tried out to "add" 71/47 modes to my monitor (not the TV):
- they won't show up in OS at all
After thinking about it, I think I know why:
In an Optimus system, we have 2 GPUs. But you only have one DVI/HDMI output port, right? I believe this port is always driven by the same GPU, which is very likely the Intel GPU. Basically this means that you need to create the custom resolutions for the Intel GPU, not for the Nvidia. So while you want madVR to talk to the Nvidia GPU for fastest rendering speed, you actually want the settings dialog (madHcCtrl.exe) to talk to the Intel GPU !!!
I don't have an Optimus system, so I don't know how to configure which GPU is used for which process, but maybe you know how to make madHcCtrl.exe use the Intel GPU instead of the Nvidia GPU? If you can do that, probably custom modes will start working for you. However, you'll run into the Intel custom mode limitations I mentioned in the tutorial.
What do I do, just leave it on overnight and wait, is it in a recovery mode or something?
You may have to boot into safe mode. See google.
70MM
23rd August 2017, 11:33
Thanks very much madshi, the reboot in safe mode fixed my windows 10 problem. Back to my amazing madvr image!
Bernix
23rd August 2017, 12:27
Madshi,
thank you for your interest. I have latest 0.92.1 version. Settings is default. I am using Potplayer also latest. But it was same in older.
Here are 2 videos in HEVC because of limitation of 200kb but everything was done in x264. Then I compressed it in crf 38 hevc.
I croped it virtualy in mkvtoolnix. 720x576 video from top I take 64 and from bottom 64 pixels too.
The before and after words are on absolute top of original (not croped video) because I tried something with this video in avisynth. So the Videokazeta_normal_.mkv is properly croped. And the other madshi is wrongly.
Thank you again for your interest.
Bernix
Edit I added video Video_virtualy_croped.7z which is agresively croped. You can notice that tail of the dog shouldnt be seen whole video. At my side in madshi almost whole duration in normal almost not.
Bernix
Manni
23rd August 2017, 13:37
Strange. It should be official EDID values, just maybe an ever so slightly modified pixel clock. I don't think the pixel clock digital value is actually transferred to the display, it's just how the pixel clock is driven. So this is confusing to me.
This is confusing to me too. What's even more confusing is why nVidia doesn't use the EDID values to start with (i.e. why I get a substantial improvement in 4K23p simply selecting the EDID values). On the other hand, if it used the EDID values for 1080p23, then the display wouldn't work, so it can clearly be better or worse to use the EDID values vs what nVidia is deciding upon for each mode by default. Let me know if there is any test you'd like me to do, otherwise I'm happy to let go as I only use 1080p23 for 3D (FP), not for 2D as I upscaled all my HD content with madVR to 4K.
Unfortunately neither Nvidia, nor AMD nor Intel support custom resolutions specific to 3D... :( I'm not sure right now whether this is something that could be done through an EDID override. But I have my doubts whether that would be possible, either. Not 100% sure right now, though.
Of course you could always contact Nvidia customer support and ask for custom modes to also effect 3D, or for the ability to create separate custom modes for 3D.
I will get in touch with nVidia support and see if it's better than AMD (never heard back or saw any improvement from my feedback to AMD).
I'm feeding the HDR gamut data to the Nvidia HDR API. You say it isn't passed through to the display? What metadata does the HTPC send out instead? This is something I can report to Nvidia, if it's 100% reliable information.
Can you double check both HDR methods:
1) "HDR and Advanced Color" turned on. This way I'm reporting the mastering display primaries to D3D11, which then has the duty to report it to the display. This might only work in non-exclusive fullscreen mode, though.
2) "HDR and Advanced Color" turned off, using Nvidia's direct HDR switching instead.
Would be good to know which mastering display gamut the HTPC sends out in both cases. Ideally it would be great if you could test with different HDR demo files with different gamuts, so we can see if the HTPC mastering display gamut metadata output changes at all when using different video files, or not.
First the data is 100% reliable. I'm working closely with HD Fury to implement this feature in the Vertex and I've asked them to extend the HDR metadata decoded to include the mastering display primaries and white point. I have double checked the data from the Vertex OSD with the hex data in the HDR header in the source, it's 100% correct. I have even asked them to specify if the metadata is from the source (rx) or what comes out of the vertex (tx) in case it's disabled or if new data is injected. So I know exactly what comes in the Vertex and comes out with the new f/w I've installed today. I have checked it with UHD Bluray titles with known metadata (decoded from the HDR Metadata Header in these titles) so I have no doubt about what the Vertex reports. I have the Vertex set to report the incoming HDR metadata (rx), so what I report below is what's sent by the GPU, not what gets out of the Vertex.
Now regarding the tests you've asked me to perform, they gave interesting results. I had never used the OS HDR On so I tested that, and the metadata sent is 100% wrong all the time. It seems to be fixed to ST2084 1000/0.030 maxCLL 1000 MaxFALL 20. It's the same metadata displayed whatever the content played, so clearly incorrect.
I switched back to my usual mode (OS HDR Off) and played a few test files with MadVR. I don't use FSE for anything now so all these tests were in windowed full screen as requested.
Of course we can't yet compare a UHD Bluray read in the UB900 and the same title read on the PC, but I tried to get as close as possible whith whatever legit content is available. Feel free to provide other samples if you're not satisfied with the ones I've chosen. The display primaries/white point info is never sent by MadVR, so it's not related to the file itself.
I used the Exodus trailer (there is no HDR metadata on the UHD Bluray of Life of PI so I ruled that one out), a test file called Neo Fire and the brightness pattern (MP4) from the Ryan Masciola HDR calibration set.
When read with my UB900 (from USB), I get the full and correct HDR Metadata for the files:
Exodus: ST2084 max 1200/ min 0.020 MaxCLL 0 MaxFALL 0 mastering display primaries DCI-P3 mastering display white point D65
Neo Fire: ST2084 max 1100/ min 0 MaxCLL 0 MaxFALL 0 mastering display primaries DCI-P3 mastering display white point D65
RM Bright: ST2084 max 1000/ min 0.005 MaxCLL 1000 MaxFALL 400 mastering display primaries DCI-P3 mastering display white point D65
[For reference, the metadata on the actual UHD Bluray of Exodus played on the UB900 is:
Exodus: ST2084 max 1100/ min 0 MaxCLL 0 MaxFALL 0 mastering display primaries DCI-P3 mastering display white point D65, so not too far away from what they released on the trailer file. This is my UK version, it might be different on the US version as is sometimes the case.]
With MadVR, as reported, I never get ANY metadata for the mastering display primaries and white point. The rest of the metadata, as reported, is correct except for the MaxCLL and MaxFALL which seem to always report Max Brightness. So for example, with Exodus, I get:
Exodus: ST2084 max 1200/ min 0.020 MaxCLL 1200 MaxFALL 1200 mastering display primaries nothing mastering display white point nothing
It could be a bug only when there is no MaxFall/CLL, but the RM Bright file has these specified in the metadata and I get with MadVR:
RM Bright: ST2084 max 1000/ min 0 MaxCLL 1000 MaxFALL 1000 mastering display primaries nothing mastering display white point nothing
which is not what's in the source in both cases.
It would be great if MadVR OSD could report what the Vertex reports, i.e. all the HDR metadata it reads from the source.
That way we'll be able to see if what MadVR reads is what's sent out of the GPU, which might help to trace the root of the discrepancy.
[EDIT: corrected a few typos especially in the last metadata line, it said Neo Fire instead of RM Bright and had the wrong max brightness. All should be correct now]
aufkrawall
23rd August 2017, 14:16
Which GPU?
GTX 1070 on Windows 10 Creators Update.
However, I also managed to reproduce it with a 1080p video without luma scaling and just DXVA chroma scaling (with the "use DXVA chroma upscaling when doing native DXVA decoding" checkbox).
dvd1
23rd August 2017, 14:59
If (srcWidth <= 1024) AND (srcHeight <= 576) (deintFps <26) "25 fps" DVD 25 fps
else if (srcWidth <= 1024) AND (srcHeight <= 576) (deintFps <51)"50fps" DVD 50 fps
Else If (srcWidth <= 1280) AND (srcHeight <= 720) "720p"
Else If (srcWidth <= 1920) AND (srcHeight <= 1088) "1080p"
Else "Fast"
I did well ?
madshi
23rd August 2017, 14:59
thank you for your interest. I have latest 0.92.1 version. Settings is default. I am using Potplayer also latest. But it was same in older.
Here are 2 videos in HEVC because of limitation of 200kb but everything was done in x264. Then I compressed it in crf 38 hevc.
I croped it virtualy in mkvtoolnix. 720x576 video from top I take 64 and from bottom 64 pixels too.
Attachments to this forum don't take ages to get approved. Can you please upload them somewhere else and link here?
I had never used the OS HDR On so I tested that, and the metadata sent is 100% wrong all the time. It seems to be fixed to ST2084 1000/0.030 maxCLL 1000 MaxFALL 20. It's the same metadata displayed whatever the content played, so clearly incorrect.
Good to know, I'll report this to Microsoft. And this was in fullscreen windowed mode, with no taskbar visible etc, correct?
I switched back to my usual mode (OS HDR Off) and played a few test files with MadVR. I don't use FSE for anything now so all these tests were in windowed full screen as requested.
FWIW, windowed fullscreen is important for the OS HDR, but not for Nvidia. For Nvidia, anything should go.
The display primaries/white point info is never sent by MadVR, so it's not related to the file itself.
Oh, I see. I had thought it would send wrong data, but now I understand it sends no data at all! I didn't even know that it was possible to send no gamut data.
The rest of the metadata, as reported, is correct except for the MaxCLL and MaxFALL which seem to always report Max Brightness.
MaxCLL and MaxFALL are not properly implemented in madVR yet, that's still on my to do list.
Manni
23rd August 2017, 15:10
Good to know, I'll report this to Microsoft. And this was in fullscreen windowed mode, with no taskbar visible etc, correct?
Yes, I had edited my post to clarify that but you might have read the uncorrected version. I only use MadVR full screen, so nothing visible at all apart from video.
FWIW, windowed fullscreen is important for the OS HDR, but not for Nvidia. For Nvidia, anything should go.
Thanks, I just prefer the windowed fullscreen because FSE gives me a few seconds of black screen at start and every time I need the player interface, for example when choosing audio/subtitle tracks. As it doesn't give me any performance/stability over windowed fullscreen, I'm very glad not to have to use it anymore.
Oh, I see. I had thought it would send wrong data, but now I understand it sends no data at all! I didn't even know that it was possible to send no gamut data.
Yep. No mastering display gamut, no mastering display white point data is sent, irrespective of the file played. Of course the gamut primaries of the content are always BT2020 (I mean, with consumer content), so that doesn't prevent the file from being played correctly (at least here because I force my custom BT2020/ST2084 calibration anyway, the JVC HDR mode being not optimal). Not sure what happens if a display relies on the metadata to select the relevant calibration.
MaxCLL and MaxFALL are not properly implemented in madVR yet, that's still on my to do list.
Good to know, that makes sense.
madshi
23rd August 2017, 15:18
Just to clarify, before I send the email to Microsoft: With the "HDR and Advanced Color" switch turned on, there's also no gamut/white point data sent at all, correct?
Bernix
23rd August 2017, 15:42
Here they are. I hope names of videos are selfexplaining. And I hope i did it right.
http://leteckaposta.cz/211902933
Thank you Madshi
Bernix
Manni
23rd August 2017, 15:45
Just to clarify, before I send the email to Microsoft: With the "HDR and Advanced Color" switch turned on, there's also no gamut/white point data sent at all, correct?
Correct.
I triple checked with the Exodus trailer file and can confirm that the mastering display gamut/white point metadata never makes it out of the GPU irrespective of the OS mode selected:
OS HDR On: wrong metadata (fixed values irrespective of content), and no gamut/white point
OS HDR Off: correct metadata except MaxFALL/MaxCLL, no gamut/white point
dvd1
23rd August 2017, 15:50
If (srcWidth <= 1024) AND (srcHeight <= 576) (deintFps <26) "25 fps" DVD 25 fps
else if (srcWidth <= 1024) AND (srcHeight <= 576) (deintFps <51)"50fps" DVD 50 fps
Else If (srcWidth <= 1280) AND (srcHeight <= 720) "720p"
Else If (srcWidth <= 1920) AND (srcHeight <= 1088) "1080p"
Else "Fast"
I did well ?
madshi
rightly so
Manni
23rd August 2017, 16:30
@Madshi:
Just to clarify, we are talking about the following bytes in the static metadata descriptor type 1: 3-14 (mastering display gamut) and 15-18 (white point). Because this is what the Vertex is reading and decoding. It can report rec-709, DCI-P3 or BT2020 for mastering display gamut and D65 for the white point if the x,y match, otherwise nothing (as there is no relevant white point for HDR consumer content that I know of).
madshi
23rd August 2017, 16:38
What if the bytes 3-18 have custom coordinates? Does the Vertex report them? E.g. it might be just 1 value difference to D65 (rounding issue), or it could be totally different data. I'm asking because custom coordinates are quite a different thing to no data at all. It could also be all zeroed out data, or BT.709 coordinates, or something different.
Manni
23rd August 2017, 16:57
What if the bytes 3-18 have custom coordinates? Does the Vertex report them? E.g. it might be just 1 value difference to D65 (rounding issue), or it could be totally different data. I'm asking because custom coordinates are quite a different thing to no data at all. It could also be all zeroed out data, or BT.709 coordinates, or something different.
I don't know about non-consumer content, but all the currently released UHD Bluray titles use standard DCI-P3 coordinates and those I've checked are reported as such.
Are you sure that "custom" coordinates are ever used for reporting the mastering display gamut? It looks to me like it's the standard coordinates of the gamut to which the display has been calibrated to that are reported, not the actual coordinates of the display (i.e. what the display can actually reach if slightly different from the target gamut).
At the moment the Vertex checks for the white point coordinates and reports D65 if they match the standard D65 coordinates, nothing otherwise. I could tell you the content of the bytes if you want me to.
Note that I've read all the files I've tested on my UB900 UHD Bluray player to check what is actually in the source.
The Vertex reported DCI-P3 and D65 for all three files, which proves that the issue is only present when the files are read from the HTPC and that the complete metadata is present in the source.
When they are read from the UB900, whether there is any rounding or not, the coordinates are detected as D65 by the Vertex and reported as such.
If it was a rounding or custom coordinates issue, the Vertex would report the same (nothing) both when reading from the UB900 and when reading from the HTPC.
At least that's what my (possibly flawed) logic would suggest. :)
madshi
23rd August 2017, 17:02
What I meant is that maybe both win10 and the Nvidia custom solution might have small errors in their data (e.g. a rounding error) which might result in the Vertex not reporting anything. It's also possible that the data is completely empty (zeroed out), or just wrong. I don't know, any of that is probably possible. The only thing we know for sure is that neither win10 nor Nvidia output perfect gamut metadata. Maybe there's a small error, maybe they're completely wrong, we don't know that for sure right now. I suppose the Vertex isn't able to show the raw hex bytes?
Manni
23rd August 2017, 17:05
One last thing, as reported earlier, the Vertex supports rec-709, DCI-P3, BT2020 for gamut and D65 for white point (all that it relevant with consumer content). If it's anything else (a few titles have no metadata at all, for example The Fourht Phase which is SDR Rec-709, or Life of Pi), it will display nothing.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.