madVR - high quality video renderer (GPU assisted)

[JarrettH]

"lose BTB and WTW if it improves performance"

What's this one exactly? I know it's black to black and white to white :P

[Asmodian]

madVR v0.87.15 released Mostly v0.87.15 is about fixing bugs, and improving DXVA related stuff. Some of these changes go a bit deeper than previous v0.87.x minor releases, so a few new bugs could eventually show up. If so, please let me know.

Wow some big fixes in there though, portrait mode! Optimus too. Amazing. :D

:thanks:

edit:
I like that the OSD has a quite detailed report on the resize algorithm. I did find what seems like an oddity; when using image doubling on both luma and chroma but using a different number of neurons for chroma. The OSD simply reports "image" and the number of neurons used for luma instead of luma and chroma as it does when not doubling the chroma. This is not a big deal but it might as well use the same luma and chroma entries. :)

"lose BTB and WTW if it improves performance"

What's this one exactly? I know it's black to black and white to white :P

It is actually "Blacker Than Black" and "Whiter Than White". If losing below 16 and above 235 allows a speed optimization, use it. I am not sure what the optimization would be or when it would apply though. ;)

[Siso]

A quick question, using madvr on 72 hz Dell u2913wm, with version 0.87.13 and 0.87.14 the info "1 frame repeat every /1 frame drop every " was from 6 hours to 3 days etc., with 0.87.15 is always around ~ 1 hour and 10-40 min, is this a bug or incorrect info, I'm using reclock.

[StinDaWg]

Thanks for all the IVTC decimation/cadence fixes!

[ryrynz]

If losing below 16 and above 235 allows a speed optimization, use it. I am not sure what the optimization would be or when it would apply though. ;)

Madshi, could you impart some knowledge in what particular situations a typical user would not want this option disabled?

[madshi]

Great... That option was the only way for me to use NNEDI normally.
Really? I know that some people needed this option, but that before I had implemented a significant interop speedup. So I had hoped that after the speedup this option wouldn't be needed, anymore. If you absolutely do need it, I can put it back. I've just hidden it, the code is still there. Removing the option was kind of a test balloon to see if anybody would notice and complain.

Otherwise framerate detection (display xx.xxxxx Hz) now constantly resets to 0s and they both with GPU load start to jump like crazy, and I get stuttering with some presentation glitches reported. Nothing I've tried since then fixed it.
Try adding an empty file "disableRefreshRate1" into the madVR folder. Does that fix this problem? If not, try renaming it to "disableRefreshRate2". Does that fix it?

"lose BTB and WTW if it improves performance"

What's this one exactly? I know it's black to black and white to white :P
It is actually "Blacker Than Black" and "Whiter Than White". If losing below 16 and above 235 allows a speed optimization, use it. I am not sure what the optimization would be or when it would apply though. ;)
It allows madVR to use integer textures instead of floating point textures in some situations, which may improve performance.

Wow some big fixes in there though, portrait mode! Optimus too. Amazing. :D
Does it work? Especially the Optimus fix is just a hope, I wasn't able to verify that it works yet.

when using image doubling on both luma and chroma but using a different number of neurons for chroma. The OSD simply reports "image" and the number of neurons used for luma instead of luma and chroma as it does when not doubling the chroma. This is not a big deal but it might as well use the same luma and chroma entries. :)
Yeah, I'll rather keep it the way it is. Things are complicated enough as they are, e.g. when using different algorithms for X and Y!

A quick question, using madvr on 72 hz Dell u2913wm, with version 0.87.13 and 0.87.14 the info "1 frame repeat every /1 frame drop every " was from 6 hours to 3 days etc., with 0.87.15 is always around ~ 1 hour and 10-40 min, is this a bug or incorrect info, I'm using reclock.
This information has always been an estimate, not something you can fully trust in. FWIW, v0.87.15 has modified the way it calculates refresh rates, this probably is causing the estimation change. That shouldn't have an effect on anything other than the estimate.

Thanks for all the IVTC decimation/cadence fixes!
No problem. Have you had a chance yet to check whether all problems are fixed?

Madshi, could you impart some knowledge on in what situations for a typical user one would not want this option disabled? Thanks.
It's a "trade quality" option like all the others. So don't use it if you're looking for best quality. But do use it if you need the extra performance. Usually it shouldn't hurt (much) to enable this option, unless you have a very specific calibration that includes some BTB/WTW content. If you have that then you will know not to enable this option.

