madVR - high quality video renderer (GPU assisted)

[Warner306]

Originally Posted by Schwartz

That's the reason I haven't touched sharpening either. I rather take a softer picture without extra artifacts. Remember ffdshow's xsharpen? Now that would be a filter I'd like to see some time in madVR. It was fairly lightweight and it even reduced artifacts.

SuperRes with the right setting looks pretty good. Every other sharpener rings too much. If SuperRes could be adapted to Image Enhancements, I'd be set.

[huhn]

Originally Posted by James Freeman

How do you think 50fps film on a 120Hz monitor with SmoothMotion will perform/look?
24fps on a 60Hz monitor ratio is 2.5, so 50fps on 120hz will be 2.4.

should be totally fine on a 120 hz screen

a blended frame is shown for 8.33 ms so the refresh rate doesn't really matter.

Originally Posted by dansrfe

But you can sort of eyeball gradient patterns on images in exclusive mode to check, right? Or is that unreliable too?

it's unreliable. could be easily dithered to 8 bit too.

For the record, I did try the image test as the other thread on the topic suggested and although it suggests the screen is 10-bit with a 10-bit signal, I find it hard to believe since 10-bit screens are supposed to be crazy expensive and mine is not.

10 bit panel kind of doesn't exist. most of them are relative cheap adobeRGB photo monitors and some of the high end displays from this year are 10 bit for HDR and bigger colorspaces.

a proper screen that supports 10 bit/12 bit input can just dither the input to 8 bit which looks smooth like madVR dither.

AMD dithers 10 bit input to 8 bit for all displays that doesn't support 10 bit input. nvidia does the same for me too.

getting 10 bit in a screen doesn't tell us anything about the bit deep of the screen.

a true 10 bit display adobeRGB screen should show difference in the green ramp but mostly there.

dithered 8 bit looks already like 11/12 bit.

[madshi]

Originally Posted by nevcairiel

That was madVR?
Somehow it felt like I always get that, and I don't think I always used madVR. But maybe I'm wrong..

Well, I always *thought* it was madVR's fault, caused by the low level keyboard hook. I might be wrong. I haven't actually tested it, I have to admit. I had one media player developer complain about madVR screwing keyboard stuff up during debugging, so I simply disabled the low level keyboard hook when madVR is running inside of a debugger, to make sure madVR doesn't cause any problems. And I *thought* it would also fix that other issue, but haven't tested it.

Originally Posted by sneaker_ger

Yes.

It already was unticked. I have now tested with ticked and unticked but it does not make a difference.

Are you by any chance using the "old windowed mode" (meaning you have present several frames in advance unchecked in the windowed mode settings)?

Originally Posted by Siso

With version 0.88.17 no problem, with versions 0.88.18 and 0.88.19 I have the problem. GTX 550 TI 353.30, win 7 64 ultimate. The problem only happens in Overlay mode (with builds 0.88.18, 0.88.19).Works fine in D3D9 windowed and fullscreen mode, also works in D3D11 modes.

Ok.

Does it occur with any video or just some? Do you get a madVR crash box? If so, I'd like to see the crash report.

Originally Posted by James Freeman

Confirmed.
There is a problem with Overlay mode.

When there is any GUI text from mpc-hc like (Volume, Chapter, etc...) the downscaling is messed up; it looks like it stretched to 100% from the downscaled window.
As soon as the text is gone the downscaling works properly again.

Ok, will have a look at that.

Originally Posted by Ceremony

I recently switch from stock Kodi to Kodi with DSPlayer, so that i can use madVR on my media center pc (AMD APU A10-7850K).

For some reason though, the GPU clock is stuck at its lowest speed. In my case 351MHz. It should however go up to 900MHz. I cannot use Jinc for upsampling, image doubling and any other advanced and demanding features... Anyone got a solution for this?

madVR has zero control over GPU clocks at the moment. I don't know when and why the GPU would clock up or down. Usually it should run at max clocks if anyone renders a lot. If that doesn't work, that looks like a GPU driver bug, or some other application or some configuration holds your clocks down for some reason. In any case, madVR's got pretty much nothing to do with that.

Originally Posted by THX-UltraII

Madshi, do you have any plans to integrate madVR in a 3D frame-packed support tool like PowerDVD?

At some point in the future, probably.

Originally Posted by 6233638

So it would be nice to either:

1. Have a preference which only enables 3DLUTs in full-screen mode.
2. Allow for profile support in the devices section of the madVR settings.

