madVR - high quality video renderer (GPU assisted)

[huhn]

use trade quality for performence
check
use 10 bit chroma buffer instead of 16 bit
use 10 bit image buffer instead of 16 bit
don't use dithering

set chroma/image/up/down-scaling to bilinear

and use aero without aero it's hard to avoid tearing in window mode. if you can't use aero you shouldn't be able to use madvr.

you can try evr with d3d fullscreen too

[Xaurus]

Sorry, my fault. Here's a fixed build:

http://madshi.net/madVRanotherTestBuild2.rar
Hi madshi, I still get dropped frames with this build. I settled on medium deband strength since that looked best to me.
Adjusting queue sizes does not seem to have any effect. Otherwise all defaults are used. Smooth motion is off. Decoders are not activated. Refresh rate 23.9765 fps, tested on 720p material on a 1080p display.
Same result with/without ReClock.

Look at system in signature.

Any idea what I can do more to debug this?

[madshi]

I still get dropped frames with this build.
There are many many madVR users. I don't happen to remember the problems you had. So you gotta be a bit more specific.

[James Freeman]

No dropped frames over here.

i7 3770K, Gigabyte GTX660.

[MSL_DK]

If you read the queues from top to bottom, is the render queue the first one which is empty all the time? Or do the queues above the render queue also have a problem? The queue which is causing all the trouble is the top most queue which is getting empty all the time. Which is the fill state of the queue directly above the render queue?

I'm going to a concert with Depeche Mode and move to another apartment this weekend, so can not provide more information before monday.

[cvrkuth]

I update my OS (Windows 8.1 Pro), I have same problem again.
I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz. Because of this, there is a drop frames every 30-40 sec.

If I uncheck 'Present Several frames in advance "(old path), my screen stays in 24hz.