[Qaq]

with 0.87.15 is always around ~ 1 hour and 10-40 min, .... I'm using reclock.Perhaps you need to reset ReClock's database.

[Siso]

Perhaps you need to reset ReClock's database.

I did that yesterday, but it is the same :) Thank you for the reply madshi :)

[hannes69]

One remark to the new version:
I use Windows 7 64 bit, Aero Theme, AMD R7 250 GPU, Catalyst 14.12. Up to version 0.87.14 I disabled desktop composition for FSE mode in the madvr options. Using the same options, in 0.87.15 the presentation glitch counter moves up by one every 8 seconds of playback regardless of the playbacked content. By enabling desktop composition I can avoid this.
I just wanted to give an information about this if someone else runs into this problem.
Thanks for the new version!

[ryrynz]

It's a "trade quality" option like all the others. So don't use it if you're looking for best quality. But do use it if you need the extra performance. Usually it shouldn't hurt (much) to enable this option, unless you have a very specific calibration that includes some BTB/WTW content. If you have that then you will know not to enable this option.

So I expect most users won't see any difference and gain a touch of speed having this enabled, figured as much, cheers.

BTW, for anyone blindly pasting over a previous software decoder enabled version, you can safely delete avcodec-mvr-53.dll and avutil-mvr-51.dll from your madVR installation directory.

[JonnyRedHed]

know issue. since driver version 347.25
http://bugs.madshi.net/view.php?id=250

i don't think mode 2 is better it's just different. just choice what looks better to you, if you don't see a difference don't use it.

I've dropped back to 347.09 and am still getting the issue and other odd flickering.

[cyberbeing]

This information has always been an estimate, not something you can fully trust in. FWIW, v0.87.15 has modified the way it calculates refresh rates, this probably is causing the estimation change. That shouldn't have an effect on anything other than the estimate.

From what I'm seeing, the Refresh Rate updates actually appear to be broken and never updating when the Windowed Mode (new path) is enabled, which is very abnormal especially during the few seconds of playback. Oddly, having the Windowed Mode (new path) enabled also breaks Refresh Rate updates for FSE (new path) as well. It appears as though madVR isn't attempting to calculate the refresh rate at all, and instead just reporting a fixed value based on the Desktop Composition Rate? In this case, it starts reporting 96.00000Hz (exactly the inaccurate desktop compaction integer rate), then a few ms later to either 95.90400Hz or 95.90465 and then never budges even +/- 0.00001Hz after that point. Both madVR debug logs and the OSD seem in agreement.

Yet if I enable Windowed Mode (old path) and restart madVR, OSD Refresh Rate reports functions correctly and updates constantly every second with a more accurate measurement using both Windowed (old path) & FSE (new path). Can anyone else reproduce this? I'll create a bug report after I wake up tomorrow if still needed. (Win7 x64 SP1, GTX 770, 347.90)

Edit: I can also reproduce a madVR hang (video display freezes) if I disable Windowed Mode (new path) during the first couple seconds of playback. Anyway heading to bed since it's 4am now.

[heiseikiseki]

Madshi, I'm using a optimus desktop(ASUS ROG GR8),
but I didn't have the black screen problem since I updated the drivers of the intel and Nvidia in 0.87.13.
So I think that other optimus laptop may be the same.
Only needs to update the drivers.

But the performance of optipus seens not good. Even GR8 has a GTX750TI，performed just like a HD7750，
I can't do nnedi3 16 on HD to FHD.(cause dropped frames) even the rendering time is only 28ms or lower.

I think the performance is not good is because the output port(HDMI/DISPLAY PORT) is from INTEL GPU.


Sorry for my bad English.

[huhn]

From what I'm seeing, the Refresh Rate updates actually appear to be broken and never updating when the Windowed Mode (new path) is enabled, which is very abnormal especially during the few seconds of playback. Oddly, having the Windowed Mode (new path) enabled also breaks Refresh Rate updates for FSE (new path) as well. It appears as though madVR isn't attempting to calculate the refresh rate at all, and instead just reporting a fixed value based on the Desktop Composition Rate? In this case, it starts reporting 96.00000Hz (exactly the inaccurate desktop compaction integer rate), then a few ms later to either 95.90400Hz or 95.90465 and then never budges even +/- 0.00001Hz after that point. Both madVR debug logs and the OSD seem in agreement.