The latter would have many other uses.
For example, I have certain videos where I would want to enable different gamma settings, and it would be nice to use the very flexible profiling system to automate this.

Allowing profiling in the "devices" section is already high on my to do list.

Originally Posted by Dogway

Man, you surely had a bad day aside of programming it would be nice to learn some language comprehension, it would avoid the typical over-the-top harshness so common in today forums.

That is the 2nd time in a row you complain about my attitude, without any reason or cause. As you can see from the reaction of the other users (thanks, guys), the fault is on your side, not mine.

Why don't you simply stick to on-topic factual posts? Then we can all just get along fine. Thanks.

Originally Posted by Dogway

-less is more, get rid of placebo junk like all of the "upscaling refinement", one good sharpener is better than 4.

I absolutely agree that there are way too many options in that section right now. If you read through the last dozens of pages, you'll see that I'm working very hard to reduce options as much as possible, although many users urge me to keep all the options. My ultimate goal is to end up with just one sharpening setting, with low/medium/high options. However, there are various algorithms available which all do somewhat different things, and different users seem to have surprisingly different preferences. So it's a hard fight to reduce the current mess of options down to an acceptable amount. Give it some time, the number of options is going to reduce constantly over the next few weeks.

Originally Posted by Dogway

-Also get rid of ringing fest Jinc, and all the bicubic based (add "b" and "c" boxes for anyone to fill as replacement)

At some point I'm going to thin out scaling options, but Jinc is very much loved by a lot of users, so I can't remove that, and adding "b" and "c" boxes would be confusing to the average user. But I do share your overall sentiment that reducing options to make things simpler is generally a good idea. It needs to be done with care, though.

Originally Posted by Dogway

-remove deinterlacing, software deinterlacing is never going to replace offline deinterlacing. Better let TV deinterlace real-time.

Strongly disagree. You cannot scale an interlaced image. And all the processing algorithms like sharpening, debanding, even noise reduction etc, work much better on progressive images. Also I'm not sure how many displays can deinterlace *RGB* input well.

Originally Posted by Dogway

-Profile groups for displays

Already on my to do list.

Originally Posted by Dogway

-Make a guide (what Ordered Dither, what Error Diffusion algo?, process chain?, adaptive sharpen?). hint: a thread is not a guide.

Too early for that. Things are still changing an awful lot every week. This is planned for when I get to version 1.0, but not before. I simply don't have the resources to write a manual/guide now, and to update it every week with all the various changes.

Originally Posted by aufkrawall

In image doubling, maybe it should be named "double luma axis resolution" etc.?
E.g. in games rendering, you usually refer to the total amount of pixels when having a multiplicator. Of course you can define doubling the one way or the other, but giving a hint that it's meant for each axis sounds like a compromise to me that should make fans of both types content.
Maybe it would reduce confusion, as image doubling options are probably not easy to understand when you are new to madVR.

