madVR - high quality video renderer (GPU assisted)

[dimitrik]

It looks like you took the screenshot in pause mode, so hard to tell exactly but rendering time looks OK.
Check that the NVIDIA driver didn't reset to "Optimal power" setting and try setting it to "Adaptive" if it did.
Why a present queue of 14? That seems unnecessary high.
Under Windows 10 I'd also try switching to D3D11 Windowed to see if it works better.

D3D11 Windowed with the present queue set to something between 1 and 3 (inclusive ;)).



Thanks to both of you!

Indeed the nvidia driver was at "optimal" so I changed that, which helped a bit, but not completely.

But changing to D3D11 windowed mode and setting the present queue to 3 solved the problem completely - everything now works fine.
My settings were ancient from back when exclusive mode was the best, during the Win 7 days...


I was getting so frustrated, I was thinking of going back to Windows 8.1 via recovery image but, now I'll hold off for a while:p

I am now having a problem with 1080p25 not working properly, which I suspect is another driver issue, but that's something solve tomorrow...

[Klaus1189]

Never use 25p for 25 Hz mode, always use 50p for 50Hz mode. If you play a 25 fps file which is not progressive but interlaced, then you do not get the „motion resolution“ of the 50 fields. That was the idea of Interlacing.

[CZ Eddie]

Anyone know of a way to get MadVR working for live TV (antenna) playback in Windows Media Center?

[aufkrawall]

Indeed not related to a broken source. Funny thing is that mpv shows the same behavior, again only in fullscreen. It plays it fine on Linux, so it's probably an awfully specific issue/regression regarding vsync of Windows or the Nvidia driver.
Seems to be a driver bug with MPO, disabling it solves the issue: https://nvidia.custhelp.com/app/answers/detail/a_id/5157
In the next driver there is a fix promised for a similar issue with YT playback in browser. Hopefully it will fix this issue as well.

[NoTechi]

Anyone know of a way to get MadVR working for live TV (antenna) playback in Windows Media Center?

I use DVBViewer for live TV, which supports madvr and lav filter. I stream from a VU-box to DVBViewer so it doesnt matter if it was coming from an antenna or something else.
Don't know if it can be integrated in WMC.

NoTechi

[clsid]

You can't change which video renderer WMC uses.

[CZ Eddie]

Thank you.

[CZ Eddie]

I tried DVBViewer but it doesn't seem to work for USA. Anyone know of any LiveTV software that can play DRM protected channels and works with MadVR?

Or even something that doesn't work for DRM playback but does support MadVR (other than JRiver)?

[el Filou]

MediaPortal 1 client supports madVR. Its TV Server supports CableCards but only for decoding channels with the "copy freely" tag: https://www.team-mediaportal.com/wiki/display/MediaPortal1/1.5.x+-+Support+for+CableCard+tuners
I know other front-end solutions exist that can use the MediaPortal TV Server but I never researched them.

[interpolation]

I'm trying to passthrough HLG using madvr, mpc-bc, and the latest Win 10. I can see that it says "transfer HLG" in the madvr info, but HDR doesn't switch on the TV. Of course, the file plays properly when played on the TV's internal player via USB.

If HLG passthrough isn't currently supported with madvr, is there any way to get it to work in Win 10? I saw a custom Kodi build (https://forum.kodi.tv/showthread.php?tid=357799) that claims to trick Windows into outputting HLG as HDR10, but haven't tried it.

[JaylumX]

I'm trying to passthrough HLG using madvr, mpc-bc, and the latest Win 10. I can see that it says "transfer HLG" in the madvr info, but HDR doesn't switch on the TV. Of course, the file plays properly when played on the TV's internal player via USB.

If HLG passthrough isn't currently supported with madvr, is there any way to get it to work in Win 10? I saw a custom Kodi build (https://forum.kodi.tv/showthread.php?tid=357799) that claims to trick Windows into outputting HLG as HDR10, but haven't tried it.

The MPC Video Renderer supports HLG. Just go to video renderer in the link.