Yet if I enable Windowed Mode (old path) and restart madVR, OSD Refresh Rate reports functions correctly and updates constantly every second with a more accurate measurement using both Windowed (old path) & FSE (new path). Can anyone else reproduce this? I'll create a bug report after I wake up tomorrow if still needed. (Win7 x64 SP1, GTX 770, 347.90)
after some time the refresh isn't changing at all. i have to investigated old path more but that doesn't work at all anymore.
Edit: I can also reproduce a madVR hang (video display freezes) if I disable Windowed Mode (new path) during the first couple seconds of playback. Anyway heading to bed since it's 4am now.

reproduced and reported.

[Siso]

Same problem here :/

[madshi]

From what I'm seeing, the Refresh Rate updates actually appear to be broken and never updating when the Windowed Mode (new path) is enabled
Does the "second counter" (not minute but second) increase during playback? If so, refresh rate calculation is working fine. I've added the second counter to make sure everything's still working ok. madVR v0.87.15 knows several methods to calculate the refresh rate. The "newer" methods are more stable than the older methods, because of that it locks into the detected refresh rate very quickly and as a result doesn't *have* to change, anymore. That doesn't mean refresh rate detection is broken, as long as the second counter is increasing.

That said, I plan to change the whole logic again in the next build.

Madshi, I'm using a optimus desktop(ASUS ROG GR8),
but I didn't have the black screen problem since I updated the drivers of the intel and Nvidia in 0.87.13.
So I think that other optimus laptop may be the same.
Only needs to update the drivers.

But the performance of optipus seens not good. Even GR8 has a GTX750TI，performed just like a HD7750，
I can't do nnedi3 16 on HD to FHD.(cause dropped frames) even the rendering time is only 28ms or lower.

I think the performance is not good is because the output port(HDMI/DISPLAY PORT) is from INTEL GPU.
There were always some Optimus users who had problems and others who didn't. I'm not sure if the fix I implemented works or not. So I'm still waiting for feedback from those who had problems before.

[JohnLai]

@mashi,

Is there any method to show if hardware acceleration is being used at madvr OSD?
If DXVA native is being selected at lavf, there is a [DXVA2] shown at the OSD.
But if other method is being used, eg:Quicksync, CUVID,DXVA CopyBack, these are not being shown at all.

[kasper93]

Because only in native mode renderer knows that H/W acceleration is used. Your player should have indication whether H/W acceleration is used. (e.g MPC-HC have this information on status bar)

[JohnLai]

Because only in native mode renderer knows that H/W acceleration is used. Your player should have indication whether H/W acceleration is used. (e.g MPC-HC have this information on status bar)

Strange are you certain about this? EVR CP can display it on OSD like this :

"H.264 E, bitstream decoder, no FGT [ LAV Video Decoder (Intel Quicksync) ]"

[nevcairiel]

The player tells EVR-CP, the renderer doesn't find out on its own. And really, the renderer doesn't even care, nor should it. It only cares if its DXVA2 Native mode, because it then receives the image differently. For all the other modes, it receives the image the exact same way, no matter if software, QS, CUVID or DXVA2-CopyBack.

[aufkrawall]

In this picture, Shiandow's deband filter seems to give a better result than madVR's@high:

madVR:
http://abload.de/thumb/madvrdebandj3armxuft.png (http://abload.de/image.php?img=madvrdebandj3armxuft.png)

MPDN Shiandow (new mode):
http://abload.de/thumb/mpdndebandj4aruyuwh.png (http://abload.de/image.php?img=mpdndebandj4aruyuwh.png)

Yes, madVR Jinc3 AR is much sharper than MPDN Jinc4 AR, but the banding is not related to this.
Shiandow deband + SuperRes:
http://abload.de/thumb/mpdndebandsuperres35usv.png (http://abload.de/image.php?img=mpdndebandsuperres35usv.png)

[MS-DOS]

Really? I know that some people needed this option, but that before I had implemented a significant interop speedup. So I had hoped that after the speedup this option wouldn't be needed, anymore. If you absolutely do need it, I can put it back. I've just hidden it, the code is still there. Removing the option was kind of a test balloon to see if anybody would notice and complain.