Well, NNEDI3 can double X and Y separately (super-xbr and NEDI can't). So if you scale the image in only one direction, image doubling could really only be doubling. This could e.g. happen if you have an anamorphic lens with cinescope content. Then you need to stretch Y by 1.33x. In that case NNEDI3 might be used for doubling Y, while X would remain untouched.

Anyway, I do agree that some options are maybe named confusingly. But this is not really the time to spend hours on fine tuning option names. I will do that for 1.0, but not before.

Originally Posted by Akeno

Will smooth motion work well with 23.976>60hz conversions or should I let reclock speed up video to 24fps and let smooth motion blend it to 60?

Smooth motion FRC loves high display refresh rates and low movie frame rates. It doesn't matter much if the movie frame rate is 23.976fps or 24fps or 25fps. Not to smooth motion FRC, anyway.

Originally Posted by James Freeman

As you can see, I have a 30% faster rendering time with d3d11, if d3d9 is the base.
Or a 44% slow down with d3d9, if d3d11 is the base.
This is in P8 state (GTX660, 324MHz both gpu and memory clocks).
D3D11 definitely got faster in the last few releases.

Interesting. I'm not fully sure why that would be the case, though. When using D3D9, do you have "use a separate device for presentation" checked or unchecked? Try checking it, maybe that will give you a similar performance increase when using D3D9?

Originally Posted by Ver Greeneyes

@madshi: I've noticed something interesting about D3D9 windowed mode: it seems to deal with repeated frames much worse than the new D3D11 path. I thought this was an artifact of livestreamer, but whenever a stream drops frames, the D3D9 path seems to show a much older frame (the oldest in the queue?), which looks very glitchy. The D3D11 path, on the other hand, just stutters a little, which is how I would expect it to look.

This behavior might only occur when the source is dropping frames, i.e. not when madVR's queues run empty because the system can't keep up. If the queues are empty it presumably just repeats the last frame it had. Is there an error in the logic here? Is it pulling up the wrong frame to repeat when the queues are filled up?

Edit: I think this behavior only happens when "present several frames in advance" is checked in the windowed mode settings. It seems to just stutter with that unchecked, like with the D3D11 path.

Well, why does it drop/repeat frames at all? Are the queues empty? Or does Aero/DWM not manage the load? Or some other reason? Generally, D3D9 and D3D11 windowed modes are quite similar, although they do differ a bit on how they handle presentation glitches reported by D3D.

Originally Posted by Warner306

[*]As a result of this subjectivity, I would suggest adding as many presets as possible. A Low, Med, High seems too restrictive. 1-10 would be much better, or, instead, a Beginner and Expert setting. It would be very challenging to get the settings just right for every display.

I might do that where it makes sense. But it doesn't make sense everywhere. E.g. with SuperRes, the difference between 1 and 2 passes is much higher than between 2 and 3 passes. Taking such things into account, it's possible to reduce the "passes" options quite a bit. The next madVR build is going to combine "passes" and "strength" into one, and I don't think you'll find a reason to complain, although the options got much "cleaned up".

Originally Posted by Warner306

[*]SuperRes is the most natural sharpener. It would be nice if this shader could be added to Image Enhancements somehow for consistency's sake.

Technically not possible, I think. SuperRes works by comparing the upscaled image to the original. In Image Enhancement this comparison would result in zero differences, so SuperRes would not have anything to do. Would you could do is upscale, then apply SuperRes, then downscale again. But that would consume *A LOT* of resources.

Originally Posted by Warner306

[*]If not, FineSharp, what I would consider the best sharpener in Image Enhancements, is in dire need of an anti-ringing filter.

Agreed.

Originally Posted by James Freeman

How do you think 50fps film on a 120Hz monitor with SmoothMotion will perform/look?
24fps on a 60Hz monitor ratio is 2.5, so 50fps on 120hz will be 2.4.

Should work just fine. Of course it will consume extra GPU power. But can't you just switch that monitor to 100Hz? Native framerate should always be superior to smooth motion FRC, if the display does native framerate correctly.

[madshi]

So here's a new test build to further fine tune the SuperRes algorithm:

http://madshi.net/madVR8819b.rar

All previous options are gone exact for "strength", which combines the previous "strength" and "passes" options. Please let me know if you're ok with the new "strength" option.

There's one important new option for you to play with: The "radius". This option mostly affects aliasing, but also sharpness to some extent. There were some (justified) complaints about SuperRes introducing aliasing. The current radius default of 0.66 is probably set too low. Please try to find videos where SuperRes produces aliasing with 0.66, and then try to find a setting which gets rid of the aliasing. Generally higher radius settings reduce aliasing, but if you set it too high, we'll get other artifacts. So we need to find a good value.

Please test with only SuperRes, without any of the other sharpeners active. Also please make sure you have "refine the image only once" activated. I'd suggest to test with the highest strength, even if it might not run in real time, so that changes to the radius can be judged better.

Looking forward to your feedback - thanks!

(P.S: leeperry, you can create an empty file called "BilinearSuperRes" in the madVR folder. That means HQ turned off. I pretty much hate the look it produces, though, so use it at your own "risk".)

[sneaker_ger]

Originally Posted by madshi

Are you by any chance using the "old windowed mode" (meaning you have present several frames in advance unchecked in the windowed mode settings)?

No, all my settings are at the defaults. No exceptions.

I just tested with and without "present several frames in advance" (windowed mode) but the problem happens in both modes.

[TheLion]

Originally Posted by madshi

Technically not possible, I think. SuperRes works by comparing the upscaled image to the original. In Image Enhancement this comparison would result in zero differences, so SuperRes would not have anything to do. Would you could do is upscale, then apply SuperRes, then downscale again. But that would consume *A LOT* of resources.

Who cares about resources? That's exactly our pipe dream! And how could we do that? (I am guessing at some point you will get really annoyed by these "internal over-/supersampling" questions... )

[Ceremony]

Originally Posted by har3inger

Force GPU clocks to max for mpchc through CCC if you can. You might need to rename the mpchc executable to something else for this to work (I had to--ATI is stupid and locks certain applications to lower power states or iGPU and takes away user control). You can also try turning off hardware decoding (DXVA) in LAV filters. This tends to lock clocks for AMD gpus to lower clocks as well. In general, GPU power states are entirely controlled by your OS and GPU driver settings and how they handle your video player (NOT madVR, which runs inside the vid player). There's likely nothing madVR can do to force certain GPU power states, so unfortunately, don't expect support here if troubleshooting doesn't work.

Not possible for APUs apparently. Also, i renamed the exe to hl2.exe. didnt make a any difference.

Originally Posted by huhn

reinstall the driver and delete everything that can change or control the clock of your GPU there are so many possibilities.

after that try to rename your mpc-hc exe.

BTW. your screen shows a huge issue with the buggy and most likely windows 7 desktop composition.

already tried that. did a clean install using DDU. Nothing changed. Also, disabling desktop composition doesnt solve this issue either.

Originally Posted by madshi

madVR has zero control over GPU clocks at the moment. I don't know when and why the GPU would clock up or down. Usually it should run at max clocks if anyone renders a lot. If that doesn't work, that looks like a GPU driver bug, or some other application or some configuration holds your clocks down for some reason. In any case, madVR's got pretty much nothing to do with that.

yeah, thats what i though as well. but apparently, it just doesnt do that for some unknown reason... i dont get it either.
Anyone else here with an AMD APU who is willing to test this? I doubt its anything on my system "holding it down" as it is basically stock Win7 set up as a media center pc and network storage space. Nothing else running on there in the bg

[6ari8]

Originally Posted by madshi

Please try again with v0.88.19. If you still get the issue, try disabling both D3D11 and the "use a separate device for presentation" options. That might "solve" the issue. At this point I think if you still get the issue with v0.88.19, it's most probably some sort of GPU driver issue, unfortunately...

The issue only happens in D3D11 so by using D3D9 it played normally in previous versions. "use a separate device for presentation" doesn't seem to have any effect as far as I can see.
The issue seems to be reduced by a bit in v0.88.19 but still very obvious so I went and did some testing.

First, I activated debug mode and I was surprised because the issue was completely gone in all builds that had it. So maybe debug mode is doing something to prevent the stuttering?
Anyway, I then went and reset everything to defaults and it played normally. I then activated my settings one by one to see which one is causing the stuttering and ended up with the culprit.

It was the GPU/Present queues.
More specifically, whenever the present queue is less than the GPU queue by a certain amount, the stuttering happens. As you saw in my screenshots before, my GPU queue was set to 10 and my present was set to 6.

When I keep the present queue as 6 and decrease my GPU queue to 8, the stuttering is gone. When I then decrease the present queue to anything less than 6 it comes back.
Similarly, when I increase my present queue to 8 and keep my GPU queue at 10, the stuttering is gone. However, when I go and increase the GPU queue to anything more than 10, the stuttering comes back.

When I put madVR in debug mode, the stuttering goes away regardless of whatever queues I set.

[mogli]

Originally Posted by madshi

When using D3D9, do you have "use a separate device for presentation" checked or unchecked? Try checking it, maybe that will give you a similar performance increase when using D3D9?

You asked me to do the same when I reported better performance with D3D11 some pages ago.
Checking that option does almost gain nothing here.

[Ver Greeneyes]

Originally Posted by madshi

Well, why does it drop/repeat frames at all? Are the queues empty? Or does Aero/DWM not manage the load? Or some other reason? Generally, D3D9 and D3D11 windowed modes are quite similar, although they do differ a bit on how they handle presentation glitches reported by D3D.

I can't say for sure what's going on, but this is what it looks like to me: the queues are full, and there are no presentation glitches, but the stream occasionally sends fewer frames than its advertised frame rate, thus causing madVR to repeat a frame. I assume madVR has already accounted for this missing frame, since the queues are full, but somehow it, or the DWM, ends up showing a much older frame briefly instead of repeating the most recent one.

I'll try and get a debug log to see if it shows anything, but I might have to wait to catch this particular stream again; I don't know if it happens with all of them.

[Siso]

Originally Posted by madshi

Does it occur with any video or just some? Do you get a madVR crash box? If so, I'd like to see the crash report.

I watch only 1080p rarely some 720p mkv files, and it happens with everyone of them in Overlay mode.

[James Freeman]

Originally Posted by Ver Greeneyes

I can't say for sure what's going on, but this is what it looks like to me: the queues are full, and there are no presentation glitches, but the stream occasionally sends fewer frames than its advertised frame rate, thus causing madVR to repeat a frame. I assume madVR has already accounted for this missing frame, since the queues are full, but somehow it, or the DWM, ends up showing a much older frame briefly instead of repeating the most recent one.

I'll try and get a debug log to see if it shows anything, but I might have to wait to catch this particular stream again; I don't know if it happens with all of them.

After reading your posts, I confirm.

D3D11, FSE, there are may unreported skipped/dropped/repeated frames. The video is stuttering.
*Present a frame for every Vsync, enabled or disabled.

If a Youtube video is playing along with MPC-HC, this unreported frame skipping also happens in windowed fullscreen, D3D11.

D3D9 works perfectly in all modes.

[Ver Greeneyes]

Originally Posted by James Freeman

D3D9 works perfectly in all modes.

You're reporting an entirely different problem from me I'm specifically talking about how D3D9 'new' windowed mode throws a fit when there's a frame missing in the source. These repeated frames show up in the OSD. Windowed mode D3D11 actually fixes that problem: it just stutters. The 'old' D3D9 windowed mode ("present several frames in advance" unchecked) also doesn't exhibit the problem.

What you seem to be reporting is that D3D11 stutters more than can be explained through missing frames, and it doesn't show up in the madVR OSD. I haven't looked at that too closely.

[Shiandow]

Originally Posted by madshi

Technically not possible, I think. SuperRes works by comparing the upscaled image to the original. In Image Enhancement this comparison would result in zero differences, so SuperRes would not have anything to do. Would you could do is upscale, then apply SuperRes, then downscale again. But that would consume *A LOT* of resources.

In principle you could just blur the image, instead of downscaling it. This basically means that SuperRes will assume that the original image is a blurred version of the 'actual' image, and SuperRes will then try to recover the 'actual' image. Not too sure if this is any better than a normal sharpener though.

[sneaker_ger]

Originally Posted by madshi

Are you by any chance using the "old windowed mode" (meaning you have present several frames in advance unchecked in the windowed mode settings)?

Originally Posted by sneaker_ger

No, all my settings are at the defaults. No exceptions.

I just tested with and without "present several frames in advance" (windowed mode) but the problem happens in both modes.

Wait, with or without "present several frames in advance" it says "D3D9 windowed (old path)" in the OSD. I assume because I have Aero off or something like that? Is it relevant?

[madshi]

Originally Posted by TheLion

Who cares about resources? That's exactly our pipe dream! And how could we do that? (I am guessing at some point you will get really annoyed by these "internal over-/supersampling" questions... )

Yes, maybe I'll add supersampling at some point, but if you look at the current sharpening options, they're a mess, much too many options. We first need to clean that up. Then maybe we can think about supersampling afterwards. I don't want to make the options any more complicated right now.

Originally Posted by 6ari8

The issue only happens in D3D11 so by using D3D9 it played normally in previous versions. "use a separate device for presentation" doesn't seem to have any effect as far as I can see.
The issue seems to be reduced by a bit in v0.88.19 but still very obvious so I went and did some testing.

First, I activated debug mode and I was surprised because the issue was completely gone in all builds that had it. So maybe debug mode is doing something to prevent the stuttering?
Anyway, I then went and reset everything to defaults and it played normally. I then activated my settings one by one to see which one is causing the stuttering and ended up with the culprit.

It was the GPU/Present queues.
More specifically, whenever the present queue is less than the GPU queue by a certain amount, the stuttering happens. As you saw in my screenshots before, my GPU queue was set to 10 and my present was set to 6.

When I keep the present queue as 6 and decrease my GPU queue to 8, the stuttering is gone. When I then decrease the present queue to anything less than 6 it comes back.
Similarly, when I increase my present queue to 8 and keep my GPU queue at 10, the stuttering is gone. However, when I go and increase the GPU queue to anything more than 10, the stuttering comes back.

When I put madVR in debug mode, the stuttering goes away regardless of whatever queues I set.

That sounds quite interesting. I don't really have an explanation for that, unfortunately. Looking at my code, I seem to be doing everything correctly. Also on my PC I can't reproduce these issues. As a test I've setup GPU queues to 16 and the present queue to 8, and playback is mooth with D3D11 in both windowed and FSE mode, regardless of whether the OSD is on or off.

It seems there are some odd problems out there atm, with v0.88.17+, but it seems to affect only few users, and every of them seems to have different problems, and I can't reproduce any of them. So it's really hard for me to do anything about it. Of course I could simply revert all changes I did, but then we would lose some important improvements that several media player devs have been wishing for and been quite happy to see introduced in v0.88.17 (like low latency OSD, smooth and low GPU power paused mode rendering etc).

Originally Posted by mogli

You asked me to do the same when I reported better performance with D3D11 some pages ago.
Checking that option does almost gain nothing here.

Does it say "(new windowed path)" when you do that with D3D9?

Originally Posted by Ver Greeneyes

I can't say for sure what's going on, but this is what it looks like to me: the queues are full, and there are no presentation glitches, but the stream occasionally sends fewer frames than its advertised frame rate, thus causing madVR to repeat a frame. I assume madVR has already accounted for this missing frame, since the queues are full, but somehow it, or the DWM, ends up showing a much older frame briefly instead of repeating the most recent one.

That sounds weird. And this is a new problem with the recent builds, I suppose? If the madVR queues are full and neither frame drops nor presentation glitches are reported, then this could be a GPU driver bug, or a bad flush setting (are you using defaults?), or a bug in madVR.

Originally Posted by Siso

I watch only 1080p rarely some 720p mkv files, and it happens with everyone of them in Overlay mode.

Do you get a madVR crash box? If so, I'd like to see the crash report.

Originally Posted by James Freeman

After reading your posts, I confirm.

D3D11, FSE, there are may unreported skipped/dropped/repeated frames. The video is stuttering.
*Present a frame for every Vsync, enabled or disabled.

That is not something anybody else has reported yet (unless it only occurs if any sort of OSD in on). If you reliably have this issue, I'd need more information. E.g. OS, GPU, which exact madVR build introduced it, whether you're using default flush settings or not, whether the problem only shows if any sort of OSD is visible or whether it always shows etc.

Originally Posted by Shiandow

In principle you could just blur the image, instead of downscaling it. This basically means that SuperRes will assume that the original image is a blurred version of the 'actual' image, and SuperRes will then try to recover the 'actual' image. Not too sure if this is any better than a normal sharpener though.

Ok, good idea. Something to try in the future, maybe.

Originally Posted by sneaker_ger

Wait, with or without "present several frames in advance" it says "D3D9 windowed (old path)" in the OSD. I assume because I have Aero off or something like that? Is it relevant?

Yes, it's relevant. I think the "new path" can only be used if Aero is on, IIRC, but I'm not 100% sure right now. Also, the new path can only be used if it's also enabled in the FSE settings.

[sneaker_ger]

I have the new path for FSE so that's not it (like I said: default settings). Must be the Aero off thing, then.

[Siso]

Originally Posted by madshi

Do you get a madVR crash box? If so, I'd like to see the crash report.

No crashes so far. It seems that something is wrong with Overlay mode after version 0.88.17

[James Freeman]

Originally Posted by madshi

That is not something anybody else has reported yet (unless it only occurs if any sort of OSD in on). If you reliably have this issue, I'd need more information. E.g. OS, GPU, which exact madVR build introduced it, whether you're using default flush settings or not, whether the problem only shows if any sort of OSD is visible or whether it always shows etc.

Please download from here a 24fps judder test video:
Judder test videos 24fps
I use the 10s 30 one.

Just look at the line to see if it stutters.

D3D11, FSE, = Stutter (All P states).
D3D11, FS Window, Youtube, = Stutter (P8 only).
D3d11, FS Window, Youtube paused, = No Stutter.
*All stutters are unreported by madVR.

Can anyone please confirm?

EDIT:
Windows 7 64bit, Nvidia GTX660.

[madshi]

Originally Posted by Siso

No crashes so far. It seems that something is wrong with Overlay mode after version 0.88.17

Ok, I'll have a look.

Originally Posted by James Freeman

D3D11, FSE, = Stutter (All P states).
D3D11, FS Window, Youtube, = Stutter (P8 only).
D3d11, FS Window, Youtube paused, = No Stutter.
*All stutters are unreported by madVR.

[...] which exact madVR build introduced it, whether you're using default flush settings or not, whether the problem only shows if any sort of OSD is visible or whether it always shows etc.