madVR - high quality video renderer (GPU assisted)

[Warner306]

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]

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.

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]

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.

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)?

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.

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.

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.

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.

So it would be nice to either:

Have a preference which only enables 3DLUTs in full-screen mode.
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.

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.

-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.

-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.

-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.

-Profile groups for displays
Already on my to do list.

-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.

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.

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.

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?

@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.

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".

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.

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

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]

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]

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? :devil: 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...:p )

[Ceremony]

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.


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.

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]

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]

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]

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]

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]

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]

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]

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]

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.
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]

Who cares about resources? :devil: 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...:p )
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.

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).

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?

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.

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.

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.

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.

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]

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]

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.

Please download from here a 24fps judder test video:
Judder test videos 24fps (https://drive.google.com/folderview?id=0B4SHVPm2DfK5RnZIMDdINTFBN2s&usp=sharing)
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]

No crashes so far. It seems that something is wrong with Overlay mode after version 0.88.17
Ok, I'll have a look.

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.

[Ver Greeneyes]

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.I think the problem has been around ever since the new windowed mode was introduced, I just never made the connection before. I see it on both my laptop (with an old AMD GPU, legacy drivers) and my desktop (with a GeForce GTX 580, latest drivers), but there's probably something about the way livestreamer (http://livestreamer.tanuki.se/en/latest/index.html) connects with MPC-HC that causes it. I definitely don't see it on every stream though, so I think I'll have to wait for a 'low quality' stream to get a debug log. I'll also try it with smooth motion disabled in case it makes a difference.

Edit: Oh, and flush settings are |flush, flush & wait (sleep), don't flush, don't flush|, which I believe is the default. I have it set to present 8 frames in advance, with a CPU queue size of 48 and a GPU queue size of 24, and "use a separate device for presentation" is checked.

[James Freeman]

Unreported Stutter,
[...] 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.

88.17 introduced it; 88.16 is fine.
Only when something on the screen besides the video (Stats menu, volume, time marks, etc...).
Flushes are at default.
* added automatic OSD low latency logic
I guess this one is to blame

Also 88.17 (and on) makes my rendering times faster in D3D11, from 23ms to 16ms.
With 88.16 rendering times are the same as d3d9, 23ms.

Anyone else can confirm?
Try videos with smooth pans.
D3D11, FSE, stats menu On (ctrl+j).

[Siso]

88.17 introduced it; 88.16 is fine.
Only when something on the screen besides the video (Stats menu, volume, time marks, etc...).
Flushes are at default.

I guess this one is to blame

Also 88.17 (and on) makes my rendering times faster in D3D11, from 23ms to 16ms.
With 88.16 rendering times are the same as d3d9, 23ms.

Anyone else can confirm?
Try videos with smooth pans.
D3D11, FSE, stats menu On (ctrl+j).


All kinds of panning shots are somehow problematic in the latest builds etc 0.16, 0.17, 0.18, 0.19. I'm on Dell ud2913wm @ 72 hz+reclock. Also I lowered my dpc latency a lot, around 40-50-60 nanoseconds.

[mogli]

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

New path, yes, but I'm only testing FSE since I don't use windowed mode. (I restart MPC-HC after switching between D3D9/11.)

Also 88.17 (and on) makes my rendering times faster in D3D11, from 23ms to 16ms.
With 88.16 rendering times are the same as d3d9, 23ms.

I reported the speed increase with v88.12. However I don't remember if it started earlier.

Note that D3D11 also about halves my presentation timings. Using 'separate device' has no effect on this at all, only on rendering.

[James Freeman]

I restart MPC-HC after switching between D3D9/11.

I reported the speed increase with v88.12. However I don't remember if it started earlier.

You can simply ctrl+c without restarting mpc-hc when changing between d9 and d11 or any other operation that requires closing madVR.

Apparently my speed up is because of the new OSD low latency logic from 88.17 on.

[Akeno]