Try adding an empty file "disableRefreshRate1" into the madVR folder. Does that fix this problem? If not, try renaming it to "disableRefreshRate2". Does that fix it?


disableRefreshRate1 - refresh rate still jumping and the amout of presentation glitches is about the same as without it
disableRefreshRate2 - refresh rate is stable, but the amout of glitches and stuttering is now beyond roof

Only ~60% GPU usage in all three cases =\ While using alternative hack, I had about 1-2% more GPU load in that particular video I tested but could bump every single option like neurons up having a perfectly smooth playback until I reached 99% GPU load where it just obviously couldn't handle it. So, yeah, here's your balloon :)

[madshi]

And really, the renderer doesn't even care, nor should it.
Agreed. No plans to add this to the OSD.

In this picture, Shiandow's deband filter seems to give a better result than madVR's@high
It's not the same video frame! If you look at the trees in the background, they move slightly. Such comparisons only make sense if you use exactly the same video frame. Furthermore, debanding is always a compromise between removing artifacts and maintaining details. So just looking at debanding smoothness doesn't help much if you don't look for detail loss at the same time. For a really meaningful comparison please make sure you use exactly the same video frame, and also the same scaling algorithms. I'd suggest Lanczos3 *without* anti-ringing. Then the image should be equally sharp, which allows us to better compare debanding quality. Please also use an alternative test image which allows us to compare detail loss.

All that said, it's possible that Shiandow's filter could be better for "high" debanding. I've put most of my development efforts into the "low" and "mid" settings. For "high" I've just dialed the tresholds up, and even disabled some parts of the algorithm. Once I've added support for extended custom shaders, it should be easy to make all of Shiandow's algorithms work in madVR, too.

disableRefreshRate1 - refresh rate still jumping and the amout of presentation glitches is about the same as without it
disableRefreshRate2 - refresh rate is stable, but the amout of glitches and stuttering is now beyond roof

Only ~60% GPU usage in all three cases =\ While using alternative hack, I had about 1-2% more GPU load in that particular video I tested but could bump every single option like neurons up having a perfectly smooth playback until I reached 99% GPU load where it just obviously couldn't handle it. So, yeah, here's your balloon :)
Ok, thanks.

[aufkrawall]

I really tried to jump to the exact frame, but unfortunately, MPDN didn't let me.
Hm, I may need the help of AviSynth.