Linkage (https://forum.doom9.org/member.php?u=160706)

[huhn]

mpcVR does not support HLG passthrough output is uses the HLG to HDR 10 for passthrough.

[Aleksoid1978]

mpcVR does not support HLG passthrough output is uses the HLG to HDR 10 for passthrough.

And it's "normal" working :)

[Sunspark]

Is MadVR not very compatible with Windows 10?

I have GPU usage of approx 28% (9% in Windows 7) and it doesn't seem to be related to the LAV filters decoding mode (tried them all as well as 3 different versions of LAV) or various madvr output settings (exclusive, windowed, overlay, backbuffers, etc). CPU usage is also higher than in 7 as well (13% vs 3%).

I copied over my Windows 7 MadVR install using an older version with different settings and it did not change the %s. So we know it's not specific to .92.17 here. It's not the player, because when I changed it to EVR-CP CPU, GPU %s then dropped to a more normal number.

Using DXVA2 for the downscaling and upscaling. Changing to something else like Lanczos does not improve things. All other players not using MadVR have significantly lower CPU and GPU usage.

So, what's different about the Windows 7 environment that it doesn't stress the system as much when playing a video? In Windows 10, the fans start whining because even though the CPU usage is about 13% the integrated GPU is at 28%.

[huhn]

window mode can easily add a overhead bigger than audio decoding you can observe this with the DWM process.

i get down to ~1% CPU cpu usage at below 800 mhz peak so basically 0 the % number is pointless here.

try overlay rendering and make sure you have driver supporting the current WDDM.
win 7 can't read the hardware decoder but 10 can that is far far higher then my idling GPU so the taskmanager shows 15 % from the decoder.
to test real power saving i need to disconnect displays i'm not going to do that.

[Matias]

I tried DVBViewer but it doesn't seem to work for USA. Anyone know of any LiveTV software that can play DRM protected channels and works with MadVR?

Or even something that doesn't work for DRM playback but does support MadVR (other than JRiver)?

I don't have any DRM protected channels but maybe ProgDVB can do this, you must try.

[Sunspark]

window mode can easily add a overhead bigger than audio decoding you can observe this with the DWM process.

i get down to ~1% CPU cpu usage at below 800 mhz peak so basically 0 the % number is pointless here.

try overlay rendering and make sure you have driver supporting the current WDDM.
win 7 can't read the hardware decoder but 10 can that is far far higher then my idling GPU so the taskmanager shows 15 % from the decoder.
to test real power saving i need to disconnect displays i'm not going to do that.

Thanks, and I actually am using D3D9 overlay rendering. I found it to present a smoother display which is why I am using it. Video driver is the one that Windows installed itself, and dxdiag confirms that it is WDDM 2.0. Possible it's a video driver issue, but odd in that it is only the madvr module that has the problem in 10.

GPU-Z will work in Windows 7 to show GPU % (as the task manager won't show it in that version). Also shows power watts. Not sure how accurate it is, but it's useful all the same.

The software is working and presents well, it just uses a lot of resources in Windows 10 and makes the fans spin up.

[huhn]

your WDDM version is 4-5 years old which suggest the driver is also that old.
the current release wddm is 2.7 the newest test is 3.0.
but this is a best a guess based on the fact that the WDM shows quite some CPU/GPU usage when an windowed image is shown.

there are some game tests which show that win 10 is clearly superior in performance and my systems has such low GPU and CPU usage that it's hard to make anything out of it.

[el Filou]

Whatever is the cause, 28% Vs 9% for GPU and 13% Vs. 3% for CPU (assuming the clocks are the same as huhn said) is a much bigger difference than anything possibly due to the OS, especially the GPU because WDDM 2.x is supposed to be more resource efficient than WDDM 1.1.

What hardware do you have?
When I set madVR to DXVA scaling on my desktop (1440p), it uses only 17% at 450 MHz on my old Radeon 7870 i.e. nothing, and my 4690K is only at 4,8% at lowest clock 800 MHz.

[Sunspark]

Whatever is the cause, 28% Vs 9% for GPU and 13% Vs. 3% for CPU (assuming the clocks are the same as huhn said) is a much bigger difference than anything possibly due to the OS, especially the GPU because WDDM 2.x is supposed to be more resource efficient than WDDM 1.1.

What hardware do you have?
When I set madVR to DXVA scaling on my desktop (1440p), it uses only 17% at 450 MHz on my old Radeon 7870 i.e. nothing, and my 4690K is only at 4,8% at lowest clock 800 MHz.

It's an Intel Core i5-5250U (Broadwell, 2 cores, 4 threads) using integrated graphics Intel HD Graphics 6000 (Broadwell GT3).

Turning off image scaling (Normal size vs touch window from inside) does not change the 28%.

Likewise, this high utilization does not happen with any other video renderer.. MpcVR, EVR-CP, whatever VLC uses, whatever Windows Film & TV uses, etc. only specifically with MadVR and it's not limited to .92.17 because I tried an older version (.90.17).

The issue does not occur on Windows 7. It's so strange, I can't figure it out.

Who knows, maybe it's a bug in Windows 10 itself.. MS has had a run of breaking things lately.

I suppose I should try installing the Windows 11 preview (if it lets me) into a partition and see if anything changes.

[el Filou]

Can you try to change Windows power plan from Balanced to High performance, just for a test? Or just change the power balance setting (forgot what it's called) in the Intel Graphics control panel ?

That's a 15W part which is not a lot, maybe it's getting in some power save mode where the clocks are much lower? Are you sure the playback clocks are the same as on Win7?
The utilization percentages are not a bad thing per se, it all depends on how much power it actually uses, but I don't see why they would differ so much.

[bitterman]

Is MadVR not very compatible with Windows 10?

I have GPU usage of approx 28% (9% in Windows 7) and it doesn't seem to be related to the LAV filters decoding mode (tried them all as well as 3 different versions of LAV) or various madvr output settings (exclusive, windowed, overlay, backbuffers, etc). CPU usage is also higher than in 7 as well (13% vs 3%).

I copied over my Windows 7 MadVR install using an older version with different settings and it did not change the %s. So we know it's not specific to .92.17 here. It's not the player, because when I changed it to EVR-CP CPU, GPU %s then dropped to a more normal number.

Using DXVA2 for the downscaling and upscaling. Changing to something else like Lanczos does not improve things. All other players not using MadVR have significantly lower CPU and GPU usage.

So, what's different about the Windows 7 environment that it doesn't stress the system as much when playing a video? In Windows 10, the fans start whining because even though the CPU usage is about 13% the integrated GPU is at 28%.

I encounter the exact same issue.

Using:
Windows 10 21h1 (latest build)
MPC-HC 1.9.14
madVR 0.92.17
Nvidia drivers 471.11 (with a GTX 970)

https://i.imgur.com/gmFkrlT.png

[huhn]

check what part of the GPU it could be easily the hardware decoder.

[nevcairiel]

Percentages can also be rather misleading if the GPU has a dynamic clock. It could run at what seems a high percentage but run at a lower clock because the driver/OS figured out that this is plenty to do the task at hand.
If you really want to check, collect more data points with actual GPU monitoring tools (eg. GPU-Z might be the simplest that shows much more data), not task manager.

[ryrynz]

Anyone had any luck with automatic profile selection on a mounted ISO? I'm only using location and resolution as the conditions and both are correct but it's not taking.
MPC-BE even specifies the location in it's recent files list so it appears to be parsing this location correctly but madVR isn't having a bar of it.

[brazen1]

If I understand you correctly, auto profile selection has always worked perfectly for mounted iso's using resolution here.

if (srcWidth > 1920) and (deintFps < 25) "2160p 24fps"
else if (srcWidth <= 1920) and (srcHeight > 1080) "2160p 24fps"
else if (srcheight <= 2160) and (deintFps > 58) "2160p 60fps"

else if (srcWidth > 1280) and (srcWidth <= 1920) "1080p"
else if (srcWidth <= 1280) and ((srcHeight > 720) and (srcHeight <= 1080)) "1080p"

else if (srcWidth > 960) and (srcWidth <= 1280) "720p"
else if (srcWidth <= 960) and ((srcHeight > 540) and (srcHeight <= 720)) "720p"

else if (srcWidth <= 960) and (srcHeight <= 540) "540p"

[ryrynz]

No issues with resolution, location is the problem.

if (srcHeight <= 480) and (filepath = "E:\*.*")
"480"

E: is the ISO mounted location.
I've also tried E:\Video_TS\*.* but that doesn't work either. I've had to resort to using an else statement to get it to select the appropriate profile.

Can anyone else confirm this?

[el Filou]

It works for Blu-ray ISOs but not DVDs.
I think it's because the DVD Navigator doesn't pass filename/path information (when opening VOB files directly, it works)?
I can see that also in ReClock, it says File: DVD from DVD drive (in mpc-hc) whereas with a BD ISO it shows the path of index.bdmv even when opening as disc.
I've tried with filename = "*DVD*" but it doesn't work either.

[Sunspark]

el Filou: I did try High Performance, it didn't change anything.

nevcairiel: These two images show the same file being played. It seems that something in Win10 is triggering heavier power consumption with madVR but I don't have an understanding as to what it could be.

https://www.dropbox.com/s/nt7qcgsralp6hpo/madvrwin7.gif?raw=1

https://www.dropbox.com/s/n4fioz63nrpb4vj/madvrwin10.gif?raw=1

[el Filou]

@Sunspark: can you create a file named ShowRenderSteps (with no file extension) in madVR's program files folder, and then take screenshots of madVR OSD during playback (wait for the clocks and GPU utilization to stabilize) on both Win7 and Win10 and compare the figures? To check if the GPU utilization is due to one particular step of madVR's pipeline or if all steps have higher rendering times on Windows 10.
(I know it's cumbersome, but I don't see another way to find out what is causing that much higher usage)

[SirMaster]

No issues with resolution, location is the problem.

if (srcHeight <= 480) and (filepath = "E:\*.*")
"480"

E: is the ISO mounted location.
I've also tried E:\Video_TS\*.* but that doesn't work either. I've had to resort to using an else statement to get it to select the appropriate profile.

Can anyone else confirm this?

In MPC, enable the web interface and open up the variables page:

http://localhost:13579/variables.html

Here you can see the paths for playing media files that MPC will be sending to madVR, so check the paths of your playing ISOs to see how you would write your profile selection rules.

[Sunspark]

@Sunspark: can you create a file named ShowRenderSteps (with no file extension) in madVR's program files folder, and then take screenshots of madVR OSD during playback (wait for the clocks and GPU utilization to stabilize) on both Win7 and Win10 and compare the figures? To check if the GPU utilization is due to one particular step of madVR's pipeline or if all steps have higher rendering times on Windows 10.
(I know it's cumbersome, but I don't see another way to find out what is causing that much higher usage)

Thanks el Filou for the suggestion to look closer again with the ShowRenderSteps.

The mystery is solved.

In Win7 I wasn't using exactly the same settings, so I thought to myself, let's try to make it more like the setup in Win10 for consistency in measurement so I added a module I wasn't using there, and all of a sudden, heavy usage in Win7 too.

It was the subtitle renderer that was adding all the extra usage, but also another setting as well. Different combinations of stuff will vary cpu & gpu usage, etc. slightly but it generally came down to 2 settings together. Overlay mode and the subtitle renderer.

overlay mode on, xysubfilter on - heavy usage
overlay mode off, xysubfilter on - heavy usage
overlay mode on, internal subtitle renderer on - heavy usage
overlay mode off, internal subsubtitle renderer on - normal usage
overlay mode on, assfilter on - heavy usage
overlay mode off, assfilter on - heavy usage

There is only 1 combination in mpc-hc that doesn't crank up the power if you need to have subtitles on as I do. DON'T use D3D9 Windowed Overlay mode and ONLY use the player's internal subtitle renderer.

Such a shame, because xysubfilter has sharper rendering and better positioning. Sigh..

Incidentally, in D3D9 windowed (non-overlay) mode backbuffers has lower cpu/gpu usage than frames in advance.

Image below is what it looks like with xysubfilter active.. all the extra rendering steps that doesn't happen with the internal subtitle renderer.

https://www.dropbox.com/s/gzx0yidgp5u25zf/madvrwin10.png?raw=1

[el Filou]

Excellent news.
Have you tried D3D11 presentation to see if it worked better than D3D9? Broadwell's iGPU should be recent enough to work well with it, but sometimes there are quirks.In MPC, enable the web interface and open up the variables page. Here you can see the paths for playing media files that MPC will be sending to madVRThat's really strange, it shows the correct path (E:\VIDEO_TS\VIDEO_TS.IFO), but the rule still doesn't work when it's a DVD. Are you sure that's how madVR gets its file info?

[clsid]

MPC does not send any filenames to madVR. I assume madVR uses standard DirectShow interfaces to get the filename from the source filter. The DVD navigator probably does not implement that interface.

Such a shame, because xysubfilter has sharper rendering and better positioning. Sigh..Nonsense. You can let the internal renderer run at 4k resolution if you want. You need to check your settings.

[ryrynz]

MPC does not send any filenames to madVR. I assume madVR uses standard DirectShow interfaces to get the filename from the source filter. The DVD navigator probably does not implement that interface.

Can we fake it somehow so the path can be parsed for MadVR to pick up on? Having a profile specifically for DVD ISOs would be quite a boon.

[clsid]

If it isn't working properly, then it is something that madshi has to fix. I have checked and the DVD Navigator does also expose the required interface for getting file path.
https://docs.microsoft.com/en-us/windows/win32/api/strmif/nn-strmif-ifilesourcefilter

What you could try is to check if the path variable is empty for ISOs. Or if it does not contains any / or \ characters.

[doffen]

MPC does not send any filenames to madVR. I assume madVR uses standard DirectShow interfaces to get the filename from the source filter. The DVD navigator probably does not implement that interface.

Nonsense. You can let the internal renderer run at 4k resolution if you want. You need to check your settings.

Is there still any advantages of using xysubfilter then?

[huhn]

Is there still any advantages of using xysubfilter then?

sub title moving, smooth motion compatible and calibration but sharpness was never part of it.

[doffen]

Thanks! I'll stick with xysubfilter then since I use 3dlut with madvr. (assuming these works for the subtitles as well)

[huhn]

xy does the internal renderer doesn't.

[Sunspark]

I'm not so sure about the whole sharpness is the same aspect. It might be player specific because even with two different ones set to use the internal subtitle renderer and both set to use "desktop" as the texture resolution, one is sharper than the other. But on mpc-be xysubfilter is noticeably sharper than the internal renderer set to desktop on my system. Whereas on mpc-hc (1.7.13) it doesn't make a difference, both internal and xysubfilter are both sharp so it makes sense to use the internal one to reduce gpu load otherwise it will be 3x load. The converse is true on mpc-be because xysubfilter does not increase gpu load when paired with the mpc video renderer so in that player xysubfilter should be used instead of the internal subtitle renderer if you are using d3d9 as I am.

The subtitle moving support in madvr, I don't believe it works all that well with the internal subtitle renderer in mpc-hc because I did test it out. Made sure dxva2 copy-back was being used because I determined the following things: subtitle moving will not take place if you do not have black bar detection turned on (which in turn is dependent on having copy-back). When this condition is met, and the subtitle is moved, only one of the two options works well. Moving into the active video area does work and will move the subtitle into the video picture itself. However, most people want the subtitle below for non 16:9 content, and the option "move subtitles to bottom of screen/window" just doesn't work at all. So, in that scenario don't even waste your time with that option. Leave it off along with black bar detection off since you won't need them, and instead in subtitle style settings for the margin for top and bottom, change it from 20 to 1. It'll be a compromise. Subtitles with 2 lines will be nicely centered in the black portion below the video. Subtitles with 1 line unfortunately will be at the bottom of the monitor. Nothing can be done about it, not even turning the madvr option for "bottom" back on. Movies and shows that aren't 16:9 will have black bars which is why this situation of subtitle moving or lack thereof may not always be noticed if all your content is exclusively 16:9.

So, I have another stupid edge case bug to warn you about in Windows 10 with madvr. If you are using dxva2 copy-back and have exclusive mode turned on (and yes for good measure i also have "disable full-screen optimisations" checked in the player's windows file properties) do not have "frames in advance" selected in madvr options for both windowed mode (which is where your playback begins first) and exclusive mode. If you have frames in advance selected for both, what happens is that something gets stuck with the gpu load, it is higher than it should be when in windowed mode and remains higher when you switch into fullscreen exclusive. Windowed mode needs to have frames in advance unchecked, and it's ok to use frames in advance for exclusive. If you have the two separate, one with backbuffers and the other with frames in advance, then the gpu load will be ok for both and not get stuck at a higher utilization. Unfortunately, there is no benefit in using backbuffers for exclusive also, because it will be higher gpu usage than with frames in advance. It doesn't make sense to me that windowed mode uses lower gpu with backbuffers and exclusive is lower with frames, but you can't have both set to the same thing at the same time, or that if you reverse the options and make windowed frames, and exclusive backbuffers then both will have higher gpu usage.

What can you do? There is no such thing as a perfectly implemented player anywhere, always edge case bugs and glitches. Even Microsoft's Movies & TV (Films & TV) player which is backed by a huge corporation has the following annoyances that I have noticed: subtitles are unable to show outlines, everything else works just not the option to choose outline, raised, etc. so you have to live with subtitles that have no separation from the video unless you are willing to accept a black bar behind it. It cannot play AC3/E-AC3 audio. It cannot play 10-bit anime files. It does however have the best lower power consumption which is important to know about if you're running off batteries for awhile.

[clsid]

You are using a 4 year old version of MPC-HC. Latest one is 1.9.14.

If you want subs below video, then simply disable the option in MPC-HC to render relative to the video frame. Then it will render relative to window. Or semi-checked (= default) which means relative to window for normal subs, and relative to video for anime stuff.

[huhn]

the new interface can move text only and does not move typeset and such.

what so ever a device with dead driver should not be considered as the general state of things.

[ashlar42]

No, something is wrong there. Are you SURE your LG is set to low? Because it absolutely should be Limited, FULL, Limited (madvr, gpu, display).
Sorry for quoting an old post but I just wanted to double check on this.

While this works fine, and I understand it's the best choice (no scaling during color conversion YCbCr-->RGB), is it normal to have crushed blacks on desktop applications, right?
It's not a problem, as I can select a different picture mode (maybe Game) when I need to play a game (and have Black Level set to Full for that picture mode) but I just want to be sure that it's normal for that to happen.

Thanks.

Edit: for people curious about this, I find this post to be quite informative https://kodi.wiki/view/Video_levels_and_color_space

[el Filou]

Yes, it's expected.

Edit:Windowed mode needs to have frames in advance unchecked, and it's ok to use frames in advance for exclusive. [...] Unfortunately, there is no benefit in using backbuffers for exclusive also, because it will be higher gpu usage than with frames in advance. It doesn't make sense to me that windowed mode uses lower gpu with backbuffers and exclusive is lower with frames, but you can't have both set to the same thing at the same time, or that if you reverse the options and make windowed frames, and exclusive backbuffers then both will have higher gpu usage.I think those observations are highly specific to your iGPU. I've tested every combination just out of curiosity, with both DXVA scaling and madVR shaders scaling, and there is 0 difference between backbuffers and presented frames in advance on my GeForce and my legacy Radeon. Exclusive mode has a very small GPU usage advantage on the Radeon but it's 14% Vs. 18% at best which isn't worth the inconvenience.
Also, if you're going to use DXVA chroma & image scaling anyway, you may as well not use madVR at all except if you need some specific misc. feature.

[huhn]

the kodi page is incomplete the range is 16-235 for luma and 16-240 for chroma.

so the argument ycbcr -> rgb limited doesn't need a level conversation is invalid.

the fact that ycbcr to limited and to full are float point operation and can be done directly and even have existing coefficients to do it directly so there is no scaling.
https://mymusing.co/bt-709-yuv-to-rgb-conversion-color/

there is one exception that's black white Y only to RGB (test pattern) where the limited conversation is lossless no dithering needed i guess that's the reason they don't dither with limited range even through it's just wrong...

the recommended levels are still full full full.
https://www.avsforum.com/threads/madvr-argyllcms.1471169/page-19#post-23457822

[chros]

I'm not sure about that, if you use an sdr 3dlut:
- full, full, full: clips whiter than white (wtw)
- limited, full, limited: passing through wtw

You can try it with white clipping pattern form avshd bt709 set.
I still use full, full, full, because I didn't create a 3dlut for the other one, but I have set limited, full, limited for HDR10 otput.

[huhn]

3D lut can be bugged with madVR if they come from displaycal/argyllCMS.

WTW and BTB can go crazy.
there is a fix clipping btb and wtw but madshi says it should be fixed in displaycal/argyllcms and they say wtw or btb as input is not allowed and should be clipped neither fixed it.
try a clipping shader.

this has nothing to do with out put level the 2D LUT will still do 100 % the same it's just with showing wtw and btb you can see heavy artifacts.

if that's even the issue you are talking about.

[chros]

Good question, not sure, I would have to create one 3dlut for limited to see whether it behaves the same or not. But if you have a full 3dlut for madvr (created by displaycal) then you can quickly try it out.

[huhn]

if it is the same issue i may not be affected at all.

even if you create a limited range LUT madVR still feeds WTW or BTB and that compromised by something like the chroma scaler or even image scaler and it is not able to output it. it's not made for it. it should never be feeding it into a 3D LUT with limited or full range output.

BTW. the 3D LUT doesn't at all it's always limited range as input and just to stop the confusion this is irrelevant for output ranges.

edit: my current 3D LUT does not seem to expose the issue. it's hard to judge with the coating of this TV...