Log file here (http://www.krstic.eu/madvr_log.zip).
I have Sapphire Radeon HD 5670 Ultimate 1GB,
Intel Core2 Duo E8400 3.00GHz, RAM 8 Gb
Panasonic TX-P42G20E, Catalyst™ 13.9
Win8.1 Pro x64, JRiver Media Center 18 Ver. 18.0.212, madVR v0.86.11

Is there a fix for issue?

[antoine.brisebard]

Hello everyone!

thankyou for the latest testbuild. fixed green layer for me with DXVA.

I'm afraid I'm having delayed and dropped frames with testbuild 2.

backbuffer plus render queue runs empty again and again.
having attached a screenshot taken after roughly 4 minutes of movie.

kind regards - Antoine

i3-3245 | 1920x1200/60 Hz | W7/64 | 8 GB | MPC-HC nightly

[michkrol]

Quick question, can somebody recommend a list of settings how to maximize madVR performance for older hardware (Win 7, no aero)? The main reason is that only with madVR I don't get any tearing on that machine.

Set all scaling algorithms to bilinear.
Depending on how old is old hardware, try DXVA up-/down-scaling.

Check if you get better results with software or hardware (DXVA) decoding. LAVFilters are recommended codecs on Windows.

In rendering -> trade quality for performance try enabling more and more options, going top to bottom, until you get good results.
What I mean is enable first option, try if you get good results, if not, then enable second options with first still enabled, check results, then enable third with first and second still enabled and so on.

I'm afraid I'm having delayed and dropped frames with testbuild 2.

While the screenshot gets approval, are you sure your GPU is not overloaded? Use GPU-Z or similar to monitor GPU usage. Also try to set all scaling algorithms to bilinear to reduce load.

[madshi]

I update my OS (Windows 8.1 Pro), I have same problem again.
I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz. Because of this, there is a drop frames every 30-40 sec.

If I uncheck 'Present Several frames in advance "(old path), my screen stays in 24hz.
Your log file indicates that the display mode is reported as 1080p24 when madVR starts rendering. And madVR knows that 24Hz is what you need, so it doesn't touch the display mode. Then madVR goes into fullscreen exclusive mode, telling Direct3D9 to use 24Hz. It seems that in your case Direct3D9 ignores madVR's wish and switches to 23.976Hz instead. That would be a bug in Windows/Direct3D9. I've already implemented some hacks to fix this problem with Intel GPUs, but it's possible that this fix doesn't work with AMD/NVidia GPUs, I'm not sure. Feel free to add a bug report to the madVR bug tracker about this problem, if there isn't one already. Maybe if I find some time I'll see if I can workaround the problem with AMD/NVidia GPUs, too. It's not a madVR bug, though, but a bug in Windows or Direct3D9 or in the GPU drivers. madVR clearly requests 24.000Hz, according to the log.

I'm afraid I'm having delayed and dropped frames with testbuild 2.

backbuffer plus render queue runs empty again and again.
having attached a screenshot taken after roughly 4 minutes of movie.

kind regards - Antoine

i3-3245 | 1920x1200/60 Hz | W7/64 | 8 GB | MPC-HC nightly
Attaching anything here in the forum is a bad idea, it sometimes takes a long time for attachments to get approved. Better upload stuff somewhere else.

Does the problem only occur with the test build? Or also with the official version? Is the render queue the first queue which is empty (when reading the queue from top to bottom)?

[v0lt]

@madshi
What pixel formats renderer can take as input?
What pixel formats are preferred?

[antoine.brisebard]

Does the problem only occur with the test build? Or also with the official version? Is the render queue the first queue which is empty (when reading the queue from top to bottom)?

Dear madshi, problem occurs with testbuild only.
render queue stays at 6-8/8 when playing the movie.
bb queue jumps often to 0-4/4.
(using last intel igpu driver ...build 3345; all video enhancements are not activated in driver)
regards - Antoine

[madshi]

What pixel formats renderer can take as input?
What pixel formats are preferred?
Accepted are almost any pixel formats you can think of (or that I found documentation for). Preferred are planar formats like:

4:2:0, 8bit: NV12, YV12
4:2:2, 8bit: YV16
4:4:4, 8bit: YV24
4:2:0, 10/16bit: P010/P016
4:2:2, 10/16bit: P210/P216

For these madVR has built in SSE2 handling routines. For the other pixel formats slower C++ code is used atm. Unfortunately there's no planar 4:4:4 10/16bit format (that I know of).

Dear madshi, problem occurs with testbuild only.
render queue stays at 6-8/8 when playing the movie.
bb queue jumps often to 0-4/4.
In your previous post you said that both the render and backbuffer queues get empty. Now which is true? Your latest post or your previous post?

Is this windowed mode or overlay mode or fullscreen exclusive mode?

[antoine.brisebard]

In your previous post you said that both the render and backbuffer queues get empty. Now which is true? Your latest post or your previous post?
Latest post is true.
Having played same movie again:
Happens at windowed mode. fullscreen exclusive mode is not watchable at all: heavy "jitter" from left to right. have tried to copy a screenshot-but that's not possible. screenshot only shows black content.

regards- A.

[Xaurus]

There are many many madVR users. I don't happen to remember the problems you had. So you gotta be a bit more specific.
Yes of course, I actually never reported anything before during the first test builds you put out since others were reporting dropped frames and I was content on following the thread.

In my case the queues take a hit sometimes, like each 10-30 seconds. It never goes to 0 in any of the queues (visibly), but I can see that they go down by 1-2 and then back at full in "virtually" no time. In this moment the dropped frames happens.

This is in FSE mode using CUVID. Disabling the deband makes it all fine again.

I am using a GTX 660 and Jinc 3 for up/down.

Let me know if you need further info.

[madshi]

Latest post is true.
Having played same movie again:
Happens at windowed mode. fullscreen exclusive mode is not watchable at all: heavy "jitter" from left to right. have tried to copy a screenshot-but that's not possible. screenshot only shows black content.
There's something very wrong if fullscreen exclusive mode produces such artifacts. Try reinstalling the GPU drivers. Are you using default madVR options or did you change anything? Maybe it would make sense trying to reset to default options to see if that improves anything. IMHO your first priority should be to get fullscreen exclusive mode working because that's the most reliable mode.

One thing to try would be to increase GPU queue size and number of backbuffers for both window and FSE modes. 4 backbuffers is relatively low.

In my case the queues take a hit sometimes, like each 10-30 seconds. It never goes to 0 in any of the queues (visibly), but I can see that they go down by 1-2 and then back at full in "virtually" no time. In this moment the dropped frames happens.

This is in FSE mode using CUVID. Disabling the deband makes it all fine again.
What happens if you enable deband, but choose the same settings for both deband options? Does that also make the problem go away? Another question: What happens if you use Lanczos instead of Jinc? Does that make the problem go away?

[Weirdo]

I often get this (https://www.mediafire.com/?o28gamciif6be86) problem with smooth motion in windowed mode. It'll go away if I enter full screen exclusive, but in windowed mode it's quite common.

[madshi]

That are really weird(o) artifacts. Try increasing the GPU queue size, the number of backbuffers and the number of pre-presented frames. Also try deactivating the "render in a separate device" option (or however it was named). Does any of that help?

[ryrynz]

I often get this (https://www.mediafire.com/?o28gamciif6be86) problem with smooth motion in windowed mode. It'll go away if I enter full screen exclusive, but in windowed mode it's quite common.

That are really weird(o) artifacts. Try increasing the GPU queue size, the number of backbuffers and the number of pre-presented frames. Also try deactivating the "render in a separate device" option (or however it was named). Does any of that help?

I've had that before, If I remember rightly the queue size is the culprit here.

[antoine.brisebard]

was able to decrease slightly number of dropped and delayed frames by changing those settings:
gpu queue 8 -> 10
backbuffers 4 -> 6
frames in advance 4 -> 6

regards!

[v0lt]

Accepted are almost any pixel formats you can think of (or that I found documentation for). Preferred are planar formats like:

4:2:0, 8bit: NV12, YV12
4:2:2, 8bit: YV16
4:4:4, 8bit: YV24
4:2:0, 10/16bit: P010/P016
4:2:2, 10/16bit: P210/P216

For these madVR has built in SSE2 handling routines. For the other pixel formats slower C++ code is used atm. Unfortunately there's no planar 4:4:4 10/16bit format (that I know of).
I tested AYUV and YV24. And I haven't seen advantages in YV24 processing speed.

Intel i5-3750K, Win7 x64.

[nevcairiel]

AYUV is bad because EVR accepts AYUV, but it fails at properly processing it (its extremely slow, on some GPUs no image at all), so thats why YV24 is preferred for me. Not to mention that a decoder typically outputs planar video, and conversion to AYUV requires manual labor.

[madshi]

was able to decrease slightly number of dropped and delayed frames by changing those settings:
gpu queue 8 -> 10
backbuffers 4 -> 6
frames in advance 4 -> 6
I'd still recommend to try to make FSE mode work.

I tested AYUV and YV24. And I haven't seen advantages in YV24 processing speed.
Hmmmm... Wait a moment, YV24 does not have an SSE2 routine yet in madVR (except if the user activates DXVA2 scaling), that's my mistake. But YV24 is much more likely to get an SSE2 routine than AYUV in the future. Planar is much preferred here, because some current and future algorithms (e.g. fade in/out detection) work on the luma channel, only, and that's so much easier with planar formats.

[cvrkuth]

Your log file indicates that the display mode is reported as 1080p24 when madVR starts rendering. And madVR knows that 24Hz is what you need, so it doesn't touch the display mode. Then madVR goes into fullscreen exclusive mode, telling Direct3D9 to use 24Hz. It seems that in your case Direct3D9 ignores madVR's wish and switches to 23.976Hz instead. That would be a bug in Windows/Direct3D9. I've already implemented some hacks to fix this problem with Intel GPUs, but it's possible that this fix doesn't work with AMD/NVidia GPUs, I'm not sure. Feel free to add a bug report to the madVR bug tracker about this problem, if there isn't one already. Maybe if I find some time I'll see if I can workaround the problem with AMD/NVidia GPUs, too. It's not a madVR bug, though, but a bug in Windows or Direct3D9 or in the GPU drivers. madVR clearly requests 24.000Hz, according to the log.

Thanks for answering my question. I hope, You'll find solution for this annoying thing.

[Xaurus]

What happens if you enable deband, but choose the same settings for both deband options? Does that also make the problem go away? Another question: What happens if you use Lanczos instead of Jinc? Does that make the problem go away?
I have no idea what's changed, but instead of using the shortcut key for toggling deband, I went into madvr processing options and set both to medium. I had not gone into those options before. If there's a difference somewhere, I don't know about it. But now the problem is gone, no matter what algorithm I use. :)

Thanks madshi.

[Weirdo]

That are really weird(o) artifacts. Try increasing the GPU queue size, the number of backbuffers and the number of pre-presented frames. Also try deactivating the "render in a separate device" option (or however it was named). Does any of that help?
Thanks a lot. It happens on both my PC's (HD5670-GT240). Increasing backbuffers seems to do the trick, I'll test some more.

[madshi]

I have no idea what's changed, but instead of using the shortcut key for toggling deband, I went into madvr processing options and set both to medium. I had not gone into those options before. If there's a difference somewhere, I don't know about it. But now the problem is gone, no matter what algorithm I use. :)
So what happens if you go back and use different settings both those 2 deband options in the settings dialog again? Does the problem come back? If so, please create a debug log with frame drops in it, caused by those deband configuration, and upload it for me to look it somewhere (zipped, please).

Thanks a lot. It happens on both my PC's (HD5670-GT240). Increasing backbuffers seems to do the trick, I'll test some more.
I guess I should check out how many buffers are needed and force them. Can you please double check how many backbuffers you need exactly for the problem to go away?

[Xaurus]

So what happens if you go back and use different settings both those 2 deband options in the settings dialog again? Does the problem come back? If so, please create a debug log with frame drops in it, caused by those deband configuration, and upload it for me to look it somewhere (zipped, please).
Yes you are right, I set it to "low" then "medium" and now the problem is back.

Ok so I couldn't find a debug .ax in the madVRanotherTestBuild2.rar package. So I tried the one from 0.86.11 but that didn't seem to work properly as I got no dropped frames according to the debug OSD, even if the processing options are still there and set to "low" and "medium". Switching back to the madVRanotherTestBuild2 .ax makes the dropped frames appear again in the debug OSD.

Is there another way of getting this debug log now that I don't know of?

Thanks.

[madshi]

Ah sorry, I forgot that I didn't upload a debug madVR.ax version. Will do that for the next test build (if there is one). Would be great to get a debug log then.

[v0lt]

@madshi
I have problems with YV16 in madVR. But it is not clear reason in decoder or renderer.
http://i.imgur.com/YQh8eq9s.jpg (http://i.imgur.com/YQh8eq9.jpg)

[aufkrawall]

That are really weird(o) artifacts. Try increasing the GPU queue size, the number of backbuffers and the number of pre-presented frames. Also try deactivating the "render in a separate device" option (or however it was named). Does any of that help?
I had some problems too with windowed mode and smooth motion, especially with complex videos (10bit 444 high bitrate...).
It was a good idea then to mess with the flush settings.
However, I can't recall if this was mostly regarding dropped frames (haven't watched videos in windowed mode for a long time).

[Xaurus]

Ah sorry, I forgot that I didn't upload a debug madVR.ax version. Will do that for the next test build (if there is one). Would be great to get a debug log then.
Hi madshi,

No worries. I'll be sure to provide it to you if you decided to release a new test build.

[Weirdo]

I guess I should check out how many buffers are needed and force them. Can you please double check how many backbuffers you need exactly for the problem to go away?
Typically, the issue now refuses to show up again. I remember it disappearing immediately, by increasing backbuffers from 3 to 4 (windowed settings).

[annovif]

Hi , i know that with an HTPC i've got to output in RGB (4:4:4) 0-255 for the best quality , and in the catalyst control panel i've setted it (RGB full). About the level I've got coreavc that can set the input level and the output level separately 0-255 or 16-235 . Now , i know that the Blu ray level is 16-235 , so i have setted the coreavc input level in 16-235 . About the output level i want coreavc untouch the signal level and i've setted it to 16-235 too .
In the final In madvr i've setted 0-255 . Is this all ok for the best quality? Or have i to set 0-255 madvr and coreavc too ?

Thank you, Fabio

[huhn]

Hi , i know that with an HTPC i've got to output in RGB (4:4:4) 0-255 for the best quality , and in the catalyst control panel i've setted it (RGB full). About the level I've got coreavc that can set the input level and the output level separately 0-255 or 16-235 . Now , i know that the Blu ray level is 16-235 , so i have setted the coreavc input level in 16-235 . About the output level i want coreavc untouch the signal level and i've setted it to 16-235 too .
In the final In madvr i've setted 0-255 . Is this all ok for the best quality? Or have i to set 0-255 madvr and coreavc too ?

Thank you, Fabio

first of all what is your tv a lot of tvs can't handle 0-255
just test it.
http://www.lagom.nl/lcd-test/black.php

normally just let everything at default i don't use coreavc because i don't see a reason lav filter is totally fine for me.
there are settings like 0-255 16-235 too but they do nothing with a bd source except you change the output color spaces types too... and this should be the same with coreavc.

just leave your hands from those options and everything will run perfectly madvr gets untouched 16-235 nv12 and takes care of the rest

[dansrfe]

Are there settings for changing the black/white levels in the settings dialog along with the keyboard shortcuts? Also, does changing them adjust the top and bottom of the gamma curve?

[Prot]

may i ask is there any x64 release of this VR?

[PetitDragon]

may i ask.....?

No, you may not.












:D

[leeperry]

any x64 release of this VR?
\madVR\madHcNet64.dll :devil:

but no, not anytime soon.

[Prot]

\madVR\madHcNet64.dll

but no, not anytime soon.

thx for the info,
i could not found that file in some versions, did it really pubed before? if so, please tell me the version num.

[flashmozzg]

thx for the info,
i could not found that file in some versions, did it really pubed before? if so, please tell me the version num.

It's a joke. This file is needed only for some specific staff on 64-bit machines and no more.

[cvrkuth]

I update my OS (Windows 8.1 Pro), I have same problem again.
I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz. Because of this, there is a drop frames every 30-40 sec.

If I uncheck 'Present Several frames in advance "(old path), my screen stays in 24hz.

Your log file indicates that the display mode is reported as 1080p24 when madVR starts rendering. And madVR knows that 24Hz is what you need, so it doesn't touch the display mode. Then madVR goes into fullscreen exclusive mode, telling Direct3D9 to use 24Hz. It seems that in your case Direct3D9 ignores madVR's wish and switches to 23.976Hz instead. That would be a bug in Windows/Direct3D9. I've already implemented some hacks to fix this problem with Intel GPUs, but it's possible that this fix doesn't work with AMD/NVidia GPUs, I'm not sure. Feel free to add a bug report to the madVR bug tracker about this problem, if there isn't one already. Maybe if I find some time I'll see if I can workaround the problem with AMD/NVidia GPUs, too. It's not a madVR bug, though, but a bug in Windows or Direct3D9 or in the GPU drivers. madVR clearly requests 24.000Hz, according to the log.


I found this... In my display settings, I have checked 'Let me choose one scaling level for all my displays'.. I uncheck this and trouble is gone!

Regards!

[Niyawa]

Yes, sorry, forgot to add that to the interface.
We appreciate it.

If it works with your specific OS/GPU/driver setup then it's usually beneficial to enable it. At least it rarely harms. There have been some reports about problems with this option, though. E.g. some AMD/NVidia laptop users with a shared AMD/NVidia <-> Intel GPU had problems. Also the latest Intel drivers don't play nice with this option. These are all GPU driver problems, though, and not madVR's fault.
Hm, so it's more or less as I thought. Thanks for the help.

I've heard about this only if there's a display mode change and the display needs 5 seconds to resync.
Strange. When I change my display mode it takes about 1-2 seconds most, I guess this goes from display to display.

Oh yeah, there's one more thing I'd like everyone to give their thoughts about. This user (haruhichan.com/forum/showthread.php?7545-KCP-Kawaii-Codec-Pack&p=28213&viewfull=1#post28213) has been having issues with madVR output to TV with HDMI. We're not particularly sure what is causing that so any input here would be welcome.

[ryrynz]

Never mind have to look into this one..

[6233638]

The disabling of dithering for pixels which don't need it is has 3 potential benefits:

(1) With full black or white video areas, dithering ever so slightly increased the black level and decreased peak white brightness. This also meant that some displays didn't "recognize" full black video areas, due to dithering, and thus they didn't turn off the local dimming LEDs etc. With the new test build, hopefully this problem should be solved.Thank you for the fix. If calibration is disabled, or I tell madVR that my display is calibrated to BT.709, things work as expected. But if I enable yCMS calibration (lowest value is a 5% measurement) I'm still seeing an elevated black level.

[Megalith]

Quick question. The decoding options (decode MPEG2/VC-1/h264) under the "processing" tree only need to be checked if you aren't using any other kind of video decoder, correct? So with the latest release of MPC-HC, which includes the LAV Video Filter, these may be left off?

EDIT: I've answered my own question. Now I'd like to know if the madVR decoder is better than the LAV one, or if they produce identical output.

[LoRd_MuldeR]

EDIT: I've answered my own question. Now I'd like to know if the madVR decoder is better than the LAV one, or if they produce identical output.

In theory, any decoder is supposed to give identical output for an identical input bitstream.

Differences in the output can only be the result of decoder bugs or additional post-processing, but the latter isn't really part of the actual decoder anymore.

Biggest difference between different decoders is the performance and whether they are implemented in software or use "hardware" acceleration.

[THX-UltraII]

Hi , i know that with an HTPC i've got to output in RGB (4:4:4) 0-255 for the best quality , and in the catalyst control panel i've setted it (RGB full). About the level I've got coreavc that can set the input level and the output level separately 0-255 or 16-235 . Now , i know that the Blu ray level is 16-235 , so i have setted the coreavc input level in 16-235 . About the output level i want coreavc untouch the signal level and i've setted it to 16-235 too .
In the final In madvr i've setted 0-255 . Is this all ok for the best quality? Or have i to set 0-255 madvr and coreavc too ?

Thank you, Fabio

Now that (I think) that I know how all things works I ll try to summarize the BTB/WTW discussion. You basically have 3 options:

1.
Set madvr to pc levels, set gpu to pc levels, set TV to pc levels (0-255). This means, that BTB and WTW will be clipped, it also means that there is expansion involved, which might lead to banding. madvr dithering does a good job of eliminating that.

2.
Set madvr to TV levels, set GPU to pc levels, set TV to TV levels. This means there will be neither clipping nor expanding.

3.
If your TV doesn't have settings to change black levels and is fixed to TV levels: Set madvr to PC, GPU to TV. BTB and WTW will be clipped, and there is double processions going on (expansion by madvr -> reduction by gpu).

The second option is the best quality wise, because there is no processing of the levels involved, and therefore no banding introduced. The problem is that if you use your PC for anything but viewing through madvr, your levels will be messed up.

There is also a 4th option if you want both limited(video) and full-range(pc applications) to display properly. If you can adjust input mapping on your display (usually low or limited vs. normal or full) then use option 2 and switch display input to normal when displaying desktop applications.

[Asmodian]

Thank you for the fix. If calibration is disabled, or I tell madVR that my display is calibrated to BT.709, things work as expected. But if I enable yCMS calibration (lowest value is a 5% measurement) I'm still seeing an elevated black level.

I hope this issue will be fixed by the new Argyll 1.6.2 but I haven't tested it yet. The new Argyll might also address (some of) the issues you have had with it in the past?

[6233638]

I hope this issue will be fixed by the new Argyll 1.6.2 but I haven't tested it yet. The new Argyll might also address (some of) the issues you have had with it in the past?I think that issue is unrelated, as I'm still using the yCMS options in madVR rather than loading an external 3DLUT.

[madshi]

@madshi
I have problems with YV16 in madVR. But it is not clear reason in decoder or renderer.
http://i.imgur.com/YQh8eq9s.jpg (http://i.imgur.com/YQh8eq9.jpg)
Hmmmm... Is this your own decoder, respectively the MPC-HC decoder? Or LAV? Or something else? I can look into this, if you think it might be a renderer issue, but I'd need to be able to reproduce it somehow.

Are there settings for changing the black/white levels in the settings dialog along with the keyboard shortcuts? Also, does changing them adjust the top and bottom of the gamma curve?
Which black/white levels are you talking about? The source black/white levels? Or the display black/white levels? There are settings for the display in the settings dialog - but not settings for the source, because by definition source black/white levels may differ from source to source, so it makes no real sense specifying them in the settings dialog.

may i ask is there any x64 release of this VR?
No. There might be one some time in the future, but probably not any time soon.

I found this... In my display settings, I have checked 'Let me choose one scaling level for all my displays'.. I uncheck this and trouble is gone!
Weird. I'm not sure why such a setting would affect the refresh rate switching!

Oh yeah, there's one more thing I'd like everyone to give their thoughts about. This user (haruhichan.com/forum/showthread.php?7545-KCP-Kawaii-Codec-Pack&p=28213&viewfull=1#post28213) has been having issues with madVR output to TV with HDMI. We're not particularly sure what is causing that so any input here would be welcome.
I don't know what that would be. First check would be to try windowed mode instead of fullscreen exclusive mode. In windowed mode at least the media player window should be visible. If it is, does madVR show video rendering? If not, try disabling Overlay mode, in case it's activated. Of course it's possible that the GPU doesn't support PS3.0 pixel shaders, then madVR can't render.

Thank you for the fix. If calibration is disabled, or I tell madVR that my display is calibrated to BT.709, things work as expected. But if I enable yCMS calibration (lowest value is a 5% measurement) I'm still seeing an elevated black level.
The feature works by checking if the output pixel happens to be a straight cardinal 8bit value (or very near to that). If it is, dithering can be safely disabled for this pixel. If there's a fractional part (worth mentioning) then dithering is necessary to produce a correct color (averaged over a bigger image area).

If dithering is not disabled for a pure black screen with yCMS calibration then that means that the yCMS 3dlut probably produces a fractional black level value for some reason. I don't know why. It could be a problem with yCMS, or a result of your display needing black correction of some sort, or some sort of inaccuracy in madVR's 3dlut processing. In the first 2 cases there's probably not much I can do about it.

In theory, any decoder is supposed to give identical output for an identical input bitstream.

Differences in the output can only be the result of decoder bugs or additional post-processing, but the latter isn't really part of the actual decoder anymore.

Biggest difference between different decoders is the performance and whether they are implemented in software or use "hardware" acceleration.
Mostly agreed. Two minor additions/corrections:

(1) I've read that the decoder is only 100% strictly defined for h264. For MPEG2 I've read that there's a tiny room of interpretation. So h264 decoder output should be bit identical, but MPEG2 decoder output might not be. But it's probably a very minor difference.

(2) Different decoders can produce different timestamps, which can result in different levels of motion smoothness. E.g. with really bad MPEG2 broadcasts, depending on the decoder behaviour some sections might be smooth or not smooth.

From a technical point of view, if the splitter timecodes contain jitter, decoder A might decide to use the splitter's I frame timecodes and interpolate the other timecodes. Decoder B might decide to use some sort of timecode averaging/smoothing. Decoder C might pass the splitter timecodes through untouched.

Another difference is when the decoder restarts its timecode logic. Some decoders do that when DirectShow reports a discontinuity. Others do it with every I frame.

"Bad" timecodes can result in motion judder/stutter, but that also depends on the renderer. madVR is a bit less sensitive about jittery timecodes than some other renderers, but with really bad timecodes you can bring madVR into trouble, too.