However, I'm very sure that there's not a noteworthy difference in banding between the two frames (gap shouldn't be larger).

[madshi]

You can use Ctrl+Right (at least in MPC-HC) to move forward frame by frame. That should allow you to get to the same frame.

[aufkrawall]

I see that now. I really didn't realize the tree has moved a little in the background. Already confusing enough that NNEDI3 shifts the image. :o

Ok, will test again with Lanczos 3 w.o. AR and will find us another test image. Probably a game screenshot would fit well, since they usually have very fine detail compared to movies.

[madshi]

The important thing is that the detail must be low contrast. High-contrast detail isn't affected by debanding. E.g. fine detail in a very low contrast shadow area should work well to test debanding algorithms. The detail should be so that the algorithm mistakes it for banding, but the intelligent human eye sees that it's detail and not banding. Banding is usually only 1-2 steps on the grayscale away from the next pixel. So the detail can't have more contrast than 1-2 grayscale steps (max!).

[Asmodian]

Yes, madVR Jinc3 AR is much sharper than MPDN Jinc4 AR, but the banding is not related to this.

madVR Jinc3 is equivalent to MPDN Jinc6. MadVR's debanding is meant to be pretty subtle, so as not to change the video too much, not to be the strongest at removing banding.

[aufkrawall]

MPDN doesn't offer Lanczos 3 taps, so I set both renderers to 8 (both luma and chroma). However, they are still not totally equivalent (but almost).

madVR Lanczos 8:
http://abload.de/thumb/mpchcl8gjjxo.png (http://abload.de/image.php?img=mpchcl8gjjxo.png)

madVR Lanczos 8 + deband@high:
http://abload.de/thumb/mpchcl8deband0qkdt.png (http://abload.de/image.php?img=mpchcl8deband0qkdt.png)

MPDN Lanczos 8:
http://abload.de/thumb/mpdnl81vkh9.png (http://abload.de/image.php?img=mpdnl81vkh9.png)

MPDN Lanczos 8 + Shiandow deband:
http://abload.de/thumb/mpdnl8debandjpjny.png (http://abload.de/image.php?img=mpdnl8debandjpjny.png)

To my eyes, Shaindow's algorithm fights much better banding at the sign, the walls or also the table.

Now I'm gonna try to find a more detailed picture. At least in the very low quality pictures above, I could hardly see details vanashing.

[madshi]

MPDN doesn't offer Lanczos 3 taps, so I set both renderers to 8 (both luma and chroma). However, they are still not totally equivalent (but almost).
MPDN counts taps differently compared to madVR. madVR 3 taps = MPDN 6 taps.

To my eyes, Shaindow's algorithm fights much better banding at the sign, the walls or also the table.
Now here comes the problem: How much of that is actually banding and how much is compression artifacts? Banding means visible steps in large gradients caused by rounding to a too small bitdepth. Most of the artifacts in your image appear to be compression noise to me (blocking and mosquito noise artifacts). Is a debanding algorithm supposed to remove compression noise? Well, it doesn't hurt if it does, but then I wonder if it does that, maybe it also removes more detail? I don't know, just wondering. As I said, it's possible that Shiandow's algo is better at this debanding strength. But we first need to test for detail loss.

[cyberbeing]

Does the "second counter" (not minute but second) increase during playback? If so, refresh rate calculation is working fine. I've added the second counter to make sure everything's still working ok. madVR v0.87.15 knows several methods to calculate the refresh rate. The "newer" methods are more stable than the older methods, because of that it locks into the detected refresh rate very quickly and as a result doesn't *have* to change, anymore. That doesn't mean refresh rate detection is broken, as long as the second counter is increasing.

Yes, the counter is increasing just fine in both cases. Though when Windowed mode (new path) is enabled the actual refresh rate calculation doesn't seem accurate. If I mess around with toggling render mode settings, sometimes I see madVR make sudden jumps between claiming the the refresh is the desktop composition rate (96.00000Hz) and this other rate (95.90465Hz) with no other values reported in-between in the middle of playback.

Any idea why when I enable Windowed mode (old path), madVR behaves like older builds and updates and refines the calculation every second in small 0.00001Hz-0.00004Hz movements until it settles on a values only after a couple minutes or so of playback?

If this an entirely separate refresh rate algorithm, it seems considerably more reliable on 'traditional desktop PCs' considering as it never makes massive sudden jumps and always seems to settle on the same refresh rate that older builds of madVR always did reliably (95.90445Hz). Actually, after looking at your old post this seems to be the case. If I add a 'disableRefreshRate2' file to the madVR directory it resolves the refresh rate calculation issue with Windowed mode (new path) is enabled.

That said, I plan to change the whole logic again in the next build.

There were always some Optimus users who had problems and others who didn't. I'm not sure if the fix I implemented works or not. So I'm still waiting for feedback from those who had problems before.
Ah, so I assume this 'Refresh Rate 2' method was part of the 'try not to break for Optimus users' fixes, while 'Refresh Rate 1' is the older traditional method which madVR has always used?

It madVR intentional defaults to 'Refresh Rate 2' with Windowed (new path) or rather what should be madVR defaults on a new install, this all makes sense now. Will the ability to disable the 'Refresh Rate 2' method remain in future builds, or were you intending to actually refine this method and eventually eliminate the traditional 'Refresh Rate 1' method?

Edit: I can also reproduce a madVR hang (video display freezes) if I disable Windowed Mode (new path) during the first couple seconds of playback.
FWIW, adding the 'disableRefreshRate2' file to my madVR directory also seems to resolve this hanging issue when stitching new->old path Windowed modes.

[madshi]

Yes, the different refresh rate behaviour was fully intended. And the jump from 96.000Hz to the correct rate was part of the algorithm. The "new" method doesn't work with the old windowed mode, though. There are also a couple of other circumstances in which the new method doesn't work. Furthermore, I've received feedback from a user who said that in dual monitor setup the "new" method has severe problems. So for the next madVR build I'll go back to the old method and use the new one only if the old one doesn't work. That should still fix the Optimus problems. At least I hope so.

[madshi]

madVR v0.87.16 released

http://madshi.net/madVR.zip

* fixed: #181: "deint" tag sometimes didn't work when using profiles
* fixed: #267: crash when seeking with smooth motion enabled
* fixed: #272: black screen in old windowed mode
* fixed: #275: image freeze when switching from new path to old path window mode
* fixed: some BT.709 video files were misdetected as BT.601
* reintroduced the "interop hack" option
* improved DXVA color space conversion performance again
* added trade option "trust DXVA color & levels conversion"
* SettingsSetBoolean("DebugOsd") now turns the debug OSD on/off
Just to make sure this doesn't get lost:

There's now a DSPlayer version (XBMC/kodi) available with full support for madVR. It's still a work in progress, but already looking good. It's a custom build, though, and not officially endorsed by the kodi devs. Still, it's based on the latest kodi sources, AFAIK. See here for more details:

http://forum.kodi.tv/showthread.php?tid=154534

[TheElix]

Hi, madshi! Great to know the project's alive and kickin'! After the update to 0.87.16 I have weird colors. Here's a comparison against the screenshot (the one above):
http://i.imgur.com/wPmvylKl.png

[sneaker_ger]

Post a sample and your config and screenshot of OSD.

[TheElix]

Post a sample and your config and screenshot of OSD.OSD: https://yadi.sk/i/O3n4S3wPffChr
Torrent file (315 Mb): http://www.nyaa.se/?page=view&tid=670389

What config do you mean? MadVR or my hardware? I have an AMD GPU (HD7990).

[nevcairiel]

Almost looks like U/V are swapped.
On second thought, maybe not.

But your madVR config would be useful. What I can think of would be a possible 3DLUT or other color calibration settings, for example.
Entire settings to be safe. ;)