Base Image / No image sharpening (http://i.imgur.com/1fl2sHr.png)

SuperRes Strength: 1 (http://i.imgur.com/isgMCr3.png)
SuperRes Strength: 4 (http://i.imgur.com/aA4IJbA.png)
SuperRes Strength: 4 + Radius: 1.00 (http://i.imgur.com/F59JFQr.png)

The source I used actually has aliasing already in it. NNEDI3 miraculously anti-aliases the image and SuperRes brings back the aliasing. Anyone know why that is?

For fun, I set image upscaling to softcubic 100 and doubled the image.
Base Image / No image sharpening (http://i.imgur.com/aKMYQdb.png)

SuperRes Strength: 1 (http://i.imgur.com/KL6E2JH.png)
SuperRes Strength: 4 (http://i.imgur.com/uRfg0yj.png)
SuperRes Strength: 4 + Radius: 1.00 (http://i.imgur.com/5PZcHHL.png)

And added fun, I compared Adaptive Sharpen set to 1.5 and SuperRes Strength: 1 and Strength: 4 + Radius: 1.00 (http://screenshotcomparison.com/comparison/135573/picture:0). There's a lot less ringing in SuperRes and the lines are closer to what you would expect (i.e. not horrendously thick). There's still aliasing regardless of settings though. Upping the radius only provided a marginal decrease in aliasing at the cost of marginal blurring.

[har3inger]

If the source has aliasing, presumably SuperRes is interpreting that aliasing as meaningful information and is trying to reproduce the lost aliasing in the final result.

[nijiko]

MPEG2 deinterlacing is too SLOWLY (according to rendering time)

[michkrol]

Please provide more information:
Do you actually get dropped frames?
What decoder are you using (software/DXVA/CUVID/QuickSync)?
What OS and player are you using?
What GPU and drivers (version) are you using?
A screenshot of the OSD would also be helpful.

[Warner306]

Using the test build, the performance of SuperRes has degraded to the point I can no longer run Strength 1. Previously, my settings were as follows:

Profile: "720p"

Chroma: super-xbr150 + AR
Image: Jinc3 + AR
Luma Doubling: Off
Upscaling Refinement: SuperRes (passes: 1; strength: 1.0; algo: 2; alt color space: off)
Artifact Removal - Debanding: Medium/High
Image Enhancements: Off
Dithering: Ordered

No presentation glitches, rendering closer to 30ms than 38ms. This is with a Nvidia GTS 450.

[KoD]

Hi, I experience lots of dropped frames after switching between fullscreen and windowed modes, the way I describe below:

What I do is this: start playback-> all is fine, go fullscreen -> everything is still fine, then go back to windowed mode -> all still fine -> go back to full screen -> now lots of frames dropped, it does not recover itself unless I pause the video, and then resume. With 0.88.12 it was enough to pause once, and then playback would be smooth again after resuming; with 0.88.19 once is often not enough, I have to pause twice. It looks like the render queue does not recover staying at 1-3 or 2-3, even though the decoder, subtitle and upload queues fill up to their normal stats. The present queue also ends up with the same fill status as the render queue.

Some details: I'm using MPC, with its internal filters for h264 playback of mkvs, it happens on both 8 bit and 10 bit content, irrespective of whether I use software or hardware decoding. Happens only when using D3D11 and fullscreen exclusive mode. If I use full screen windowed mode, or I use the D3D9 renderer, all is fine.

I happen to have a Sony TV which accepts 12 bit color input. When using D3D11 and fullscreen exclusive mode, the TV receives 12bit per channel input (I can see this by pressing the Info key on the remote).

Have not changed the graphics drivers since a long time ago, it's still version 347.25 on a GTX980 for me.

[ryrynz]

Hi, I experience lots of dropped frames after switching between fullscreen and windowed modes


I bothered to do a little further testing tonight on this issue I reported a month ago and came to post the exact same thing.. looks like I didn't need not bother..

Sometimes I've seen it recover while paused only to drop the queue to low values again once it's started playing. And yes it's generally when you do a "messy" (multiple switching, pausing etc) windowed to fullscreen switch.


Does it only occur in 10bit output mode?


Yup.


Does the screen refresh rate matter?


Nope.


Please make sure you close everything else, even 3rd party background services, just to be safe.


Played it safe. No difference.

[tFWo]

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".

I'll be using this too. HQ is the source of most of the problems I have with Superres. There is a new problem when using this. Strength 1 is too strong with HQ turned off :) . Maybe add strength 0 that halves the strength.

"Radius" option helps only a little when HQ is on. Turning it higher than 0.75-0.80 does remove most of the artifacts, but it also softens the image considerably. Again I fail to find a purpose for Superres with a trade-off like that.

With HQ off, "radius" is less important. It just has to be just above 0.5 (i set it at 0.7 just to be sure). When it's set below 0.5 aliasing/pixelization appears.

[Dlget]

any chance of x64 release of madVR???
since x64 does better CPU utilization
:thanks:

[sneaker_ger]

MadVR already has a 64 bit version. It's in the same package as the 32 bit version.

[Dlget]

does that mean i can use 64 bit lav filter + mpc be for 10 bit files???

[sneaker_ger]

correct

[Nachbar]

I noticed my new 4K TV will not display anything above 235 or below 16 when it is set to Full Range. Set to limited I am now able to perceive those values. Should I set it to limited or full range in the driver and in madvr?
Also should I set LAV Video to PC, limited, or untouched? I think untouched is correct for now.
Should I also be using YCbCR instead of RGB?

These are the brightness settings I've found to get reference black to be the darkest black using the black clipping video in the avs hd calibration disc:
When in Full Range in madvr with the driver set to Full: 45 (0-15 are clipped)
When in Limited Range in madvr with the driver set to Full: 27 (no clipping)
When in Full Range in madvr with the driver set to limited: 31 (0-15 are clipped)
When in Limited Range in madvr with the driver set to limited: 16 (no cipping)

I'm going to try out limited/limited for a while and see what I think.

I also noticed no matter what setting I choose I cannot get white to clip above reference white. ALl the white levels show no matter what. Even when adjusting brightness and contrast.

[Dlget]

correct

Nahhh...
It doesn't work.
I just tested with everything x64

[Ver Greeneyes]

Nahhh...
It doesn't work.
I just tested with everything x64It works fine with MPC-HC. Make sure the files are registered by running "install.bat".

[James Freeman]

Nahhh...
It doesn't work.
I just tested with everything x64

Its been working for a couple of months now...

[leeperry]

I'll be using this too. HQ is the source of most of the problems I have with Superres. There is a new problem when using this. Strength 1 is too strong with HQ turned off :) . Maybe add strength 0 that halves the strength.

"Radius" option helps only a little when HQ is on. Turning it higher than 0.75-0.80 does remove most of the artifacts, but it also softens the image considerably. Again I fail to find a purpose for Superres with a trade-off like that.

With HQ off, "radius" is less important. It just has to be just above 0.5 (i set it at 0.7 just to be sure). When it's set below 0.5 aliasing/pixelization appears.
Been running tests for a few days now and I wanted to be 100% sure of my impressions, the thing is that they pretty much match exactly yours :o

HQ adds a foggy smoke screen onto the picture, 1 is way too strong to be useful to anything(w/o HQ at least) and radius makes very weird artifacts when I mess with it.

TBH this release has completely killed SuperRes for me, I'm kinda tired of whining in this thread to have SR reverted to how it was in .15(which would never happen anyway) so I might either call it a day and stick with it(3 passes at 0.65 is actually quite a bit too sharp, 0.42 looks less edgy) or I might just bite the bullet and give up on SR altogether as it would appear that a combination of sxbr+adaptive sharpen also gives very nice results(too bad the strength of sxbr doesn't come with a knob but AS does...for now at least). Usual story that all roads lead to Rome, hopefully you won't kill AS too by removing its strength knob and adding weird radius options or something http://forum-images.hardware.fr/images/perso/zytradance.gif

And I wholeheartedly disagree that 2 passes at 1.0 look "pretty much" identical to 3@0.65 in .15 as the former looks way sharper and less detailed....like upscaling posterization and unchecking "refine after every 2X upscaling" makes matters even worse. Oh well.

[Dlget]

Its been working for a couple of months now...

Can you tell me extra steps if any required for x64 processing

[sneaker_ger]

There aren't really any extra steps.
1. Download and unpack latest madvr
2. Right click "install.bat" -> "run as admin" (read any error messages)
3. run MPC-HC x64 or MPC-BE x64 and set to madvr renderer
4. enjoy

[James Freeman]

Also run "restore default settings.bat"

[iSunrise]

Been running tests for a few days now and I wanted to be 100% sure of my impressions, the thing is that they pretty much match exactly yours :o

HQ adds a foggy smoke screen onto the picture, 1 is way too strong to be useful to anything(w/o HQ at least) and radius makes very weird artifacts when I mess with it.

TBH this release has completely killed SuperRes for me, I'm kinda tired of whining in this thread to have SR reverted to how it was in .15(which would never happen anyway) so I might either call it a day and stick with it(3 passes at 0.65 is actually quite a bit too sharp, 0.42 looks less edgy) or I might just bite the bullet and give up on SR altogether as it would appear that a combination of sxbr+adaptive sharpen also gives very nice results(too bad the strength of sxbr doesn't come with a knob but AS does...for now at least). Usual story that all roads lead to Rome, hopefully you won't kill AS too by removing its strength knob and adding weird radius options or something http://forum-images.hardware.fr/images/perso/zytradance.gif

And I wholeheartedly disagree that 2 passes at 1.0 look "pretty much" identical to 3@0.65 in .15 as the former looks way sharper and less detailed....like upscaling posterization and unchecking "refine after every 2X upscaling" makes matters even worse. Oh well.
If you disagree and you show samples, madshi will always listen. madshi is known to not ignore your feedback if you have enough data on your hands to proof that what you say should be taken into consideration. I don't get why you invest countless hours in testing, yet, you show no screenshots to prove your point.

How do you expect madshi to react? Believe 20 other people that say A looks more satisfying and agree with madshi's findings or with 2-3 other people that don't agree, but they also don't show why they don't agree with e.x. samples or screenshots (including the settings they used).

Especially when you write "tests for a few days now". Well, to be quite frank, IF I had so much time on my hands to do tests, I would not hesitate for even a second to provide a couple example shots to show it to everyone, so there actually is some discussion that will help everyone.

[madshi]

If you disagree and you show samples, madshi will listen. I don't get why you invest countless hours in testing, yet, no screenshots to prove your point.

How do you expect madshi to react? Believe 20 other people that say A looks more satisfying and agree with madshi's findings or with 2-3 other people that don't agree, but they also don't show why they don't agree with e.x. samples or screenshots (including the settings they used).

Especially when you write "tests for a few days now". Well, to be quite frank, IF I had so much time on my hands to do tests, I would no hesitate a second to provide a couple example shots to show it to everyone, so there actually is some discussion that will help everyone.
Exactly.

[nevcairiel]

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


Its not software deinterlacing, its hardware deinterlacing in the GPU, which has an acceptable quality for real-time processing.
On top of that, output of interlaced material from a PC has all sorts of problems.

[madshi]

I think the problem has been around ever since the new windowed mode was introduced, I just never made the connection before. I see it on both my laptop (with an old AMD GPU, legacy drivers) and my desktop (with a GeForce GTX 580, latest drivers), but there's probably something about the way livestreamer (http://livestreamer.tanuki.se/en/latest/index.html) connects with MPC-HC that causes it. I definitely don't see it on every stream though, so I think I'll have to wait for a 'low quality' stream to get a debug log. I'll also try it with smooth motion disabled in case it makes a difference.

Edit: Oh, and flush settings are |flush, flush & wait (sleep), don't flush, don't flush|, which I believe is the default. I have it set to present 8 frames in advance, with a CPU queue size of 48 and a GPU queue size of 24, and "use a separate device for presentation" is checked.
Those should be the default flush settings. For now I'd kindly ask you to postpone this bug until all the new bugs introduced by v0.88.17 are solved, if you don't mind. Otherwise it's just too much atm. I can handle only so many bug reports at a time.

88.17 introduced it; 88.16 is fine.
Only when something on the screen besides the video (Stats menu, volume, time marks, etc...).
Ok, please try with v0.88.20.

All kinds of panning shots are somehow problematic in the latest builds etc 0.16, 0.17, 0.18, 0.19. I'm on Dell ud2913wm @ 72 hz+reclock. Also I lowered my dpc latency a lot, around 40-50-60 nanoseconds.
You sure it occurs with v0.88.16?? Because the "dramatic" change that caused problems for most other users happened in v0.88.17. Please try to find out the exact build which introduced the problem for you. You can download old builds with the link from the first post in this thread.

New path, yes, but I'm only testing FSE since I don't use windowed mode. (I restart MPC-HC after switching between D3D9/11.)

I reported the speed increase with v88.12. However I don't remember if it started earlier.

Note that D3D11 also about halves my presentation timings. Using 'separate device' has no effect on this at all, only on rendering.
Well, might be that the modified OSD logic doesn't properly measure the time the OSD drawing costs, I'm not sure right now.

The source I used actually has aliasing already in it. NNEDI3 miraculously anti-aliases the image and SuperRes brings back the aliasing. Anyone know why that is?
If the source has aliasing, presumably SuperRes is interpreting that aliasing as meaningful information and is trying to reproduce the lost aliasing in the final result.
Thanks for taking the time to make comparison screenshots. har3inger is correct, though. SuperRes works by trying to make sure that the upscaled image is a "fair representation" of the original source. If the source had aliasing artifacts and the upscale doesn't, SuperRes probably considers that a "degradation" and tries to make the upscaled image nearer to the original source, which will probably reintroduce the aliasing artifacts to a certain extent.

I suppose the proper solution for this would be to remove the aliasing artifacts before upscaling the image. AviSynth has some filters for that, but they're pretty slow, IIRC. Maybe madVR will get such a filter at some time in the future, but probably not soon.

MPEG2 deinterlacing is too SLOWLY (according to rendering time)
Please provide more information:
Do you actually get dropped frames?
What decoder are you using (software/DXVA/CUVID/QuickSync)?
What OS and player are you using?
What GPU and drivers (version) are you using?
A screenshot of the OSD would also be helpful.
^

Using the test build, the performance of SuperRes has degraded to the point I can no longer run Strength 1.
Compared to which older build? v0.88.17 introduced a SuperRes anti-ringing filter, which costs some performance. So if you compare to e.g. v0.88.16, the newer builds are expected to perform a bit slower. However, there should be no big difference between v0.88.17 and v0.88.19.

Anyway, there may be room for further performance optimizations. For now we're trying to fine tune the algorithm, remove what's superfluous, set fixed values where it makes sense. Once the dust has settled, maybe some performance optimizations can be done.

Hi, I experience lots of dropped frames after switching between fullscreen and windowed modes, the way I describe below:

What I do is this: start playback-> all is fine, go fullscreen -> everything is still fine, then go back to windowed mode -> all still fine -> go back to full screen -> now lots of frames dropped, it does not recover itself unless I pause the video, and then resume. With 0.88.12 it was enough to pause once, and then playback would be smooth again after resuming; with 0.88.19 once is often not enough, I have to pause twice. It looks like the render queue does not recover staying at 1-3 or 2-3, even though the decoder, subtitle and upload queues fill up to their normal stats. The present queue also ends up with the same fill status as the render queue.

Some details: I'm using MPC, with its internal filters for h264 playback of mkvs, it happens on both 8 bit and 10 bit content, irrespective of whether I use software or hardware decoding. Happens only when using D3D11 and fullscreen exclusive mode. If I use full screen windowed mode, or I use the D3D9 renderer, all is fine.

I happen to have a Sony TV which accepts 12 bit color input. When using D3D11 and fullscreen exclusive mode, the TV receives 12bit per channel input (I can see this by pressing the Info key on the remote).

Have not changed the graphics drivers since a long time ago, it's still version 347.25 on a GTX980 for me.
Is this a new problem with the newer madVR builds? Or what it "always" this way?

I bothered to do a little further testing tonight on this issue I reported a month ago and came to post the exact same thing.. looks like I didn't need not bother..

Sometimes I've seen it recover while paused only to drop the queue to low values again once it's started playing. And yes it's generally when you do a "messy" (multiple switching, pausing etc) windowed to fullscreen switch.
So this is an "old" issue and was not caused by the recent changes in v0.88.17?

I'll be using this too. HQ is the source of most of the problems I have with Superres. There is a new problem when using this. Strength 1 is too strong with HQ turned off :) . Maybe add strength 0 that halves the strength.

"Radius" option helps only a little when HQ is on. Turning it higher than 0.75-0.80 does remove most of the artifacts, but it also softens the image considerably. Again I fail to find a purpose for Superres with a trade-off like that.

With HQ off, "radius" is less important. It just has to be just above 0.5 (i set it at 0.7 just to be sure). When it's set below 0.5 aliasing/pixelization appears.
Can you show a couple of screenshots which show why you prefer HQ off? Please post the original image (PNG is fine) together with the upscaled & SuperRes'ed results. The original image is important, so we can reproduce your results here, and maybe fine tune the algorithm. Thanks!

I noticed my new 4K TV will not display anything above 235 or below 16 when it is set to Full Range. Set to limited I am now able to perceive those values. Should I set it to limited or full range in the driver and in madvr?
Also should I set LAV Video to PC, limited, or untouched? I think untouched is correct for now.
Should I also be using YCbCR instead of RGB?
Such questions are asked all the time in this thread, so I'm not going to go into any detail here. Makes no fun writing the same replies every couple of pages all over again.

Leave LAV at default values. Don't use YCbCr unless after extensive testing you find it works best, due to technical limitations of your TV. Whether you should set the GPU, TV and madVR to PC or TV levels is a complicated question that can't be explained in one short sentence. Anybody has a link to a guide that explains this?

TBH this release has completely killed SuperRes for me
Huh? This release re-introduced "HQ off" for you. I'm confused how that would kill SuperRes for you? Instead of saying "thank you" for adding a tweak *just for you*, you continue to whine, and you don't do screenshots, as I asked you to multiple times already. You're not very motivating atm.

And I wholeheartedly disagree that 2 passes at 1.0 look "pretty much" identical to 3@0.65 in .15 as the former looks way sharper and less detailed....
I've already told you that if that is your opinion, I want proof, in the form of screenshots. Put up or shut up!! :p

[madshi]

madVR v0.88.20 released

http://madshi.net/madVR.zip

* changed OSD rendering logic all over again
* added SuperRes "radius" option (only for testing purposes)
* removed SuperRes "use alternative color space" option
* replaced SuperRes strength+passes option with a new strength option
* added madTPG APIs "IsFseModeEnabled" and "En/DisableFseMode"
Since there have been a couple of users having problems with all kinds of weird stuttering issues, caused by the OSD rendering changes in v0.88.17, I've decided to change the OSD rendering logic all over again in this build. These are deep changes, once again, and might cause follow-up problems. So this might be another experimental build, introducing new bugs. On the other hand, I hope that at least some of those stuttering issues are resolved now?

Everyone who had *new* problems, introduced by v0.88.17, please test this new build and let me know if your problems are fixed.

Everyone who has "old" problems (which affect builds older than v0.88.17, too), please hold your horses for now. Allow me to fix all the new issues first, otherwise I'll get bugfix overload.