[TheElix]

But your madVR config would be useful. What I can think of would be a possible 3DLUT or other color calibration settings, for example.
Entire settings to be safe. ;)There are no 3DLUTs loaded on an active display. There are 3DLUTs active, however, on inactive displays. Is there a function to copy entire madVR settings? There're no settings in the log file, unfortunately.

Edit: I hope that's enough settings: https://yadi.sk/d/QMPfjQpCffEN9

[kasper93]

@TheElix: See this post http://forum.doom9.org/showpost.php?p=1715342&postcount=57 and you will know what to do :)

[fairchild]

As always, thanks madshi for the new versions of MadVR. There is some new behavior introduced in latest version which is causing a bug with FSE search bar from MadVR to not display because for some reason. Going to the bottom of the screen triggers MPC-HC's navigation bar to kick in which kicks the video out of FSE into windowed mode for some odd reason.

I verified that it's the latest v0.87.16 because when rolling back to v0.87.15 I can retain MadVR's FSE seek bar and MPC-HC stays in background properly as it should.

[Qotscha]

As always, thanks madshi for the new versions of MadVR. There is some new behavior introduced in latest version which is causing a bug with FSE search bar from MadVR to not display because for some reason. Going to the bottom of the screen triggers MPC-HC's navigation bar to kick in which kicks the video out of FSE into windowed mode for some odd reason.

I verified that it's the latest v0.87.16 because when rolling back to v0.87.15 I can retain MadVR's FSE seek bar and MPC-HC stays in background properly as it should.

I have the same issue with 0.87.16. However, enabling OSD prevents MPC-HC navigation bar from showing.

[TheElix]

@TheElix: See this post http://forum.doom9.org/showpost.php?p=1715342&postcount=57 and you will know what to do :)That did it, Kasper... Thanks.)

[fairchild]

I have the same issue with 0.87.16. However, enabling OSD prevents MPC-HC navigation bar from showing.

Yep, just verified that. enabling the OSD by doing CTRL+J and then going FSE allows MadVR's FSE bar to function as it should. I'm 100% sure this is not the intended behavior unless we are meant to watch all videos with the OSD up :p

[kasper93]

IMadVRSettings::SettingsGetBoolean(L"enableExclusive", &bOptExcl);
IMadVRSettings::SettingsGetBoolean(L"enableSeekbar", &bOptExclSeekbar);

Both returns false, while it should be true in exclusive mode and when seekbar is enabled. At least it was like that ;p

[Shii]

Found a problem with latest Kaspersky Internet Security 15.0.1.415(c) and it's process avpui.exe. When running, sometimes it prevents madVR from entering Fullscreen Exclusive Mode. Only full antivirus unloading helps.
My setup: Windows 7 SP1, monitor and tv in extended mode. Monitor works at 1920x1080 60Hz DVI, TV - 1920x1080 24Hz HDMI. GeForce GTX 660Ti.

madVR log:
00013685 Render CSettings::GetCurrentWhiteLevel(self: 15AD6018) -> 255
00013685 Render COsd::Update(self: 158926C8);
00013685 Render fullscreen windowed mode, covered by some windows
00013685 Render madVR window [madVR] {-1920,0,0,1080}
00013687 Render covered by avpui.exe window [AVP.SandboxWindow] {-1920,0,3840,1080}
00013687 Render COsd::SetBitmap(self: 158926C8, name: madVR.internal.DebugOSD, leftEye: 01051F0F, posX: 10, posY: 10, duration: 0);
00013688 Render CQueue::IsStillImage();
00013688 Render CQueue::IsStillImage() -> no

[madshi]

Hi, madshi! Great to know the project's alive and kickin'! After the update to 0.87.16 I have weird colors. Here's a comparison against the screenshot (the one above):
@TheElix: See this post http://forum.doom9.org/showpost.php?p=1715342&postcount=57 and you will know what to do :)
Good catch by kasper93. FWIW, I've suggested a little change to the FineSharp scripts to fix this issue.

As always, thanks madshi for the new versions of MadVR. There is some new behavior introduced in latest version which is causing a bug with FSE search bar from MadVR to not display because for some reason. Going to the bottom of the screen triggers MPC-HC's navigation bar to kick in which kicks the video out of FSE into windowed mode for some odd reason.

I verified that it's the latest v0.87.16 because when rolling back to v0.87.15 I can retain MadVR's FSE seek bar and MPC-HC stays in background properly as it should.
SettingsGetBoolean(L"enableExclusive", &bOptExcl);
SettingsGetBoolean(L"enableSeekbar", &bOptExclSeekbar);

Both returns false, while it should be true in exclusive mode and when seekbar is enabled. At least it was like that ;p
kasper93 is doing all the work for me... :)

Thanks, that was a stupid mistake. I hate when I have to release a new build just because of one stupid mistake.

Found a problem with latest Kaspersky Internet Security 15.0.1.415(c) and it's process avpui.exe. When running, sometimes it prevents madVR from entering Fullscreen Exclusive Mode. Only full antivirus unloading helps.
My setup: Windows 7 SP1, monitor and tv in extended mode. Monitor works at 1920x1080 60Hz DVI, TV - 1920x1080 24Hz HDMI. GeForce GTX 660Ti.

madVR log:
00013685 Render CSettings::GetCurrentWhiteLevel(self: 15AD6018) -> 255
00013685 Render COsd::Update(self: 158926C8);
00013685 Render fullscreen windowed mode, covered by some windows
00013685 Render madVR window [madVR] {-1920,0,0,1080}
00013687 Render covered by avpui.exe window [AVP.SandboxWindow] {-1920,0,3840,1080}
00013687 Render COsd::SetBitmap(self: 158926C8, name: madVR.internal.DebugOSD, leftEye: 01051F0F, posX: 10, posY: 10, duration: 0);
00013688 Render CQueue::IsStillImage();
00013688 Render CQueue::IsStillImage() -> no
Uhm, that's really ugly. Seems they have a window which is probably "on top" and covers both of your monitors. Probably the window is transparent or something, I don't know. It seems weird. But that's what the log says. There isn't really much I can do about it, I fear.

[madshi]

madVR v0.87.17 released

http://madshi.net/madVR.zip

* fixed: FSE seekbar didn't show, anymore
No further changes planned for the next 2-3 weeks, unless some important new bug shows up.

[MS-DOS]

* reintroduced the "interop hack" option


NNEDI is working fine again, thanks :)

[cyberbeing]

madVR v0.87.17 released
No further changes planned for the next 2-3 weeks, unless some important new bug shows up.
I have an important new bug. ;)
http://bugs.madshi.net/view.php?id=276

Ever since madVR 0.87.10, TV.601 subtitle colors are incorrect on TV.709 when upscaling if the subtitle trade quality for performance option is enabled.

[ThurstonX]

Thanks for the new versions, and esp. getting the fix in before you take a madVR break. I had to laugh when I saw the date stamp: 4/1/2015 12:37 AM. It's software from the future! As long as it's not an April Fool's joke ;-)